6 图助你理解 SQL 优化策略

案例

在本例中，举一个表函数( table-valued function)来说明下 rewind, rebind 微妙的关系。

函数的意图很明显，根据 PK 拿到表中其他的几个字段，封装成表返回。

第一种写法：

在这里，说先要说明的是 EXT_GAP_EMP 是一张从表，EXT_GAP_INITIATIVES 是主表。通过 GAP_ID 来关联。因此 EXT_GAP_EMP 与 EXT_GAP_INITIATIVES 是多对一的关系。而表值函数（Table Valued Functions）将会重复的去捞取同一个 GAP_ID 下的多个属性，因此 产生了大量的数据。聪明的你肯定在想，如果这些重复拉取的过程可以将之前的数据都缓存起来，就能提高性能。没错，你想到的方案，微软那帮子牛上天的工程师也想到了。如果你认识轮子哥，你可以求证下，当年他在 SQL Server 做过优化器的引擎开发。我在他隔壁 ：）。言归正传，我用图证明：

标红的 Actual Rewinds 就是将连续同值的 GAP_ID 返回的结果缓存起来，以快速返回给下一个等值的 GAP_ID. 而 Actual Rebinds 统计的就是有多少次连续同值的 GAP_ID 出现。一定是连续同值，连续同值，连续同值！

一定要将上面的例子好好理解，继续往下看才能保证理解的了！

第二种写法：

接下来，我不标红 SQL 的修改部分，可能大多数读者都不会注意。请仔细看 SQL 的变化。因为 Execution Plan 变得完全不一样了，有了 sort 反而变快了，是不是很难理解？因为我们一直在优化部分强调不要用 order by 来进行排序，尽量避免 sort 操作。对于 rewind, rebind 来说，情况变了

细心的你，发现了没，标红部分 Actual Rebinds 减少了至少 3 倍。意味着 Actual Rewinds 有效提高了缓存。

前面一篇对 SQL 运行时执行统计信息的文章，提到的收集执行统计信息的方法，还记得吗，SET Statistics IO/TIME ON, 可以派上用场了。我们来比较下两段 SQL 的异同：

CPU 时间少了至少 3 倍，而执行流失时间则少了近 1 倍！原因全在于 ORDER BY GEMP.GAP_ID !