真正影响性能的关键参数是innodb_buffer_pool_size、max_connections和query_cache_type（MySQL 8.0已移除）；盲目调大sort_buffer_size等易致内存溢出；需按加载顺序确认配置生效路径，并注意8.0兼容性变化。
my.cnf 中哪些参数改了真能提升性能
不是所有参数都值得调，多数线上问题出在 innodb_buffer_pool_size、max_connections、query_cache_type（MySQL 8.0 已移除）这几个上。盲目调 sort_buffer_size 或 join_buffer_size 反而可能因线程内存暴涨拖垮实例。
-
innodb_buffer_pool_size建议设为物理内存的 50%–75%，但必须留足系统和 MySQL 其他组件（如连接线程、排序缓冲）所需内存 -
max_connections不要硬设成 10000；先看SHOW STATUS LIKE 'Threads_connected'峰值，再加 20% 余量 - MySQL 5.7 及以前若启用了查询缓存，
query_cache_type=0关掉通常更稳——缓存失效开销大，且任何表写操作都会清空对应 cache
配置文件位置和加载顺序容易踩的坑
MySQL 启动时按固定顺序读多个 my.cnf，后加载的会覆盖前面的。常见误操作是改了 /etc/my.cnf 却没生效，因为实际加载的是 /etc/mysql/my.cnf 或 ~/.my.cnf。
- 用
mysqld --help --verbose | grep "Default options"查看实际搜索路径（注意输出里带(/path/to/my.cnf)的行） - Docker 环境下，宿主机挂载的
my.cnf必须放在容器内 MySQL 认可的路径，比如/etc/mysql/conf.d/下的*.cnf文件会被自动包含 - 修改后必须重启 MySQL（
systemctl restart mysql），仅 reload 不会重载[mysqld]段大部分参数
针对慢查询和连接数暴增的最小有效配置组合
如果应用刚上线就频繁超时或连接被拒绝，优先确认并设置这三项，比调优索引前更紧迫：
-
wait_timeout和interactive_timeout设为 300（5 分钟），避免空闲连接长期占位 -
innodb_log_file_size至少 256M（配合innodb_log_files_in_group=2），太小会导致频繁 checkpoint 影响写入吞吐 -
table_open_cache设为max_connections × 2左右，防止打开表频繁触发磁盘扫描
改完记得验证：mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';" 确认值已更新，别只信配置文件内容。
MySQL 8.0+ 配置要注意的兼容性断裂点
8.0 默认关闭 sql_mode 中的 STRICT_TRANS_TABLES？错。它默认开启更强的严格模式，且移除了 query_cache_type、old_passwords 等旧参数——配置里若还留着，MySQL 启动直接报错退出。
- 升级前用
mysqld --validate-config检查配置合法性 -
default_authentication_plugin=cache_sha2_password是 8.0 默认，老客户端连不上时先检查这个，不是密码错了 -
log_bin开启后，server_id必须显式设置，否则启动失败
配置不是越全越好，MySQL 启动日志里出现 unknown variable 或 deprecated 提示，得立刻删掉对应行——留着等于埋雷。
