真正能立竿见影提升性能的只有innodb_buffer_pool_size、max_connections和wait_timeout三个参数；其他调优多属锦上添花，误配反致实例崩溃。
直接说结论：真正能立竿见影提升性能的，只有 innodb_buffer_pool_size、max_connections 和 wait_timeout 这三个参数；其他多数调优属于“锦上添花”，甚至可能因误配拖垮实例。
innodb_buffer_pool_size 设多少才不拖慢查询
这个值决定 MySQL 能把多少数据和索引常驻内存，直接影响 80% 的读性能。设小了，频繁磁盘 IO；设大了，可能挤占系统其他进程内存，触发 OOM Killer 杀掉 mysqld。
- 生产环境建议设为物理内存的 50%–75%，但必须是
128MB的整数倍（否则启动报错Invalid value for innodb_buffer_pool_size） - 若机器总内存 32GB，可设
innodb_buffer_pool_size = 24G；但若同时跑 Redis 或 Java 应用，得留足至少 6GB 给它们 - 别盲目设到 90% —— Linux 内核、文件系统缓存、连接线程栈都需要内存，
top看%MEM持续超 95% 就危险了 - 低内存（≤2GB）机器建议设为
512M，避免 buffer pool 刷脏页时吃光剩余内存
max_connections 和 wait_timeout 配合不好会爆连接
连接数不是越多越好。设太高，每个连接吃内存（尤其用了大量临时表或排序），还容易被慢查询拖垮；设太低，应用报 Too many connections。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 先查真实峰值：
SHOW GLOBAL STATUS LIKE 'Threads_connected';，再加 20% 余量作为max_connections -
wait_timeout（默认 28800 秒）必须配合应用连接池设置。Spring Boot 默认 HikariCPconnection-timeout=30000，那wait_timeout建议设成300（5 分钟），避免连接池复用“半死”连接导致MySQL server has gone away -
interactive_timeout控制交互式客户端（如mysql命令行），一般和wait_timeout设成一样，否则容易混淆
query_cache_type 关掉就对了
MySQL 5.7 默认已弃用 query cache，8.0 直接删了。但很多老配置还留着 query_cache_type = 1，反而引发锁争用——每次写操作都要清空整个 cache，高并发下性能反降。
- MySQL 8.0 配置里若还留着
query_cache_type或query_cache_size，启动直接报错退出 - 升级前务必用
mysqld --validate-config检查配置合法性 - 即使 5.7 环境，也应设为
query_cache_type = 0，比开着更稳
改完配置后最容易被忽略的验证动作
很多人改完 /etc/my.cnf 就以为万事大吉，结果参数根本没生效。
- MySQL 启动时按固定顺序读多个
my.cnf，后加载的会覆盖前面的。常见误操作是改了/etc/my.cnf却没生效，因为实际加载的是/etc/mysql/my.cnf或~/.my.cnf - 用
mysqld --help --verbose | grep "Default options"查看实际搜索路径（注意输出里带(/path/to/my.cnf)的行） - 修改后必须重启 MySQL（
systemctl restart mysql），仅reload不会重载[mysqld]段大部分参数 - 验证是否生效：
mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"，别只信配置文件内容
