MySQL字符串列索引存储机制及UUID主键索引大小影响咨询

嘿，这两个问题问得很到位，刚好是日常MySQL索引优化里的关键细节，我来给你拆解清楚：

首先明确：MySQL的B树索引（包括InnoDB的聚簇索引、二级索引）存储的是字符串的原始内容（或指定前缀），而非哈希整数值。这里要区分两种情况：

• 常规的B树索引：不管是VARCHAR、CHAR还是TEXT列（只要能建索引），InnoDB都会按照字符串的字典序来存储完整或指定长度的字符串内容。这么做的核心原因是为了支持范围查询（比如WHERE username LIKE 'zhangsan%'）、排序、分组这类依赖有序性的操作——如果存哈希值，这些操作根本没法高效执行，因为哈希值是无序的。
• 特殊的哈希索引：只有Memory引擎默认用哈希索引，或者InnoDB的自适应哈希索引（这是InnoDB在内存中自动构建的优化结构，不是磁盘上持久化的索引），才会用哈希值存储。但这类哈希索引只支持等值查询，不支持范围操作，适用场景很有限。

另外补充：MySQL支持前缀索引，比如你可以执行CREATE INDEX idx_email ON users(email(15));，这种情况下B树里只会存储字符串的前15个字符，能大幅节省索引空间，但代价是可能降低索引的区分度，增加查询时的回表次数。

这部分要结合InnoDB的聚簇索引特性来看：InnoDB的主键就是聚簇索引，所有二级索引的叶子节点都会包含主键值，所以主键的大小直接决定了整个索引体系的体积。

UUID通常是36个字符的字符串（比如550e8400-e29b-41d4-a716-446655440000），和自增INT（4字节）、BIGINT（8字节）比，体积差距非常大，带来的影响主要有：

• 聚簇索引空间暴增：每个主键条目要存储36个字符（如果是UTF8MB4编码，每个字符最多4字节，那就是144字节；如果是ASCII兼容的编码，比如latin1或utf8，是36字节），而INT只有4字节，空间占用差了9倍以上。
• 二级索引体积翻倍增长：所有二级索引的每条记录都会携带这个主键值，比如你有5个二级索引，每个索引的每条记录都要多存36字节，这会让整个索引文件的体积大幅膨胀，不仅占用更多磁盘空间，还会降低缓存命中率——同样的内存能缓存的索引条目更少，查询时需要更多磁盘IO，性能下降明显。
• 写入性能受影响：UUID是完全无序的，每次插入新的UUID主键时，InnoDB需要在聚簇索引的中间位置插入数据，频繁触发页分裂，导致写入变慢，同时索引会变得碎片化，进一步影响后续的查询效率。

如果业务必须用UUID做主键，给你两个优化方向：

• 把UUID转换成二进制存储：用UNHEX(REPLACE(uuid(), '-', ''))把36字符的UUID转成16字节的二进制，能把主键体积从36字节降到16字节，大幅节省空间。查询时再用HEX(uuid_bin)转成字符串即可。
• 使用有序UUID：比如基于时间戳生成的UUID（UUIDv1或自定义规则），让新插入的主键尽量有序，减少页分裂的发生，提升写入性能。

内容的提问来源于stack exchange，提问作者bazinga012