减少 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，彻底免除数据库访问。不复杂但容易忽略。架构优化不是一锤子买卖，而是在业务增长中持续观察、测量、验证的过程。每次上线新功能前，先问一句：它会多查几次库？会不会产生新慢 SQL？有没有缓存兜底？
