生产环境MySQL 8.0 my.cnf调优核心是三件事：设对innodb_buffer_pool_size（占内存70%+，如16GB机配10G）、限制单连接内存（sort_buffer_size=4M等）、匹配日志刷写策略（innodb_log_file_size=buffer_pool×0.25，innodb_flush_log_at_trx_commit=2）。
直接说结论：生产环境 MySQL 8.0 的 my.cnf 调优，核心就三件事：把 innodb_buffer_pool_size 设对、控制单连接内存不炸、让日志刷写策略匹配你的数据安全要求。其他参数都是围绕这三点打辅助，盲目调大反而容易 OOM 或锁表。
innodb_buffer_pool_size 必须按物理内存算，不是拍脑袋填数字
这个参数占 MySQL 总内存消耗的 70% 以上，设错是生产事故高发区。
- 8GB 内存服务器 → 建议
innodb_buffer_pool_size = 5G（不是 6G，留足系统和 OS 缓存） - 32GB 内存服务器 → 建议
innodb_buffer_pool_size = 20G（不超过 65%，避免 swap） - 必须同时配
innodb_buffer_pool_instances = 8（≥8GB 内存时），否则大缓冲池会因内部锁争用拖慢并发 - 改完必须重启 MySQL 生效，不能只用
SET GLOBAL；验证方式：SHOW VARIABLES LIKE 'innodb_buffer_pool_size'和SHOW STATUS LIKE 'Innodb_buffer_pool_read%'，目标是Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests
单连接内存参数要限制，否则一个慢查询就能吃光内存
MySQL 每个连接会独占排序、JOIN、临时表等缓冲区，不设上限等于给内存泄漏开后门。
-
sort_buffer_size = 4M（默认 256K，复杂 ORDER BY 易触发磁盘排序） -
join_buffer_size = 8M（多表 JOIN 场景下比 sort_buffer 更易失控） -
tmp_table_size = 64M和max_heap_table_size = 64M必须相等，否则内存临时表会无声降级为磁盘表 - 监控关键指标：
Created_tmp_disk_tables / Created_tmp_tables > 0.1就说明临时表撑爆了内存，得调大；但别超过 128M，否则单连接可能吃掉 300MB+
innodb_log_file_size 和 innodb_flush_log_at_trx_commit 是性能与安全的分水岭
这两个参数一起调，单独动一个容易翻车。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
innodb_log_file_size推荐值 =innodb_buffer_pool_size × 0.25（例如 buffer_pool=20G → log_file_size=5G），改它必须停库、删旧日志文件、再启库，否则 MySQL 启动失败报错Invalid log file size -
innodb_flush_log_at_trx_commit = 1（默认）：每次事务都刷盘，最安全但吞吐低；=2：每秒刷一次日志，崩溃最多丢 1 秒数据，OLTP 常用；=0：只写内存日志，风险极高，仅测试环境考虑 - 注意：
innodb_flush_method = O_DIRECT必须开启，否则 Linux page cache 和 InnoDB buffer pool 双重缓存，实际可用内存远低于预期
max_connections 和 thread_cache_size 要看真实连接模式，不是堆数字
很多团队把 max_connections 设成 2000，结果发现 Threads_created 每秒涨几十个 —— 这说明连接池没配好，MySQL 在疯狂创建销毁线程。
- 先查真实峰值：
SHOW STATUS LIKE 'Threads_connected'，取过去一周最高值 × 1.5 作为基准 -
max_connections = 500是多数中小业务的安全起点；配套设thread_cache_size = 16（不是 500×0.25=125，缓存太大反而增加管理开销） - 如果用连接池（如 HikariCP、Druid），重点压测连接复用率，而不是狂加
max_connections - 漏掉的关键项：
open_files_limit必须 ≥max_connections × 3，否则会出现Too many open files错误，且该值需在系统级（/etc/security/limits.conf）同步调整
最容易被忽略的点：所有内存参数加起来不能超过物理内存的 80%，innodb_buffer_pool_size 是主力，但 sort_buffer_size × max_connections 这块“隐形内存”在高并发下会突然爆发。上线前务必用 sysbench 或真实流量压测，看 free -h 的 available 是否持续低于 1GB。
