MySQL: значительно медленнее выполнение запроса, если используется LIMIT 1 вместо LIMIT 5

я заметил резкое снижение скорости, если я LIMIT запрос к 1 вместо 5.

SELECT he. *
FROM homematic_events he
WHERE he.homematic_devices_id =30
ORDER BY id DESC
LIMIT 1 

вместо

SELECT he. *
FROM homematic_events he
WHERE he.homematic_devices_id =30
ORDER BY id DESC
LIMIT 5

В моей таблице содержится около 12 000 000 строк со следующей структурой:

CREATE TABLE IF NOT EXISTS `homematic_events` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `homematic_devices_id` int(11) DEFAULT NULL,
  `address` char(16) COLLATE utf8_unicode_ci NOT NULL,
  `interface_id` char(16) COLLATE utf8_unicode_ci NOT NULL,
  `key` char(32) COLLATE utf8_unicode_ci NOT NULL,
  `value` float(12,2) NOT NULL,
  `timestamp` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `timestamp` (`timestamp`),
  KEY `address` (`address`),
  KEY `key` (`key`),
  KEY `homematic_devices_id` (`homematic_devices_id`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=12637557 ;

Это объяснение измерения скорости для LIMIT 5:

  mysql> EXPLAIN SELECT he. * FROM homematic_events he WHERE he.homematic_devices_id =30 ORDER BY id DESC LIMIT 5;
  +----+-------------+-------+------+----------------------+----------------------+---------+-------+------+-----------------------------+
  | id | select_type | table | type | possible_keys        | key                  | key_len | ref   | rows | Extra                       |
  +----+-------------+-------+------+----------------------+----------------------+---------+-------+------+-----------------------------+
  |  1 | SIMPLE      | he    | ref  | homematic_devices_id | homematic_devices_id | 5       | const | 4171 | Using where; Using filesort |
  +----+-------------+-------+------+----------------------+----------------------+---------+-------+------+-----------------------------+


starting                          0.000010
checking query cache for query    0.000030
Opening tables                    0.000007
System lock                       0.000004
Table lock                        0.000015
init                              0.000019
optimizing                        0.000007
statistics                        0.000098
preparing                         0.000012
executing                         0.000002
Sorting result                    0.022965
Sending data                      0.000047
end                               0.000004
query end                         0.000002
freeing items                     0.000302
storing result in query cache     0.000009
logging slow query                0.000002
cleaning up                       0.000003

Это объяснение измерения скорости для LIMIT 1:

mysql> EXPLAIN SELECT he. * FROM homematic_events he WHERE he.homematic_devices_id =30 ORDER BY id DESC LIMIT 1;
+----+-------------+-------+-------+----------------------+---------+---------+------+------+-------------+
| id | select_type | table | type  | possible_keys        | key     | key_len | ref  | rows | Extra       |
+----+-------------+-------+-------+----------------------+---------+---------+------+------+-------------+
|  1 | SIMPLE      | he    | index | homematic_devices_id | PRIMARY | 4       | NULL | 3029 | Using where |
+----+-------------+-------+-------+----------------------+---------+---------+------+------+-------------+

starting                              0.000010
checking query cache for query        0.000034
Opening tables                        0.000009
System lock                           0.000004
Table lock                            0.000015
init                                  0.000020
optimizing                            0.000008
statistics                            0.000069
preparing                             0.000016
executing                             0.000002
Sorting result                        0.000005
Sending data                        502.290180
end                                   0.000010
query end                             0.000003
freeing items                         0.000293
logging slow query                    0.000004
logging slow query                    0.000002
cleaning up                           0.000003

Может ли кто-нибудь объяснить это поведение мне, пожалуйста? Я упоминаю, что это результат разного индекса, который udes с LIMIT 1. Но почему mysql использует разные ключи для разных значений LIMIT?

Ответы

Ответ 1

По какой-то причине MySQL как-то быстрее использует первичный ключ ID для доступа к этим строкам, а не к индексу. Несмотря на то, что в запросах вы специально используете поле, для которого был создан индекс homematic_devices_id. Мне также кажется странным, что MySQL во втором случае имеет homematic_devices_id под possible_keys, но затем выбирает PRIMARY. Обычно MySQL показывает как PRIMARY, так и другие возможные индексы в этом столбце.

Возможно ли, что это проблема, зависящая от данных? Вы пробовали свой запрос с другими device_id?

Попробуйте использовать FORCE INDEX в обоих случаях и посмотрите, можете ли вы устранить проблему.

Ответ 2

С LIMIT 1, я предполагаю, что анализатор запросов заглаживает первичный ключ и находит последнюю запись, чей homematic_devices_id =30 - по-видимому, потому, что анализатор знает, что операция сортировки будет дороже.

Когда вы LIMIT 5, я предполагаю, что анализатор запросов решает сначала найти записи, а затем сортировать их. Если вы хотите ускорить эту операцию, вы можете создать индекс как для homematic_devices_id, так и для ID так: ALTER TABLE homematic_events_test ADD INDEX ( homematic_devices_id, id ) - сначала помещая идентификатор устройства, вы размещаете предложение "Where", а столбец идентификатора помогает SORT

Ответ 3

Мое предположение заключается в том, что когда у вас есть и order by в сочетании с limit 1, запрос внутренне обрабатывается как max() (или min), который может быть достигнут сразу с индексом, тогда как когда вы запрашиваете a limit 5, сначала нужно выполнить упорядочение.