Я пытаюсь устранить проблему с высокой нагрузкой на сервере. Сегодня по какой-то причине 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