MyISAM转InnoDB需停写操作并避开高并发期，注意表锁、外键与NULL唯一索引冲突，调大innodb_buffer_pool_size，处理死锁重试逻辑，修正业务层对MyISAM的惯性假设。
MyISAM 表还在用？先停掉写操作再转
MyISAM 的表级锁在并发写入时会直接卡死，转 InnoDB 不是「ALTER TABLE 一下就完事」。如果线上有持续 INSERT/UPDATE，ALTER TABLE 过程中表会被锁住，其他写请求排队甚至超时，尤其大表可能锁几十分钟。
实操建议：
- 选业务低峰期操作，提前用
SHOW PROCESSLIST确认无长事务或慢查询占用该表 - 对核心表，先在从库上执行转换，验证无误后再切主库
- 避免用
mysqldump --no-create-info+ 手动改 CREATE 语句的方式——容易漏掉索引、AUTO_INCREMENT、字符集等细节 - 转换前确认磁盘空间充足：InnoDB 行格式（如
ROW_FORMAT=DYNAMIC）和 MVCC 机制会让数据文件比 MyISAM 大 20%–50%
ALTER TABLE ENGINE=InnoDB 卡住不动？检查外键和唯一索引
常见现象是命令一直显示 copy to tmp table 或卡在 rebuilding table，不是性能问题，而是隐性约束冲突。MyISAM 不校验外键，但 InnoDB 会严格检查；MyISAM 允许 NULL 值的列建唯一索引，InnoDB 在 UNIQUE 索引中把多个 NULL 当作不同值，但某些旧版本（如 MySQL 5.6）对含 NULL 的 UNIQUE 索引转换会异常等待。
实操建议：
- 转换前跑一遍
SELECT COUNT(*) FROM table_name WHERE column_name IS NULL，如果对应列上有UNIQUE索引，先清理或改用普通索引 - 禁用外键检查只对当前会话有效：
SET FOREIGN_KEY_CHECKS = 0;，但必须确保上下游表结构一致，否则转完启用检查时会报错 - 加
ALGORITHM=INPLACE（MySQL 5.6+）可跳过拷贝，但仅限部分场景支持；不确定时加ALGORITHM=COPY显式声明，避免隐式降级导致意外锁表
转完发现 SELECT 变慢？重点调 innodb_buffer_pool_size
InnoDB 依赖缓冲池缓存数据页，MyISAM 直接读文件系统缓存。如果 innodb_buffer_pool_size 还沿用 MyISAM 时代的配置（比如只设 128M），热点数据全在磁盘上，QPS 下跌明显，尤其是 JOIN 多、范围扫描多的查询。
实操建议：
- Linux 下该值建议设为物理内存的 50%–75%，但别超过 80%，留内存给 OS 文件缓存和连接线程
- 上线后观察
SHOW ENGINE INNODB STATUS中的Buffer pool hit rate，低于 990/1000 就说明缓存不够 - 不要一上来就开
innodb_file_per_table=0—— 共享表空间难回收空间，单表损坏影响全局，现在默认就是ON，保持即可 - MyISAM 的
KEY_BUFFER_SIZE可同步调低，避免内存争抢
应用层还报 Deadlock？不是锁少了，是锁得更细了
MyISAM 表级锁最多阻塞，不报死锁；InnoDB 行级锁 + MVCC 虽并发高，但事务交叉更新同一行时极易触发 Deadlock found when trying to get lock。这不是 bug，是正常行为——但很多老代码没做重试逻辑，一报错就崩。
实操建议：
- 查最近死锁：执行
SHOW ENGINE INNODB STATUS，看LATEST DETECTED DEADLOCK区块，定位冲突的 SQL 和事务顺序 - 写操作尽量按相同顺序访问表和行（比如固定先更新 users 再更新 orders），减少循环等待
- 短事务优先：把一个大事务拆成多个小事务，避免长时间持有锁；UPDATE 语句加
WHERE条件精确到主键，别用全表扫描条件 - 应用里捕获
Deadlock found when trying to get lock错误码（1213），自动重试 1–2 次，别直接抛异常
真正麻烦的不是转换动作本身，是那些藏在业务逻辑里的「MyISAM 假设」：比如认为 UPDATE 不会阻塞 SELECT，或者 COUNT(*) 总是秒出——这些惯性思维不改，InnoDB 的锁机制反而会放大问题。
