MySQL读写性能优化本质是匹配硬件与数据库行为，核心在于减少磁盘IO、内存不足、连接争抢和日志刷盘延迟；硬件层优先SSD（推荐NVMe）、内存配70%–80%给Buffer Pool、CPU需足够核心数、网卡千兆起步；系统层调优文件描述符、IO调度器、swappiness；参数层聚焦innodb_buffer_pool_size、innodb_log_file_size、innodb_flush_log_at_trx_commit等关键项；架构上禁用Query Cache、强制索引、批量写入、读写分离。
MySQL 数据库读写性能的优化，本质是让硬件资源与数据库行为更匹配。重点不在堆配置，而在减少瓶颈——尤其是磁盘 IO、内存不足、连接争抢和日志刷盘延迟这几个高频卡点。
硬件层：先确保“地基”够稳
再好的配置也跑不赢物理限制：
- 存储必须用 SSD，优先选 NVMe 协议；机械盘在高并发下极易成为 IO 瓶颈，随机读写差距可达百倍
- 内存要留足给 InnoDB 缓冲池：建议设为物理内存的 70%–80%，例如 64GB 服务器配 48GB；低于 50% 时缓冲池命中率常跌破 95%，触发大量磁盘读
- CPU 不求单核最强，但需足够核心数：InnoDB 多线程支持良好，8 核起步较稳妥；避免用低频多核（如 16×2.0GHz），不如 8×3.2GHz 实际表现好
- 网卡至少千兆，主从同步频繁时建议万兆；多网卡可做 bond（如 mode 4）提升吞吐与容错
操作系统层：释放底层调度潜力
Linux 默认设置偏保守，需针对性调优：
-
文件描述符上限必须提高：MySQL 每个连接、每张表、每个日志文件都占一个 fd；在 /etc/security/limits.conf 中设
* soft nofile 65535和* hard nofile 65535 -
IO 调度器适配存储类型：SSD 用
mq-deadline（非cfq或noop），可通过echo mq-deadline > /sys/block/nvme0n1/queue/scheduler临时生效 -
关闭或严格限制 SWAP：设
vm.swappiness=1，避免内存压力大时将热数据换出到慢速磁盘 -
TCP 连接复用开启：
net.ipv4.tcp_tw_reuse = 1，缓解高并发短连接下的 TIME_WAIT 积压
MySQL 参数层：聚焦几个关键变量
不必改上百项，盯住真正影响读写效率的几处：
-
innodb_buffer_pool_size：设为可用内存的 70%–80%，且建议配合innodb_buffer_pool_instances（值 ≈ CPU 核心数），避免单实例锁争抢 -
innodb_log_file_size：总和建议为 Buffer Pool 的 25%–50%，例如 48GB 缓冲池可设两个 4GB 日志文件；太大恢复慢，太小导致频繁 checkpoint -
innodb_flush_log_at_trx_commit：=1 最安全（每次 commit 写盘），=2 适合非金融场景（每秒刷一次），性能提升明显但可能丢 1 秒数据 -
sync_binlog：=1 最可靠，=100 或 0 可提升写入吞吐，但主从一致性风险上升；与上一项需协同权衡 -
max_connections：按业务峰值预估，一般设为(CPU核心数 × 2) + 磁盘数左右，并搭配thread_cache_size = 16–32减少线程创建开销
架构与使用习惯：绕不开的现实约束
配置再优，也扛不住不合理用法：
-
禁用 Query Cache（MySQL 5.7+ 默认已移除）：高并发下它反而成锁热点；若还在用 5.7 且开启，务必设
query_cache_size = 0 -
所有大表必须有合理索引：尤其 WHERE、JOIN、ORDER BY 字段；用
EXPLAIN验证执行计划，避免全表扫描 - 写操作尽量批量提交：单条 INSERT 改成 INSERT ... VALUES (...), (...), (...)；事务内批量处理比多次小事务快得多
- 读写分离早规划：哪怕初期只有一主一从，也能分担报表、统计等只读压力；用 ProxySQL 或 MaxScale 做流量路由
