MySQL 5.7低内存优化核心是按需裁剪而非简单关闭：必须将innodb_buffer_pool_size设为2M、performance_schema关闭、table_open_cache等缓存参数大幅调低，才能将启动内存压至30～60MB。
MySQL 5.7 在低内存（如 1G～4G）服务器上默认启动就占 400MB～2GB，不是配置冗余，而是它默认启用大量监控、缓存和预分配机制。关键不是“关掉什么”，而是**按需裁剪缓冲区、禁用非必要服务、限制连接数**——否则容易因 OOM 被系统 kill。
为什么刚装完 mysqld 就吃掉 400MB+？
默认配置里几个“隐形大户”在作祟：
-
performance_schema在 5.7 中默认开启，仅这一项就能占 100MB+（尤其performance_schema_max_table_instances默认是 10000+） -
innodb_buffer_pool_size默认 128MB，但若没显式设小，它可能按物理内存比例自动推算（比如 4G 内存时推成 512MB） -
table_open_cache和table_definition_cache默认值偏高（2000/1400），每打开一个表都要内存，小内存机器撑不住 - 每个连接还会额外分配
sort_buffer_size、read_buffer_size等，max_connections=151默认值意味着潜在几百 MB 预留
必须改的三个参数：让内存降到 30～60MB
编辑 /etc/my.cnf，在 [mysqld] 段下强制覆盖：
-
innodb_buffer_pool_size=2M—— 如果你数据量 16M，别超内存 10% -
performance_schema=OFF—— 不做深度性能诊断时直接关，省下最大一块内存；别只调performance_schema_max_table_instances，关总开关才彻底 -
table_open_cache=32、table_definition_cache=32—— 和你的实际表数量对齐（SHOW TABLES数一下），设太高反而触发频繁 LRU 清理开销
附带收紧连接资源：max_connections=30、wait_timeout=30、interactive_timeout=60，避免空闲连接长期驻留。
容易被忽略的启动后内存泄漏点
改完配置重启 mysqld 后，用 ps aux --sort=-%mem | head -5 看真实 RSS 占用，注意以下陷阱：
- 如果启用了
query_cache_type=1（5.7 默认 OFF，但某些一键脚本会开），它会在内存碎片化严重时持续增长，建议保持query_cache_type=0 -
tmp_table_size和max_heap_table_size默认 16MB，复杂 GROUP BY 或 ORDER BY 可能触发磁盘临时表，但设太小会导致频繁落盘降速；低内存机建议统一设为4M - 阿里云 CentOS 7 的
systemd有时会限制mysqld的 memory.max（cgroup v2），检查systemctl show mysqld | grep Memory，如有输出，需在/etc/systemd/system/mysqld.service.d/override.conf中加MemoryMax=512M显式放宽
真正压到 30MB 左右，靠的是组合裁剪：关 performance_schema、砍 buffer pool 到个位数 MB、锁死连接上限、匹配真实表数设 cache。别信“调小几个参数就行”的零散建议——少关一项，内存就多飘 80MB。
