在MySQL中执行建表或加索引语句时，如果收到错误信息“Too many keys specified; max 64 keys allowed”，意味着当前数据表试图定义的键（key）总数已经超过了MySQL单机实例里单表最多64个键的硬限制。这里的“键”不仅指主键，还包括唯一索引、普通索引、全文索引以及外键自动生成的索引等所有在表结构中占据一个key slot的对象。
一、理解MySQL的64键限制
MySQL在存储引擎层对每个表的索引数量有上限控制。以最常用的InnoDB引擎为例，虽然官方文档提到InnoDB自身支持更多索引，但在MySQL服务器层的表定义结构中，单个表允许的键数最大为64。这个计数方式是将每一个被显式声明为PRIMARY KEY、UNIQUE、INDEX或FULLTEXT的约束都算作一个键。即便是一个联合索引，也只占用一个键位，但如果在同一列上反复建不同类别的索引，就会分别计数。
很多人在排查时只数自己写的INDEX语句，却忽略了主键本身占用一个位、外键约束会自动建立索引、以及早期遗留的废弃索引没有删除。当表经过多次迭代，键数会在不知不觉中逼近64。一旦触发限制，任何新增索引的语句都会失败，影响业务扩展。
二、定位当前表的索引情况
要解决该报错，第一步是查清这张表到底有哪些键。可以通过information_schema库的STATISTICS表来统计，也可以直接用SHOW INDEX命令。下面给出一个查询示例，按表名统计索引数量及明细。
SELECT TABLE_NAME, INDEX_NAME, COUNT(*) AS column_count, GROUP_CONCAT(COLUMN_NAME ORDER BY SEQ_IN_INDEX) AS columns FROM information_schema.STATISTICS WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table' GROUP BY TABLE_NAME, INDEX_NAME;
执行后你能看到每个索引由哪些列组成。配合以下统计总键数的语句，可快速判断是否已达上限：
SELECT COUNT(DISTINCT INDEX_NAME) AS total_keys FROM information_schema.STATISTICS WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table';
如果total_keys已经接近64，就需要做减法。注意，主键在STATISTICS里也会以INDEX_NAME为PRIMARY出现，不要漏算。理清现状才能避免盲目删索引导致查询变慢。
三、合并与清理索引的实操方案
最常见的浪费是给每一列都建单列索引。比如表里有a、b、c三列，分别建了idx_a、idx_b、idx_c，而业务查询常常是WHERE a=? AND b=?。此时idx_a和idx_b可以被一个联合索引idx_ab替代，直接减少一个键。联合索引遵循最左前缀原则，能覆盖更多查询场景。
-- 原有多余索引 CREATE INDEX idx_a ON orders(a); CREATE INDEX idx_b ON orders(b); -- 优化后只保留联合索引 CREATE INDEX idx_ab ON orders(a, b); DROP INDEX idx_a ON orders; DROP INDEX idx_b ON orders;
另外，区分度极低的列（如性别、状态标志）单独建索引意义不大，且占用键位。若必须过滤，可放入联合索引右侧。对于历史遗留、已无查询使用的索引，应通过慢查询日志和运营后台确认后删除。清理时务必在测试环境验证，防止删错导致全表扫描。
四、当业务真需要超多检索维度时
若经过合并后仍需超过64个键，说明单表设计已无法承载查询复杂度。此时可考虑垂直分表，将不常用检索字段拆分到扩展表；或采用生成列加少量索引来变相实现多条件过滤。对全文搜索、标签检索等场景，更合理的做法是引入Elasticsearch等外部引擎，主库只保留核心索引。
-- 使用生成列减少直接索引数 ALTER TABLE product ADD COLUMN search_tag VARCHAR(100) GENERATED ALWAYS AS (CONCAT(cate, '-', brand)) VIRTUAL; CREATE INDEX idx_search_tag ON product(search_tag);
生成列把多个字段拼成一个值，只需一个索引即可支持组合查询，从而降低键总数。架构层面，将复杂搜索能力外移，既能突破64键约束，也能减轻数据库压力，是规模化系统的常见选择。
五、预防再次出现超限
建议在团队内部建立索引评审机制：新索引必须说明命中哪些SQL、为何不能合并进已有索引。定期用上面的统计SQL巡检核心表，将键数超过50的表列为预警。通过CI脚本在合并DDL前检查键数，能从源头避免报错。
控制索引数量不是越少越好，而是让每一个键都发挥价值。理解64键限制的本质，结合查询场景做减法与重构，才能保障MySQL表结构既灵活又稳定。