disable keys仅对myisam生效，innodb执行无效果；myisam借此暂停非唯一索引更新，导入后enable keys一次性构建索引，大幅提升速度，但耗时长、i/o密集，仅适用于离线维护。
DISABLE KEYS 只对 MyISAM 表生效，InnoDB 完全不认这个命令
执行 ALTER TABLE t DISABLE KEYS 时如果表是 InnoDB 引擎，MySQL 不会报错，但也不会有任何效果——索引照常更新。这是最常被误用的点。MyISAM 才真正支持该机制：它会暂停所有非唯一索引（KEY）的实时写入，只保留主键和唯一索引约束。导入完再执行 ENABLE KEYS，才一次性构建 B+ 树索引文件。
常见错误现象包括：
- 在 InnoDB 表上执行
DISABLE KEYS后插入速度毫无改善 -
SHOW PROCESSLIST看到状态长期卡在Repair by sorting—— 其实是 MyISAM 表在重建索引，不是卡死 - 误以为“关了索引就安全”，结果因没关
unique_checks或事务提交太频繁，仍被日志刷盘拖慢
为什么禁用非唯一索引能省掉大量随机 I/O
每插入一行，MySQL 不是只写一次数据页，而是要同步更新聚簇索引 + 所有二级索引的叶子节点。每个二级索引都对应独立的 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：避免事务日志过大 - 导入前
DROP INDEX idx_name ON t，导入完CREATE INDEX idx_name ON t(col) - 优先用
LOAD DATA INFILE，它默认跳过非聚集索引维护（除非加KEEP_INDEXES）
特别注意：unique_checks = 0 下，如果实际存在重复值，MySQL 不会当场报错，也不会自动修复，而是在后续第一次访问该索引项时才触发冲突检测——这个延迟失败很难排查。
