直接改my.cnf中innodb_buffer_pool_size、max_connections、wait_timeout、innodb_log_file_size、skip-name-resolve这5个参数最见效；必须置于[mysqld]段，修改后需重启生效并验证。
直接改 my.cnf 里这 5 个参数，比调 SQL 或加索引见效更快——但必须全放在 [mysqld] 段，改完要重启，否则等于没改。
innodb_buffer_pool_size 必须和物理内存对齐
这是性能“命门”，设小了频繁刷盘，设大了触发 OOM 杀进程。它不是越大越好，得留足系统空间给 OS、binlog、连接线程等：
- 16GB 内存服务器：
innodb_buffer_pool_size = 10G（约 62%） - ≤4GB 小内存机：
innodb_buffer_pool_size = 1G就顶天了，再大容易被 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 < 0.01
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 diffe：
- 先停库：
systemctl stop mysqld（Linux）或服务管理器（Windows） - 删旧日志：
rm -f /var/lib/mysql/ib_logfile*（路径以datadir为准） - 改配置：
innodb_log_file_size = 1G（推荐 1G～4G，SSD 可更大） - 再启动，InnoDB 自动重建日志文件
default_authentication_plugin 要提前防 Navicat 连不上
Docker 或远程工具连 MySQL 8.0 常报 Authentication plugin 'caching_sha2_password' cannot be loaded，根源是客户端不兼容新认证协议：
- 在
[mysqld]段加一行：default_authentication_plugin=mysql_native_password - 该配置只影响新创建用户，已有用户需单独执行：
ALTER USER 'xxx'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd'; - Windows 下确认路径是
C:\ProgramData\MySQL\MySQL Server 8.0\my.ini（隐藏目录），Linux 下优先级是/etc/my.cnf > /etc/mysql/my.cnf
最容易被忽略的是配置段位置——innodb_buffer_pool_size 写在 [client] 或 [mysql] 里完全不生效，而很多人查日志、看监控都正常，就是性能起不来，最后发现配置压根没加载。
