电商订单表用MyISAM等于主动放弃数据一致性、并发可用性和故障自恢复能力：其表级锁导致抢购时整表阻塞，无事务致下单中途失败数据不一致，无redo/undo log致崩溃后逻辑错乱且无法自动恢复，MySQL 8.0.33起更因系统表校验强制禁用。
电商订单表用 MyISAM 就等于主动放弃数据一致性、并发可用性和故障自恢复能力——不是“性能差一点”，而是核心链路随时可能断裂。
MyISAM 的表级锁会让抢购接口直接挂起
订单创建本质是高频写操作，而 MyISAM 对任何 INSERT、UPDATE、DELETE 都加整表排他锁。哪怕只更新一条订单状态，orders 表所有其他读写请求全得排队。
- 现象：用户点“立即购买”后长时间转圈，
SHOW PROCESSLIST显示大量线程卡在Waiting for table level lock - 更糟的是：写锁优先级高于读锁，已有 10 个
SELECT在等，一个新INSERT会插队，导致读请求长期饥饿 - 监控指标
Table_locks_waited / (Table_locks_immediate + Table_locks_waited)超过 10%，说明已进入阻塞临界点
没有事务 = 下单成功但库存没扣、余额没减
电商下单必须原子化完成：扣库存 + 写订单 + 减余额。MyISAM 没有 undo log，也没有事务边界，中间任意一步失败（如网络中断、OOM），数据库就停在半截状态。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 常见错误现象：
SELECT * FROM orders WHERE order_id = 'xxx'查到订单，但对应stock表里qty没变，或account表余额未扣 -
INSERT ... ON DUPLICATE KEY UPDATE在 MyISAM 中实际执行为“先删后插”，自增 ID 跳变，且删和插无法原子化 -
SELECT ... FOR UPDATE被静默忽略，应用层以为加了锁，实际并发写入仍在发生
崩溃后数据逻辑错乱，且 MySQL 不报错
MyISAM 没有 redo log 和 undo log，所有写操作直写 .MYD（数据）和 .MYI（索引）文件。断电、kill -9 或磁盘 I/O 错误后，两文件极易偏移错位。
- 典型表现：
SELECT COUNT(*)和SELECT * FROM t WHERE id > 1000返回矛盾结果；CHECK TABLE报error: 134 (record header crashed) -
REPAIR TABLE只是暴力重建索引，不验证业务逻辑是否一致（比如库存数是否真扣减了） - 主从复制中，从库执行完
REPLACE INTO看似成功，但金额/状态已错位，SHOW SLAVE STATUS却无任何错误提示 - 云数据库平台无法自动恢复，必须人工介入
myisamchk，期间服务中断、SLA 失效
MySQL 8.0+ 已从系统层面封杀 MyISAM
这不是团队规范建议，而是 MySQL 官方强制行为。MySQL 8.0.33 起，启动阶段会对 mysql 库所有系统表做引擎校验，任一表仍是 MyISAM，服务立即退出：
- 报错：
ER_UNKNOWN_STORAGE_ENGINE: Unknown storage engine 'MyISAM' -
disabled_storage_engines=MyISAM只拦截新建表，不修复已有表 -
skip-myisam在系统表加载完成后才生效，此时校验早已失败 -
mysql_upgrade自 8.0.16 起已弃用，不再转换任何系统表
真正危险的不是“现在还能用”，而是当某次升级、备份还原或主从切换触发校验时，整个实例突然不可用——而你根本没在代码或建表语句里显式声明 MyISAM。
