disable keys 在 innodb 中无效，仅对 myisam 表生效；innodb 需改用 drop index、set unique_checks=0、set foreign_key_checks=0 等方式优化批量插入。
DISABLE KEYS 在 InnoDB 中是否有效
MySQL 5.7 的 ALTER TABLE t DISABLE KEYS 对 InnoDB 表**基本无效**——它只对 MyISAM 表起作用。执行后不会报错，但也不会跳过二级索引更新，插入时仍会实时维护所有 B+ 树。如果你在 InnoDB 表上用了这句还觉得慢，不是配置没生效，而是它压根不支持该语义。
InnoDB 真正能禁用的只有约束检查
对 InnoDB 来说，可安全临时关闭的只有两类开销：唯一性校验和外键检查。它们不涉及索引结构重建，但能省掉每次插入时的哈希查重和关联表扫描。
-
SET UNIQUE_CHECKS = 0：跳过所有唯一索引（含主键、UNIQUE）的重复值检测——前提是数据本身无冲突，否则导入中途可能卡在ERROR 1062 -
SET FOREIGN_KEY_CHECKS = 0：跳过外键约束验证，避免每次 INSERT 都去主表查对应记录 - 二者必须成对使用，且仅限可信数据源；导入完成后务必立刻恢复为
1
替代 DISABLE KEYS 的实际提速操作
想绕过索引维护开销，InnoDB 下更可行的是“先清空索引，再重建”。但这不是禁用，而是拆解动作：
- 用
DROP INDEX idx_name ON t删除非主键索引（注意：主键无法删除） - 导入全部数据（此时只有主键 B+ 树在写入）
- 用
CREATE INDEX idx_name ON t (col)单独建索引——InnoDB 5.7+ 支持ALGORITHM=INPLACE, LOCK=NONE，只要满足 ROW 格式、无外键等前提，就能并发读写 - 若表有唯一索引，必须先用
SELECT col, COUNT(*) FROM t GROUP BY col HAVING COUNT(*) > 1清理重复值，否则CREATE UNIQUE INDEX直接失败且不提示具体哪行出问题
为什么很多人误以为 DISABLE KEYS 有用
因为 MySQL 客户端执行 SOURCE 导入 SQL 文件时，如果文件里混着 ALTER TABLE ... DISABLE KEYS 和 ENABLE KEYS，而目标表恰好是 MyISAM，就会真生效；一旦换成 InnoDB，这些语句就变成“静默无害的注释”。更隐蔽的问题是：某些 ORM 或迁移工具自动生成的 dump 脚本默认带这类语句，开发者没验证引擎类型就直接跑，结果性能毫无改善。
