myisam表面内存占用小，实则将压力转嫁os page cache并引发i/o瓶颈与稳定性风险；innodb虽rss高，但buffer pool可有效降低随机读延迟，配合合理配置（如buffer_pool_size设40%–50%物理内存）在低配环境反而更稳更高效。
不建议，低配置服务器上选 MyISAM 并不能真正“节省内存”，反而会放大稳定性风险，得不偿失。
MyISAM 的内存占用真的更小吗？
表面看是的：MyISAM 只有 key_buffer_size 缓存索引，不缓存数据；InnoDB 默认启用 innodb_buffer_pool_size，看起来吃内存。但现实没这么简单：
- MyISAM 不缓存数据 → 每次
SELECT都要读磁盘 → 在低配机器（尤其是机械盘或小内存+swap频繁）上，I/O 延迟直接拉高响应时间，CPU 等待更久 - InnoDB 的
buffer_pool虽然占内存，但能同时缓存数据页和索引页；哪怕只设为 256MB（总内存 1GB 时），也能显著减少随机读，整体吞吐反而更高 - MyISAM 的
key_buffer_size对非主键查询效果有限；而 InnoDB 的聚簇索引让主键查询几乎零额外 I/O
低配环境里 MyISAM 更容易出什么故障？
不是“慢一点”的问题，是“不可用”的问题：
- 断电或异常 kill 后，MyISAM 表大概率损坏，
REPAIR TABLE失败率高，且无法保证修复后逻辑一致（比如自增 ID 乱跳、部分行丢失） - 哪怕只是
UPDATE一行，也会触发表级锁 → 低配机器并发稍一上来（比如几个 cron job + 后台脚本），SHOW PROCESSLIST里全是Waiting for table level lock - 没有崩溃恢复机制 →
mysqld重启后，MyISAM 表可能处于“未关闭”状态，需要手动检查，无法自动上线
如果内存实在紧张，InnoDB 怎么调才合理？
与其换引擎，不如精准压榨 InnoDB 的配置空间：
-
innodb_buffer_pool_size设为物理内存的 40%–50%（例如 1GB 内存 → 设 400–500MB），比默认 128MB 更实用，也留出空间给 OS 和其他进程 - 关掉不用的功能：
innodb_file_per_table=ON（必须开），innodb_stats_on_metadata=OFF（避免SHOW TABLE STATUS拖慢） - 日志文件不必大：
innodb_log_file_size=16M或32M即可，小 log 文件 checkpoint 更频繁，但低写入场景下影响极小 - 确认
innodb_flush_log_at_trx_commit=1—— 别为省那点写入延迟去动它，否则断电=丢事务
真正卡在内存上的，往往不是引擎本身，而是没关掉 query cache（MySQL 8.0 已移除）、没限制连接数（max_connections 设太高）、或者应用层反复建连。查 SHOW GLOBAL STATUS LIKE 'Threads_connected' 和 SHOW ENGINE INNODB STATUS\G，比纠结 MyISAM 实在得多。
