Назад | Перейти на главную страницу

MySQL высокая загрузка процессора медленные запросы регистрируются, нужна помощь, чтобы понять

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

В таблицах около 700 тыс. Строк.

SELECT SUM( likes ) AS likes, image_id FROM post_files_likes WHERE image_id NOT IN(563593,591800,578109,581180,515832,646310,670601,626185,689090,80019,399472,468198) AND date > DATE_SUB( '2013-08-19' , INTERVAL 1 MONTH ) GROUP BY image_id ORDER BY likes DESC LIMIT 12;

`

mysql> describe post_files_likes
    -> ;
+----------+---------+------+-----+---------+----------------+
| Field    | Type    | Null | Key | Default | Extra          |
+----------+---------+------+-----+---------+----------------+
| id       | int(10) | NO   | PRI | NULL    | auto_increment |
| image_id | int(10) | NO   | MUL | NULL    |                |
| likes    | int(11) | NO   |     | NULL    |                |
| date     | date    | NO   |     | NULL    |                |
+----------+---------+------+-----+---------+----------------+
4 rows in set (0.00 sec)

mysql> EXPLAIN SELECT SUM( likes ) AS likes, image_id FROM post_files_likes WHERE image_id NOT IN(563593,591800,578109,581180,515832,646310,670601,626185,689090,80019,399472,468198) AND date > DATE_SUB( '2013-08-19' , INTERVAL 1 MONTH ) GROUP BY image_id ORDER BY likes DESC LIMIT 12;
+----+-------------+------------------+-------+---------------------+------------+---------+------+--------+----------------------------------------------+
| id | select_type | table            | type  | possible_keys       | key        | key_len | ref  | rows   | Extra                                        |
+----+-------------+------------------+-------+---------------------+------------+---------+------+--------+----------------------------------------------+
|  1 | SIMPLE      | post_files_likes | range | image_id,image_id_2 | image_id_2 | 4       | NULL | 709885 | Using where; Using temporary; Using filesort |
+----+-------------+------------------+-------+---------------------+------------+---------+------+--------+----------------------------------------------+
1 row in set (2.92 sec)

Я выполнил этот запрос несколько раз и получил от 0 до 30 секунд.

Что-то в этом вопросе не так? или этот запрос занимает много времени из-за других проблем с mysql?

РЕДАКТИРОВАТЬ

 SHOW INDEX FROM post_files_likes;
+------------------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table            | Non_unique | Key_name   | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+------------------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| post_files_likes |          0 | PRIMARY    |            1 | id          | A         |      710969 |     NULL | NULL   |      | BTREE      |         |
| post_files_likes |          0 | image_id   |            1 | image_id    | A         |      355484 |     NULL | NULL   |      | BTREE      |         |
| post_files_likes |          0 | image_id   |            2 | date        | A         |      710969 |     NULL | NULL   |      | BTREE      |         |
| post_files_likes |          1 | image_id_2 |            1 | image_id    | A         |      355484 |     NULL | NULL   |      | BTREE      |         |
+------------------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
4 rows in set (0.05 sec)

ИЗМЕНИТЬ Добавленные индексы

mysql> SHOW INDEX FROM post_files_likes;
+------------------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table            | Non_unique | Key_name   | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+------------------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| post_files_likes |          0 | PRIMARY    |            1 | id          | A         |      711181 |     NULL | NULL   |      | BTREE      |         |
| post_files_likes |          0 | image_id   |            1 | image_id    | A         |        NULL |     NULL | NULL   |      | BTREE      |         |
| post_files_likes |          0 | image_id   |            2 | date        | A         |      711181 |     NULL | NULL   |      | BTREE      |         |
| post_files_likes |          1 | image_id_2 |            1 | image_id    | A         |      237060 |     NULL | NULL   |      | BTREE      |         |
| post_files_likes |          1 | likes      |            1 | likes       | A         |         445 |     NULL | NULL   |      | BTREE      |         |
| post_files_likes |          1 | likes      |            2 | date        | A         |        4709 |     NULL | NULL   |      | BTREE      |         |
| post_files_likes |          1 | likes      |            3 | image_id    | A         |      711181 |     NULL | NULL   |      | BTREE      |         |
+------------------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+

По сути, в запросе нет ничего неправильного, но вы забыли сообщить нам, как настроены индексы.

Оптимально этот запрос будет использовать индекс BTREE для post_files_likes.date, но есть случаи, когда он не будет использоваться СУБД / не улучшит производительность (например, если мощность столбца даты низка, СУБД не будет используйте его, индекс на основе хэша очень неэффективен для поиска диапазонов данных).

Добавление image_id, а затем LIKES к индексу (ПОСЛЕ даты) означает, что индекс покрывает, и запрос может быть удовлетворен без ссылки на данные таблицы. Но можно ли поставить лайк более одного раза в одно и то же время?

Если вы часто запускаете этот запрос, то денормализация и / или кеширование результатов поможет, поскольку (опять же, исходя из контекста) данные не нужны в реальном времени.

Эта таблица проиндексирована?

SHOW INDEX FROM post_files_likes;

Сколько строк было возвращено этим запросом (без СУММ)?

Ваш my.cnf оптимизирован для этого?

Попробуйте настроить параметры для оптимальной конфигурации, хотя бы с помощью этого: https://raw.github.com/major/MySQLTuner-perl/master/mysqltuner.pl

Из вашего плана запроса:

Using where; Using temporary; Using filesort

Это будет отстой. Он будет использовать временную таблицу на диске.

Вероятная причина этого в том, что mysql использует ключ image_id_2, что делает не укажите дату, потому что вы используете DATE_SUB(...) вместо простого сравнения. Попробуйте предварительно рассчитать дату отсечения в своем коде и использовать date >= that-date-here