MySQL 8.0 性能关键在于 my.ini 中 innodb_buffer_pool_size、innodb_log_file_size、default_authentication_plugin、max_connections 和 thread_cache_size 等参数需按硬件与用途合理配置，盲目套用模板易引发内存溢出、连接拒绝或写入延迟。
my.ini 里几个关键参数是否贴合你的硬件和用途。盲目套用网上模板，反而容易导致内存溢出、连接拒绝或写入延迟飙升。
innodb_buffer_pool_size 设置不当会直接拖垮查询速度
这是 MySQL 最关键的内存参数，它决定多少数据能常驻内存。设太小，频繁读盘；设太大，OS 内存不足，触发交换（swap），性能断崖式下跌。
- 开发机（8GB 总内存）：建议设为
innodb_buffer_pool_size=2G，留足 4GB 给系统和其他进程 - 专用数据库服务器（32GB 内存）：可设为
innodb_buffer_pool_size=24G（约 75%） - 绝对不要写成
innodb_buffer_pool_size=100%或8G（而实际物理内存只有 6GB）——Windows 会直接拒绝启动服务，日志里报Cannot allocate memory for the buffer pool - 若启用多个实例，每个实例的 buffer pool 必须独立配置，不能共用
innodb_log_file_size 过大会延长崩溃恢复时间
这个值影响事务日志（ib_logfile0/1）大小，直接影响 crash recovery 耗时和写入吞吐。不是越大越好，尤其在 SSD/NVMe 上需谨慎。
- 默认值（如 48MB）适合低并发场景，但写入密集时易成为瓶颈
- 推荐值：设为 buffer pool 的 25% 左右（例如 buffer pool=2G → log file size=512M），但单个文件不超过 2G
- 修改前必须先停服务、删旧日志：
net stop mysql→ 手动删除ib_logfile0和ib_logfile1→ 启动服务，MySQL 会重建 - 如果改完启动失败并报错
InnoDB: Error: log file ib_logfile0 is of different size，说明没清干净旧日志
default_authentication_plugin 导致老客户端连不上
MySQL 8.0 默认用 caching_sha2_password，比旧版 mysql_native_password 更安全，但 Navicat ≤ v12、某些 PHP PDO 驱动、甚至旧版 MySQL Workbench 会握手失败，报错 Client does not support authentication protocol requested by server。
- 临时兼容方案：在
[mysqld]段加default_authentication_plugin=mysql_native_password - 长期建议：升级客户端工具，或对特定用户单独改认证方式：
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'xxx'; - 注意：改完需执行
FLUSH PRIVILEGES;，且该设置不影响已创建用户的插件类型，只影响新用户
max_connections 和 thread_cache_size 配合不好会卡死新连接
光调高 max_connections 没用。如果 thread_cache_size 太小，每次新连接都要创建销毁线程，CPU 空转，连接排队超时。
-
max_connections=150是合理起点；若应用报Too many connections，再逐步加（每次 +50） -
thread_cache_size建议设为max_connections的 1/8～1/4（如 150 → 设 16） - 观察指标：运行中执行
SHOW STATUS LIKE 'Threads_created';，如果该值每秒持续增长 > 2，说明 cache 不够 - Windows 下线程开销比 Linux 高，不建议盲目设到 64+，容易触发系统级线程资源限制
SHOW VARIABLES 和 SHOW ENGINE INNODB STATUS\G 核对生效情况，别只信配置文件里写了什么。 
