MySQL 8.0 容器启动即占300MB+内存，主因是innodb_buffer_pool_size按宿主机内存设为75%、performance_schema默认开启及缓冲区预分配；需显式配置buffer_pool、禁用performance_schema、下调连接与日志参数，并确保总内存占用≤容器限制的60%。
为什么 MySQL 8.0 容器一启动就吃掉 300MB+ 内存
MySQL 8.0 默认启用 performance_schema、innodb_buffer_pool_size 按主机内存自动推算（Docker 内无 cgroup 限制时会按宿主机内存算），再加上默认开启的监控表、预分配连接缓冲区等，空载下常驻内存轻松突破 350MB。这不是 bug，是“开箱即用”设计的代价——但你不需要它全部启动。
innodb_buffer_pool_size 是内存占用最大变量
这个参数控制 InnoDB 缓冲池大小，MySQL 8.0 官方镜像在未指定配置时，会尝试设为宿主机物理内存的 75%，哪怕容器只分配了 512MB。必须显式覆盖它。
- 对 512MB 容器：设为
innodb_buffer_pool_size = 128M（不超过可用内存的 30%） - 对 1GB 容器：设为
innodb_buffer_pool_size = 256M～384M，留足系统和连接缓冲余量 - 切勿设为
512M或更高——InnoDB 还要额外申请日志缓冲、排序缓冲等，极易 OOM - 该值必须写入配置文件（如
/etc/mysql/conf.d/lowmem.cnf），SET GLOBAL重启即丢
禁用 performance_schema 能省 80–120MB
它用于运行时性能诊断，但默认开启 800+ 张监控表，每个连接还会分配独立结构体。开发/测试/低负载场景完全可关。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 在配置文件中加一行：
performance_schema = 0 - 同时建议配对关闭：
table_definition_cache = 200、table_open_cache = 128（避免缓存膨胀） - 注意：
performance_schema = off是无效写法，必须用0或OFF（推荐数字） - 验证是否生效：
SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'performance_schema';应返回OFF
其他关键节流点：连接、临时表与日志缓冲
MySQL 启动后为每个连接预分配多个缓冲区，max_connections 设太高会直接拉高基线内存。同时，tmp_table_size 和 innodb_log_buffer_size 也需按比例下调。
-
max_connections = 50（非高并发场景够用；每连接约多占 2–3MB） -
tmp_table_size = 16M、max_heap_table_size = 16M（防止内存临时表失控） -
innodb_log_buffer_size = 4M（默认 16M，日志写入频率不高时可压） -
key_buffer_size = 8M（MyISAM 已淘汰，但部分系统表仍用，设小即可） - 所有参数必须放在
[mysqld]段下，且挂载进容器的/etc/mysql/conf.d/目录（官方镜像会自动加载!includedir /etc/mysql/conf.d/）
真正容易被忽略的是：Docker 启动时若没限制内存（--memory=512m），MySQL 会误判可用资源；而即使限制了，也要确保配置文件里的数值总和 ≤ 容器内存的 60%——剩下的得留给 OS、glibc malloc arena、连接上下文等。调完别忘 docker restart 并用 docker stats 看 RSS 是否稳定在目标区间。
