Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#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. План запроса печальный (во вложении). Периодически отваливается по таймауту (запрос вызывается из Java кода): Код: java 1. 2. Движок NDB. Возможно ли как-то оптимизировать данный запрос? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2018, 13:16 |
|
||
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#18+
sergey-iv3, В запросе точно нужны именно UNION, а не UNION ALL ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2018, 13:50 |
|
||
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#18+
Ну и тотальное отсутствие индексов выглядит странно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2018, 14:04 |
|
||
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#18+
miksoft, miksoftВ запросе точно нужны именно UNION, а не UNION ALL ? Это сильно может повлиять на производительность? miksoftНу и тотальное отсутствие индексов выглядит странно. Согласен, только не пойму на какие поля их надо навесить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2018, 14:16 |
|
||
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#18+
miksoft В запросе точно нужны именно UNION, а не UNION ALL ? UNION ALL оставляет дубликаты ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2018, 14:38 |
|
||
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#18+
sergey-iv3miksoftВ запросе точно нужны именно UNION, а не UNION ALL ? UNION ALL оставляет дубликатыОставлять-то оставляет. Но есть ли они по факту? И мешают ли они, если есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2018, 15:07 |
|
||
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#18+
Опишите вообще словами полностью смысл этого запроса. У меня есть ощущение, что его можно переписать намного короче и быстрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2018, 15:14 |
|
||
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#18+
miksoftsergey-iv3пропущено... UNION ALL оставляет дубликатыОставлять-то оставляет. Но есть ли они по факту? И мешают ли они, если есть? По факту они есть. Если использовать просто UNION, то такой запрос: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. вернет 13834 записи. Тогда как UNION ALL возвращает 28870. Они мешают, т.к. они попадут в результирующую выборку (SELECT tsc.Id, min(spc.sDate) ...). Словами описать не смогу, т.к. сам писал его не я, а досталось наследство, с задачей, устранить ошибку с таймаутом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2018, 15:32 |
|
||
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#18+
sergey-iv3вернет 13834 записи. Тогда как UNION ALL возвращает 28870. Они мешают, т.к. они попадут в результирующую выборку (SELECT tsc.Id, min(spc.sDate) ...).Как же они попадут, если в результирующей выборке группировка? Попробуйте, результат всего запроса меняется, если заменить UNION на UNION ALL ? Насчет индексов - попробуйте индекс на таблице DICT.Price из поля PriceChangeId. После создания индекса сделайте OPTIMIZE TABLE DICT.Price ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2018, 15:43 |
|
||
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#18+
miksoftsergey-iv3вернет 13834 записи. Тогда как UNION ALL возвращает 28870. Они мешают, т.к. они попадут в результирующую выборку (SELECT tsc.Id, min(spc.sDate) ...).Как же они попадут, если в результирующей выборке группировка? Попробуйте, результат всего запроса меняется, если заменить UNION на UNION ALL ? Нет, результат не поменялся. Только сейчас я тестирую на другой базе, где меньше данных. miksoftНасчет индексов - попробуйте индекс на таблице DICT.Price из поля PriceChangeId. После создания индекса сделайте OPTIMIZE TABLE DICT.Price Добавил индекс: Код: sql 1. План запроса такой. Тестирую на другой базе с такой же структурой. Не понятно, почему он отличается от первоначального: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2018, 17:22 |
|
||
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#18+
В том посте случайно выложил старый план. Вот после добавления индекса: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2018, 17:22 |
|
||
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#18+
sergey-iv3Вот после добавления индекса:А как время выполнения запроса изменилось? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2018, 17:34 |
|
||
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#18+
miksoftsergey-iv3Вот после добавления индекса:А как время выполнения запроса изменилось? По факту нет, без индекса и с union отработал за 17.83, с индексом и union all за 17.37 в тестовой таблице TEST.`Services` tsc - 9076 записей, в реале 2 млн. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2018, 18:21 |
|
||
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#18+
miksoft, и почему-то после добавления индекса, в плане type все равно остался ALL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2018, 18:23 |
|
||
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#18+
sergey-iv3Словами описать не смогу, т.к. сам писал его не я, а досталось наследство, с задачей, устранить ошибку с таймаутом. Дружище. Послушай совет. Я не разбираюсь в MySQL. Я по другой части. Но ты не можешь "устранять ошибку" (а если быть точным то это не ошибка а performance issue) без понимания задачи с точки зрения бизнеса. Механическая оптимизация может привести к другим последствиям. Например отчот выдаст неверные данные. Более того.. он может выдать верные данные сейчас. Но это не будет формальным доказательством его правоты вообще. Может быть баг на других исходных. Смотри у тебя 3 справочника Price, Plan, Service соединяются сложным образом чтобы получить Id-шники и минимальные даты. Подумай в чем их бизнес-смысл. Найти самую неэффективную выборку. У тебя есть как минимум 3 независимых под-запроса. Какой из них самый медленный? Определи и займись только им. По топику тебе дали совет построить инексы. Построй по всем ключам где есть соединение. Как минимум primary и foreign должны быть всегда. Фильтр по справочнику цен PriceChangeId > ? у тебя повторяется трижды. Материализуй его результат. Ну и сделай UNION ALL как советуют. Попробуй. У тебя получится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2018, 18:32 |
|
||
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#18+
sergey-iv3в тестовой таблице TEST.`Services` tsc - 9076 записей, в реале 2 млн.Так не получится. Применение индексов сильно зависит от статистики данных. Приводите тестовые данные в соответствие с реальными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2018, 19:21 |
|
||
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#18+
sergey-iv3miksoft, и почему-то после добавления индекса, в плане type все равно остался ALLДа, а колонка KEY пуста, значит индекс не применяется. Сколько записей в таблице DICT.Price и сколько из них выбирает условие sp.PriceChangeId > ? Что подставляется вместо знака вопроса? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2018, 19:24 |
|
||
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#18+
miksoftsergey-iv3miksoft, и почему-то после добавления индекса, в плане type все равно остался ALLДа, а колонка KEY пуста, значит индекс не применяется. Сколько записей в таблице DICT.Price и сколько из них выбирает условие sp.PriceChangeId > ? Что подставляется вместо знака вопроса? 16067 записей. Выбирается, около 500 записей. Вместо знака вопроса подставляется число, например: Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2018, 19:33 |
|
||
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#18+
sergey-iv316067 записей. Выбирается, около 500 записей.Это немногим более 3% - близко к пограничной величине для применения индекса, хотя и ниже ее. Но в плане колонка filtered больше, т.е. собранная статистика не соответствует факту. Поэтому я и говорил, что после создания индекса желательно сделать ANALYZE TABLE или OPTIMIZE TABLE, чтобы в т.ч. и статистику пересчитать. Но лучше все-таки довести данные до реальных. Тогда, подозреваю, эта доля изменится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2018, 19:47 |
|
||
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#18+
miksoft, а вообще можно как-то избавится от derived table которая во FROM: SELECT tsc.Id, min(spc.sDate) FROM TEST.`Services` tsc, ( ...), как-то заменить это? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2018, 22:43 |
|
||
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#18+
sergey-iv3miksoft, а вообще можно как-то избавится от derived table которая во FROM: SELECT tsc.Id, min(spc.sDate) FROM TEST.`Services` tsc, ( ...), как-то заменить это?Можно, если переписать запрос так, чтобы в нем не было подзапросов. Но особого смысла в этом нет. Да и невозможно, не зная его логики. Избавляться надо от других вещей, от using filesort, например. Или добиваться использования индексов там, где это имеет смысл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2018, 23:40 |
|
||
|
Оптимизация тяжелого SQL запроса MySQL
|
|||
|---|---|---|---|
|
#18+
авторИзбавляться надо от других вещей, от using filesort, например. он там все 2 миллиона группирует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2018, 04:42 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39630302&tid=1829908]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
47ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
| others: | 14ms |
| total: | 164ms |

| 0 / 0 |
