key_buffer_size仅对MyISAM有效，InnoDB库应设为16M或默认值；innodb_buffer_pool_size才是核心参数，建议设为物理内存50%–75%且按MB对齐；sort_buffer_size等线程级参数不宜过大，避免OOM。
my.cnf 中 key_buffer_size 设错会导致查询变慢甚至崩溃
MySQL 5.7 及以前版本用 key_buffer_size 缓存 MyISAM 索引，但宝塔默认装的通常是 InnoDB 表——这时候调大它毫无意义，反而挤占系统内存。很多用户看到“缓冲区”就无脑翻倍，结果 mysqld 启动失败，日志里反复报 Cannot allocate memory。
- 只对 MyISAM 表有效；InnoDB 表完全不走这个参数
- 若数据库全是 InnoDB（宝塔新建库默认如此），建议设为
16M或干脆保留默认值，别乱动 - 查表引擎：执行
SELECT ENGINE, COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db' GROUP BY ENGINE; - 改完必须重启 MySQL：
bt 16→ 选择重启，不能只重载配置
innodb_buffer_pool_size 是唯一真正影响性能的核心参数
它决定 InnoDB 能缓存多少数据和索引页，占内存比例不对，性能会断崖下跌。宝塔面板里“数据库配置”页的滑块只是个摆设，实际生效靠的是手动改 /www/server/mysql/my.cnf 里的这一行。
- 生产环境建议设为物理内存的 50%–75%，但最低不少于
128M；小内存机器（如 1G）别超过512M，否则系统会 OOM - 改前先看当前使用率：
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_%';关注Innodb_buffer_pool_read_requests和Innodb_buffer_pool_reads，比值低于 99% 就说明缓存不够 - 该值必须是
1024 * 1024的整数倍（即按 MB 对齐），写成2G或2048M都行，但别写2000M - 修改后用
mysqladmin -u root -p variables | grep innodb_buffer_pool_size验证是否加载成功
sort_buffer_size 和 join_buffer_size 不是越大越好
这两个是线程级缓冲区，每个查询连接都会独立分配。设太高会导致并发稍高时内存爆炸，尤其在宝塔这类共享环境里容易触发 OOM killer 杀掉 mysqld 进程。
- 默认值（
256K/256K）已够大多数中小查询；除非你频繁跑ORDER BY大结果集或JOIN十万行以上宽表，否则别动 - 线上调优优先看
Sort_merge_passes和Select_full_join状态值；持续增长才考虑微调，每次加128K观察 - 绝对不要设成
4M以上——一个 200 并发的连接池就能吃掉 800MB 内存 - 它们在配置里要写在
[mysqld]段下，且不能放在[client]或其他段里，否则无效
改完 my.cnf 必须验证配置语法和实际加载效果
宝塔的“保存”按钮只是写文件，不校验语法，也不检查参数是否被真正接受。很多问题出在看似改了，其实 MySQL 启动时跳过了错误行，还沿用旧值。
- 先用
mysqld --defaults-file=/www/server/mysql/my.cnf --verbose --help | grep "Default options"确认配置文件路径没被覆盖 - 再用
mysqld --defaults-file=/www/server/mysql/my.cnf --validate-config（MySQL 5.7.20+ 支持）检查语法 - 重启后立刻执行
SELECT @@innodb_buffer_pool_size, @@key_buffer_size;，对比输出和配置文件是否一致 - 留意错误日志：
/www/server/mysql/data/*.err，里面若有Warning: Using a password on the command line interface can be insecure之类提示，说明启动参数有误
最常被忽略的一点：宝塔的 MySQL 服务可能被 systemd 或 init.d 双重管理，bt 16 重启有时不彻底。真要确认，得看 ps aux | grep mysqld 的启动命令里带的配置路径是不是你刚改的那个。
