数据经理：性能和成本优化的连锁反应（每个管理员都需要了解数据库优化的收益）

核心提示：在寻找节省 IT 成本的机会时，数据库可能是您最后考虑的领域，数据经理：性能和成本优化的连锁反应（每个管理员都需要了解数据库优化的收益），毕竟，数据库最重要的任务是随时及时地提供正确的信息，就像是开着轮胎没气的满载的车到处跑，请这样想：如果您能够把数据库服务器的数量、许可证成本和能源成本都减少一半儿，但是，数据库优化可

在寻找节省 IT 成本的机会时，数据库可能是您最后考虑的领域。毕竟，数据库最重要的任务是随时及时地提供正确的信息。但是，数据库优化可以同时降低成本和改进性能。优化数据库会减少不必要的 CPU 消耗，这会产生积极的连锁反应：减少 CPU 消耗，降低硬件的能源和制冷成本，改进服务器整合和虚拟化，降低硬件成本，降低软件许可证成本，提供更好、更可靠、更可预测的响应时间，从而改进组织的生产力。

但是，为了通过数据库优化获得最大的收益，您需要了解两件事。第一件事是数据库的物理设计是极其重要的，尤其是索引。在人查找信息时，索引有助于轻松快速地找到信息，索引对于数据库也起这种作用。

假设您的冰箱里有一碗蓝莓，您想用它做菜。您找出您喜欢的烹调书，寻找使用蓝莓的食谱，但是这本书非常大，有 592 页。您可以翻阅这本烹调书的每一页，在食材清单中寻找蓝莓，但是这种扫描成本很高。这会花费大量时间，消耗体力，甚至可能让您的眼睛酸疼。烹调书后面很可能有索引，可以在索引中查找 “蓝莓”，然后直接跳到您要找的页面。

数据库采用同样的工作方式。如果把 592 页的烹调书保存在数据库中，它算不上非常大的数据库表；实际上相当小，用一个 32 MB U 盘就能够保存它。但是，如果要求应用程序搜索食材清单中包含蓝莓的食谱，应用程序会向数据库发送一个查询，数据库会扫描食谱条目。扫描可能执行 592 条 CPU 指令，如果烹调书还没有放在数据库内存中，指令可能更多；扫描可能会花费 5 秒才能完成。现在，如果在 INGREDIENT 上有合适的索引，同样的搜索只需 6 个 CPU 指令，会在几分之一秒内完成。

您的业务系统可能不会经常搜索蓝莓，但是原理是一样的。每个业务系统数据库和数据仓库经常访问许多非常小的表（往往不超过 U 盘的容量）。问一下您的 DBA，数据库中有多少个表小于 64 MB；他的回答可能让您大吃一惊。小数据库表之所以重要，是因为您需要了解的第二件事是：只有全盘考虑整个系统，才能获得最好的性能优化效果。

DBA 使用数据库厂商提供的实用程序 EXPLAIN 查看数据库的访问策略。EXPLAIN 实用程序会报告执行查询的预期计算资源成本。DBA 通常会在把查询投入生产之前检查预期成本。如果预期成本很高，他们会调整语句和数据库的物理设计（常常会添加索引），从而降低预期成本。

如果一个查询的预期成本相当低（比如对蓝莓的查询花费 5 秒），DBA 往往不会注意它。但问题是，EXPLAIN 提供的只是特定查询的一次执行的估计值。如果应用程序频繁地访问没有适当索引的小表，数据库每次都会把它们装载进内存并扫描它们。

在至少 90% 的生产数据库中，这样的处理能力浪费现象非常多。在我最近工作的一家大银行中，一个数 TB 的 OLTP 银行应用程序把 34% 的 CPU 时间花在对一个只有 32 行的表的查询上。在一家大型零售商的 8 TB 数据仓库中，在一个 2,000 行的小表上添加一个索引之后，一个决策支持查询花费的时间从三小时一下降到了两分钟。在另一家在线零售商那里，在有 8 个 CPU 的系统上，访问一个相当小的表的查询占用了 97% 的 CPU 计算能力。就像德克萨斯人常说的，“这真是要命”。像这样浪费资源的高成本的语句在几乎每个数据库中都存在，它们常常会被忽视，因为它们访问很小的表。

具有内存自调优功能的数据库会检测高成本的查询，尝试把小表一直放在内存中，这会在一定程度上降低 I/O 成本和响应时间。但是，运行这些查询的 CPU 成本仍然很高。内存自调优功能仅仅对观察到的性能特征做出反应，尽可能对物理设计缺陷采取补偿措施。

在当今的经济环境中，数据库性能和成本优化的重要性和价值怎么强调也不过分。现在必须好好优化您的数据库，除非您的组织有花不完的钱，而且不关心能源和环境。忽视这一需求是非常不明智的，就像是开着轮胎没气的满载的车到处跑。请这样想：如果您能够把数据库服务器的数量、许可证成本和能源成本都减少一半儿，同时把性能和可靠性提高两三倍，您会怎么办？您会不愿意设法获得这些节约和改进吗？