Сообщение Re[10]: [SQL Server] Анализ всех запросов к таблице от 25.07.2015 18:47
Изменено 27.07.2015 8:24 Somescout
Здравствуйте, Olaf, Вы писали:
O>Для того чтобы уменьшить фрагментированность индекса и снизить количество операций деления страниц при вставке, крайне рекомендуется для кластерного индекса построенного на типе данных uniqueidentifier в качестве ограничения по умолчанию использовать функцию NEWSEQUENTIALID(), генерирующую псевдопоследовательные уникальные значения.
Увы, над этим я не властен. Структура базы уже есть и определяется не мной.
O>Объективные признаки, используя например статистику накопленную сервером, для поиска лучшего кандидата на кластерный индекс будет найти не просто, но можно рассмотреть варианты. Кластерный индекс сам по себе покрывающий индекс, поэтому идеальным вариантом будет картина, на которой запрос указанный выше выдаёт максимум операций поиска (seeks), минимум операций сканирования (scans) и уточняющих запросов (lookups). Если кластерный индекс выбран неудачно, значит количество операций поиска будет сведено к минимуму, а преобладать будут операции сканирования и уточняющих запросов. Тогда необходимо обратить внимание на некластерный индекс с максимальным значением операций поиска, возможно именно он, не являясь покрывающим индексом, дает уточняющие запросы и является более подходящим кандидатом на роль кластерного индекса. Но это идеальная картина мира, некластерных индексов может быть много и все вместе они могут вносить свой вклад в количество дополнительных обращений к некластерному индексу. Придется выбирать лучший уже основываясь на целесообразности, общих рекомендациях ну и самом бизнес процессе.
O>Update:
O>Автор статьи Choosing the Best Clustered Index математически определяет лучших кандидатов на кластерный индекс. Основывается он на соотношении seek и lookup операций между кластерным и некластерным индексом. В целом можно рассмотреть в качестве подспорья.
Есть ещё один момент, который эта теория не учитывает — кластерный индекс в идеале должен монотонно возрастать. То есть если вставка и обновление индекса проводятся очень часто фрагментация и деление страниц съест всю пользу от наиболее оптимального с точки зрения запросов ключа (а дефрагментировать многогигабайтный индекс долго). По хорошему надо как-то отследить какие именно данные вставлялись в таблицу и из требуемых индексов выбрать тот, который будет монотонно изменяться. Альтернатива только задать fillfactor, но на кластерном индексе это автоматом снижает эффективность Index Lookups. Либо можно попробовать partition table, но я пока этого не пробовал делать, надо изучать.
Есть ещё filtered index, но я не совсем понимаю: если есть два таких индекса (key>x и key<=x — покрывающие вместе всю таблицу), оптимизатор задействует их если в запросе будет условие key>y, где y<x — т.е. попадающее в оба индекса?
O>Для того чтобы уменьшить фрагментированность индекса и снизить количество операций деления страниц при вставке, крайне рекомендуется для кластерного индекса построенного на типе данных uniqueidentifier в качестве ограничения по умолчанию использовать функцию NEWSEQUENTIALID(), генерирующую псевдопоследовательные уникальные значения.
Увы, над этим я не властен. Структура базы уже есть и определяется не мной.
O>Объективные признаки, используя например статистику накопленную сервером, для поиска лучшего кандидата на кластерный индекс будет найти не просто, но можно рассмотреть варианты. Кластерный индекс сам по себе покрывающий индекс, поэтому идеальным вариантом будет картина, на которой запрос указанный выше выдаёт максимум операций поиска (seeks), минимум операций сканирования (scans) и уточняющих запросов (lookups). Если кластерный индекс выбран неудачно, значит количество операций поиска будет сведено к минимуму, а преобладать будут операции сканирования и уточняющих запросов. Тогда необходимо обратить внимание на некластерный индекс с максимальным значением операций поиска, возможно именно он, не являясь покрывающим индексом, дает уточняющие запросы и является более подходящим кандидатом на роль кластерного индекса. Но это идеальная картина мира, некластерных индексов может быть много и все вместе они могут вносить свой вклад в количество дополнительных обращений к некластерному индексу. Придется выбирать лучший уже основываясь на целесообразности, общих рекомендациях ну и самом бизнес процессе.
O>Update:
O>Автор статьи Choosing the Best Clustered Index математически определяет лучших кандидатов на кластерный индекс. Основывается он на соотношении seek и lookup операций между кластерным и некластерным индексом. В целом можно рассмотреть в качестве подспорья.
Есть ещё один момент, который эта теория не учитывает — кластерный индекс в идеале должен монотонно возрастать. То есть если вставка и обновление индекса проводятся очень часто фрагментация и деление страниц съест всю пользу от наиболее оптимального с точки зрения запросов ключа (а дефрагментировать многогигабайтный индекс долго). По хорошему надо как-то отследить какие именно данные вставлялись в таблицу и из требуемых индексов выбрать тот, который будет монотонно изменяться. Альтернатива только задать fillfactor, но на кластерном индексе это автоматом снижает эффективность Index Lookups. Либо можно попробовать partition table, но я пока этого не пробовал делать, надо изучать.
Есть ещё filtered index, но я не совсем понимаю: если есть два таких индекса (key>x и key<=x — покрывающие вместе всю таблицу), оптимизатор задействует их если в запросе будет условие key>y, где y<x — т.е. попадающее в оба индекса?
Re[10]: [SQL Server] Анализ всех запросов к таблице
Здравствуйте, Olaf, Вы писали:
O>Для того чтобы уменьшить фрагментированность индекса и снизить количество операций деления страниц при вставке, крайне рекомендуется для кластерного индекса построенного на типе данных uniqueidentifier в качестве ограничения по умолчанию использовать функцию NEWSEQUENTIALID(), генерирующую псевдопоследовательные уникальные значения.
Увы, над этим я не властен. Структура базы уже есть и определяется не мной.
O>Объективные признаки, используя например статистику накопленную сервером, для поиска лучшего кандидата на кластерный индекс будет найти не просто, но можно рассмотреть варианты. Кластерный индекс сам по себе покрывающий индекс, поэтому идеальным вариантом будет картина, на которой запрос указанный выше выдаёт максимум операций поиска (seeks), минимум операций сканирования (scans) и уточняющих запросов (lookups). Если кластерный индекс выбран неудачно, значит количество операций поиска будет сведено к минимуму, а преобладать будут операции сканирования и уточняющих запросов. Тогда необходимо обратить внимание на некластерный индекс с максимальным значением операций поиска, возможно именно он, не являясь покрывающим индексом, дает уточняющие запросы и является более подходящим кандидатом на роль кластерного индекса. Но это идеальная картина мира, некластерных индексов может быть много и все вместе они могут вносить свой вклад в количество дополнительных обращений к некластерному индексу. Придется выбирать лучший уже основываясь на целесообразности, общих рекомендациях ну и самом бизнес процессе.
O>Update:
O>Автор статьи Choosing the Best Clustered Index математически определяет лучших кандидатов на кластерный индекс. Основывается он на соотношении seek и lookup операций между кластерным и некластерным индексом. В целом можно рассмотреть в качестве подспорья.
Есть ещё один момент, который эта теория не учитывает — кластерный индекс в идеале должен монотонно возрастать. Так как если вставка строк в таблицу и обновление индекса проводятся очень часто, фрагментация и деление страниц съест всю пользу от наиболее оптимального с точки зрения запросов ключа (а дефрагментировать многогигабайтный индекс долго). По хорошему надо как-то отследить какие именно данные вставлялись в таблицу и из требуемых индексов выбрать тот, который будет монотонно изменяться. Альтернатива только задать fillfactor, но на кластерном индексе это автоматом снижает эффективность Index Lookups. Либо можно попробовать partition table, но я пока этого не пробовал делать, надо изучать.
Есть ещё filtered index, но я не совсем понимаю: если есть два таких индекса (key>x и key<=x — покрывающие вместе всю таблицу), оптимизатор задействует их если в запросе будет условие key>y, где y<x — т.е. попадающее в оба индекса?
O>Для того чтобы уменьшить фрагментированность индекса и снизить количество операций деления страниц при вставке, крайне рекомендуется для кластерного индекса построенного на типе данных uniqueidentifier в качестве ограничения по умолчанию использовать функцию NEWSEQUENTIALID(), генерирующую псевдопоследовательные уникальные значения.
Увы, над этим я не властен. Структура базы уже есть и определяется не мной.
O>Объективные признаки, используя например статистику накопленную сервером, для поиска лучшего кандидата на кластерный индекс будет найти не просто, но можно рассмотреть варианты. Кластерный индекс сам по себе покрывающий индекс, поэтому идеальным вариантом будет картина, на которой запрос указанный выше выдаёт максимум операций поиска (seeks), минимум операций сканирования (scans) и уточняющих запросов (lookups). Если кластерный индекс выбран неудачно, значит количество операций поиска будет сведено к минимуму, а преобладать будут операции сканирования и уточняющих запросов. Тогда необходимо обратить внимание на некластерный индекс с максимальным значением операций поиска, возможно именно он, не являясь покрывающим индексом, дает уточняющие запросы и является более подходящим кандидатом на роль кластерного индекса. Но это идеальная картина мира, некластерных индексов может быть много и все вместе они могут вносить свой вклад в количество дополнительных обращений к некластерному индексу. Придется выбирать лучший уже основываясь на целесообразности, общих рекомендациях ну и самом бизнес процессе.
O>Update:
O>Автор статьи Choosing the Best Clustered Index математически определяет лучших кандидатов на кластерный индекс. Основывается он на соотношении seek и lookup операций между кластерным и некластерным индексом. В целом можно рассмотреть в качестве подспорья.
Есть ещё один момент, который эта теория не учитывает — кластерный индекс в идеале должен монотонно возрастать. Так как если вставка строк в таблицу и обновление индекса проводятся очень часто, фрагментация и деление страниц съест всю пользу от наиболее оптимального с точки зрения запросов ключа (а дефрагментировать многогигабайтный индекс долго). По хорошему надо как-то отследить какие именно данные вставлялись в таблицу и из требуемых индексов выбрать тот, который будет монотонно изменяться. Альтернатива только задать fillfactor, но на кластерном индексе это автоматом снижает эффективность Index Lookups. Либо можно попробовать partition table, но я пока этого не пробовал делать, надо изучать.
Есть ещё filtered index, но я не совсем понимаю: если есть два таких индекса (key>x и key<=x — покрывающие вместе всю таблицу), оптимизатор задействует их если в запросе будет условие key>y, где y<x — т.е. попадающее в оба индекса?