| |||
|
|
Вопрос про MySQL часть 2 это перепост заметки, оригинал находится на моем сайте: https://lleo.me/dnevnik/2020/06/07 По советам умных людей перевез базы сайта с MyISAM на InnoDB, написав себе для этого всяких новых кнопок в админке баз движка (которая уже немного по функционалу приближается к PhpMyAdmin :). И немного уже пожалел, что переехал на InnoDB. Да, проблема инкрементального бэкапа решилась, он стал умнее: /backup 1450M /inc 3701042 Проблема тут другая. У меня на сервере и раньше подтормаживал MySQL уже не первый год — сайт, как вы наверно не раз наблюдали, подвисает. А с переездом на InnoDB торможение стало таким сильным, что следующие полдня сайт вообще висел, загрузка CPU 400% и всё такое... Когда я поглядываю SHOW PROCESSLIST, вижу такое:
Из чего становится понятно, что тормозит вот этот запрос: =============== cut =============== Это и правда самый сложный запрос в движке — формирование ленты комментариев, по крайней мере, очень частый. Он берет все комментарии из таблицы комментариев `dnevnik_comm`, относящиеся к номеру заметки $num, добавляет к ним по номеру автора его данные из таблицы посетителей `db_unic` (там этот номер называется `unic`, а тут исторически `id`), причем информации об авторе может не быть у комментариев 15-летней давности, там unic=0 Ну и сортирует по дате комментариев Time. По индексам — у таблицы посетителей `db_unic` есть primary индекс `id`. У таблицы комментариев `dnevnik_comm` есть индексы PRIMARY `id`, `DateID` (`DateID`), `poset` (`unic`,`scr`) и `Parent` (`Parent`), который к нашей задаче сейчас не относится. Вопрос специалистам: в этом моем запросе что-то не так? Его можно как-то оптимизировать? Или это нормально, что он выполняется долго и время от времени подвисает на длительное время? Может, надо добавить индекс для `Time`, а иначе он ORDER BY `Time` не может толком сделать для результата (результаты-то выборки комментариев к одной заметке обычно не слишком велики)? Я пока что отключил вывод простыни комментариев под заметками, чтобы этот запрос хотя бы выполнялся не для каждого посетителя, а только для тех, кто хочет почитать комментарии, нажав соответствующую кнопку. UPD: Ого, обнаружил сейчас в движке еще один запрос, начинающийся с тех же букв, только еще сложнее — он работает по адресу /comm и показывает ленту новых комметариев: =============== cut =============== Я не думаю, что кто-то пользуется лентой /comm Там 50 посетителей за все время было * , поэтому запрос редкий, и вряд-ли проблема в нем. Так навскидку-то он выглядит сильно ужаснее, потому что объединяет базу комментариев, посетителей и еще базу самих заметок `dnevnik_zapisi` (индексы для z.`Access`, z.`acn` и z.`num` в ней есть). Также, я гляжу, там используются из базы комментариев c.`scr` и c.`unic`, но у меня для этого там их общий индекс `poset` (`unic`,`scr`), вот только не уверен, что в запросе типа AND c.`scr`=0 OR c.`unic`=1 этот объединенный индекс чем-то поможет, наверно надо дополнительно продублировать его последнюю часть `scr`? это перепост заметки, оригинал находится на моем сайте: https://lleo.me/dnevnik/2020/06/07 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||