delay_key_write仅加速myisam写操作，不提升查询性能；必须配myisam-recover=force,backup才可控，否则异常退出易致索引损坏；全局变量需匹配表定义，且myisam本身已不适合作为高可靠业务引擎。
DELAY_KEY_WRITE 不提升查询性能，只加速写操作；但它会显著增加索引损坏风险，且必须配 --myisam-recover 才能勉强可控。
DELAY_KEY_WRITE 是写优化，不是查询加速器
它只影响 INSERT、UPDATE、DELETE 过程中索引页的刷盘时机：把原本每次变更都写磁盘的动作，推迟到表关闭时批量执行。普通 SELECT 完全不受影响——既不更快，也不更慢。
常见误解是“开了就快”，但实际场景中：
- 如果你的业务以读为主（比如报表查询、静态页面缓存），开启后毫无收益
- 如果写入频率低、或表经常被
FLUSH TABLES触发关闭，延迟效果也极弱 - 真正受益的是高频小批量写 + 大索引 + 机械硬盘的 MyISAM 表（如日志归档表）
不配 myisam-recover 就等于放弃数据一致性
一旦 MySQL 异常退出（kill -9、断电、OOM killer），所有未刷盘的索引变更永久丢失。下次启动时，SELECT 可能返回错误结果、CHECK TABLE 报 error: 1034、甚至整个表无法打开。
必须在 my.cnf 的 [mysqld] 段明确配置：
myisam-recover=FORCE,BACKUP
这个选项不是可选补丁，而是安全底线。它让 MySQL 启动时自动扫描所有 MyISAM 表，发现索引不一致就强制修复并备份原索引文件。没有它，DELAY_KEY_WRITE=1 就是定时炸弹。
全局变量 delay_key_write 必须匹配表定义
光在建表或 ALTER TABLE 里写 DELAY_KEY_WRITE = 1 不生效。MySQL 还要看全局开关：
-
SET GLOBAL delay_key_write = 'OFF'：所有表禁用，无论表定义如何 -
SET GLOBAL delay_key_write = 'ON'：仅对显式声明了DELAY_KEY_WRITE = 1的表启用 -
SET GLOBAL delay_key_write = 'ALL'：所有 MyISAM 表强制启用（含未声明的）
这个变量不能靠 mysqladmin reload 生效，必须重启 MySQL 或用 SET GLOBAL 动态设置。生产环境务必写进配置文件并重启，避免服务漂移后失效。
MyISAM 本身就不该用于高可靠写场景
哪怕配齐了 DELAY_KEY_WRITE 和 myisam-recover，MyISAM 仍无事务、无崩溃安全、无行级并发。一次修复可能花数分钟，期间整张表只读。现在还坚持用 MyISAM 做核心业务表，本质是在用 2005 年的技术解 2026 年的问题。
真正该做的不是调优 MyISAM，而是评估迁移成本：ALTER TABLE t ENGINE=InnoDB 虽然耗时，但换来的是 MVCC、行锁、崩溃恢复、在线 DDL —— 这些才是现代 OLTP 的基础。延迟索引写入，只是给一个过时引擎打的止痛针，不是升级方案。
