MySQL复合索引最多16列，是InnoDB层面的硬性上限，超限会直接报错ERROR 1070；虽技术允许至16列，但实际建议不超过5列以保障性能与可维护性。
复合索引最多只能16列？是硬限制，不是建议
这是 InnoDB 层面的硬性上限，不是配置可调的“推荐值”。当你执行 CREATE INDEX 时，如果在括号里写了超过 16 个字段，MySQL 会直接报错：ERROR 1070 (42000): Too many key parts specified; max 16 parts allowed。
这个限制源于 InnoDB 内部索引元数据结构对“键部分（key part）”数量的编码约束，和行格式、字符集无关，也无法绕过。哪怕你只加 1 列，只要总数超 16，就失败。
- 注意：单列索引不计入此计数 —— 每个单列索引是独立的 1 个 key part；只有在一个
INDEX定义里显式列出多个字段，才累计为一个复合索引的 key parts - 例如：
INDEX idx_a_b_c (a, b, c)占用 3 个 key parts；INDEX idx_d (d)占用 1 个；两者共存不冲突 - 但
INDEX idx_long (c1,c2,...,c17)一定会失败
为什么官方文档说“最多16列”，却有人误以为是“最多16个索引”
混淆根源在于 MySQL 错误信息和文档表述的耦合点：早期版本中，ERROR 1070 的提示语是 “Too many key parts specified; max 16 parts allowed”，而“key parts”在中文语境里容易被简读为“键部分 → 键 → 索引”。再加上开发中常把“建索引”口语化为“加 key”，进一步强化了误解。
实际验证很简单：建一张空表，连续执行 20 次 ALTER TABLE t ADD INDEX idx_n (col_n)（每次单列），你会发现全部成功 —— 这说明 16 不是索引总数上限，而是单个索引的列数上限。
- 真正限制索引总数的是另一个规则：
64 个二级索引 + 1 个主键 = 65 个，但这是 InnoDB 表定义级的上限，和 16 列无关 - 如果你看到“表不能有超过 16 个索引”，那基本是团队规范或旧版 MyISAM 的遗留说法，不是当前 InnoDB 的事实
复合索引列数超过 5 就该警惕性能与维护成本
虽然技术上允许到 16 列，但业务表里真用满 16 列的复合索引几乎不存在，也不合理。每多一列，索引体积增大、写入开销上升、优化器选择难度增加 —— 更关键的是，**能被有效利用的前缀长度往往远小于总列数**。
- MySQL 只能使用最左侧前缀匹配查询，比如
(a,b,c,d)索引，对WHERE b = ? AND c = ?是完全无效的 - 索引列越多，数据更新时 B+ 树分裂/合并概率越高，
INSERT/UPDATE/DELETE延迟越明显 - 阿里《Java 开发手册》明确建议：“组合索引字段数不建议超过 5 个”，这不是拍脑袋，而是基于千万级订单表压测得出的拐点数据
- 真实案例：某用户表加了
(tenant_id, status, create_time, user_type, region, channel)六列索引，结果UPDATE平均耗时从 8ms 升至 42ms，且EXPLAIN显示只有前 3 列被真正用到
前缀索引能突破单列长度限制，但不能绕过 16 列总数限制
当字段本身很长（比如 varchar(1000)），你可以用 name(50) 这种前缀方式缩短索引长度，避免触发 3072 字节 的单索引长度上限。但这只是解决“单列太长”的问题，对“列数太多”无能为力。
例如：INDEX idx_full (title(100), content(200), tag(30), author_id, created_at) —— 这仍是 5 列，没超 16；但如果你试图再加第 6 个字段，哪怕全是 tinyint，依然会触发 ERROR 1070。
- 前缀索引只影响索引项的存储大小和区分度，不影响 key parts 计数逻辑
-
innodb_large_prefix=ON解决的是字节长度限制（767→3072），不是列数限制 - 真正想“变相扩容”的做法，是引入哈希列（如
sha2(concat(col1,col2,col3),224)）并单独建索引，但这属于应用层权衡，不是索引语法层面的突破
