MyISAM在抢购时不会崩溃，而是因表级锁导致彻底阻塞；所有写操作触发整表排他锁，高并发下请求排队，表现为接口超时、QPS骤降、SHOW PROCESSLIST中大量线程卡在Waiting for table level lock。
MyISAM在抢购时卡死不是崩溃，而是表级锁彻底阻塞
MyISAM不会“崩溃”——它只是在高并发写入下被锁死，所有后续请求排队等待，现象是接口超时、QPS骤降、SHOW PROCESSLIST里大量线程卡在Waiting for table level lock。真正的崩溃（如Table is marked as crashed）通常发生在断电、kill -9 或 myisamchk 与 mysqld 同时操作同一张表时。
抢购场景下MyISAM的表级锁如何瞬间压垮服务
电商抢购本质是高频并发更新同一张表（比如stock或orders），而MyISAM对任何写操作都施加整表排他锁：
- 用户A执行
UPDATE stock SET qty = qty - 1 WHERE sku = 'A001'→ 整张stock表被锁 - 用户B、C、D……的同一条UPDATE全部排队，不读不写，连
SELECT COUNT(*)都会等锁 - MyISAM写锁优先级高于读锁，哪怕已有10个
SELECT在等，新来的INSERT会插队，导致读请求长期饥饿 -
Table_locks_waited / (Table_locks_immediate + Table_locks_waited)超过10%就该立刻干预
为什么修复后仍可能丢数据？MyISAM没有崩溃恢复能力
MyISAM没有redo log和undo log，所有变更直接刷盘到.MYD（数据）和.MYI（索引）文件。一次异常中断会导致：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 索引与数据文件不同步：查
COUNT(*)和SELECT * FROM t WHERE id > 1000返回矛盾结果 -
REPAIR TABLE只是暴力重建索引，不验证业务逻辑是否一致（比如库存数是否真扣减了） - 主从复制中，从库执行完
REPLACE INTO看似成功，但金额/状态已错位，且无错误日志可查 - SSD老化或I/O错误时，
myisamchk可能越修越坏，因为缺乏校验机制
InnoDB同样会卡，但原因完全不同——别误判为“MyISAM也行”
如果InnoDB在抢购中也变慢，大概率不是引擎问题，而是用法错误：
-
WHERE status = 1但status列没索引 → InnoDB退化为全表扫描+隐式表锁 - 事务未及时提交，
SELECT ... FOR UPDATE持有锁时间过长 → 其他事务持续等待 - 未开启
innodb_file_per_table = ON，大表删除无法释放空间，间接拖慢IO -
innodb_buffer_pool_size太小（低于物理内存70%），热点商品页频繁刷盘
真正要警惕的，是把InnoDB的性能问题归咎于“引擎不行”，然后退回MyISAM——这等于用更脆弱的机制去掩盖配置或SQL缺陷。
