系统越用越卡？慢？SQL治理三条路线对比

企业系统上线三五年后普遍出现一个症状：月初还好好的，一到月底结账、报表汇总就卡成幻灯片；数据量从几十万涨到几千万，原来秒开的列表页现在要转圈半分钟。老板问能不能加服务器解决，运维说加了效果也不大——钱花了，卡顿还在。

核心矛盾是：数据库变慢很少是"机器不行"，更多是 SQL 写法、索引设计、数据规模与架构之间的不匹配，治理的深度不同，投入产出天差地别。 业界有三条递进的路线：SQL 与索引级优化、架构级读写分流、数据生命周期治理，改造成本和收益周期逐级变化。

路线一：SQL 与索引级优化

原理： 从最直接的层面入手：开启慢查询日志定位 Top 慢 SQL，用执行计划（EXPLAIN）分析全表扫描、索引失效、隐式类型转换等问题，通过补索引、改写 SQL、拆分大事务逐条治理。

优点：

• 投入最小：不动架构、不改代码框架，DBA 或开发几天就能见效
• 收益立竿见影：Top 10 慢 SQL 通常贡献八成以上的数据库负载，治理性价比极高
• 风险可控：加索引、改 SQL 都是局部变更，回退简单

缺点：

• 治标不治本：数据量持续膨胀，今天的优化会被明天的数据规模吃掉
• 依赖个人能力：没有制度化，优化靠"哪位高手有空看一眼"
• 对架构性问题无效：单表几亿行、报表和业务抢资源这类问题，改 SQL 救不回来

适用场景： 数据量千万级以内、卡顿刚冒头的系统。所有性能治理的第一步都应该是它——先把低垂的果子摘了。

路线二：架构级读写分流

原理： 把数据库压力从架构上拆开：读写分离让查询走只读副本；报表、大列表等重查询引入缓存（Redis）或搜索引擎（Elasticsearch）承接；定时任务与批量操作错峰调度，避免和业务高峰抢资源。

优点：

• 承载能力质变：读流量可以水平扩展，不再受单机上限约束
• 业务与报表解耦：管理层的汇总查询不再拖垮一线业务操作
• 对应用改造可控：读写分离有成熟中间件（ShardingSphere、MyCat、云数据库代理），缓存可以逐接口灰度引入

缺点：

• 架构复杂度上台阶：主从延迟、缓存一致性、搜索引擎的数据同步，每个组件都是新的运维面
• 一致性问题浮现：写入后立刻读、缓存与库不一致，业务要接受"近实时"的语义
• 成本明显增加：副本、缓存集群、同步链路，硬件和人力都是新开销

适用场景： 数据量千万到亿级、读多写少、报表需求重的业务系统。互联网和 SaaS 系统的标准配置。

路线三：数据生命周期治理

原理： 从源头控制数据规模：冷热分离，历史数据归档到低成本存储（归档库、数据仓库），在线库只保留热数据；大表按业务维度拆分；建立数据保留策略，到期数据自动归档或清理。

优点：

• 治本：在线库数据量被锁死在健康水位，性能不再随年限劣化
• 存储成本下降：冷数据放廉价存储，比一直堆在高性能库省钱
• 顺带解决合规：数据保留与清理策略本身就是等保和审计的要求

缺点：

• 改造最重：归档涉及业务语义（历史订单还要不要查、怎么查），不只是技术问题
• 周期最长：归档策略要业务、财务、法务多方确认，以季度为单位推进
• 历史查询体验要设计：查三年前订单要走"归档查询"入口，产品体验需要专门打磨

适用场景： 运行五年以上、单表数据量过亿的存量系统，以及对数据保留有明确合规要求的金融、医疗行业。

按症状对号入座

实战中的合理顺序是先救命再治病：索引优化一周内把 Top 慢 SQL 压下去，争取时间；读写分流把报表和业务拆开，稳住中期；生命周期治理排进年度规划，解决根本。

落地前必做的三件事

第一件：先量化再优化。 慢查询阈值、Top 慢 SQL 清单、每条 SQL 的执行频率与耗时分布，用数据说话。"感觉最近卡"优化不出结果，抓到的必须是可复现的慢 SQL 和执行计划。

第二件：建立慢查询的持续监控。 优化不是一锤子买卖：新功能上线带来新的慢 SQL 是常态。慢查询日报、SQL 审核进 CI 流程，把性能问题拦截在上线前，比事后救火便宜一个数量级。

第三件：归档策略拉上业务一起定。 历史数据保多久、要不要可查、查询时效要求，这些是业务决策不是技术决策。技术单方面定归档规则，迟早被业务部门投诉推翻。

写在最后

慢 SQL 治理的核心不是"找几条慢 SQL 改改"，而是建立"监控发现-优化处置-架构演进"的持续机制。系统变慢是个慢性病，急症靠索引优化救场，中期靠架构分流续命，根治靠数据生命周期管理。只救急不治病，明年今天还会卡。