Как предотвратить медленный запрос от курения сервера

Автор оригинала: David Wong.

Привет? ХХХ? Что не так с вашим сервисом? Машина снова мертва! А? Сколько из них было повешено? Ты одолжил 40 комплектов и повесил два! Подожди, дай мне посмотреть, что случилось!

Сервер снова закурил из-за этого:

Некоторое время назад проект положил начало фестивалю “Пик Циси”. Изначально интерфейс SQL был таким:

mysql> explain SELECT *,sum(num) AS sum FROM search WHERE search_time >= '2016-08-30' AND type = 0 AND state = 1 GROUP BY keyword ORDER BY sum DESC LIMIT 50;
+----+-------------+-----------+------+--------------------------+------+---------+-------+--------+----------------------------------------------+
| id | select_type | table     | type | possible_keys            | key  | key_len | ref   | rows   | Extra                                        |
+----+-------------+-----------+------+--------------------------+------+---------+-------+--------+----------------------------------------------+
|  1 | SIMPLE      | search | ref  | type,search_time,keyword | type | 2       | const | 651114 | Using where; Using temporary; Using filesort |
+----+-------------+-----------+------+--------------------------+------+---------+-------+--------+----------------------------------------------+

время поиска , тип , состояние Были построены индексы. тип и государство Диапазон значений ограничен, поэтому он в основном бесполезен, в основном в зависимости от search_time Но объясните Результат указывает на то, что не используется допустимый индекс, и на самом деле таблица содержит 130w+ Выполнение этой инструкции занимает в среднем некоторое время при наличии данных. 5с Многое, должно быть, невыносимо.

А как насчет обязательной индексации? Попробуйте:

mysql> explain SELECT *,sum(num) AS sum FROM search FORCE INDEX (search_time) WHERE search_time >= '2016-08-30' AND type = 0 AND state = 1 GROUP BY keyword ORDER BY sum DESC LIMIT 50;
+----+-------------+-----------+-------+---------------------+-------------+---------+------+--------+---------------------------------------------------------------------+
| id | select_type | table     | type  | possible_keys       | key         | key_len | ref  | rows   | Extra                                                               |
+----+-------------+-----------+-------+---------------------+-------------+---------+------+--------+---------------------------------------------------------------------+
|  1 | SIMPLE      | search | range | search_time,keyword | search_time | 4       | NULL | 290616 | Using index condition; Using where; Using temporary; Using filesort |
+----+-------------+-----------+-------+---------------------+-------------+---------+------+--------+---------------------------------------------------------------------+

Эффективный. строки падение до 29 Вт Это не слишком медленно, чтобы проверить 29 Вт, но вы все это знаете. объясните Li строки Это всего лишь ссылка, но для ее реального запуска все равно требуется время. 3с Много, но и невыносимо.

Эта машина базы данных также управляет другими предприятиями, которые имеют большое значение. Нагрузка на сервер не низкая. Циси еще не приехала. Поскольку этот SQL заставляет сервер дымить напрямую, медленный запрос этого бизнеса также замедляет время выполнения других предприятий, что приводит к цепной реакции.

Ранее считанная часть данных была кэширована, но записи журнала по-прежнему показывают, что в течение определенного периода времени генерируется большое количество медленных запросов. Сначала мы подозревали, что кэш был недействителен, но позже мы обнаружили, что высокий параллелизм фактически привел к этапу кэширования. Из-за длительного времени выполнения инструкций SQL это вызвало большое количество медленных запросов к базе данных за эти пять секунд.

Давайте сразу перейдем к решению.

1. Уменьшите объем запроса на предыдущий запрос 3 дня Изменить на запрос 1 день Величина уменьшается до 130 Вт+ Данные.

2. Принудительное использование индекса может в некоторой степени сократить время запроса.

3. Напишите сценарий для регулярного сохранения результатов запроса в memcache В случае высокой параллелизма это в основном делается для предотвращения большого количества обращений к базе данных за короткое время в ожидании записи в mc.

4. Кэшируйте результаты чтения базы данных.

5. Кэшируйте результаты интерфейса.

Выполнив эти пять шагов, моей маме больше не нужно беспокоиться о моем сервере курение.~~

Примечание: Позже я постепенно перенесу сюда другие блоги, и в основном я буду писать здесь позже.

Оригинал: “https://developpaper.com/how-to-prevent-a-slow-query-from-smoking-the-server/”