MySQL默认启动内存100–300MB，但实际占用取决于innodb_buffer_pool_size配置；5.7/8.0默认值常过小，需按场景手动设置，否则引发缓存命中率低、慢查询、OOM等问题。
MySQL 5.7/8.0 默认安装后吃多少内存
MySQL 启动后不加载任何业务数据时，mysqld 进程通常占 100–300MB 内存，但这只是表象。真正影响内存占用的是缓冲区配置，尤其是 innodb_buffer_pool_size —— 它默认在 5.7 是 128MB，8.0 是 128MB（Linux）或自动设为物理内存的 75%（Windows），但很多包管理器（如 Ubuntu 的 apt install mysql-server）会忽略这点，直接用极小值启动。
常见错误现象：SHOW ENGINE INNODB STATUS 显示 Buffer pool hit rate 长期低于 950/1000；慢查询频发但 CPU 不高；top 看 mysqld RSS 持续增长后卡住。
- 开发机（4GB 内存）：建议手动设
innodb_buffer_pool_size = 512M，别超 1.5GB - 生产环境（16GB+）：起步设为物理内存的 50%～75%，但需预留至少 2GB 给 OS 和其他进程
- 容器部署（Docker）：必须用
--memory限制，并在my.cnf中显式设置innodb_buffer_pool_size，否则 MySQL 可能按宿主机内存计算，OOM 被 kill
CPU 核心数对 MySQL 并发性能的实际影响
MySQL 单连接基本是单线程工作（除并行查询、InnoDB 后台线程等少数场景），所以「CPU 核越多越快」只在并发连接数高、且 SQL 能有效分摊到多核时才成立。瓶颈常不在 CPU，而在磁盘 I/O 或锁竞争。
使用场景判断：
- OLTP（如电商订单）：16 个活跃连接 + 复杂事务 → 4 核足够；若连接数常超 200，需关注
innodb_thread_concurrency（8.0 已废弃，靠innodb_read_io_threads/innodb_write_io_threads调整 I/O 线程数） - OLAP（大表 JOIN、GROUP BY）：开启
innodb_parallel_read_threads（8.0.14+）可利用多核，但仅对全表扫描生效，且受read_buffer_size限制 - 复制延迟高：检查
SHOW SLAVE STATUS中Seconds_Behind_Master，若 CPU 持续 100% 且Slave_SQL_Running_State停在 “executing” —— 很可能是单线程 apply event 成为瓶颈，考虑升级到 8.0+ 的并行复制（slave_parallel_type = LOGICAL_CLOCK）
docker run mysql 容器为啥一启动就 OOM？
根本原因是 MySQL 启动时读取系统内存总量（不是容器限制值），然后按比例分配 innodb_buffer_pool_size。比如宿主机 64GB，容器只给 2GB 内存，但 MySQL 仍可能申请 32GB 缓冲池，立刻被 Linux OOM Killer 干掉。
