冷数据会挤占Buffer Pool中热数据空间，因其全表扫描等操作被加载至LRU链表头部；可通过调优innodb_old_blocks_pct/innodb_old_blocks_time、分区表DROP PARTITION释放内存、或迁移冷表至归档库三种方式缓解。
为什么冷数据会吃掉 Buffer Pool 里的热数据空间
冷数据本身不常被访问，但一旦被全表扫描、备份或误触发的 SELECT * 加载进 Buffer Pool，就会直接插到 LRU 链表头部，把正在高频访问的热页挤出去。InnoDB 默认的 innodb_old_blocks_pct=37 和 innodb_old_blocks_time=1000 就是为防这个——新加载的页先扔进 Old Sublist 头部，得等 1 秒后又被访问，才晋升到 New Sublist。但如果你没调过这两个值，或者业务里频繁执行范围查询（比如 WHERE create_time > '2024-01-01'），冷数据照样能“混进来”。
用分区表 + DROP PARTITION 主动释放索引内存
分区表本身不减少索引大小，但它让 MySQL 能精准丢弃整块冷数据的索引结构。关键不是“查得快”，而是“不加载”。比如你按月分区的订单表，ALTER TABLE orders DROP PARTITION p_202301 后，对应分区的 B+ 树索引页、undo log、甚至 buffer pool 中残留的页都会被清理。注意：这招只对 RANGE/LIST 分区有效，HASH 或 KEY 分区不行；且必须确保该分区无活跃事务、无未提交的 DDL。
- 执行前先确认分区是否真冷：
SELECT TABLE_ROWS FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_NAME = 'orders' AND PARTITION_NAME = 'p_202301';返回 0 或极小值再操作 - 避免锁表：加
ALGORITHM=INPLACE, LOCK=NONE（MySQL 5.6+ 支持） - 别直接删物理文件：手动删
.ibd会导致 crash-safe 机制失效，必须走DROP PARTITION
把冷数据表迁出主库，彻底移除索引加载路径
Buffer Pool 只缓存当前库中打开的表。只要冷数据不在主库的 information_schema.tables 里，它的索引就永远不会被加载。常见做法是用 mysqldump --no-create-info --skip-triggers 导出冷数据，再导入到归档库（哪怕只是同一实例下的不同 schema）。迁移后，在应用层或中间件做路由，热查询走 orders_hot，冷查询走 archive.orders_his。这时主库 Buffer Pool 完全被热表索引占据，命中率自然拉满。
- 迁移时用
INSERT INTO ... SELECT比mysqldump更可控，可加WHERE order_date 精确切片 - 迁移完立刻
ANALYZE TABLE orders_hot，让优化器更新统计信息，避免执行计划误判 - 别忽略外键：如果原表有外键指向冷数据，迁移前得先
DROP FOREIGN KEY，否则DELETE会失败
innodb_buffer_pool_size 不是越大越好，尤其当冷热混存时
调大 innodb_buffer_pool_size 看似能多缓存热数据，但如果冷数据还在库里，它只会加速冷页填充 Buffer Pool。实测中，当冷数据占比超 60%，把 buffer pool 从 12G 拉到 24G，QPS 反而下降 15%——因为 LRU 淘汰更频繁，热页反复进出内存。真正有效的做法是：先做分区或分表隔离冷数据，再按热表实际索引大小的 1.5 倍设 buffer pool。比如 SHOW INDEX FROM orders_hot 显示索引总大小约 3GB，那就设 innodb_buffer_pool_size = 4G 足够。
- 检查当前 buffer pool 使用率：
SELECT (pages_data*16384)/1024/1024/1024 AS gb_used FROM information_schema.INNODB_BUFFER_POOL_STATS; - 观察冷页残留：
SELECT COUNT(*) FROM information_schema.INNODB_BUFFER_PAGE WHERE TABLE_NAME LIKE '%orders%' AND SPACE = 0;（SPACE=0 表示系统表空间，冷数据页常卡在这儿出不去） - 别在高峰期调 buffer pool：动态调整会触发整个 buffer pool 重建，瞬时 QPS 归零
DROP PARTITION 就丢掉关键审计数据。最危险的是只动表结构不动应用逻辑，结果查询条件没路由过去，热库照样被冷数据拖垮。 
