|
|
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#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. Он возвращает 275 записей и выполняется несколько секунд: от 2 до 10 в зависимости от текущей нагрузки на сервер. Если убрать в конце "ORDER BY BE.ACTIVE_FROM desc" то время выполнения падает до нескольких десятых секунд. Поле "ACTIVE_FROM" имеет тип DateTime, индекса нет. Вопросы: Это нормально, то 275 записей сортируются так долго? Он же должен только итоговый набор сортировать? Могут ли влиять какие-то параметры сервера MySQL на время сортировки? Исправит ли ситуацию добавление индекса? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2016, 16:35 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
udp забыл добавить, что если сделать сортировку по полю iblock_id, значение которого для всех записей одинаково и равняется 15, то запрос тоже проходит быстро. Т.е. ощущение, что протормаживает само изменение порядка записей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2016, 16:51 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
YurikGLощущение, что протормаживает само изменение порядка записей.При сортировке записи в памяти не перемещаются, изменения затрагивают только массив ссылок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2016, 16:55 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
Akina, знаю... Оттого оно и странно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2016, 17:38 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
AkinaYurikGLощущение, что протормаживает само изменение порядка записей.При сортировке записи в памяти не перемещаются, изменения затрагивают только массив ссылок.С большой долей вероятности сортировка сваливается на диск, а туда перемещается всё. Поле BE.DETAIL_TEXT имеет тип longtext. Насколько я помню, это автоматически приводит к filesort-у. Хотя найти этот момент в доке не получилось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2016, 18:38 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
Да и план может быть в принципе разный с сортировкой и без. YurikGL, покажите планы обоих вариантов запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2016, 18:39 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
miksoftПоле BE.DETAIL_TEXT имеет тип longtext. Насколько я помню, это автоматически приводит к filesort-у. Хотя найти этот момент в доке не получилось. а как иначе? индекс может быть только префиксным, а сортировка по всему полю. однозначно filesort вопрос в том, где он происходит: в памяти или на диске? это можно узнать через show status (sort_merge_passes) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2016, 19:16 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
Sort_merge_passes = 16тысяч Срочно увеличивать innodb_sort_buffer_size ? У меня 2 мбайта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2016, 20:56 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
YurikGL, сделай запрос без сортировки вложенным, и результат сортируй ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 05:58 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
Итак 1) Выполнение тормозящего запроса с сортировкой не увеличивает Sort_merge_passes 2) Sort_buffer_size 8 мбайт 3) План запроса с order by (выполняется долго) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 4) План запроса без order by(выполняется быстро) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 4) авторсделай запрос без сортировки вложенным, и результат сортируй запрос CMS формирует. з.ы. правильно я понимаю, что по BE.ACTIVE_FRO имеет смысл индекс построить? Его сейчас нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 09:22 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
YurikGLз.ы. правильно я понимаю, что по BE.ACTIVE_FRO имеет смысл индекс построить? Его сейчас нет. сделал ORDER BY BE.ID desc (по проиндексированному полю) - результат такой же как по непроиндексированному. Медленно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 09:27 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
. Вопросы: Это нормально, то 275 записей сортируются так долго? дело не в этом, а в том, что у запросов разные планы выполнения. Он же должен только итоговый набор сортировать? нет. может быть по-разному. Могут ли влиять какие-то параметры сервера MySQL на время сортировки? дело не в сортировке. Исправит ли ситуацию добавление индекса? может, вопрос - какой индекс нужно добавить. я запрос не читал, сказать не смогу. сделай планы для обоих вариантов запросов, покажи. параметры надо зафиксировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 11:12 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
YurikGL, таки немного разобрал запрос, подходе в нем нет SARGов вообще, берется класс, по ид классе, и все его интересы протряхиваются предмет успешности трех под запросов, введенных через exists. запрос таким образом почти не имеет шансов на успех. ну и чтобы его выкручивать, нужно знать из структуру и раскладку по данным. лучше всего обратиться в поддержку того модуля битрикс, откуда запрос, пусть сами трахаются, если понаписали... это полезно, им - чтобы знать о проблемах и чтобы в следующий раз думать, тебе - чтобы не иметь проблем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 11:26 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
YurikGL, да, еще, если это используется редко, раз в неделю, скажем, то оставь как есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 11:27 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
авторОн же должен только итоговый набор сортировать? нет. может быть по-разному. А можно с этого места поподробнее? з.ы. индексы добавил - не помогло. Смущает "Using temporary; Using filesort" на сортировку. Если сортировать по BE.ACTIVE_FROM оно вылазит. Если по BE.ID (первичный ключ) то тоже вылазит. А вот если делать order by iblock_id (у него во всей выборке одинаковые значения) то "Using temporary; Using filesort" не наблюдается и запрос проходит мгновенно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 11:56 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#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. очень не нравится INNER JOIN b_iblock_element_prop_s15 FPS0 ON FPS0.IBLOCK_ELEMENT_ID = BE.ID Выдает что тип All и в сортировке при этом Using temporary; Using filesort Если в этом же запросе убрать две отмеченные строчки (фактически, эту связку), то все сразу становится очень хорошо и быстро. Проверил этот план запроса на почти пустой битрисовой базе. Исходный план нормальный т.е. один и тот же запрос на примерно одинаковых базах выдает разные планы. FPS0.IBLOCK_ELEMENT_ID и BE.ID - первичные ключи. Что не нравится в этой связке не совсем понятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 13:50 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
Упростил до предела. Код: sql 1. 2. 3. 4. b_iblock_element_prop_s15.IBLOCK_ELEMENT_ID - первичный ключ b_iblock_element.ID - первичный ключ План говорит, что type='ALL' All – Для нахождения соответствующих строк используются сканирование всей таблицы. Это наихудший тип соединения и обычно указывает на отсутствие подходящих индексов в таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 14:54 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
retvizanmiksoftПоле BE.DETAIL_TEXT имеет тип longtext. Насколько я помню, это автоматически приводит к filesort-у. Хотя найти этот момент в доке не получилось. а как иначе? индекс может быть только префиксным, а сортировка по всему полю. однозначно filesort вопрос в том, где он происходит: в памяти или на диске? это можно узнать через show status (sort_merge_passes)Так сортировка не по этому полю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 15:14 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
Ну и совсем не понимаю Запрос Код: sql 1. 2. 3. 4. использует индекс Запрос Код: sql 1. 2. 3. 4. не использует индекс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 15:25 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
YurikGL, в первом случае нужно прочитать все строки, но только 1 столбец, который индексирован т.е. можно не трогать сами данные, а читать только индекс ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 15:35 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
retvizanYurikGL, в первом случае нужно прочитать все строки, но только 1 столбец, который индексирован т.е. можно не трогать сами данные, а читать только индекс Код: sql 1. 2. 3. 4. Однако вышеуказанный план замечательно использует индекс. Есть подозрение, что в b_iblock_element_prop_s15 что-то не так с индексом первичного ключа. Или из-за каких то особенностей данных не хочет использовать индекс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 15:49 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
miksoftТак сортировка не по этому полю.сорри, проглядел тогда - это не приводит автоматически к filesort-у но если выбран filesort, то он будет двухпроходным MySQL. Оптимизация производительности, 2-е изданиеЭтот алгоритм задействован и тогда, когда хотя бы один из запрошенных столбцов – пусть даже он не встречается в ORDER BY – имеет тип BLOB или TEXT. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 16:03 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
YurikGLНу и совсем не понимаю я не думаю, что тебе нужно вообще пытаться тут что-то понять , запрос сложный, структура сложная, вероятность что ты тут что-то поймешь стремится к нулю. ок, даже допустим ты что-то понял, запрос генерируется, и максимум, что ты можешь сделать, это создать индекс, но условия сортировки разные, наверное, и подо всё индекса не создашь, Так что вообще бессмысленно. тем более, еще раз повторяю, проблема не в сортировке вообще, а в том, что с горя mySQL пытается в разных случаях использовать разные планы, которые тем не менее все плохие. что запрос иногда работает быстро - ну, иногда угадывает. да еще, analyse table для всех таблиц сделай на всякий, вдруг не делали... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 22:13 |
|
||
|
Долгая сортировка в запросе.
|
|||
|---|---|---|---|
|
#18+
MasterZiv, Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 22:24 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39343250&tid=1831231]: |
0ms |
get settings: |
9ms |
get forum list: |
22ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
183ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
| others: | 240ms |
| total: | 534ms |

| 0 / 0 |
