「越用越慢」不是错觉，是几类劣化在同时累积

几乎所有跑了两年以上的业务系统，都会经历同一个阶段：刚上线时点哪儿都是秒开，一年后开始有人抱怨「这个页面要转半天」，两年后变成「月底那几天根本打不开」。业务部门的直觉是服务器不够用了，于是加内存、升配置，效果维持两三周，然后又慢回去。钱花了，问题没解决。

原因在于，系统变慢很少是单一原因，而是几类劣化叠在一起同时发作：数据量从十万涨到五百万，原来的查询没索引就撑不住了；接口调用从每天几千次涨到几十万次，连接池排起了队；日志文件从几十兆涨到几十个G，磁盘一满整个服务就假死；前端代码在两年里加了二十个功能，首屏要加载的资源从八百K涨到三兆多。每一项单独看都只是「慢一点」，叠起来就是用户感知的「卡死」。

所以正确的做法不是先买服务器，而是先量出到底慢在哪一层。这篇清单把存量系统的性能治理拆成可以逐条核对的动作，包括怎么用症状反推位置、数据库和应用层各自的典型坑、以及优化做完之后用什么口径验收。合肥本地软件开发公司在承接这类治理项目时，第一步从来不是改代码，而是拿到一份可信的分层耗时数据。

从症状反推位置：五类病因的对照表

性能问题最怕瞎猜。同一个「页面打不开」，可能是数据库慢查询、可能是接口串行调用、可能是前端资源太大、也可能是网络出口带宽被打满。用症状去反推，能少走很多弯路。

这张表里最容易被误判的是第一行和第三行。第一行如果只看应用服务器指标，会发现 CPU 并不高，于是判断「服务器够用」，实际瓶颈在数据库，应用只是在等结果。第三行更隐蔽：某企业的月结对账任务设在每月一号凌晨两点，本来不冲突，后来业务扩展到全国门店，凌晨两点正好是西部门店的营业高峰，任务一跑，收银端就开始转圈，查了两个月才定位到调度表。

定位阶段有个硬要求：必须按接口维度统计 P95 和 P99，不能看平均值。一百次请求里九十九次两百毫秒、一次二十秒，平均值算下来不到四百毫秒，看起来完全正常，但那一次二十秒对应的就是真实用户在投诉。平均值会把最该修的问题藏起来。

这里补一句方法论上的提醒：拿到耗时数据之前，任何「优化方案」都只是猜测。合肥本地软件开发公司做这类项目，报价里通常应当包含一段单独的度量期，客户有时觉得这钱花得冤枉，想让工程师直接上手改。真跳过这一步的后果，是把预算花在不是瓶颈的地方——见过一个项目花两个月把前端重做了一遍，首屏从四秒二降到三秒九，因为真正的瓶颈在数据库，而没人去量。

数据库这一层：数据量翻十倍后失效的三件事

存量系统最普遍的瓶颈在数据库，而数据库的问题又有极强的规律性。数据量小的时候，全表扫描也就几十毫秒，谁都不会在意；数据量涨到几百万行，同样的写法就变成了几秒。

深分页这一项值得单独说。很多后台列表默认按偏移量翻页，前几十页毫无感觉，业务人员为了找一条半年前的记录一路翻到几百页，接口就开始超时。改成游标方式以后，无论翻到第几页耗时都一样，改动量通常只有几十行代码，收益却非常直接。

另一个常被忽略的是历史数据。订单表在线保留三年，五年就是千万级，即使索引齐全，备份、统计、报表都会被拖慢。合理的做法是冷热分离：在线库只保留一到两年的活跃数据，更早的数据迁到只读的历史库，业务上仍可查询，但不再参与高频事务。这个动作要提前和财务、审计对齐保留期限，不能自己拍脑袋删数据。

应用层：缓存、连接池、日志与定时任务

数据库修完，很多系统还是会慢，问题往往出在应用层的四个角落。它们的共同点是：代码写起来很顺手，出问题却极难定位。

缓存这一项还有个隐蔽的坑：一致性。很多人习惯「先删缓存再写库」，两个并发请求交错时会把旧值写回缓存，之后一直读到脏数据。相对稳的顺序是先更新数据库、再删除缓存，并对删除失败做补偿重试；对一致性要求高的字段干脆不缓存，直接查库。

连接池的容量估算经常被拍脑袋决定。一个可用的经验是：每秒请求数乘以单次平均耗时（秒），得到大致需要的并发连接数，再留三成余量。比如每秒两百次请求、单次平均三十毫秒，算下来需要六个连接，设二十个足够；反过来单次耗时涨到三百毫秒，同样并发就需要六十个连接，这时候该做的是把单次耗时降下来，而不是继续加连接。

安徽好牛软件有限公司在接手存量系统治理时，通常会先做一周的埋点观察再动手，原因是应用层的慢往往有很强的时段性，只抓一次现场很容易误判成偶发问题。

前端与网络：首屏那几秒是怎么丢掉的

后端优化完，用户还是会说「打开慢」，这时候要看的是浏览器到服务器之间这一段。这一段的损耗几乎全部来自资源体积和请求数量。

最常见的三种情况：一是打包没有拆包，一个入口文件把整个应用的所有页面、所有组件、所有工具库都装进去，首屏必须等这三兆下载完才能渲染；二是图片直接上传原图，一张商品图四兆，列表页一屏十几张；三是静态资源没有走内容分发网络，所有请求都打到同一台源站服务器，跨省用户访问要多绕几百毫秒。这三种问题叠加，首屏从一点二秒变成四秒多很常见。

对应的处理也不复杂：按路由拆包，首屏只加载当前页面需要的代码；图片在上传时就压缩并生成多种尺寸，列表用小图、详情用大图；静态资源加长缓存并走分发网络；字体文件只保留实际用到的字重和字符集。这些改动不需要重构架构，通常一到两周能做完，对感知速度的提升却最明显。

还有一类问题来自交互设计本身：首屏一次性发起十几个接口请求，串行依赖，第一个不回来第二个不发。合理的做法是把互不依赖的请求并行发出，把非首屏必需的数据延后加载，列表先出骨架再填充数据。用户对「有反馈」的容忍度远高于「白屏等待」，哪怕总耗时一样。

治理四步与验收口径：别用平均值自欺

性能治理最怕做成一次性的运动。改完当天很快，一个月后又慢回去，因为没有人守着指标。可行的做法是四步，并且每一步都留下可对比的数据。

第一步度量。接入接口级监控或至少打开数据库慢查询日志，前端接入真实用户测速，把「慢」变成可排序的数字。第二步定位。按耗时排序抓前二十个接口，实践中往往两成的接口吃掉八成的总耗时，先把这批修完，整体体感立刻改善。第三步止血。补索引、加缓存、改分页、把同步动作改异步、对非核心接口限流，目标是两周内让核心链路回到可接受区间。第四步结构化改造。读写分离、冷热数据分离、批量替代循环、把重计算挪到离线任务，这一步周期长，但决定系统还能撑几年。

这四步里，第三步最容易做成半拉子。补索引当天见效，团队就觉得问题解决了，后面的归档、异步化、冷热分离全部搁置，结果半年后数据量再涨一轮，同样的页面又开始慢。安徽好牛软件有限公司在交付这类治理项目时，会把第四步拆成明确的季度任务写进交付清单，而不是留一句「后续可优化」——性能这件事没有终点，只有节奏。

验收必须用同一份压测脚本、同一批数据量、同一时段对比，否则数字没有意义。还有一个容易被忽略的指标：优化后连续七天的曲线是否平稳。如果只是把峰值挪到了另一个时段，问题并没有解决，只是被推迟了。

预算上给一个参考区间：存量系统的性能治理通常落在原项目造价的百分之十到二十五之间，或者按人天算十五到三十人天。超过这个量级，就要认真评估是不是该重写核心模块，而不是继续在旧结构上打补丁。有三种情况确实不值得大动：业务总量本来就小，日请求不到五万次；瓶颈明确在第三方接口，自己能改的空间有限；这套系统一到两年内就要被替换。

常见问题解答

Q1：加了服务器配置，为什么只快了两三天？

因为瓶颈不在算力。加配置能缓解 CPU 和内存压力，但对慢查询、连接池排队、磁盘写满、前端资源过大这四类问题几乎无效。典型表现是：加完配置后数据库 CPU 从九成降到六成，看似好转，但慢查询依旧存在，一旦并发再涨上去，同样的页面又开始转圈。判断方法很简单，看应用服务器 CPU 是否长期低于五成而响应仍然慢，如果是，问题一定在依赖侧。

Q2：索引是不是加得越多越好？

不是。每个索引都要在写入时维护，一张表挂十几个索引，插入和更新的耗时会明显上升，批量导入时尤其明显。合理的做法是按真实查询条件建联合索引，遵循最左前缀原则，把选择性高的字段放前面，并且定期清理从未被使用的索引。判断某个索引有没有用，看它的使用统计，长期为零的直接删掉。另外注意，同一个字段上既建了单列索引又建了以它为前缀的联合索引，单列那个是多余的。

Q3：上缓存能不能一次性解决慢的问题？

只能解决读多写少、且允许短暂不一致的场景。缓存引入的是新的复杂度：一致性怎么保证、缓存击穿怎么办、热点键怎么分散、缓存和数据库同时故障时如何降级。把不该缓存的数据缓存起来，最容易出现的是「用户看到的是昨天的价格」。建议的顺序是先把查询本身优化到可接受，再对确实扛不住的热点加缓存，而不是一上来就套一层缓存掩盖问题。

Q4：老系统是继续优化，还是直接重写？

看三个信号。一是核心链路的耗时里，超过一半花在架构性缺陷上，比如单库单表、同步阻塞、无法水平扩展，这类问题打补丁的边际收益很低。二是业务本身要大改，优化完也要推倒，那就没有优化价值。三是团队已经没人能读懂核心代码，改一处崩一处。三条里中两条，重写的账更容易算平；只中一条，先做治理更划算。还有一种折中路径：把最慢的模块单独抽出来重写，其余保留，用接口隔离，风险最小。

Q5：怎么确认优化真的生效，而不是心理作用？

三个动作。一是保留治理前的基线数据，包括接口 P95、慢查询条数、首屏时间、数据库峰值，没有基线就没有对比。二是治理后用同一份压测脚本复测，并发梯度保持一致，看曲线拐点是否右移。三是上线后连续观察七天，看真实用户侧的 P75 是否同步下降。只看某一天「感觉快了」不算数，性能问题常常有时段性，赶上一个空闲时段测出来的漂亮数字没有参考价值。