MySQL 8.0+ 数据字典内存溢出会导致OOM Killer杀进程，需通过SHOW ENGINE INNODB STATUS和performance_schema确认用量，停用非必要information_schema查询、禁用innodb_stats_persistent、清理冗余对象，并中长期合并小表、归档历史库、分库分片。
MySQL 8.0+ 中，数据字典由 InnoDB 管理并常驻内存，不走 Buffer Pool，也不受 table_open_cache 控制。当表数量达数万、索引超数十万（如知识库中提到的“20w+ 表、70w+ 索引”），dictionary memory allocated 可能飙升至数 GB，直接触发 OOM Killer 杀掉 mysqld——这是典型的“数据字典内存溢出”，和查询缓存、连接内存无关，必须针对性处理。
确认是不是数据字典真占满内存
别凭感觉调参。先执行：
-
SHOW ENGINE INNODB STATUS\G，搜索 dictionary memory allocated —— 若显示值远超预期（如 >4GB），且与表/索引总数正相关，基本锁定问题 -
SELECT COUNT(*) FROM information_schema.tables WHERE table_schema NOT IN ('mysql','sys','information_schema','performance_schema');查真实业务表数 -
SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_mem_dictionary';（MySQL 8.0.29+）获取精确字典内存用量
立即缓解：限制字典内存增长源头
数据字典内存主要来自三类对象：表定义（TABLE）、索引定义（INDEX）、外键/约束定义。关键不是删表，而是阻断无节制加载：
- 停用非必要 information_schema 查询：这类查询会强制加载大量元数据到字典缓存，尤其
SELECT * FROM information_schema.COLUMNS或模糊匹配（LIKE '%xxx%'）极易引爆内存 - 禁用 innodb_stats_persistent（若未启用）或设为
OFF：避免每次统计收集都反复解析表结构 - 检查并清理冗余 触发器、事件、存储过程：它们的定义也计入字典内存；用
SELECT COUNT(*) FROM information_schema.TRIGGERS;快速评估规模
中长期治理：精简结构 + 合理分片
靠参数硬压只是延缓，根本解法是降低字典对象总量：
-
合并小表：大量单字段、低数据量的配置表（如
user_status_config,order_type_config）可统一为一张泛型配置表 + JSON 字段，减少表定义数量 -
归档历史库：将已下线业务的表迁出主实例（哪怕只保留空表结构，仍占字典内存），用
DROP TABLE彻底释放；切勿仅TRUNCATE - 按租户/业务域分库：20w 表压在一个实例上本就不合理；拆成多个物理实例后，每个实例字典内存自然下降，也利于权限隔离与运维
配套参数调整：不治本但防雪崩
在完成结构治理前，需稳住当前实例：
-
table_definition_cache设为略高于峰值表数（如 25000），避免频繁重载定义；注意它有上限：open_files_limit必须 ≥ 此值 + 其他文件句柄 -
innodb_buffer_pool_size反向下调 10%～20%，为字典内存腾出余量（字典内存不计入 buffer pool，但系统总内存是固定的） - 禁用
query_cache_type=0（已弃用）及残留的key_buffer_size，释放 MyISAM 相关冗余内存
