Question

我有一个直接的表，目前有~10M行。这是定义：

CREATE TABLE `train_run_messages` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `train_id` int(10) unsigned NOT NULL,
  `customer_id` int(10) unsigned NOT NULL,
  `station_id` int(10) unsigned NOT NULL,
  `train_run_id` int(10) unsigned NOT NULL,
  `timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `type` tinyint(4) NOT NULL,
  `customer_station_track_id` int(10) unsigned DEFAULT NULL,
  `lateness_type` tinyint(3) unsigned NOT NULL,
  `lateness_amount` mediumint(9) NOT NULL,
  `lateness_code` tinyint(3) unsigned DEFAULT '0',
  `info_text` varchar(32) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `timestamp` (`timestamp`),
  KEY `lateness_amount` (`lateness_amount`),
  KEY `customer_timestamp` (`customer_id`,`timestamp`),
  KEY `trm_customer` (`customer_id`),
  KEY `trm_train` (`train_id`),
  KEY `trm_station` (`station_id`),
  KEY `trm_trainrun` (`train_run_id`),
  KEY `FI_trm_customer_station_tracks` (`customer_station_track_id`),
  CONSTRAINT `FK_trm_customer_station_tracks` FOREIGN KEY (`customer_station_track_id`) REFERENCES `customer_station_tracks` (`id`),
  CONSTRAINT `trm_customer` FOREIGN KEY (`customer_id`) REFERENCES `customers` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION,
  CONSTRAINT `trm_station` FOREIGN KEY (`station_id`) REFERENCES `stations` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION,
  CONSTRAINT `trm_train` FOREIGN KEY (`train_id`) REFERENCES `trains` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION,
  CONSTRAINT `trm_trainrun` FOREIGN KEY (`train_run_id`) REFERENCES `train_runs` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB AUTO_INCREMENT=9928724 DEFAULT CHARSET=utf8;

我们有很多查询按customer_id和timestamp进行过滤，因此我们为此创建了一个组合索引。

现在我有了这个简单的查询：

SELECT * FROM `train_run_messages` WHERE `customer_id` = '5' AND `timestamp` >= '2013-12-01 00:00:57' AND `timestamp` <= '2013-12-31 23:59:59' LIMIT 0, 100

在我们当前拥有约10M条目的机器上，这个查询需要大约16秒，这是我的口味，因为有一个像这样的查询索引。

让我们看看这个查询的解释输出：

+----+-------------+--------------------+------+-------------------------------------------    +--------------------+---------+-------+--------+-------------+
| id | select_type | table              | type | possible_keys                             | key                | key_len | ref   | rows       | Extra       |
+----+-------------+--------------------+------+-------------------------------------------+--------------------+---------+-------+--------+-------------+
|  1 | SIMPLE      | train_run_messages | ref  | timestamp,customer_timestmap,trm_customer | customer_timestamp | 4       | const | 551405     | Using where |
+----+-------------+--------------------+------+-------------------------------------------+--------------------+---------+-------+--------+-------------+

所以MySQL告诉我它会使用customer_timestamp索引，没问题！为什么查询仍然需要大约16秒？因为我并不总是相信MySQL查询分析器让我们尝试使用强制索引：

SELECT * FROM `train_run_messages` USE INDEX (customer_timestamp) WHERE `customer_id` = '5' AND `timestamp` >= '2013-12-01 00:00:57' AND `timestamp` <= '2013-12-31 23:59:59' LIMIT 0, 100

查询时间：0.079秒!!

我：困惑！

所以有人可以解释为什么MySQL显然没有使用它说它会从EXPLAIN输出中使用的索引吗？有没有办法证明它在执行真实查询时真正使用了什么索引？

Btw：这是慢速日志的输出：

# Time: 131217 11:18:04
# User@Host: root[root] @ localhost [127.0.0.1]
# Query_time: 16.252878  Lock_time: 0.000168 Rows_sent: 100  Rows_examined: 9830711
SET timestamp=1387275484;
SELECT * FROM `train_run_messages` WHERE `customer_id` = '5' AND `timestamp` >= '2013-12-01 00:00:57' AND `timestamp` <= '2013-12-31 23:59:59' LIMIT 0, 100;

尽管它没有特别说它没有使用任何索引，但Rows_examined建议它进行完整的表扫描。

这样可以在不使用USE INDEX的情况下修复吗？我们使用Propel作为ORM，目前无法在不手动编写查询的情况下使用特定于MySQL的“USE INDEX”。

修改这是EXPLAIN和USE INDEX的输出：

+----+-------------+--------------------+-------+--------------------+--------------------+---------+------+--------+-------------+
| id | select_type | table              | type  | possible_keys      | key                | key_len | ref  | rows   | Extra       |
+----+-------------+--------------------+-------+--------------------+--------------------+---------+------+--------+-------------+
|  1 | SIMPLE      | train_run_messages | range | customer_timestmap | customer_timestmap | 8       | NULL | 191264 | Using where |
+----+-------------+--------------------+-------+--------------------+--------------------+---------+------+--------+-------------+

Answer 1

MySQL有三个候选索引

（时间戳）
（customer_id，timestamp）
（CUSTOMER_ID）

你问的是

`customer_id` = '5' AND `timestamp` BETWEEN ? AND ?

优化程序已从统计信息中选择(customer_id, timestamp)。

InnoDB Engine的优化器依赖于在表打开时使用采样的统计信息。默认采样在索引文件上读取8页。

所以，我建议如下三件事

增加innodb_stats_sample_pages=64。
- innodb_stats_sample_pages的默认值为8页。
- 请参阅http://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_stats_sample_pages
删除redandant索引。以下索引就好了。目前只有customer_id = 5（你说）
- （时间戳）
- （CUSTOMER_ID）
运行OPTIMIZE TABLE train_run_messages重新组织表格。
- 这会减少表和索引的大小，有时这会使优化器更智能

Answer 2

对我来说，最重要的是它将您的客户ID包装在引号中失败...例如='5'。通过这样做，它无法使用客户/时间戳索引，因为客户ID需要转换为字符串以匹配您的'5'与仅= = 5，您应该很高兴。

为什么MySQL不使用EXPLAIN中的索引？

2 个答案: