myisam只缓存索引不缓存数据，依赖os page cache管理.myd文件，内存开销集中于key_buffer_size；innodb则需缓冲池同时承载数据页、索引页及事务元数据，内存压力更大且delete后不自动释放空间。
MyISAM只缓存索引，数据完全甩给OS page cache
MyISAM的内存开销几乎全在key_buffer_size，它只用来缓存.MYI索引文件块，不碰.MYD数据文件。表数据读写由操作系统用page cache管理——MySQL进程RSS低，不是它“轻”，而是把缓存压力转嫁给了内核。你看到ps aux里mysqld占内存少，但/proc/[pid]/status或cat /proc/[pid]/maps | grep -i "cache"往往显示大量page cache被占满，这点容易被忽略。
InnoDB缓冲池必须同时扛住数据页+索引页+事务元数据
InnoDB的innodb_buffer_pool_size要缓存聚簇索引、二级索引、undo日志页、change buffer、自适应哈希索引等。哪怕一个空表，建完就占16KB（一页），海量小表会快速稀释缓冲池利用率；每个表还额外带元数据结构开销。更关键的是：开启innodb_adaptive_hash_index后，小表多时哈希条目竞争latch，反而降低有效缓存率。而MyISAM没这些负担。
DELETE后InnoDB不释放内存，MyISAM可在线压缩
执行DELETE FROM t后，InnoDB只是把记录标记为可复用，页内空闲空间保留在缓冲池中，不会主动淘汰或归还——所以缓冲池实际占用持续偏高；真正收缩得靠OPTIMIZE TABLE t或ALTER TABLE t ENGINE=InnoDB重建，期间加MDL锁，阻塞写入。MyISAM的OPTIMIZE TABLE能在线重写.MYD/.MYI，直接截断空洞，缓冲池压力小得多。
从库场景下MyISAM的“低RSS”假象更危险
从库若混用MyISAM，key_buffer_size仍生效，但它的读请求集中在复制后的报表类查询，OS page cache命中率高，看起来更“省”。可一旦主库是InnoDB、从库切MyISAM，Binlog格式（ROW）和复制一致性就出问题——MySQL 9.6.0已将外键与级联上移到SQL层，但MyISAM根本不支持外键，这种混合部署在2026年生产环境基本等于放弃事务保障和崩溃恢复能力。
