Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Приветствую! Есть такой запрос: Код: sql 1. 2. 3. 4. 5. 6. 7. Он считает кол-во строк, и потом в соотв. с этим рисует пагинацию. Проблема в том, что этот запрос выполняется примерно 4-5 секунд. План: idselect_typetablepartitionstypepossible_keyskeykey_lenrefrowsExtra1SIMPLEaNULLindexNULLPRIMARY4NULL252651Using index; Using temporary1SIMPLEuNULLeq_refPRIMARYPRIMARY4---.a.id11SIMPLEeNULLeq_refPRIMARYPRIMARY4---.a.id1Using index1SIMPLEmNULLeq_refPRIMARYPRIMARY4---.u.manager_id1Using index1SIMPLEmmNULLreffirm_idfirm_id5---.a.id11SIMPLEaccNULLrefuser_iduser_id4---.mm.id2Using index Индексы по всем полям присутствуют. Количество строк во всех таблицах, кроме users_acct примерно 260 тыс. В users_acct ~6000 строк. Движок MyISAM. Подскажите, что можно тут улучшить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.08.2017, 14:03 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Victor256, Как часто и насколько сильно изменяется количественный состав данных в таблицах? Может нет смысла каждый раз выполнять запрос, а сделать некую табличку с результатом этого запроса и обновлять Ее периодические по мере необходимости? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.08.2017, 14:41 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
1) Оцените количество записей в связываниях (u-m) и в (mm-acc). Результат в студию. 2) Убедитесь, что Вам ДЕЙСТВИТЕЛЬНО не жить без левых связываний. Если не сможете - замените все или часть на внутренние. 3) Измените порядок связывания. Возможно, на a-e-u-m-mm-acc. Возможно, на a-e-(u-m)-(mm-acc). Victor256Индексы по всем полям присутствуют.DDL всех таблиц в студию (почистив от ненужных для связывания полей). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.08.2017, 15:01 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Victor256Приветствую! Есть такой запрос: Код: sql 1. 2. 3. 4. 5. 6. 7. Он считает кол-во строк, и потом в соотв. с этим рисует пагинацию. Проблема в том, что этот запрос выполняется примерно 4-5 секунд. План: idselect_typetablepartitionstypepossible_keyskeykey_lenrefrowsExtra1SIMPLEaNULLindexNULLPRIMARY4NULL252651Using index; Using temporary1SIMPLEuNULLeq_refPRIMARYPRIMARY4---.a.id11SIMPLEeNULLeq_refPRIMARYPRIMARY4---.a.id1Using index1SIMPLEmNULLeq_refPRIMARYPRIMARY4---.u.manager_id1Using index1SIMPLEmmNULLreffirm_idfirm_id5---.a.id11SIMPLEaccNULLrefuser_iduser_id4---.mm.id2Using index Индексы по всем полям присутствуют. Количество строк во всех таблицах, кроме users_acct примерно 260 тыс. В users_acct ~6000 строк. Движок MyISAM. Подскажите, что можно тут улучшить? Ничего. В запросе нет SARG-ов, нечего оптимизировать, кроме JOIN-ов. Если на все условия JOIN-а есть индексы в дочерних (правых) таблицах, то более ничем запросу не помочь. Кроме этого, и финальный запрос, для которого делается пагинация, тоже, подозреваю, идиотский. Сколько у тебя там будет записей ? 200 тыщ ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.08.2017, 17:02 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Добрый Э - ЭхVictor256, Как часто и насколько сильно изменяется количественный состав данных в таблицах? Может нет смысла каждый раз выполнять запрос, а сделать некую табличку с результатом этого запроса и обновлять Ее периодические по мере необходимости? к сожалению, все таблицы активно обновляются Akina1) Оцените количество записей в связываниях (u-m) и в (mm-acc). Результат в студию. 2) Убедитесь, что Вам ДЕЙСТВИТЕЛЬНО не жить без левых связываний. Если не сможете - замените все или часть на внутренние. 3) Измените порядок связывания. Возможно, на a-e-u-m-mm-acc. Возможно, на a-e-(u-m)-(mm-acc). Victor256Индексы по всем полям присутствуют.DDL всех таблиц в студию (почистив от ненужных для связывания полей). 1) ~260к в обоих случаях 2) не соображу, как это можно сделать? 3) a-e-u-m-mm-acc попробовал, те же яйца. А что такое a-e-(u-m)-(mm-acc)? MasterZivНичего. В запросе нет SARG-ов, нечего оптимизировать, кроме JOIN-ов. Если на все условия JOIN-а есть индексы в дочерних (правых) таблицах, то более ничем запросу не помочь. Кроме этого, и финальный запрос, для которого делается пагинация, тоже, подозреваю, идиотский. Сколько у тебя там будет записей ? 200 тыщ ? даже больше, 260к записей в итоге. Тут весь сайт такой. Один сложный проблемный запрос улучшить удалось, но для этого пришлось переделывать логику работы. Но там хоть были варианты, а с этим вообще не могу придумать ничего. Он простой как двери. Таблицы: Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 14:00 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Victor256что такое a-e-(u-m)-(mm-acc)? a-b-c == from a join b on a.a=b.a join с on b.b=c.b a-(b-c)== from a join (b join с on b.b=c.b) on a.a=b.a ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 14:57 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Victor256 MasterZivКроме этого, и финальный запрос, для которого делается пагинация, тоже, подозреваю, идиотский. Сколько у тебя там будет записей ? 200 тыщ ? даже больше, 260к записей в итоге. Тут весь сайт такой. Один сложный проблемный запрос улучшить удалось, но для этого пришлось переделывать логику работы. Но там хоть были варианты, а с этим вообще не могу придумать ничего. Он простой как двери. ну и кому нужен запрос, выдающий 260 тыщ записей? Ставь в финальный запрос в конец LIMIT 2000, а вместо подсчётного напиши SELECT 2000, -- и все дела оптимизации. Дебильные не нужные никому запросы не нужно оптимизировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 18:42 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
MasterZivну и кому нужен запрос, выдающий 260 тыщ записей? Ставь в финальный запрос в конец LIMIT 2000, а вместо подсчётного напиши SELECT 2000, -- и все дела оптимизации. Дебильные не нужные никому запросы не нужно оптимизировать. ты наверно не понял. Это всего 260к записей. Но выбираются они через лимит: LIMIT 55555, 10 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2017, 15:04 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Victor256LIMIT 55555, 10Такой лимит не может не тормозить... пока он там 55 тыщ отсчитает... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2017, 16:06 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
AkinaVictor256LIMIT 55555, 10Такой лимит не может не тормозить... пока он там 55 тыщ отсчитает... тогда, какой выход? По id не получится, записи могут удаляться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2017, 10:18 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Victor256Akinaпропущено... Такой лимит не может не тормозить... пока он там 55 тыщ отсчитает... тогда, какой выход? По id не получится, записи могут удаляться. Условие ORDER BY инвертировать ( в другом порядке чтобы) и LIMIT 10 Но и такой запрос не сильно хороший, поскольку он будет обрабатывать ВСЕ записи, а только затем отбирать 10. Сортироваться будут также (почти) все записи. Но главное даже не это, я вовсе не уверен, что там у тебя вообще запрос правильный. Подозреваю, у тебя JOIN-ятся к родителю несколько 1:N параллельно, это будет множить записи в дочерних параллельных таблицах. Хотя, проверить это я не могу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2017, 20:25 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
MasterZiv Подозреваю, у тебя JOIN-ятся к родителю несколько 1:N параллельно, это будет множить записи в дочерних параллельных таблицах. Хотя, проверить это я не могу. а что это значит? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2017, 09:50 |
|
||
|
Как оптимизировать запрос?
|
|||
|---|---|---|---|
|
#18+
Victor256MasterZivПодозреваю, у тебя JOIN-ятся к родителю несколько 1:N параллельно, это будет множить записи в дочерних параллельных таблицах. Хотя, проверить это я не могу. а что это значит? Ну как же тебе объяснить, если не понимаешь ? ПРоверь просто, что дочерние записи не двоятся. users_extra, users_acct... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2017, 11:32 |
|
||
|
|

start [/forum/topic.php?fid=47&fpage=68&tid=1830446]: |
0ms |
get settings: |
13ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
46ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
66ms |
get tp. blocked users: |
2ms |
| others: | 250ms |
| total: | 412ms |

| 0 / 0 |
