Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Добрый день, Есть такой запрос: Код: sql 1. 2. pkey в данном случае ключ по которому таблица партицированна. Всего партиций 15000. Если запустить подобный запрос на не партицированной таблице: Код: sql 1. 2. То время исполнения (из Джава приложения) в два-три раза ниже: 170ms вместо 400-500. Но при этом у первого запроса в реальном плане исполнения Estimated subtree cost = 0.073 а у вторго 0.1366 Почему более низкая стоимость запроса не транслируется в более короткое время исполнения? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2019, 11:20 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Roust_mПочему более низкая стоимость запроса не транслируется в более короткое время исполнения? потому что стоимость плана это не время исполнения. Не говоря уже, что это Estimated Покажите планы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2019, 11:43 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Roust_m, вы смотрите на предполагаемый план, смотрите на фактический. Сравните, например, объем просмотренных данных в том и ином случае. Например, для второй таблицы есть индекс по ID и вы получите seek, а в первой таблице индекса нет и получите просмотр секции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2019, 11:44 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Вот план по партицированной таблице. Ниже добавлю второй план по непартицированной По идее вся суть партицирования это зверски улучшить скорость чтения когда ты знаешь в какой партиции ищещь. А получается наоборот, улучшение в непартицированной таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2019, 02:41 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Вот непартицированная таблица ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2019, 02:41 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Roust_mПо идее вся суть партицирования это зверски улучшить скорость чтения когда ты знаешь в какой партиции ищещьТот евангелист, который вам это в уши напел, вас злостно обманул. Index seek по индексу даже с невероятной глубиной в 8-9 уровней уделает любой скан по партиции, если нет нормального seek predicate после elimination. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2019, 02:46 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Модератор: Короче, уважаемый Roust_m. Давайте так. Или вы предоставляете скрипты ваших таблиц, ваши запросы и нормальные планы (обфусцируйте уж как-нибудь), или я к вам за троллинг санкции применю. А то вот сначала эти эпатажные вбросы в двух топиках, что секционирование вам все замедлило, а потом выясняется, что всего лишь у разных ваших запросов к разным вашим таблицам разный план. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2019, 02:54 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Модератор: Еще раз русскими буквами: скрипты таблиц с индексами (в текстовом виде), запросы к этим таблицам (в текстовом виде), планы этих запросов (в текстовом виде или в виде sqlplan-файлов). Cкриншоты будут стираться на месте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2019, 03:15 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Вот скрипт партицированной таблицы. Там 15000 партиций. Ключ pkey есть функция от st_id: st_id % 14999 + 1 Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2019, 03:25 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2019, 03:33 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
У вас вторые некластерные индексы UX_mypartitionedtable / UX_my_not_partitionedtable вообще не идентичны если убрать ключ секционирования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2019, 03:35 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Вот запрос в партицированной таблице: Код: sql 1. А это к непратицированной: Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2019, 03:37 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Удивительно, что хоть где-то index seek... Чтобы было быстро выбирать все поля по sid, надо сделать индекс по (sid) include (все остальные поля, кроме ключей кластерного индекса). А секционирование уберите. В вашем случае оно разве что могло бы быть похоже на борьбу с latch contention, которого, скорее всего, у вас и в помине нет. Рано еще оно вам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2019, 03:43 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Гавриленко Сергей АлексеевичУ вас вторые некластерные индексы UX_mypartitionedtable / UX_my_not_partitionedtable вообще не идентичны если убрать ключ секционирования. Хоть этот индекс и не используется, исправил, теперь непратицированная таблица выглядит так. (ниже). Непратицированная таблица по прежнему гораздо быстрее по времени. Щас зашишрую немного имена объектов и выложу планы. Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2019, 03:56 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Гавриленко Сергей АлексеевичУдивительно, что хоть где-то index seek... Чтобы было быстро выбирать все поля по sid, надо сделать индекс по (sid) include (все остальные поля, кроме ключей кластерного индекса). А секционирование уберите. В вашем случае оно разве что могло бы быть похоже на борьбу с latch contention, которого, скорее всего, у вас и в помине нет. Рано еще оно вам. Предполагалось, что таблица будет зверски расти и число одновременных пользователей тоже будет сильно расти. База в стадии дизайна, какие запросы будут к ней до конца неизвестно. Большая часть запросов герерится Джавой (там есть какая-то автоматическая приблуда для этого). В редких случаях, когда совсем никак эти запросы выносятся в хранимую процедуру, остальное автоматом, чтобы ускорить время разработки. Повлиять я на это не могу. Еще один момент, который учитывался при решении применить секционирование, это то, что большинство запросов используют st_id или он известен. Поскольку диапазон st_id около миллиона, то, создали pkey, который есть остаток от деления st_id на 14999 плюс 1. То есть предполагалось, что все данные для одного и того-же студента будут в одной партиции. На данный момент в партиции с pkey=13707 всего 353 записи, из которых выбирается 31 запись. В непартицированной таблице 5843430 записей, из которых выбирается 52. Я не понимаю, почему выбрать 31 запись из 353 занимает больше времени, чем выбрать 52 записи из почти 6-ти миллионов. Я теряю веру в технологический прогресс и вообще во все человечество. Решение убрать секционирование не очень простое, ибо это может затронуть другие запросы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2019, 04:16 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Гавриленко Сергей АлексеевичУдивительно, что хоть где-то index seek... Чтобы было быстро выбирать все поля по sid, надо сделать индекс по (sid) include (все остальные поля, кроме ключей кластерного индекса). Разные запросы будут использовать разные поля, то есть придется создать индекс по sid и включить туда почти все поля в таблице. Если следовать этому подходу и для других запросов, то размер индексов будет огромен, что замедлит вставку данных в таблицу а также изменение данных. Палка о двух конца. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2019, 04:40 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Вот зашифрованный план по партицированной таблице. Очень желательно найти способ сделать так, чтобы это работало быстро на партицированной таблице. Убирать партицирование будет означать проблемы в других местах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2019, 04:56 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовRoust_m, вы смотрите на предполагаемый план, смотрите на фактический. Сравните, например, объем просмотренных данных в том и ином случае. Например, для второй таблицы есть индекс по ID и вы получите seek, а в первой таблице индекса нет и получите просмотр секции. В обеих таблицах есть индекс по ID (sid), в партицированной таблице он тоже партицирован, однако же в партицированной таблице такой индекс не используется и происходит скан по кластерному индексу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2019, 05:18 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Roust_m Большая часть запросов герерится Джавой (там есть какая-то автоматическая приблуда для этого). В редких случаях, когда совсем никак эти запросы выносятся в хранимую процедуру, остальное автоматом, чтобы ускорить время разработки. Повлиять я на это не могу. как это знакомо, а вот теперь огребаем по полной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2019, 05:53 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Roust_m, партиционирование это в основном для удобства обслуживания, а не для ускорения запросов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2019, 09:49 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Roust_m, у вас на плане просмотр секционированной таблицы и поиск в индексе по несекционированной. Отсюда и разница. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2019, 11:27 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Roust_m, сканирование может происходить в результате несоблюдения приоритета типов или самих типов передаваемого в запрос параметра и аргумента функции секционирования. И да, секционирование не всегда имеет смысл создавать для сокращения времени запросов. Нельзя утверждать, что оно предназначено именно для обслуживания, его назначение MS как раз и определяет как "средство, позволяющее ускорить выполнения запросов при больших размерах таблиц" в учебных курсах, например. Однако, они не рассматривают подробно сценарии, применимые для таких практик, поэтому возникает ощущение, что так следует делать всегда на любых больших таблицах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2019, 11:36 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Roust_mВот зашифрованный план по партицированной таблицеПокажите план для Код: sql 1. 2. 3. ЗЫ: Анонимайзер планов есть в SentryOne Plan Explorer ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2019, 14:00 |
|
||
|
Запрос к партицированной таблице и к обычной таблице
|
|||
|---|---|---|---|
|
#18+
Roust_mЯ не понимаю, почему выбрать 31 запись из 353 занимает больше времени, чем выбрать 52 записи из почти 6-ти миллионов. Я теряю веру в технологический прогресс и вообще во все человечество. В управдомы вам, батенька, надо переквалифицироваться. Иначе бы знали, что выборка по уникальному индексу из индексированной таблицы от размеров таблицы, практически, не зависит. Или другими словами: бесполезно ожидать ускорения выборки от партиционирования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2019, 15:57 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39871418&tid=1687154]: |
0ms |
get settings: |
8ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
37ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
87ms |
get tp. blocked users: |
2ms |
| others: | 221ms |
| total: | 396ms |

| 0 / 0 |
