减少 MySQL 压力需从架构设计、查询优化、连接控制、分库分表四层面系统施策：读写分离分流负载，精准索引与慢查治理，连接池限流防雪崩，冷热分离与分片应对数据增长。

减少 MySQL 数据库压力，核心在于“让数据库少做事、做对事、分担事”。不是一味加机器或调参数，而是从架构设计、查询行为、数据组织和资源协同四个层面系统优化。

合理拆分读写流量

MySQL 默认主从结构天然适合读写分离。写操作集中到主库，读请求分散到多个从库，能显著降低单点负载。

• 应用层需明确区分读写语句，避免在从库执行 INSERT/UPDATE/DELETE；

• 使用中间件（如 ProxySQL、ShardingSphere）或客户端路由逻辑自动识别并转发；

• 注意从库延迟问题，对一致性要求高的读（如刚下单查订单），应强制走主库；

• 从库可配置不同规格：高配节点处理报表类慢查询，低配节点承接简单列表页请求。

精准优化慢查询与索引

80% 的压力往往来自 20% 的低效 SQL。不优化查询，再好的硬件也扛不住。

• 开启 slow_query_log，设置 long_query_time ≤ 1s，定期分析 pt-query-digest 输出；

• 用 EXPLAIN 分析执行计划，重点看 type（尽量到 range 或 const）、rows（扫描行数越少越好）、key（是否命中索引）、Extra（避免 Using filesort / Using temporary）；

• 联合索引遵循最左前缀原则，把高频过滤字段放前面；区分度高的字段更适合建索引；

• 避免 SELECT *，只取必要字段；大字段（TEXT/BLOB）单独建表或异步加载；

• 分页深度大时（如 LIMIT 10000,20），改用游标分页（记录上一页最大 ID）或延迟关联优化。

控制连接与并发，避免雪崩

过多连接不仅耗内存，还会引发锁竞争和上下文切换开销，导致整体响应变慢。

• 应用端使用连接池（如 HikariCP），设置合理的 maxPoolSize（通常 10–30，依业务 IO 特性调整），禁止直连；

• MySQL 端调优 wait_timeout 和 interactive_timeout（建议 300–600 秒），及时回收空闲连接；

• 监控 Threads_running，持续高于 30–50 需警惕，配合 show processlist 查看阻塞源头；

• 对批量导入、统计任务等重负载操作，错峰执行，或限制并发线程数（如用 pt-archiver 控制速率）。

分库分表与冷热分离

单表超千万行或单库超 100GB 后，常规优化边际效益下降，需考虑水平或垂直切分。

• 分表优先考虑业务维度：如按 user_id 取模分 16 张订单表，或按时间（月/季度）归档历史订单；

• 分库需配套解决分布式事务（Seata）、跨库 JOIN（尽量规避，改用应用层组装）、全局 ID（雪花算法或号段模式）；

• 冷热分离：将 1 年前订单移入历史库，主库只保留活跃数据，大幅提升热区查询效率；

• 静态数据（如省份字典）缓存到应用本地或 Redis，彻底免除数据库访问。