|
|
|
Тяжелый запрос с Using temporary, Using filesort из-за ORDER
|
|||
|---|---|---|---|
|
#18+
Прошу помочь ускорить запрос или подсказать как правильно его переделать(или переделать структуру). Имеется вот такой запрос: Код: plaintext 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. Если в выборку попадает более 200к позиций(учитывая условия where), запрос выполняется от 5 до 60 секунд. Желательно не более 2-3 секунд. Если указать индекс: Код: plaintext 1. 2. ORDER заставляет БД лопатить все записи. Если добавить еще условий, напр. `a16`.`value` = "21334" и в результате это ограничит количество позиций до каких-нибудь 10к - запрос выполнится быстро. В самой таблице может быть несколько миллионов записей, на скорость влияет именно количество, попадающее в выборку(есть исключения, но общая картина такова). Если в выборку попадает несколько десятков тысяч записей(много) - часто помогает USE INDEX - но не всегда. Пробовал выделять оперативку для временных таблиц, key_buffer_size и прочие параметры - практически не влияет на производительность. Обновление с MySQL 5.1 до 5.6 ускорило запрос, но ненамного. Вернулся на 5.1. Пытался решить эту проблему уже несколько раз, многое перепробовал и честно говоря уже запутался, не хватает опыта и свежего взгляда. Что делает запрос: Здесь есть 2 таблицы: "предметы" и "характеристики" к ним. Соответственно идет выборка предметов по условиям характеристик. Может быть я неправильно организовал структуру хранения данных? Буду рад любым соображениям. EXPLAIN без USE INDEX Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. EXPLAIN без USE INDEX, но без ORDER Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. EXPLAIN с USE INDEX Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. ТАБЛИЦЫ Код: plaintext 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.04.2016, 12:59 |
|
||
|
Тяжелый запрос с Using temporary, Using filesort из-за ORDER
|
|||
|---|---|---|---|
|
#18+
supermike Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Надеюсь, не надо объяснять, что Код: sql 1. превращает соотв. LEFT JOIN в INNER JOIN? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2016, 13:12 |
|
||
|
Тяжелый запрос с Using temporary, Using filesort из-за ORDER
|
|||
|---|---|---|---|
|
#18+
supermikeПрошу помочь ускорить запрос или подсказать как правильно его переделать(или переделать структуру). Имеется вот такой запрос: Код: 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. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2016, 13:18 |
|
||
|
Тяжелый запрос с Using temporary, Using filesort из-за ORDER
|
|||
|---|---|---|---|
|
#18+
Даже, наверное, так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2016, 13:29 |
|
||
|
Тяжелый запрос с Using temporary, Using filesort из-за ORDER
|
|||
|---|---|---|---|
|
#18+
Cygapb-007 Код: sql 1. 2. Это можно заменить на: Код: sql 1. Будет и короче, и быстрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2016, 13:30 |
|
||
|
Тяжелый запрос с Using temporary, Using filesort из-за ORDER
|
|||
|---|---|---|---|
|
#18+
miksoft, да, забыл про сортировку в GROUP BY))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2016, 13:33 |
|
||
|
Тяжелый запрос с Using temporary, Using filesort из-за ORDER
|
|||
|---|---|---|---|
|
#18+
supermike, Код: sql 1. Где таблица a83? Сколько записей подходять под это условие? Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2016, 14:04 |
|
||
|
Тяжелый запрос с Using temporary, Using filesort из-за ORDER
|
|||
|---|---|---|---|
|
#18+
MasterZiv, 222144 записей.. Если это количество в районе 60к, то можно делать целую кучу условий по характеристикам и все равно запрос будет очень быстро выполняться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2016, 14:27 |
|
||
|
Тяжелый запрос с Using temporary, Using filesort из-за ORDER
|
|||
|---|---|---|---|
|
#18+
MasterZivsupermike, Код: sql 1. Где таблица a83? Это product_tmplvar_contentvalues ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2016, 14:29 |
|
||
|
Тяжелый запрос с Using temporary, Using filesort из-за ORDER
|
|||
|---|---|---|---|
|
#18+
Cygapb-007, К сожалению, получилось дольше - 17 секунд против 7. Причем если убрать ORDER, скорость не возрастает. EXPLAIN Код: plaintext 1. 2. 3. 4. 5. ПОЛНЫЙ ЗАПРОС Код: plaintext 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2016, 14:45 |
|
||
|
Тяжелый запрос с Using temporary, Using filesort из-за ORDER
|
|||
|---|---|---|---|
|
#18+
supermike, а если попробовать индекс contentid-tmplvarid-value ? там время может теряться на RID - поиск записи по PK для извлечения Value или неподъемным получится? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2016, 15:04 |
|
||
|
Тяжелый запрос с Using temporary, Using filesort из-за ORDER
|
|||
|---|---|---|---|
|
#18+
Cygapb-007, Индекс очень долго создавался, нужно потестировать - завтра отпишусь о результатх. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2016, 16:49 |
|
||
|
Тяжелый запрос с Using temporary, Using filesort из-за ORDER
|
|||
|---|---|---|---|
|
#18+
supermike, ....выкинте ВСЕ связки и все таблицы которые не участвуют в поиске хатактеристик. отсортируйте результат и выберете 100 товаров. а потом к ним подсоединяйте остальные характеристики... а то получается что все-на-все умножаете, потом сортируете и выбираете 100 верхних... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2016, 19:50 |
|
||
|
Тяжелый запрос с Using temporary, Using filesort из-за ORDER
|
|||
|---|---|---|---|
|
#18+
Прошу прощения за задержку с ответом - много времени ушло на тестирование, ведь запросы на сервер идут разной степени сложности и нужно было все проверить. Cygapb-007supermike, а если попробовать индекс contentid-tmplvarid-value ? там время может теряться на RID - поиск записи по PK для извлечения Value или неподъемным получится? USE INDEX(contentid, tmplvarid, value), на сколько я заметил, по эффективности вышел таким же как и индекс по столбцам "contentid, tmplvarid" - разницы между ними практически никакой. Эти индексы в некоторых случаях наоборот замедляют запрос, причем на порядок. Из-за того, что индекс много весит, пробовал увеличить key_buffer_size - не помогло, видимо все-таки проблема не в этом. Соответственно я писал так: Код: plaintext 1. 2. javajdbcsupermike, ....выкинте ВСЕ связки и все таблицы которые не участвуют в поиске хатактеристик. отсортируйте результат и выберете 100 товаров. а потом к ним подсоединяйте остальные характеристики... а то получается что все-на-все умножаете, потом сортируете и выбираете 100 верхних... Резонно, этот вариант ускоряет выборку в среднем раза в 2-3, что очень хорошо, спасибо за подсказку! К сожалению, это все же не решает проблему полностью. Сейчас в каждом разделе по 200+к позиций(там где parent = n), и уже все это дело еле движется. В некоторых случаях задержки по 4 сек. А потребуется выгрузить в раздел не 200к, а 500к, к примеру - тогда все будет висеть. Кэшировать не вариант, т.к. данные каждый день изменяются да и невозможно закэшировать все варианты фильтра. Как реализовывают такой фильтр продукции на других сайтах? Неужели через NOSQL? Или создают огромную таблицу с кучей столбцов-характеристик? Можно конечно все это дело вынести в оперативку, но неужели нет другого решения? Поделитесь опытом... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2016, 14:24 |
|
||
|
Тяжелый запрос с Using temporary, Using filesort из-за ORDER
|
|||
|---|---|---|---|
|
#18+
Хотя, наверно проблема надуманная, т.к. большие задержки возникают если в выборку попадает много записей, т.е. в фильтре не указаны основные характеристики продукции, а указаны только второстепенные, напр. при подборе машины(допустим) не указан ни тип кузова, ни цвет, а только размер дисков и наличие дворника - в результате в выборку попадают почти все машины и здесь поиск подходящих по фильтру машин выполняется очень медленно. Видимо нужно обозначать основные характеристики продукции, которые будут обязательными для выбора в фильтре... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2016, 14:55 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39224734&tid=1831860]: |
0ms |
get settings: |
9ms |
get forum list: |
22ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
44ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
73ms |
get tp. blocked users: |
2ms |
| others: | 210ms |
| total: | 381ms |

| 0 / 0 |
