MyISAM因不支持事务、无redo/undo log、表级锁及无崩溃恢复机制，易致数据损坏、原子性缺失、高并发阻塞与修复风险，生产环境应禁用。
MyISAM 不支持事务，INSERT/UPDATE 中途崩溃会导致数据损坏
MyISAM 没有 redo log 和 undo log，所有写操作直接刷盘。一旦在批量 INSERT 过程中发生断电、OOM 或 MySQL 进程被 kill，已写入部分数据无法回滚，未写入部分也不会补全——结果就是表处于“半截状态”，CHECK TABLE 很可能报 error: 126 / 134 / 144，必须用 REPAIR TABLE 或 myisamchk 强制修复，且修复后仍可能丢失数据。
MyISAM 的“原子性”只是单条 SQL 级别，不是事务级原子性
所谓 MyISAM “操作是原子性的”，仅指单条语句（如一条 UPDATE）内部不会只改一半行；但它完全不保证多语句逻辑的原子性。比如转账场景：UPDATE account SET balance = balance - 100 WHERE id = 1; 和 UPDATE account SET balance = balance + 100 WHERE id = 2; 必须成对成功或失败。MyISAM 下前一条成功、后一条失败，资金就凭空蒸发了。而 InnoDB 可用 BEGIN; ... COMMIT; 包裹，靠 undo log 保障整体回滚。
MyISAM 表级锁在高并发写场景下极易引发阻塞和死锁
任何写操作（INSERT、UPDATE、DELETE）都会对整张表加排他锁，期间所有读请求（SELECT）也得排队等待。更糟的是：MyISAM 写锁优先级高于读锁，即使已有 10 个 SELECT 在等，一个新来的 INSERT 会插队，导致读请求长时间饥饿。实际线上遇到过因单条慢 UPDATE 卡住整张用户信息表，连带影响登录、鉴权等核心链路。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
InnoDB 的崩溃恢复能力是 MyISAM 完全不具备的
MySQL 8.0 已彻底移除所有 MyISAM 系统表，说明官方早已放弃对其可靠性兜底。InnoDB 崩溃后重启时，自动通过 redo log 重放未刷盘的提交事务、用 undo log 回滚未提交事务，整个过程无需人工干预。而 MyISAM 表 crash 后，轻则数据错位，重则索引与数据文件（.MYD 和 .MYI）偏移不一致，REPAIR TABLE 可能越修越坏——这点在 SSD 老化或内核 I/O 错误时尤为致命。
生产环境禁用 MyISAM 不是教条，而是对“数据不能丢、业务不能断”底线的朴素响应。哪怕你只读多写少，只要涉及关键业务状态（如订单状态流转、库存扣减），MyISAM 的表级锁和无事务特性就会成为隐性单点故障源。真正需要的不是“能不能用”，而是“出问题时敢不敢担责”。
