直接改my.cnf中innodb_buffer_pool_size、max_connections、wait_timeout、innodb_log_file_size、skip-name-resolve这5个参数最见效；必须置于[mysqld]段，修改后需重启生效并验证。
直接改 my.cnf 里这 5 个参数，比加索引、调 SQL 更快见效——前提是别动错位置、别抄错值、别忽略生效逻辑。
必须放在 [mysqld] 段里的核心配置
MySQL 8.0 启动时只认 [mysqld] 下的配置，其他段（如 [client] 或 [mysql]）只影响命令行工具行为。很多人把 innodb_buffer_pool_size 写在 [client] 里，重启后完全不生效，还反复怀疑内存没配够。
-
[mysqld]是唯一控制服务端行为的模块，所有性能相关参数必须放在这里 - 配置文件路径优先级：Linux 是
/etc/my.cnf>/etc/mysql/my.cnf；Windows 是C:\ProgramData\MySQL\MySQL Server 8.0\my.ini - 改完必须重启 MySQL：
systemctl restart mysqld（Linux）或用服务管理器（Windows） - 验证是否生效：
mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"
innodb_buffer_pool_size 设多大才不翻车
这是 MySQL 8.0 性能的“命门”：设小了频繁刷盘，设大了触发 OOM 杀进程。它不是越大越好，而是要和物理内存、系统负载一起算账。
- 16GB 内存服务器：建议设
innodb_buffer_pool_size = 10G（62%），留足 4–5GB 给 OS、binlog、连接线程等 - ≤4GB 小内存机：不要超过
1G，否则mysqld容易被 OOM killer 杀掉 - 千万别和
key_buffer_size加起来超总内存——InnoDB 表不用key_buffer_size，设成16M即可 - 监控命中率：
SHOW STATUS LIKE 'innodb_buffer_pool_read%';，目标是innodb_buffer_pool_reads / innodb_buffer_pool_read_requests
max_connections 和 wait_timeout 配合防堆积
单独调高 max_connections 只是“堵漏”，不配 wait_timeout 会导致空闲连接长期占着资源，最终拖垮整个连接池。
- 开发/测试环境（8GB 内存）：
max_connections = 500+wait_timeout = 600（10 分钟） - 生产微服务环境（16GB+）：
max_connections = 2000+wait_timeout = 300（5 分钟更稳妥） - 注意
wait_timeout和interactive_timeout要设成一样值，否则 CLI 登录会话行为不一致 - 临时救急可用
SET GLOBAL max_connections = 3000;，但不持久，重启即失效
innodb_log_file_size 改完必须重建日志文件
这个参数直接影响写入吞吐和崩溃恢复时间，但修改后不能直接重启生效——InnoDB 会拒绝启动，报错类似 InnoDB: Error: log file ./ib_logfile0 is of different size。
- 推荐值：SSD 环境设
innodb_log_file_size = 1G（单个），innodb_log_files_in_group = 2 - 改前先停库：
systemctl stop mysqld - 删旧日志：
rm -f /var/lib/mysql/ib_logfile*（路径按你的datadir调整） - 再启动，InnoDB 自动重建日志文件
- 别在运行中改：MySQL 8.0 不支持在线调整该参数
最容易被跳过的其实是 skip-name-resolve 和 innodb_flush_method = O_DIRECT：前者解决内网远程连接慢到超时，后者避免双重缓冲吃 I/O。这两个开关一开，很多“莫名卡顿”就消失了——但它们都依赖配置位置正确、重启彻底、权限无误。
