InnoDB比MyISAM更适合长连接，因其行级锁与事务机制可自动回滚未提交操作并释放锁，而MyISAM表级锁不绑定连接生命周期，中断后易致表永久锁定，且无崩溃自动恢复能力。
InnoDB 比 MyISAM 更适合长连接，核心原因不是“它更先进”，而是 MyISAM 在长连接下会因表级锁和无事务状态积累不可控风险——尤其是当连接意外中断时。
长连接中断后 MyISAM 表可能被永久锁住
MyISAM 的表级锁不与连接生命周期绑定。一旦客户端建立长连接并执行 INSERT 或 UPDATE，锁就加在整张表上；如果此时连接异常断开（如网络抖动、超时、客户端崩溃），MyISAM 不会自动释放锁。后续所有对该表的读写都会卡在 Waiting for table level lock 状态，直到手动 KILL 对应线程或重启 MySQL。
- InnoDB 的行级锁 + 事务机制能自动回滚未提交事务，连接断开即释放锁
- MyISAM 没有事务概念，无法判断“这个写操作是否该继续”，只能傻等
- 线上排查时常见现象：
SHOW PROCESSLIST中大量线程状态为Locked，但找不到活跃连接源头
InnoDB 的 MVCC 让长连接并发读不阻塞
长连接常伴随长时间运行的报表查询或监控轮询，这类查询持续时间长、频率高。MyISAM 在执行 SELECT 时虽不加写锁，但一旦有写操作进来，整个表就锁死；而 InnoDB 借助 MVCC，允许长查询看到事务快照，同时不影响其他连接对同一行的更新。
- MyISAM：一个
SELECT COUNT(*) FROM logs执行 5 秒，期间所有INSERT INTO logs都排队等待 - InnoDB：同样查询跑 5 秒，其他连接仍可向
logs表插入新记录（只要不冲突同一行） - 关键依赖：
innodb_lock_wait_timeout和transaction_isolation设置需合理，否则长事务可能拖慢整体吞吐
MyISAM 的崩溃恢复缺陷在长连接场景被放大
长连接意味着更长的事务窗口、更多未刷盘的脏页、更高的意外中断概率。MyISAM 没有 redo log，崩溃后只能靠 myisamchk 手动修复，且无法保证修复后数据逻辑一致；而 InnoDB 在服务重启时自动重放 redo log，把数据库拉回崩溃前最近的一致状态。
- 典型故障链：长连接中执行批量
INSERT→ MySQL 进程被 OOM kill → MyISAM 表数据文件损坏，REPAIR TABLE可能丢数据 - InnoDB 同样崩溃，但重启后通过
ib_logfile0/1自动恢复，应用层几乎无感 - 注意：
innodb_flush_log_at_trx_commit=1是保障这一能力的前提，设为 0 或 2 会削弱安全性
真正要警惕的是“因为历史表用 MyISAM，所以新长连接业务也沿用”的惯性。InnoDB 的锁行为、事务边界和恢复逻辑，天然适配现代应用的连接模型；而 MyISAM 的设计假设是“短连接 + 低并发 + 可人工干预”，这两者在长连接场景下根本对不上。
