|
|
|
Оптимизация работы MySQL при выборке 50кк строк
|
|||
|---|---|---|---|
|
#18+
Electronnnnnmiksoftпропущено... Тут хотя бы приблизительный порядок надо навести, иначе вы систему до свопа доведете. Или уже довели. в текущем треде только одна цель - ускорить эти тяжелые неоптимизированные запросы. Если нужно будет больше памяти серверу - добавим, если надо будет под базы подключить ссд - сделаем, но нужно точно знать из-за чего сначала после ребута сервиса запросы идут по одной секунде, после 4-6 часов работы по 11-15 секунд. Нет нужды перекраивать лимиты под более низкие именно для оптимизации потребляемой сервисом памяти. мне кажеться вы это сделать будете не в состоянии. тут надо работать, понимая при этом, что делаешь. через форум с полуиспорченным телефоном очень сложно что-то такое сделать. кроме того запрос у вас не из таких, что можно оптимизировать на раз одним советом на форуме. в общем, надо вам лучше нанимать специалиста. но учтите, что результат -- оптимизированный запрос именно в таком виде -- и в этом случае не гарантирован. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2015, 08:35:33 |
|
||
|
Оптимизация работы MySQL при выборке 50кк строк
|
|||
|---|---|---|---|
|
#18+
Electronnnnnmiksoftпропущено... Это картина "после 4-6 часов работы" ? После суток-двух. Картина примерно одна и та же с начала перезагрузки сервера до начала торможений по запросам. так все понятно, ты просто загоняешь бд в своп, и все. пока бд только стартовала, все ок, потом она кэш набирает и в своп уходит. очень на то все похоже. рецепт: - конфигурацию вернуть на дефолтную. - убрать query cache в 0 - если база большая, установить innodb buffer cache в половину или треть физической памяти на компе. -дальше начинать уже от этой печки плясать заново. и еще, конкретные запросы очень редко когда можно оптимизнуть изменением конфигурации сервера, разве что в ней что-то очень сильно не так, но только на одном запросе это проявляется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2015, 08:47:52 |
|
||
|
Оптимизация работы MySQL при выборке 50кк строк
|
|||
|---|---|---|---|
|
#18+
MasterZivmiksoftпропущено... Сделайте 128 или 256 Мбайт. да в 0 эту шнягу надо ставить, в ноль. выставил в ноль - реально даже сразу после перезагрузки стали запросы пролетать быстрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2015, 11:24:57 |
|
||
|
Оптимизация работы MySQL при выборке 50кк строк
|
|||
|---|---|---|---|
|
#18+
ElectronnnnnMasterZivпропущено... да в 0 эту шнягу надо ставить, в ноль. выставил в ноль - реально даже сразу после перезагрузки стали запросы пролетать быстрее. Дело не в том, что это должно было бы влиять на производительность -- не должно было, разве за счёт того, что не тратилась бы зазря память. Дело в том, что этот кэш запросов в принципе -- идиотская затея. СУБД не должна этим заниматься. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2015, 23:37:39 |
|
||
|
Оптимизация работы MySQL при выборке 50кк строк
|
|||
|---|---|---|---|
|
#18+
Electronnnnn, Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. У тебя реально такой дебильный запрос, или это "типа для примера" ? GROUP BY не нужен, нужен DISTINCT. На эти поля : Код: plaintext 1. 2. 3. 4. есть индексы ? Должны быть на все поля по отдельности в каждой из соотв. таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2015, 23:46:31 |
|
||
|
Оптимизация работы MySQL при выборке 50кк строк
|
|||
|---|---|---|---|
|
#18+
ElectronnnnntanglirНасчёт оптимизации самого запроса - я вижу только 2 пути, оба не особо хорошие: К сожалению, на данном этапе запрос не переписать, требуется помощь или совет, каким образом можно оптимизировать именно сам MySQL сервер для более быстрой обработки. Надо проверить/создать соотв. индексы. Я написал. Но я бы тоже рекомендовал начать пробовать переписывать запрос, в смысле, попытаться найти способ это сделать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2015, 23:48:57 |
|
||
|
Оптимизация работы MySQL при выборке 50кк строк
|
|||
|---|---|---|---|
|
#18+
MasterZiv, запрос реальный из CMS , его не переделать пока, приходится пилить пока серверную часть. Сначала снизил innodb_pool_size до 10Гб , запросы стали выполняться по 28 секунд, вернул в 20Гб - ситуация опять как раньше - первые пара часов все ок, потом по 11 секунд. Текущий конфиг : Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2015, 16:22:38 |
|
||
|
Оптимизация работы MySQL при выборке 50кк строк
|
|||
|---|---|---|---|
|
#18+
MasterZiv На эти поля : Код: plaintext 1. 2. 3. 4. есть индексы ? Должны быть на все поля по отдельности в каждой из соотв. таблиц. Код: plaintext 1. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Код: plaintext 1. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Код: plaintext 1. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. Код: plaintext 1. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Все селекты отдельно выполняются очень быстро, тормозят именно inner join операции . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2015, 18:05:27 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39073804&tid=1832620]: |
0ms |
get settings: |
6ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
34ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
| others: | 208ms |
| total: | 341ms |

| 0 / 0 |
