必须选用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。
