重构"极端"SQL查询

我有一个业务用户尝试编写自己的SQL查询以获取项目统计报告(例如任务数量,里程碑等).查询开始声明80多列的临时表.然后,在将近500行代码中,临时表中有大约70个UPDATE语句,每个代码都包含自己的一组业务规则.它使用临时表中的SELECT*完成.

由于时间限制和"其他因素",这种情况已经匆忙投入生产,现在我的团队仍然坚持支持它.性能是令人震惊的,虽然由于一些整洁,它很容易阅读和理解(虽然代码气味是令人讨厌的).

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

首先,如果这不会导致业务问题,那么请将其保留直至出现问题.等到它成为问题,然后解决所有问题.

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

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

如果您因任何原因不想或不想这样做,那么您可能需要调整现有的proc.以下是我要看的一些内容:

如果要在临时表上创建索引,请等到初始INSERT之后再填充它.

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

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

如果您的表格和分组允许,请对您的更新进行分组.只有80列的70个更新很多,听起来可能有机会这样做.

祝好运