Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
Гавриленко Сергей Алексеевич, Вы наверное очень удивитесь, но если ... Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. Разница в наших показаниях заключается в том что при использовании индекса №1 сервер использует статистики индекса №2. В вашем случае для построения статистики по полю "b" был сделан FULLSCAN и значение "Х" попало в статистики. Получается что-б ваш пример работал, вы должны иметь индексы по ВСЕМ полям, либо делать апдейт статистик с опцией FULLSCAN. Но даже в вашем случае если вы запустите запрос БЕЗ указания индекса, то сервер выберет индекс №2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2018, 04:32 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
Mind, Вообще-то планы разные, так как индекс по полю А "не видит" реального распределения значений по полю "Б" если по полю "Б" нет полной статистики. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2018, 04:38 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
invmКасаемого вашего теста У меня получился такой-же результат как и у вас, когда я запустил тест в tempdb. Обнаружилась интересная закономерность. В tempdb статистика по полю "b" включает значение "X", а в пользовательской базе нет. В этом и есть разница в IO. Если надо, могу дать скриншоты статистик, хотя я уже и давал скриншоты разных планов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2018, 04:51 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
SandalTreeОбнаружилась интересная закономерность. В tempdb статистика по полю "b" включает значение "X", а в пользовательской базе нет.Вы опять фантазируете. Статистика по (a,b) не может содержать распределение по b, ибо гистограмма хранится только для первого столбца. В любой БД. Соответственно, статистика по (b,a) будет содержать такое распределение. Опять же в любой БД. SandalTreeЕсли надо, могу дать скриншоты статистик, хотя я уже и давал скриншоты разных планов.Ваши картинки мало кому интересны в качестве доказательств. Репро давайте, подтверждающее ваши слова. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2018, 10:10 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
Mindinvmпропущено... Попробуйте поразмышлять почему рекомендовано именно так.Если честно я вообще не понимаю что именно они рекомендуют. Какие еще варианты могут быть запихать колонку в WHERE кроме как = > < или BETWEEN ? С функциями что-ли? Additional columns это что? Все те что кроме first? Или те что все еще в WHERE но непонятно с какими условиями поиска или те что даже не в WHERE? А зачем они вообще в индексе нужны? А какая тогда разница на их distinctness? И вообще получается что только начиная со второй колонки есть смысл в каком порядке запихивать в индекс, а первую как выбрать если там несколько в WHERE? Или они хотели сказать "Additionally, columns...". Такое ощущение что эти рекомендации переводили индусы основываясь на доисторических свитках Sybase. like ? ================== PS Как вариант like 'АБэЦэ...%' (в идеале должен быть seek вместо scan).... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2018, 14:35 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
SandalTreeВообще-то планы разные, так как индекс по полю А "не видит"При чем тут индекс "видит", "не видит"? Чушь какую то развели. Оптимизатор решает на основании статистики. Статистики могут быть как привязанные к индексу так и отдельно. И те и другие статистики могут создаваться/обновляться с FULLSCAN и без. Исключение составляет лишь создание/ребилд индекса потому что в этом случае статистика обновляется с FULLSCAN автоматически. SandalTreeреального распределения значений по полю "Б" если по полю "Б" нет полной статистики. Так при чем тут индекс то, если все дело в статистике? А особенно при чем тут селективность полей? SandalTreeЕсли надо, могу дать скриншоты статистик, хотя я уже и давал скриншоты разных планов.Все ваши тесты доказывают лишь то что при потере всех конечностей таракан теряет слух. Связи между селективностью и тем какой индекс сервер выбирает никакой, потому что решение оптимизатора в данном случае целиком и полностью зависит от того насколько дерьмовую статистику вы ему подсовываете. SandalTreeВы наверное очень удивитесь, но если ...Удивляетесь здесь по-моему только вы... Готовы? Если в ваш пример добавить селективности по полю A Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. то сервер все равно продолжит выбирать индекс (b,a)! SandalTreeПостройте 2 разных индекса и посмотрите что сервер предпочтёт тот по которуму выше селективность в первой колонке. О ужас! Ваша псевдо-теория развалилась. Можно построить оба индекса одновременно, чтобы исключить безлапых тараканов неполноценную статистику из нашего эксперимента. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2018, 00:48 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
MindSandalTreeВообще-то планы разные, так как индекс по полю А "не видит"При чем тут индекс "видит", "не видит"? Чушь какую то развели. Оптимизатор решает на основании статистики. Статистики могут быть как привязанные к индексу так и отдельно. И те и другие статистики могут создаваться/обновляться с FULLSCAN и без. Исключение составляет лишь создание/ребилд индекса потому что в этом случае статистика обновляется с FULLSCAN автоматически. SandalTreeреального распределения значений по полю "Б" если по полю "Б" нет полной статистики. Так при чем тут индекс то, если все дело в статистике? А особенно при чем тут селективность полей? SandalTreeЕсли надо, могу дать скриншоты статистик, хотя я уже и давал скриншоты разных планов.Все ваши тесты доказывают лишь то что при потере всех конечностей таракан теряет слух. Связи между селективностью и тем какой индекс сервер выбирает никакой, потому что решение оптимизатора в данном случае целиком и полностью зависит от того насколько дерьмовую статистику вы ему подсовываете. SandalTreeВы наверное очень удивитесь, но если ...Удивляетесь здесь по-моему только вы... Готовы? Если в ваш пример добавить селективности по полю A Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. то сервер все равно продолжит выбирать индекс (b,a)! SandalTreeПостройте 2 разных индекса и посмотрите что сервер предпочтёт тот по которуму выше селективность в первой колонке. О ужас! Ваша псевдо-теория развалилась. Можно построить оба индекса одновременно, чтобы исключить безлапых тараканов неполноценную статистику из нашего эксперимента. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Код: plaintext 1. чуть меняем условие : set statistics profile on; go SELECT a, b FROM testindex WHERE a =5 and b ! = 'X' go set statistics profile off; go Получаем картину: StmtText: Код: sql 1. при Argument: Код: sql 1. Выбор в пользу другого индекса при НЕочевидном (для меня, по крайней мере) преобразовании... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2018, 14:10 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
PS Вообще, вы куда-то слишком в дебри углубились... PPS Мне так кажется.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2018, 14:18 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
SIMPLicity_, Да какие уж там дебри, все крутится (в основном) вокруг статистики. Из которой тут упоминали только селективность (selectivity), хотя в статистике присутствуют плотность (density), мощьность (cardinality) и гистограмма (histogram). Которые SQL так же использует для оценок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2018, 18:13 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
invmSandalTreeОбнаружилась интересная закономерность. В tempdb статистика по полю "b" включает значение "X", а в пользовательской базе нет.Вы опять фантазируете. Статистика по (a,b) не может содержать распределение по b, ибо гистограмма хранится только для первого столбца. В любой БД. Соответственно, статистика по (b,a) будет содержать такое распределение. Опять же в любой БД. SandalTreeЕсли надо, могу дать скриншоты статистик, хотя я уже и давал скриншоты разных планов.Ваши картинки мало кому интересны в качестве доказательств. Репро давайте, подтверждающее ваши слова. Во первых: есть 2 статистики по обоим полям и когда скуль строит план, то он смотрит на обе. (закрыли этот вопрос?) Во вторых: при запуске одного и того-же кода в разных базах происходит различная обработка алгоритма выборки сэмла. В одной базе последняя страница входит в сэмпл, а в другой нет, от этого различные статистики и планы. (какого рода репо вам предоставить? Потестируйте в разных базах и посмотрите на сэмплы и статистики.) В третьих: При двух индексах a-b и b-a скуль почему-то выбирает второй индекс. Сможете ответить на вопрос "почему?"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 06:02 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
Mindдивляетесь здесь по-моему только вы... Готовы? Если в ваш пример добавить селективности по полю A то сервер все равно продолжит выбирать индекс (b,a)! Да, вы правы. В случае выбора между двумя этими индексами скуль не видит разницы так как планы у них с одинаковой стоимостью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 07:33 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
SandalTreeВо первых: есть 2 статистики по обоим полям и когда скуль строит план, то он смотрит на обе. (закрыли этот вопрос?)Еще раз - для уровня оптимизации TRIVIAL статистика не используется для выбора плана. Только для оценки количества строк. SandalTreeВо вторых: при запуске одного и того-же кода в разных базах происходит различная обработка алгоритма выборки сэмла. В одной базе последняя страница входит в сэмпл, а в другой нет, от этого различные статистики и планы.Да? Вам был даден пример, из которого понятно из-за чего планы разные. Может для вас станет понятнее, когда отключите автосоздание статистики. Но вы продолжаете фантазировать... Особо порадовала зависимость IO запроса от статистики... SandalTreeВ третьих: При двух индексах a-b и b-a скуль почему-то выбирает второй индекс. Сможете ответить на вопрос "почему?"?Неужто из-за селективности? Попробуйте поменять порядок создания индексов. Ну и напоследок вопрос - каким образом для индексов (a, b) и (b, a), при предикате a = ... and b = ..., селективность столбцов индекса будет влиять на операцию поиска в нем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 13:43 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
invmSandalTreeВо вторых: при запуске одного и того-же кода в разных базах происходит различная обработка алгоритма выборки сэмла. В одной базе последняя страница входит в сэмпл, а в другой нет, от этого различные статистики и планы.Да? Вам был даден пример, из которого понятно из-за чего планы разные. Может для вас станет понятнее, когда отключите автосоздание статистики. Вы мне не верите, но сами проверить не желаете. Вот вам скриншот. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 17:34 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
invm, Разница в IO обусловлена тем что статистики не захватили FULLSAMPLE. Прочитано только 7% всех записей и значения с последней страницы остались неучтёнными. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 17:39 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
invm, Как только мы перестроим статистики с полным сканированием то получим результат, который нам продемонстрировал Сергей Гавриленко. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 17:44 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
Откуда появляется четвертое логическое чтение -- не понятно. (Не факт, что оно есть на самом деле и не врет statistics io.) Опять же, если выключить автосоздание статистик на базе, то чтений будет 4 в обоих вариантах, а если индекс прибить руками, то 3 в обоих вариантах. Однако при глубине индекса в три уровня, четвертое чтение не может быть из дерева индекса -- в индексе просто читать больше нечего. Короче, тут не в структуре индекса дело, а в каких-то сайд-эффектах от статистики. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 17:47 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
SandalTreeВы мне не верите, но сами проверить не желаете. Вот вам скриншот.Зачем мне ваш скриншот? В моем примере ровно то же самое. Видимо вы так не удосожились хотя бы его результаты посмотреть. SandalTreeРазница в IO обусловлена тем что статистики не захватили FULLSAMPLE. Прочитано только 7% всех записей и значения с последней страницы остались неучтёнными.И каким же образом "неучтенность значений" при компиляции повлияла на статистику IO при выполнении? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 17:57 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
Гавриленко Сергей АлексеевичОпять же, если выключить автосоздание статистик на базе, то чтений будет 4 в обоих вариантах, а если индекс прибить руками, то 3 в обоих вариантах.А если обновить все статистики с FULLSCAN, то тоже становится 3 чтения вместо 4х. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 21:12 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
Тайна 4-й страницы Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. С fullscan objectfile_idpage_idindex_idpage_type_descsysobjvalues1431INDEX_PAGEsysobjvalues11281DATA_PAGEsysobjvalues11321DATA_PAGEsyssingleobjrefs1971DATA_PAGEtestindex12904INDEX_PAGEtestindex1380974INDEX_PAGEtestindex1412504INDEX_PAGE Без fullscan objectfile_idpage_idindex_idpage_type_desc sysmultiobjrefs 11052INDEX_PAGEsysobjvalues1431INDEX_PAGEsysobjvalues11281DATA_PAGEsysobjvalues11811DATA_PAGEsyssingleobjrefs1971DATA_PAGEtestindex12904INDEX_PAGEtestindex1380974INDEX_PAGEtestindex1412504INDEX_PAGE Осталось понять какого лешего это попадает в статистику IO. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 21:23 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
В предыдущем примере накосячено. Исправлено Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. С fullscan file_idpage_idindex_idpage_type_desc12904INDEX_PAGE1380974INDEX_PAGE1412504INDEX_PAGE Без fullscan file_idpage_idindex_idpage_type_desc12904INDEX_PAGE1380974INDEX_PAGE1380974INDEX_PAGE1412504INDEX_PAGE ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 22:35 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
invm, Ну и зачем оно 2 раза читает нижнюю страничку индекса? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2018, 23:25 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
Mind, Вот нашёл более приближённый пример того что индекс с большей селективностью лучше работает: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. авторTable 'testindex2'. Scan count 1, logical reads 204, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'testindex2'. Scan count 1, logical reads 1035, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Распределение данных надумано и не реалистично, но это просто пример селективности. В реальной жизни скорее всего могут быть более серьёзные случаи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2018, 03:36 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
SandalTree, Ясен пень, что здесь будут разные seek-предикаты, в отличие от запроса с равенством. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2018, 10:18 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
SandalTreeНу и зачем оно 2 раза читает нижнюю страничку индекса?Нижнюю? Уверены? :) А зачем - это вам объяснять. Это же ваша теория "О влиянии неучтенных значений в статистике на количество чтений во время выполнения запроса при идентичных планах выполнения". SandalTreeВот нашёл более приближённый пример того что индекс с большей селективностью лучше работаетЛед тронулся. Не хотите переформулировать ваше "общее правило"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2018, 11:11 |
|
||
|
Перекрестные индексы. Как лучше?
|
|||
|---|---|---|---|
|
#18+
SandalTreeMind, Вот нашёл более приближённый пример того что индекс с большей селективностью лучше работает: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. авторTable 'testindex2'. Scan count 1, logical reads 204, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'testindex2'. Scan count 1, logical reads 1035, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Распределение данных надумано и не реалистично, но это просто пример селективности. В реальной жизни скорее всего могут быть более серьёзные случаи. Ваше различие в чтениях вызвано не селективностью индекса, а количеством записей, попадающим в диапазон between по одному и по второму полю вот вам чуть измененных скрипт, в котором я просто "размазал" значение поля i, домножив его на 100, но не менял селективность ни одного из полей, и получил противоположный вашему результат Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. STATISTICS IOTable 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'testindex2'. Scan count 1, logical reads 58 , physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. (0 rows affected) Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'testindex2'. Scan count 1, logical reads 5 , physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2018, 13:58 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39717287&tid=1688955]: |
0ms |
get settings: |
9ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
71ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 257ms |
| total: | 401ms |

| 0 / 0 |
