sql - 重构 "extreme"SQL 查询

Question

我有一个业务用户，他尝试为项目统计报告(例如任务数量、里程碑等)编写自己的 SQL 查询。查询开始时声明了一个包含 80 多列的临时表。然后有将近 70 条 UPDATE 语句到临时表，超过近 500 行代码，每行代码都包含自己的小业务规则集。它以来自临时表的 SELECT * 结束。

由于时间限制和“其他因素”，这被匆忙投入生产，现在我的团队坚持支持它。性能令人震惊，尽管多亏了一些整理，它还是很容易阅读和理解的(尽管代码味道很糟糕)。

我们应该关注哪些关键领域以加快速度并遵循良好实践？

Answer 1

首先，如果这不会导致业务问题，则将其搁置直到它成为问题。等到它成为问题，然后解决所有问题。

当你决定修复它时，检查是否有一个语句导致了你的大部分速度问题......隔离并修复它。

如果速度问题超过所有语句，并且您可以将它们全部组合到一个 SELECT 中，这可能会节省您的时间。我曾经将这样的 proc(没有那么多更新)转换为 SELECT，运行它的时间从 3 分钟多到 3 秒以下(没有狗屎......我简直不敢相信)。顺便说一句，如果某些数据来自链接服务器，请不要尝试这样做。

如果您出于某种原因不想或不能这样做，那么您可能需要调整现有的 proc。以下是我会考虑的一些事项:

如果要在临时表上创建索引，请等到初始 INSERT 后填充它。

调整初始 INSERT 以插入尽可能多的列。这样做可能会消除一些更新。

在运行更新之前索引临时表。在更新语句之前，不要在更新语句所针对的任何列上创建索引。

如果您的表和分组允许，则将您的更新分组。 70 次更新对于仅 80 列来说是相当多的，听起来可能有机会做到这一点。

祝你好运