|
|
|
Запрос тормозит при добавлении джойнов
|
|||
|---|---|---|---|
|
#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. 28. 29. Выполняется он целых 500ms, что для меня долговато. Мне надо в пределах 5ms. Статистика по таблицам: * product - около 1,200 записей * product_to_category - 1,500 записей * review - около 2,000 записей * product_to_value - 6,600 записей Т.е. в общем и целом база небольшая, но почему так долго выполняется запрос - непонятно. Более того, если от него отрезать чуть-чуть, например последние два джойна с соответствующими условиями, то будет уже 21ms, что в 40 раз меньше. Аналогично, отрезав 3 условия, мы получаем уже 4ms вместо 500, что уже смахивает на приемлемый результат. Я как бы понимаю что джойны это плохо, но другого варианта запроса я придумать не могу. Я увеличивал join_buffer_size до 8M - эффекта нет. Ставил и 16M - пофиг. Значит дело не в памяти. Но в чем тогда? explain ничего интересного не говорит: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. А вот профайлинг говорит что запрос почти все свое время проторчал на статистике; Код: 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. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. Ну и наконец таблички: Код: 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. 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. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2014, 01:34:00 |
|
||
|
Запрос тормозит при добавлении джойнов
|
|||
|---|---|---|---|
|
#18+
soforp Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2014, 02:11:43 |
|
||
|
Запрос тормозит при добавлении джойнов
|
|||
|---|---|---|---|
|
#18+
vkle, Попробовал оптимизировать выборку: Код: 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. 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. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. Результат - 9ms Код: 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. 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. 59. 60. Результат - 2ms Все запросы проверялись с SQL_NO_CACHE. Но все равно интересно знать что за статистика, потому что мне кажется что только в данной ситуации запросы выполнились быстро. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2014, 02:35:12 |
|
||
|
Запрос тормозит при добавлении джойнов
|
|||
|---|---|---|---|
|
#18+
У вас explain по первому примеру показывает что при запросе используется файловая сортировка, а tmpdir находится в памяти или на диске? При tmpdir в памяти запрос из первого сообщения будет выполняться гораздо быстрее, особенно на большом объеме данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2014, 03:30:35 |
|
||
|
Запрос тормозит при добавлении джойнов
|
|||
|---|---|---|---|
|
#18+
soforp , в первом СКЛ-е вы задолбали оптимизатор похожими связками , смесью JOIN и WHERE, некорректным использованием LEFT. Оптимизатор mysql и так не шибко умный, а тут еше и вы ему "не помогли" :-) Вот он и задумался на полсекунды над перебором всех вариантов подсоединения таблиц. И, похоже, недоперебрал, вышел по лимиту времени на переборе, и выдал таксебейный план. А во втором случае вы конкретно навязали базе порядок выполнения. И получили отличный результат! Посему: 1. зачем вам много результатов так быстро? у вас еше есть лимит 10 ? постраничный вывод? 2. постарайтесь не смешивать два стиля написания связок . 3. запомните что ЛЕФТ не используют (в вашем случае) если потом есть WHERE на эту таблицу 4. при большом количестве жоинтов имеет смысл подсказать базе что делать. например с использованием подселектое, инлине вьюшек, STRAIGHT_JOIN, форсе индех.. . Естествено -- при соответсвуюшем анализе и тестировании . Вы провели хороший пример оптимизации такого рода. Ну и не сбивать с толку пунктами #2 и #3 выше. 5. Если рейтинги меняется не каждую секунду, можно раз в час их пересчитывать и хранить на продукте ( так называемая upstream / aggregate denormalization). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2014, 06:07:37 |
|
||
|
Запрос тормозит при добавлении джойнов
|
|||
|---|---|---|---|
|
#18+
Спасибо за ответ. ПО рейтингам действительно есть идея денормализации, но пока они на скорость выборки никак не влияли - пробовал как с ними, так и без. Можно про left и where подробней? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2014, 10:49:24 |
|
||
|
Запрос тормозит при добавлении джойнов
|
|||
|---|---|---|---|
|
#18+
soforpМожно про left и where подробней? Код: sql 1. 2. 3. 4. 5. 6. 7. 8. Лефт джойн говорит, что каждой строке из "п" будет соответствовать как минимум одна строка лезультата, пусть и с нулловыми значеними полей "п2ц". В то же время все строки с нулловыми значеними полей "п2ц" отсеиваются выделенным условием. Спрашивается, зачем ЛЕФТ джойн? обычный сделает то же самое, зато оптимизатору будет проще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2014, 11:52:55 |
|
||
|
Запрос тормозит при добавлении джойнов
|
|||
|---|---|---|---|
|
#18+
On 29.07.2014 02:34, soforp wrote: > Автор: soforp. > Выполняется он целых 500ms, что для меня долговато. Мне надо в пределах 5ms. Я хочу ещё добавить, что в принципе 500 ms -- это нормальное время выполнения для запроса. Быстрое. 5 ms -- очень быстрое, и в реальных БД практически не встречающееся. Это никак не относится к вашему конкретному запросу. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2014, 17:40:06 |
|
||
|
Запрос тормозит при добавлении джойнов
|
|||
|---|---|---|---|
|
#18+
автор SELECT p.product_id, p.stock_status_id, (SELECT AVG(rating) AS total FROM review r1 WHERE r1.product_id = p.product_id AND r1.status = '1') AS rating GROUP BY p.product_id группировка не по всем полям выборки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2014, 17:44:30 |
|
||
|
Запрос тормозит при добавлении джойнов
|
|||
|---|---|---|---|
|
#18+
ScareCrow, ну тут группировка по ид и поля из той же таблицы, в данном случае это простительно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2014, 20:18:37 |
|
||
|
Запрос тормозит при добавлении джойнов
|
|||
|---|---|---|---|
|
#18+
MasterZiv, Прежде чем делать громкие заявления относительно "быстроты" запроса в 500мс нужно вспомнить что любое приложение выполняет сотни запросов к базе в процессе формирования 1 странички ( например блог или интернет магазин ). Теперь представим на минутку сколько бы формировалась страничка, если бы она состояла из таких "быстрых" запросов. Мне представлять не надо, у моего клиента страничка формировалась 6 минут :( . Но после оптимизации - 150мс и это отлично :) В действительности же, быстрым можно назвать запрос, который выполняется быстрее чем за 1мс. 5мс - это компромисное время для таких монструозных запросов как мой. А запросы по одной табличке вообще должны выполняться менее чем за 1мс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2014, 20:36:44 |
|
||
|
Запрос тормозит при добавлении джойнов
|
|||
|---|---|---|---|
|
#18+
tanglir, Да, действительно left join смотрится глупо в данном случае. Но вроде была еще разница между left\right и inner джойнами, заключающаяся в скорости выборки. Быстрое гугленье ничего не дало, эксперименты тоже, но если вспомню что и как - отпишу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2014, 20:39:09 |
|
||
|
Запрос тормозит при добавлении джойнов
|
|||
|---|---|---|---|
|
#18+
kixiro, На диске, причем диск обычный саташный. Видимо поэтому аналогичный запрос на сервере с SSD дисками выполняется за 50мс при куда большем размере базы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2014, 20:40:17 |
|
||
|
Запрос тормозит при добавлении джойнов
|
|||
|---|---|---|---|
|
#18+
javajdbc, да, лимит есть конечно же. Да и phpmyadmin без лимита запрос не отпустит на сервер. Можно еще чуть подробнее про смешение стилей связок? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2014, 20:43:46 |
|
||
|
Запрос тормозит при добавлении джойнов
|
|||
|---|---|---|---|
|
#18+
soforp, ну типа старый стиль: select * from t1, t2 where t1.p1 = t2.p2 select * from t1, t2 where t1.p1 = t2.p2(+) новый select * from t1 JOIN t2 ON t1.p1 = t2.p2 select * from t1 LEFT JOIN t2 ON t1.p1 = t2.p2 смешаный стиль select * from t1 JOIN t2 where t1.p1 = t2.p2 я не помню чтобы кто-то ставил под сомнение функциональную идентичность смешаного стиля, но это мешает и чтению и, возможно, требует большей работы оптимизатора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2014, 21:10:48 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38707698&tid=1834436]: |
0ms |
get settings: |
10ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
71ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
74ms |
get tp. blocked users: |
2ms |
| others: | 216ms |
| total: | 416ms |

| 0 / 0 |
