MySQL百万级example表最优索引选型咨询

方案选择：新增二级唯一联合索引，无需替换主键 #

不要将五个字段的组合调整为主键，优先选择新增二级唯一联合索引，原因如下：

• InnoDB主键采用聚簇索引结构，若使用5字段组合作为主键，会导致所有二级索引（包括你现有user_id的索引、后续可能新增的其他索引）的存储体积大幅膨胀：原主键id为4字节INT类型，5个SMALLINT组合总长度为10字节，所有二级索引的叶子节点都会存储主键值，主键体积翻倍会直接提升全表索引的存储空间占用，也会降低索引查询时的缓存命中率。
• 非自增主键会导致写入时出现大量随机IO和页分裂问题：你当前的自增id作为主键可以保证写入时顺序追加，性能远高于无序的多字段组合主键。
• 你需要用id做排序，id作为主键时排序性能最优，若改为二级索引，排序场景下大概率需要回表查询，性能反而下降。

联合索引优化建议 #

直接创建唯一联合索引即可，索引字段顺序无需特殊调整（因为你的核心场景是五个字段全等值匹配，字段顺序对查询性能影响极小），建索引语句参考：

CREATE UNIQUE INDEX uniq_node_version ON example (node0, node1, node2, node3, version);

如果要进一步优化核心查询的性能，可以把关联需要的user_id也加到联合索引中做成覆盖索引，避免回表开销：

CREATE UNIQUE INDEX uniq_node_version ON example (node0, node1, node2, node3, version, user_id);

这样核心查询在匹配到五个字段的条件后，直接从索引中就能拿到user_id去关联user表，不需要再访问聚簇索引查询数据，性能提升明显。

不需要为单个字段单独创建索引 #

你的核心查询是多字段联合等值查询，单字段索引无法满足该场景的查询需求，反而会额外增加写入时的索引维护开销、占用更多存储空间，完全没有必要创建。

内容的提问来源于stack exchange，提问作者Stéphane