|
|
|
Оптимизация запроса, большая выборка для экспорта в XML
|
|||
|---|---|---|---|
|
#18+
Добрый день, есть скрипт экспорта объявлений в XML файл. Число позиций в таблице 'ad' выросло до 30K. Начались задержки в 6-8 секунд на выборку. Есть мысли что запрос не до конца оптимален. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Вывод EXPLAIN: https://www.dropbox.com/s/ix1i0wrus9v3e7h/explain.jpg?dl=0 Может быть дело во временной таблице 'users' ? Сейчас 30k выполняется за 6 секунд, если будет 300k записей это будет уже минута, что слишком долго для этого места. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2014, 20:11:39 |
|
||
|
Оптимизация запроса, большая выборка для экспорта в XML
|
|||
|---|---|---|---|
|
#18+
adrocket, 0. какая версия МЫСКЛ? 5.1, 5.5 или 5.6? 1. да, 6 секунд это многовато. Експолейн выглядит не плохо но есть непонятки. 2. проведите SHOW CREATE TABLE для всех таблиц. 3. проверьте логику ЛЕФТ джоинов. 4. из-за большого количества таблиц и смеси ЛЕФТ и обычных джоинтов оптимизатор выбрал USER как начальную таблицу и не использовал индексы на АДС.статус и обжект_тупе. 5. Похоже что запрос вывалился на диск --- это возможно если маленький жоинт буфер или по дороге вытягивается большие поля --- напромер весь ИМАЖЕ -- который потом не нужен. 6. можно попробовать отоптимизировать этот запрос последовательным приближением, по порядки с замером времени и ЕКСПЛЕЙНОМ: 6.1 Код: sql 1. 2. 3. 4. 5. 6.2 предыдушее плюс ЮЗЕР 6.3 предыдушее плюс agencies 6.4 предыдушее плюс имаже 7. .... а там и посмотрим куда дальше плыть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2014, 21:20:24 |
|
||
|
Оптимизация запроса, большая выборка для экспорта в XML
|
|||
|---|---|---|---|
|
#18+
Огромное спасибо, не ожидал такой быстрый о четкой ответ увидеть! Запалил я конечно свою базу конкурентам :) 0. Код: plaintext 1. 2. 3. 4. 2. Код: plsql 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. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. Код: plsql 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. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 6.1 - 6.4 - в аттаче Похоже что 'users' не взирая на 'images' и остальные.. БЛИН, фигня какая-то запрос начал выполняться за 2.258 сек, может зря я эту портянку настрочил и гоню на mysql? my.cnf Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2014, 22:18:01 |
|
||
|
Оптимизация запроса, большая выборка для экспорта в XML
|
|||
|---|---|---|---|
|
#18+
adrocket, 8. Пожалуйста добавьте для всех запросов 6.1-6.4 время выполнения без ЕХПЛАИН. Поставьте sql_no_cache и замерьте время 3 раза для каждого варианта, типа Код: sql 1. 2. 3. 4. 9. Установите и погоняйте: > wget raw.github.com/major/MySQLTuner-perl/master/mysqltuner.pl > perl ./mysqltuner.pl ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2014, 03:43:09 |
|
||
|
Оптимизация запроса, большая выборка для экспорта в XML
|
|||
|---|---|---|---|
|
#18+
javajdbc4. из-за большого количества таблиц и смеси ЛЕФТ и обычных джоинтов оптимизатор выбрал USER как начальную таблицу и не использовал индексы на АДС.статус и обжект_тупе.Так индексы-то отдельные. Поэтому и не использовал. Я бы предложил сделать индекс ads (publish_status, object_type) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2014, 09:38:51 |
|
||
|
Оптимизация запроса, большая выборка для экспорта в XML
|
|||
|---|---|---|---|
|
#18+
Так, по порядку. javajdbc Хочу обратить внимание что все запросы даже без object_type. Код: plsql 1. 2. 3. Код: plaintext 1. 2. Код: plsql 1. 2. 3. 4. 5. Код: plaintext 1. 2. Код: plsql 1. 2. 3. 4. 5. 6. 7. Код: plaintext 1. 2. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Код: plaintext 1. 2. Опа, снова 7 секунд.. для этого последнего запроса снова прикрепляю вывод с EXPLAIN. Тюнер: Код: 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. Далее я добавил в my.cnf Код: plaintext 1. 2. Как быстро стал выполняться последний запрос (так же): Код: plaintext 1. 2. Какие изменения произошли в выводе тюнера. (наверное еще прошло слишком мало времени меньше часа) Код: plaintext 1. 2. 3. 4. "Joins performed without indexes" - Скорее всего относится к другим запросам. Снова добавил: Код: plaintext 1. Как быстро стал выполняться последний запрос (так же): Код: plaintext 1. 2. Думаю что дело тут так же не во фрагментации таблиц.. Пока мыслей больше нет.. miksoft Ключ добавил но запросы без `object_type`.. Код: plsql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2014, 12:30:52 |
|
||
|
Оптимизация запроса, большая выборка для экспорта в XML
|
|||
|---|---|---|---|
|
#18+
"JOIN users" Код: plaintext 1. 2. "LEFT JOIN users" Код: plaintext 1. 2. Если "JOIN users" -> "LEFT JOIN users", то EXPLAIN: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2014, 12:45:18 |
|
||
|
Оптимизация запроса, большая выборка для экспорта в XML
|
|||
|---|---|---|---|
|
#18+
ок, проблема где-то здесь, будем искать. Возмите за основу вот этот СКЛ (7-8 секунд) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Проблема может быть в UUID((), или в ГРОУП БУ или в самом факте подключения имажей или в ГРОУП_КОНКАТ -- последнее маловероятно, но для полноты списка. Определите скорость (3 раза СКЛ_НО_КАШЕ) таких СКЛ: (неважно что некоторые логически неверные) 10. СКЛ минус (3) 11. СКЛ минус (2) 12. СКЛ минус (1) плюс (4) , ГРОУП БУ перевести на имаже.ид 13. СКЛ минус (1),(2), (3) плус (4) 14. СКЛ -- заменить UUID() на RAND() EXPLAIN проверяйте на всякий случай, но скорее всего он будет одним и темже для всех СКЛ-ов 10-14 15. У вас большой запас по RAM -- тюрнер говорит что используется (мах возможного) всего 13%. Если на сервере только МЫСКЛ, то можно добавлять буферов. Например Variables to adjust: sort_buffer_size (> 256K) read_rnd_buffer_size (> 256K) поставьте 1М и 1М 16. [OK] Highest usage of available connections: 14% (14/100) Можно скинуть вниз мах_конекш до , скажем, 40-ка. Лучше эти подкрутки сделать ПОСЛЕ оптимизации основного СКЛ-а ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2014, 17:39:35 |
|
||
|
Оптимизация запроса, большая выборка для экспорта в XML
|
|||
|---|---|---|---|
|
#18+
Судя по поведению ниже, дело на 80% в GROUP BY и на 20% в GROUP_CONCAT. Причем, если хотя бы кто-то из них присутствует то эффект значителен... Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Код: plaintext 1. 2. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Код: plaintext 1. 2. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Код: plaintext 1. 2. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Код: plaintext 1. 2. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Код: plaintext 1. 2. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2014, 19:46:16 |
|
||
|
Оптимизация запроса, большая выборка для экспорта в XML
|
|||
|---|---|---|---|
|
#18+
adrocket, ок, я продолжаю подозревать вываливание на диск. лечится двумя способами : -- переписать СКЛ -- увеличить выделение памяти Первый варинат намного предпочтительнее, хотя второй тоже надо рассмотреть ибо сейчас задействовано только 13%. 21. для доказательсва (или опровержения) выпадения на диск есть быстрая проверка. Возмите такой СКЛ: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Вместо все таблицы ADS можно взять сначала 5 записей замерьте время (3 раза СКЛ_НО_КАШЕ). потом возмите ЛИМИТ 20, потом ЛИМИТ 50, потом 200, 500, 2000, 5000, 20000. Если есть резкий скачёк, значит есть качественое изменение. Лог-лог график может помочь визуально найти скачек (если он есть!). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2014, 20:14:10 |
|
||
|
Оптимизация запроса, большая выборка для экспорта в XML
|
|||
|---|---|---|---|
|
#18+
22. интересно что RAND() оказалось таки реально быстрее чем UUID(): сброс с 2.1 до 1.6 сек. 23. 1.6 сек --- это только от ГРОУП БУ. Когда есть ГРОУП_КОНКАТ и нету ГРОУП БУ то МуСКЛ делает групировку по всем остальным полям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2014, 20:19:27 |
|
||
|
Оптимизация запроса, большая выборка для экспорта в XML
|
|||
|---|---|---|---|
|
#18+
теперь как попробовать переписать. Начнем с простейшего, для все СКЛ ниже выдайте 3 раза скорость СКЛ_НО_КАШЕ: Код: sql 1. 2. 3. 4. 5. Код: sql 1. 2. 3. 4. 5. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2014, 20:31:04 |
|
||
|
Оптимизация запроса, большая выборка для экспорта в XML
|
|||
|---|---|---|---|
|
#18+
Скачка вроде нет.. Насчет RAM, не хотелось бы увеличивать ее использование, так как помимо mysql есть еще Apache, Redis и конечно одна, постоянно работающая JVM. Но ради эксперимента я попробую это сделать. Код: plaintext 1. 2. Код: plaintext 1. 2. 3. Код: plaintext 1. 2. Код: plaintext 1. 2. Код: plaintext 1. 2. Код: plaintext 1. 2. Код: plaintext 1. 2. Код: plaintext 1. 2. Код: plsql 1. 2. 3. 4. 5. Код: plaintext 1. 2. Код: plsql 1. 2. 3. 4. 5. [/SRC] Код: plaintext 1. 2. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. Код: plaintext 1. 2. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Код: plaintext 1. 2. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Код: plaintext 1. 2. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Код: plaintext 1. 2. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2014, 10:44:42 |
|
||
|
Оптимизация запроса, большая выборка для экспорта в XML
|
|||
|---|---|---|---|
|
#18+
adrocket, да, сильного перегиба графика нет. на лог-лог графике есть небольшой перегиб на 50 -- врядли можно что-то сказать. Ну да ладно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2014, 18:05:15 |
|
||
|
Оптимизация запроса, большая выборка для экспорта в XML
|
|||
|---|---|---|---|
|
#18+
adrocket, Я сам забыл в некоторые СКЛ поставить СКЛ_НО_КАШЕ, в дальнейшем всегда ставьте, иначе получаются результаты типа: 1.0132 seconds 0.0003 seconds 0.0004 seconds Теперь по сушеству. Запрос вылетает на с милисекунд на секундны если (а) есть связка (б) групировка по имаге аттрибуту (ц) непонятка с a.publish_status = 4 -- этот филтр ухудшил ситуацию Теперь рассмотрим логику. Группировку по ...IFNULL(i.ad_id, UUID()) as unq_ancestor... group by unq_ancestor я бы заменил на ...IFNULL(i.ad_id, UUID()) as unq_ancestor... group by a.id Т.е. если имаже не найден, то УУИД и адс.ид будут одинаково уникальны, т.е. как мне кажется, замена развнозначаная. Посмотрите вот такой СКЛ (СКЛ_НО_КАШЕ, 3 раза и ЕКСПЛАИН!) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Если скорость будет приемлемая (10-50 мс), то аккуратно подключайте другие таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2014, 18:21:57 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38811041&tid=1833903]: |
0ms |
get settings: |
6ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
28ms |
get topic data: |
5ms |
get forum data: |
1ms |
get page messages: |
28ms |
get tp. blocked users: |
1ms |
| others: | 233ms |
| total: | 314ms |

| 0 / 0 |
