为什么在包含char版本的UUID的列中添加索引会降低性能？

Question

我有一个包含350万行的表，在其ascii表示形式中包含UUID(所以36个字符)和一个整数。

我需要按UUID对所有金额进行汇总，所以查询非常简单：

SELECT uuid, SUM(amount) FROM table GROUP BY uuid;

结果：

• uuid上的索引:时间:68.074 s
• 没有索引:时间: 8.188s

具有索引的执行计划：

| id | select_type | table  | type  | possible_keys    | key      | key_len | ref    | rows    | Extra  |
+----+-------------+-----------------------------+-------+------------------+------------------+---------+
| 1  | SIMPLE      | amount | index | uuid_idx         | uuid_idx | 110     | <null> | 3424833 | <null> |
+----+-------------+-----------------------------+-------+------------------+------------------+---------+

没有索引的执行计划：

| id | select_type | table  | type | possible_keys | key    | key_len | ref    | rows    | Extra                           |
+----+-------------+-----------------------------+------+---------------+--------+---------+--------+---------+-------------
| 1  | SIMPLE      | amount | ALL  | <null>        | <null> | <null>  | <null> | 3424833 | Using temporary; Using filesort |
+----+-------------+-----------------------------+------+---------------+--------+---------+--------+---------+-------------

我是遗漏了什么，还是该列上的索引确实极大地降低了此类查询的性能？

Answer 1

EXPLAINs显示，在索引中，它使用了索引。这就导致了跳来跳去:选择下一个字母UUID，把手伸进表中的任意位置，为行找到要总结的金额。

如果没有索引，它只需直接遍历表，收集数据，然后排序以完成任务。

350万个随机查找显然比350万行要长。

将UUID收敛到BINARY(16)将使其缩小，从而略有帮助。

拥有INDEX(uuid, amount)将大大加快此查询的速度。但是，uuid的随机性仍然是一种性能拖累。

相关讨论：http://mysql.rjweb.org/doc.php/uuid