DISABLE KEYS 仅对 MyISAM 表生效，InnoDB 忽略该命令且不报错；MyISAM 暂停非唯一索引更新以减少随机 I/O，而 InnoDB 需用 SET unique_checks=0 等组合策略提速。
DISABLE KEYS 只对 MyISAM 表生效，InnoDB 完全不认
执行 ALTER TABLE t DISABLE KEYS 时，如果表是 InnoDB 引擎，MySQL 不报错，但也不做任何事——所有二级索引照常更新，插入速度毫无变化。这是最常被误用的点。MyISAM 才真正依赖这个机制：它会暂停所有 KEY（即非唯一、非主键的索引）的实时写入，只保留主键和 UNIQUE KEY 的约束校验。
常见错误现象包括：
- 在 InnoDB 表上执行后发现
SHOW PROCESSLIST状态没变，插入依旧缓慢 - 误以为“关了索引就快了”，结果因没调
innodb_flush_log_at_trx_commit或事务太碎，仍被日志拖垮 - 对空表执行
DISABLE KEYS，实际无效（MyISAM 对空表本就不建索引）
为什么跳过非唯一索引更新能省掉大量随机 I/O
每插入一行，MySQL 不是只写一次数据页。InnoDB 和 MyISAM 都要同步更新聚簇索引 + 所有二级索引的 B+ 树叶子节点。每个二级索引物理位置分散，导致多次随机磁盘寻道。
10 个非唯一索引 = 每行插入触发至少 10 次随机写入。而 DISABLE KEYS（MyISAM）或等效的 DROP INDEX（InnoDB）把这些更新全部跳过，把 N × 行数 次小写，压缩为 1 次大排序 + 构建。实测中，5 个非唯一索引的 MyISAM 表，禁用后 LOAD DATA 速度可提升 4 倍以上。
注意：DISABLE KEYS 不影响主键和唯一索引校验，重复值仍会报错；DROP INDEX 则直接移除约束，导入前必须确认无冲突数据。
ENABLE KEYS 耗时比插入还长，这不是 bug 是设计
ENABLE KEYS 不是“打开开关”，而是启动一个单线程、全表扫描、外部排序式的索引重建流程。它会读取全部数据、按索引列排序、逐块构建 B+ 树并写入磁盘。这个过程 I/O 密集、不可中断、无法并行。
典型表现：
- 插入 100 万行用了 35 秒，
ENABLE KEYS却跑了 112 秒 -
iostat -x 1显示磁盘%util长期 98–100% - 临时索引文件可能膨胀至原数据体积的 1.3–1.7 倍，务必检查磁盘剩余空间
所以它只适合离线维护窗口，绝不能在业务高峰期执行。
InnoDB 表想提速，得换一套组合动作
InnoDB 没有真正意义上的 DISABLE KEYS，但可以通过等效策略达成类似效果：
-
SET unique_checks = 0：跳过唯一索引重复校验（仅限确认无冲突数据） -
SET foreign_key_checks = 0：跳过外键约束检查（确保无依赖关系） -
SET autocommit = 0+ 每 1000–5000 行COMMIT：避免事务过大撑爆日志缓冲区 - 配合
LOAD DATA INFILE或INSERT ... VALUES (...), (...), ...批量语法，而非单条拼接
别忘了导完立刻恢复：SET unique_checks = 1、SET foreign_key_checks = 1，否则后续写入可能静默破坏一致性。
真正容易被忽略的是：这些操作都要求你先确认引擎类型、索引结构、数据质量，而不是无脑套命令。一招鲜吃遍天的时代早过去了。
