Нагрузка сервера, MySQL. Решения, выявляющие скрипты, которые нагружают базу

База innobd

ruhighload.com/Оптимальная+настройка+mysql

innodb_buffer_pool_size



проблем нет, всё летает

проблем нет, всё летает

Везет Вам.

Везет Вам

Бывает, но редко.

Поднастройте MySQL (ключевой параметр я указал), повезет и вам.

У меня не свой сервер, хостер говорит, что на этот параметр 48 гигов выделено. Но в рамках всего сервера.

Скопируйте свой второй запрос со скриншота (который 4 сек), откройте phpmyadmin, выберите базу, перейдите во вкладку SQL, вставьте туда его и перед самим запросом вставьте EXPLAIN, чтобы было EXPLAIN ваш запрос. Результат покажите тут.

У меня не свой сервер, хостер говорит, что на этот параметр 48 гигов выделено. Но в рамках всего сервера.

Ну думаю всё понятно. Шареды весьма ограничены.

Результат покажите тут.

Шареды весьма ограничены

Да, кто ж спорит))

Не все могут себе позволить сервер содержать. Я вот еще не заработал столько))

По таким ценам как ЗДЕСЬ могут позволить многие, даже я…
Обратите внимание на раздел Услуги-Виртуальные серверы-VDS SSD+SAS CЕРВЕР

шэльдэ бердэ бельдэ,

Отладка показывает такое для списка записей:

force index посути перебирает дерево и может по данным диска скакать, а диск на шареде подзагруженн и вот вам казалось бы выполнение быстрого запроса вылетает в медленный.
HDD или SSD ?

ну и по тупому посмотреть вообще индексы то в таблице есть ???

шэльдэ бердэ бельдэ,
Что бы я сделал в таком случае.
Проверил бы, проблема в хостере или в самой базе данных. Сделайте бэкап базы, разверните его на локальном опенсервере, подключите к базе свежеустановленный сайт, проверьте, как будет работать.
Еще вопрос. А как Вы добавляли эти 100к статей? Ведь не руками же? Тоже мигрировали таблицу?

шэльдэ бердэ бельдэ, Эту строчку приведите к виду:
В остальном всё нормально. Если хотите, можете прислать на почту доступы, гляну.

force index посути перебирает дерево и может по данным диска скакать

Это не так. force index говорит о принудительности использования указанного индекса. В данном случае есть вероятность, что MySQL действует не так, как ожидается.

База innobd. Кеширование включено.

Совсем недавно была такая же проблема с базой более 100к. Писал на форуме, доставал Ris-a, в итоге вся проблема оказалась именно в больших таблицах! Штатные средства из-за INNODB таблицы не лечили....
Вопрос решил радикальным способом:
1. Перевел проблемные таблицы в MySAM (лучше все таблицы типа контента) и прогнал их через оптимизацию и главное через восстановление таблиц! И так несколько раз!
2. Удалил и заново создал Наборы, так как именно на них возникают проблемы с индексами.
3. Проверил индексы на порядок их расположения (от этого тоже сильные тормоза)
4. Еще раз все прогнал через оптимизацию и восстановление
5. Вернул таблицы в INNODB
6. Перевел хостинг на PHP7,1 (дает серьезный прирост в скорости загрузки страниц)
Совсем забыл сообщить, что использую в качестве базы MariaDB 10.2.16 версию 10.3 пока ставить не рекомендую, у меня ее "плющило"…

приведите к виду

Помогло! Теперь летает))

Спасибо огромное!

приведите к виду:

По сути вы отключили использование индекса?

По сути вы отключили использование индекса?

Нет, лишь дал возможность оптимизатору MySQL самому принимать решение об использовании нужного индекса. Индекс по прежнему используется.

Нет, лишь дал возможность оптимизатору MySQL самому принимать решение об использовании нужного индекса. Индекс по прежнему используется.

На моей оптимизированной базе на хостинге с РНР7.1 прирост скорости составил около 25-30% на тяжелых таблицах. На более легких до 20%.
Но когда на сайт наваливаются поисковые боты эффект намного ниже около 5-10% уменьшения времени загрузки страниц.