必须选用InnoDB引擎，因其支持ACID事务、外键约束及行级锁+MVCC，并需正确配置innodb_buffer_pool_size等关键参数并验证生效。
看业务是否需要事务，直接决定引擎底线
如果你的表要处理订单、支付、库存扣减这类操作，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 缓冲池调度。