|
|
|
и снова фильтры
|
|||
|---|---|---|---|
|
#18+
Всем доброе время суток, требуется помощь по оптимизации запроса В общем схема такова: имеется таблица фильтров Код: sql 1. 2. 3. 4. 5. 6. 7. 8. Каждый фильтр закреплен за пользователе (user_id). И у каждого фильтра есть join таблицы для множественного выбора следующих характеристик: года выпуска, модели, регионы, услуги(по которым настраивается фильтр). Реализация связей фильтров и этих таблиц с помощью объединяющих(join) таблиц так как должен быть множественный выбор по каждому фильтру. Код: 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 Услуги: услуга1,услуга2,услуга3... Года выпуска: 2000,2001,2004,2005... Регионы: регион1, регион2, регион3... Марки машин: Honda, BMW, Audi... Модели машин: Accord, X5,A7 и так далее, список фильтров. С марками фильтры связаны через модели. Итого пишу следующий запрос: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. В итоге запрос занимает более 7 секунд и это почти пустая БД. Если убрать GROUP_CONCAT то индексы используются, но это GROUP_CONCAT да еще distinct тупо убивают всю производительность! :( Буду благодарен за любые подсказки, пинки, тыканье носом и прочего по оптимизации такого запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2015, 18:27:53 |
|
||
|
и снова фильтры
|
|||
|---|---|---|---|
|
#18+
scion4581, А план где ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2015, 19:56:15 |
|
||
|
и снова фильтры
|
|||
|---|---|---|---|
|
#18+
И с таким подходом будет сложно. Либо надо будет хинты прописывать для каждого случая (типовых поисков), либо всё будет работать абы как. Лучше бы было герерировать тексты запросов на основе фильтров, и выполнять их. Это хотя бы какой-то выход на оптимизируемые запросы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2015, 20:07:26 |
|
||
|
и снова фильтры
|
|||
|---|---|---|---|
|
#18+
Вот если без group_concat, индексы используются но не все ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2015, 20:16:18 |
|
||
|
и снова фильтры
|
|||
|---|---|---|---|
|
#18+
но если добавить их то сразу становится null ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2015, 20:17:03 |
|
||
|
и снова фильтры
|
|||
|---|---|---|---|
|
#18+
спасибо за ответ. пока приложение тестируется поэтому можно изменить и реализацию если что. Просто пугает что мало записей, фильтров штук 15 и на каждый из них максимум по 20 записей в связывающей таблице а результат просто кошмарный. Как бы это можно было бы пошустрее сделать. Спасибо за ответ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2015, 20:19:24 |
|
||
|
и снова фильтры
|
|||
|---|---|---|---|
|
#18+
Переписал запрос следующим образом, группируем каждую таблицу множественного выбора и соединяю по id фильтра и скорость стала космический "Запрос занял 0.0091 сек." с 7 секунд то. хотя запрос ужасный вроде получился, стоит ли так делать Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2015, 20:36:22 |
|
||
|
|

start [/forum/topic.php?fid=47&gotonew=1&tid=1833413]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
39ms |
get topic data: |
7ms |
get first new msg: |
4ms |
get forum data: |
2ms |
get page messages: |
35ms |
get tp. blocked users: |
1ms |
| others: | 194ms |
| total: | 303ms |

| 0 / 0 |
