将SQL索引中key字段改为varchar(255)对AWS Aurora MySQL性能的影响

主要性能影响 #

• 索引存储与IO开销上升：你的唯一索引由session_id（8字节固定长度）和key字段组成。原key是varchar(24)，按utf8mb4字符集算单条最多占96字节；改成varchar(255)后，单条最多占1020字节。索引条目体积暴增会导致每页能容纳的索引数量大幅减少，执行索引扫描、范围查询时需要读取更多磁盘页，IO次数直接上升，性能下滑明显。AWS Aurora的底层存储基于SSD，虽能缓解IO延迟，但索引体积带来的页数量增加依然会有影响。
• 内存缓存效率降低：MySQL（包括Aurora）的缓冲池会缓存常用的索引页，更大的索引页意味着相同内存容量下，能缓存的索引条目更少，缓存命中率可能下降，进而导致更多磁盘IO请求。
• 写入操作成本增加：插入、更新、删除数据时，需要校验唯一索引的唯一性，更长的key字段会增加字符串比较的开销；同时因为单页容纳的索引条目少，索引页更容易被写满，触发页分裂的概率提升，写入延迟可能增加。
• 字符集参数限制：InnoDB默认对索引列总长度限制为767字节（utf8mb4下约191字符），如果你的Aurora实例没开启innodb_large_prefix参数，修改key为varchar(255)会直接失败。即使开启该参数允许更长的索引列，索引页的填充率会更低，进一步放大前面提到的性能问题。

影响可忽略的场景 #

• 如果业务中key字段的真实值长度基本都不超过24字符，只是修改了字段的最大长度限制，那索引的实际存储体积不会有变化，性能影响几乎可以忽略——因为MySQL只存储字段的实际字符长度，不是定义的最大长度。
• 该唯一索引仅用于精确匹配查询（比如WHERE session_id=? AND key=?），且查询频率很低，那么性能下降可能不会被业务感知到。

实操建议 #

• 先统计业务中key字段的真实数据长度，确认大部分值的长度范围，再评估修改的必要性。
• 修改前在测试环境复刻生产数据量和查询模式，验证索引扫描、写入操作的延迟变化。
• 提前检查Aurora实例的innodb_large_prefix参数状态，避免修改失败。

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