看业务是否需要事务，直接决定引擎底线
如果你的表要处理订单、支付、库存扣减这类操作，
InnoDB不是“推荐”，而是必须。它支持完整的 ACID 事务，比如转账失败能自动回滚，不会出现“钱扣了但没到账”的数据撕裂。而
MyISAM、
MEMORY、
ARCHIVE全都不支持事务——出错只能靠人工对账或从备份恢复，生产环境基本不可接受。 有外键约束？只能选
InnoDB，其他引擎压根不识别
FOREIGN KEY语法 MySQL 8.0 已移除系统表对
MyISAM的依赖，
mysql库下少数表虽仍用它，但用户表强行切过去可能触发元数据异常 即使当前没事务需求，也建议默认用
InnoDB，避免未来加个支付功能就得全表重建
查读写特征和并发强度，避免锁成瓶颈
高并发写入（如秒杀下单、实时日志入库）下，
InnoDB的行级锁 + MVCC 是刚需；
MyISAM的表级锁会让一个
UPDATE直接堵住所有读请求，QPS 瞬间归零。 纯读多写少 + 全文检索为主？老系统若还在用
MyISAM，可保留，但注意：MySQL 5.6+ 的
InnoDB已支持全文索引，性能差距大幅缩小
MEMORY引擎响应快，但只适合会话缓存、临时中间表——服务器重启即丢数据，且受
max_heap_table_size限制，超限会报
ERROR 1114 (HY000): The table 'xxx' is full
ARCHIVE适合审计日志、历史归档表：插入极快、压缩率高，但不支持索引、不能
UPDATE/
DELETE，查单条记录得全表扫描
配对关键参数，光选引擎不够
建表时写
ENGINE=InnoDB只是第一步，没调好配套参数，照样卡顿、丢数据、OOM。
innodb_buffer_pool_size是命脉：设太小，频繁磁盘 IO；设太大，挤占 OS 内存触发 OOM。生产建议物理内存的 50%–75%，比如 32GB 机器设
innodb_buffer_pool_size = 24G
innodb_flush_log_at_trx_commit = 1才保证事务不丢，设为 2 或 0 在主库上等于裸奔；测试环境可放宽，生产别碰
innodb_file_per_table = ON必开：否则所有表数据混在
ibdata1里，删一张大表空间根本回收不了 改
innodb_log_file_size前必须停库删旧日志文件（
ib_logfile0,
ib_logfile1），否则启动失败
验证是否真生效，别被“默认”骗了
安装界面勾了 InnoDB 或配置文件写了
default-storage-engine = InnoDB，不代表万事大吉。得进库实测： 执行
SHOW ENGINES;，确认
InnoDB行的
SUPPORT列是
DEFAULT或
YES建测试表：
CREATE TABLE t_test (id INT) ENGINE=InnoDB;，再
SHOW CREATE TABLE t_test;看输出里是否明确写着
ENGINE=InnoDB老表迁移别用
ALTER TABLE t_old ENGINE=InnoDB一招鲜：含外键、全文索引或使用
ROW_FORMAT=COMPRESSED的表可能失败，得导出再重建
最容易被忽略的是混合引擎场景——比如用
MyISAM存日志表，却忘了关掉它的
key_buffer_size配置，空占内存还干扰 InnoDB 缓冲池调度。
