mysql创建表并设置createtime(int)作为索引,但是选择不使用,那为什么呢?

时间:2019-06-22 08:57:18

标签: mysql

mysql创建表并为索引设置createtime(int),但是选择不使用,为什么?

mysql> EXPLAIN SELECT
    -> player_id,
    -> COUNT(*) AS count_num,
    -> SUM( add_gold ) AS sum_add_gold
    -> FROM
    -> cloud_data_player_gold_log
    -> WHERE
    -> 1 = 1
    -> AND create_time >= 1561046400
    -> GROUP BY
    -> player_id
    -> ORDER BY
    -> sum_add_gold ASC
    -> LIMIT 0, 10;
+----+-------------+----------------------------+------------+------+---------------+------+---------+------+--------+----------+----------------------------------------------+
| id | select_type | table                      | partitions | type | possible_keys | key  | key_len | ref  | rows   | filtered | Extra                                        |
+----+-------------+----------------------------+------------+------+---------------+------+---------+------+--------+----------+----------------------------------------------+
|  1 | SIMPLE      | cloud_data_player_gold_log | NULL       | ALL  | create_time   | NULL | NULL    | NULL | 555659 |    44.47 | Using where; Using temporary; Using filesort |
+----+-------------+----------------------------+------------+------+---------------+------+---------+------+--------+----------+----------------------------------------------+
1 row in set, 1 warning (0.00 sec)
mysql> show index from cloud_data_player_gold_log;
+----------------------------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| Table                      | Non_unique | Key_name    | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible | Expression |
+----------------------------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| cloud_data_player_gold_log |          0 | PRIMARY     |            1 | log_id      | A         |      555659 |     NULL |   NULL |      | BTREE      |         |               | YES     | NULL       |
| cloud_data_player_gold_log |          1 | channel_id  |            1 | channel_id  | A         |           6 |     NULL |   NULL |      | BTREE      |         |               | YES     | NULL       |
| cloud_data_player_gold_log |          1 | game_id     |            1 | game_id     | A         |          12 |     NULL |   NULL |      | BTREE      |         |               | YES     | NULL       |
| cloud_data_player_gold_log |          1 | game_id_2   |            1 | game_id     | A         |          12 |     NULL |   NULL |      | BTREE      |         |               | YES     | NULL       |
| cloud_data_player_gold_log |          1 | game_id_2   |            2 | room_id     | A         |          14 |     NULL |   NULL |      | BTREE      |         |               | YES     | NULL       |
| cloud_data_player_gold_log |          1 | create_time |            1 | create_time | A         |       15356 |     NULL |   NULL |      | BTREE      |         |               | YES     | NULL       |
+----------------------------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
6 rows in set (0.04 sec)

表总数据行为560000,sql运行时间超过0.6s

1 个答案:

答案 0 :(得分:1)

MySQL假定create_time >= 1561046400之后有大量行(44%)。如果使用索引,则意味着MySQL必须通过在表中来回跳转来读取表的一半。由于数据存储在块中(包含多于1行),因此它实际上会读取表大小几次,因为对于每个有用的行,它还会读取一些不需要的行(尽管通过缓存可以缓解很多情况)。

在这种情况下,更快地只从头到尾读取整个表一次,然后将不需要的行扔掉,这是MySQL决定在这里做的。

通过覆盖索引(create_time, player_id, add_gold),可以通过在索引中提供它需要的所有数据来防止MySQL读取实际的表数据。然后,它只需从create_time >= 1561046400读取索引就可以一口气结束,而无需花费时间在表内跳转。

如果MySQL估计不正确,例如在您的时间范围内实际上可能只有少数几行,或者,如果您只想使用索引测试执行时间,则可以force MySQL与它一起使用。

... FROM cloud_data_player_gold_log FORCE INDEX (create_time) WHERE ...

这具有一个普遍的缺点,即MySQL无法适应更改后的数据,不同的create_time参数或其他过滤器,例如如果使用其他索引实际上会更快。

您可以尝试的替代索引是(player_id, create_time)(或覆盖(player_id, create_time, add_gold)),它支持group by

这取决于您的数据分布,哪个会更快:以create_time开头的索引必须读取较少的行,以player_id开头的索引必须减少一个时间。取决于行数,一个会抵消另一行。