DELETE触发缓冲池暴涨并非语句本身耗内存，而是每删一行需加载数据页、undo页、索引页并标记逻辑删除，事务未提交则这些页滞留缓冲池；批量操作若未分批COMMIT，叠加buffer_pool_size过大、instances配置不当及glibc内存碎片，将导致RSS飙升与假性内存泄漏。
为什么DELETE会触发InnoDB缓冲池暴涨
不是DELETE语句本身吃内存，而是它引发的后台连锁反应：每删一行，InnoDB都要在innodb_buffer_pool里加载对应的数据页、undo页、索引页，并标记为“逻辑删除”——这些页不会立刻刷盘或释放，全堆在缓冲池里。如果一次删百万行，缓冲池瞬间被填满，SHOW STATUS LIKE 'Innodb_buffer_pool_pages_data'值会猛涨，ps aux看到mysqld RSS飙升。
事务未提交是内存不释放的直接原因
大批量DELETE若没显式COMMIT，整个事务的undo日志、脏页、锁结构全保留在内存中。哪怕只删10万行但包在一个事务里，undo log可能占几百MB；更糟的是，autocommit=OFF时，每个DELETE都算独立事务，连接数多+小事务频繁，反而让内存碎片更严重。
- 检查当前事务状态：
SELECT TRX_ID, TRX_STATE, TRX_ROWS_MODIFIED FROM INFORMATION_SCHEMA.INNODB_TRX - 避免长事务：加
LIMIT 10000分批删，每批后COMMIT - 别用存储过程循环删而不commit——那是内存泄漏高发场景
buffer_pool_size设置不合理会放大问题
MySQL 5.7默认innodb_buffer_pool_size只有128MB，但如果手动设成4G，而实际活跃数据才500MB，DELETE产生的临时脏页就全往这4G里塞，系统物理内存很快见底。更隐蔽的是：buffer pool太大，innodb_buffer_pool_instances没同步调高（比如仍为1），会导致单实例锁竞争+内存分配器压力剧增，加剧碎片。
- 查真实占用：
SELECT @@innodb_buffer_pool_size / 1024 / 1024 AS mb;对比free -h看是否超物理内存60% - 安全值参考：SSD机器可设为物理内存50%~60%，HDD建议40%以下
- 必须配套调
innodb_buffer_pool_instances：≥CPU核心数，但≤8（小内存机器设1即可）
glibc内存分配器导致“假性内存泄漏”
MySQL 5.7默认用glibc的ptmalloc，它对brk/mmap管理有缺陷：DELETE产生的大量小内存块释放后，malloc_trim(0)不一定生效，空闲内存无法归还OS，top看RSS居高不下，但SHOW ENGINE INNODB STATUS里实际buffer pool使用率可能只有30%——这是典型的内存碎片现象。
- 验证方式：对比
ps auxRSS 和Innodb_buffer_pool_bytes_data（从SHOW STATUS查），差值＞1G基本就是碎片 - 生产环境慎用
gdb --batch -p $PID -ex 'call malloc_trim(0)'，可能卡住SQL执行 - 长期解法：编译MySQL时链接
jemalloc，或升级到MySQL 8.0+（默认支持malloc_lib配置）
