数据库与业务应用性能变慢：原因与修复方法

起初，系统感觉很快。报表几秒钟就能打开，收银员处理交易毫无停顿，仓库团队也从不抱怨。两三年后，抱怨开始出现：月度销售报表要等一分钟，客户搜索页面转圈很久，高峰时段应用似乎卡顿。没有发生什么剧烈的变化，但一切都感觉更慢了。

最常见的原因并非服务器性能不足，而是数据在为小规模设计的应用背后不断增长。数百万行的交易、库存历史和日志堆积起来，而过去很快的查询如今必须在大得多的数据堆里筛查。增加服务器往往只是推迟问题，还可能耗尽预算却没有解决根源。

本文以务实的方式讨论数据库与业务应用的性能：如何识别变慢的来源、索引的作用、缓存的工作方式、如何管理旧数据，以及纵向或横向扩展何时才有意义。内容面向企业主和运营经理，帮助他们与技术团队进行有的放矢的讨论。

摘要

• 先测量再优化，不要靠猜测寻找变慢的来源
• 合适的索引往往以最小的成本带来最大的提升
• 缓存可减轻读取频繁但很少变化的数据的负载
• 归档旧数据，让活跃数据表保持精简
• 在弄清根本原因之后，才增加服务器资源

系统为何会随时间变慢

刚上线的系统处理的数据很少。在这个规模下，几乎任何写法的查询都感觉很快，因为数据库只需检查几千行。随着时间推移，交易表增长了几十倍甚至几百倍，过去无害的做法开始变得沉重。

用户数量增长带来另一种压力。更多人同时打开报表、保存交易并运行同步，导致对相同资源的竞争。数据上的锁相互等待，即使服务器的算力并未耗尽，也会让界面看起来像卡死了一样。

新功能也有影响。每增加一份报表、一个集成或一个定时任务，都会给同一个数据库增加负载。如果没有定期关注，这些小改动的累积就会造成一个缓慢的系统，却找不到单一明显的原因。

先测量，再修复

最大的诱惑是凭直觉尝试各种修复。更可靠的做法从测量开始：哪个页面或报表最慢、在什么时间、使用得有多频繁。每月只打开一次的慢报表，其紧迫程度低于一天使用数百次的搜索页面。

现代数据库提供慢查询日志和查看执行计划的工具，也就是数据库决定如何获取数据的方式。借此技术团队可以看到哪些查询检查了过多的行、哪些运行得过于频繁、哪些在等待锁。

在改动任何东西之前先建立基线数字，例如主页面第 95 百分位的响应时间。有了这些数字，您就能证明修复确实有帮助，并避免在不知不觉中顾此失彼。

索引：小修复，大影响

数据库中的索引就像书中的目录。没有目录，找一个主题就得一页一页地翻。有了目录，就能直接跳到正确的位置。如果按客户编号或日期查找订单的列已建立索引，这类查询会快得多。

但索引并非没有代价。每次写入数据时都必须更新每个索引，因此索引过多会拖慢交易保存并占用空间。应根据确实频繁且缓慢的查询来选择索引，而不是在每一列上都添加。

还要注意组合索引中列的顺序，以及查询是否真的用上了它。有时查询的写法会让索引闲置，例如在列上包裹了函数，或数据类型不匹配。检查执行计划可以很快发现这类问题。

浪费的查询与重复出现的模式

一个经典模式是：一个页面悄悄运行数百个小查询，为显示的每一行各执行一次，而不是用一个查询一次性取回全部。数据量小时不易察觉，但有几千行时页面就会变慢。分批获取数据是常见的修复办法。

另一种模式是取回的数据超出所需：只显示两列却取回全部列，或用户只看本月却取回全部历史。限制列、添加分页并在数据库一侧过滤，可同时减轻网络和内存的负担。

高峰时段不应在与日常交易相同的数据库上运行繁重的报表。可将其安排在工作时间之外，或建立只读副本，或定期刷新的汇总表，这样收银员和仓库就不会感受到影响。

缓存：不重复计算已经知道的结果

很多数据被读取的频率远高于被修改的频率：分类列表、标准价格、店铺设置，或仪表盘计算的结果。把结果暂时存放在内存或缓存层，意味着下一次请求可以在不触及数据库的情况下立即得到回应。负载的减少可能非常显著。

难点在于保持数据新鲜。不刷新的缓存会显示过期的价格或库存。根据数据的性质设定合适的过期时间，并在源数据变化时清除或更新缓存。对于必须始终准确的数据，如余额或关键库存，不要随意缓存。

缓存也可以应用于其他层面：公开网站可使用内容分发网络上的静态页面，或在夜间计算报表结果。选择最契合访问模式的层面，以最小的复杂度获得最大的收益。

管理旧数据，让数据表保持精简

并非所有数据都需要永远留在活跃数据表中。三年前的交易很少被打开，却依然让每个查询更加沉重。把旧数据归档到独立存储，或按时期对表进行分区，可以让活跃表保持小巧而快速。

归档之前，请确保满足法律和审计要求。有些数据因税务或监管义务，必须在一定期限内保持可访问。设计在需要时取回归档数据的方式，即使它比活跃数据慢一些。

还要清理没有价值的数据，如旧的技术日志、过期的会话或临时文件。定期整理的习惯可以防止数据失控增长，并降低存储成本。

纵向与横向扩展：各自何时合理

纵向扩展意味着增强单台机器：更多内存、更快的处理器，或响应更快的存储。它简单，在早期阶段往往有效，无需改变架构。其局限在于成本和单机的物理极限。

横向扩展意味着把负载分散到多台机器上，例如为报表设置读副本，或在负载均衡器后部署多台应用服务器。它在大规模时更灵活，但会增加运维复杂度，包括数据同步和故障处理。

对大多数中小企业来说，查询优化、索引和缓存足以在很长时间内满足需求，之后才需要分布式架构。先采取最简单、最便宜的步骤，当测量数据确实有要求时再升级。

应用与网络层面的性能

并非所有变慢都源自数据库。加载大图、过多脚本或链式网络请求的页面，即使服务器很快也会让人感觉缓慢。图片尺寸、压缩和懒加载往往能带来用户立刻能感受到的改善，尤其是在简易设备和慢速网络上。

在移动应用和分店收银机上，网络质量影响很大。应让应用在连接不稳定时依然可用：暂存在设备上，联网后重新发送，并给出清晰的反馈，避免用户以为应用卡死。

同时要监控与第三方服务的集成。对缓慢的外部服务的同步调用，可能拖住整个交易流程。把它移到后台进程或队列中，即使供应商变慢，用户体验也能保持流畅。

在危机之前规划容量

不要等到旺季才了解系统的极限。运行负载测试，模拟您在最好的一天（例如大型促销期间或节前）预期的用户数和交易量。结果会显示哪个部分最先撑不住。

利用历史数据预测增长。如果交易量每年翻一番，您就可以估算当前极限何时会被超出，并提前安排改进，而不是在最糟糕的时刻救火。

设定预警阈值，例如当存储使用量或响应时间接近商定的限度时。这样团队有时间采取行动，而不是被已经影响到顾客的事故打个措手不及。

选择合适类型的数据库

大多数业务系统，如 ERP、收银和会计系统，适合关系型数据库，因为数据是结构化的，表与表之间的关系很重要。这类数据库成熟、有众多工具支持，并能保证交易一致性，这对财务和库存数据极为宝贵。

文档存储、键值存储或搜索引擎等其他类型也有各自的位置。例如，对大型商品目录的文本搜索，由专门的搜索引擎来承担比普通查询更合适。但新增一种数据库类型就意味着多一样需要运维和监控的东西，因此只有在需求确实明确时才这样做。

可以向技术团队提一个好问题：这个选择解决了什么具体问题，运维成本是多少？有力的回答会引用您系统中真实的访问模式，而不只是碰巧流行的技术潮流。

优化时保持安全与可靠

性能改动不能以牺牲数据安全和可靠性为代价。备份必须持续运行并经过恢复测试，访问权限继续受到限制，架构变更在接触生产数据之前先在试验环境中测试。仓促的优化是事故的常见来源。

把大的改动，例如给巨型表添加索引或迁移数据，安排在安静的时间窗口，并准备回退方案。有些操作在运行时会锁住表，因此团队在工作时间运行之前需要了解其影响。

记录每一次改动及其效果。整洁的记录有助于下一个团队理解为什么某项配置是这样的，并防止以前的修复在之后的变更中被无意撤销。

供应商与内部团队的角色

性能优化需要访问代码、数据和环境，因此应由了解您系统的人来完成。如果您使用供应商，请询问性能审计是否包含在维护服务中，以及多久进行一次。

要求提供非技术人员也能看懂的报告：问题是什么、对用户有什么影响、改动了什么，以及如何衡量结果。这样的报告有助于您判断工作的价值，并自信地决定下一个优先事项。

权衡优化的成本与收益

每一项性能修复都值得根据其对业务的价值来评判。一天被使用数百次的收银界面延迟十秒，意味着浪费的工时和不断变长的顾客队伍。把损失的秒数乘以使用次数，就能看出为什么某些修复比其他的更紧迫。

与替代方案的成本相比较。增加服务器容量看似快速简单，但其月度费用会一直持续下去，而一个放对位置的索引或一次查询修复，通常只需一次几小时的工作。

本周就可以开始的实用步骤

1. 01收集抱怨：哪些页面或报表感觉慢，在什么时间
2. 02启用慢查询日志并设定响应时间基线
3. 03检查最慢的五个查询的执行计划并添加合适的索引
4. 04把繁重的报表和同步移出高峰时段，或移到只读副本
5. 05对读取频繁、很少变化的数据应用缓存
6. 06按法律和审计要求设计旧数据的归档策略

示例：从两分钟降到三秒的销售报表

一家分销商抱怨月度销售报表要花两分钟，月底有时还会失败。启用慢查询日志之后，团队发现一个查询在日期和分店列上没有索引的情况下扫描了整个交易表，每次都要读取数百万行。

加上一个组合索引并稍微调整查询之后，时间降到约三秒。繁重的报表还被移到只读副本，这样经理提取数据时不再影响收银员。整个修复只花了几个小时的工作，比购买新服务器便宜得多。

结语

系统变慢不是必须接受的命运，也不总是购买更大服务器的理由。通过测量、找出真正的原因并逐步修复，大多数业务系统无需大规模重写就能重新变得迅速。

把性能纳入日常维护，而不是应急项目。定期审视慢查询、数据规模和响应时间趋势，能让系统在业务增长时保持健康，让您的用户和顾客从不觉得系统是一种拖累。