https://mp.weixin.qq.com/s/zFVUS8TGkJV13RAFJjoxmA

我们知道sql在底层的执行给我们上层人员开了一个窗口,那就是执行计划,有了执行计划之后,我们就清楚了那些烂sql是怎么执行的,这样 就可以方便的找到sql的缺陷和优化点。

一:执行计划生成过程

   说到执行计划,首先要知道的是执行计划大概生成的过程,这样就可以做到就心中有数了,下面我画下简图:
SqlServer的执行计划 - 图1

1. 分析过程

这三个比较容易理解,首先我们要保证sql的语法不能错误,select和join的表是必须存在的,以及你是有执行这个sql的权限,对不对。。。这样我们就走完了执行计划生命周期的第一个流程。

2. 编译过程

保证了上面sql这三点的话,引擎就必须硬着头皮看你这么一大坨烂sql,该删的删,该改的改,该转换的转换,比如说你的“子查询”会转化为 “表连接”等等。。。其实也挺难为引擎的,举个例子吧。

<1>子查询生成的sql:

SqlServer的执行计划 - 图2

<2>join生成的sql:

SqlServer的执行计划 - 图3
从上面的两个结果中,你可以看到,大家都是玩join的,如果你仔细看的话,会发现一个是“哈希匹配”,一个是“嵌套循环”,为什么不一样,这当然是引擎根据很多情况综合评选出来的,比如说:磁盘IO,逻辑读,资源占用,硬件环境等等。。。这也是所谓的“计划选优”操作。

3.执行过程

既然执行计划都选出来了,理所当然就要执行了,执行完后会把sql和执行计划放入缓存,这样下次有同样的sql过来的时候就可以直接从 Cache中提取了,不需要再次生成计划了,你也看到,生成执行计划还是比较消耗CPU时间的。

二:看看sql和执行的计划的缓存

刚才也说了,sql和plan都已经放入缓存了,那我的好奇心比较强,我就想看看sql和plan到底在哪,并且长的是个什么样子。

1. 为了方便查看缓存,我需要先将所有的缓存清空,比如下面的语句。

  1. DBCC freeproccache
  2. SELECT c.* FROM dbo.Category AS c
  3. JOIN dbo.Product AS p
  4. ON c.CategoryId=p.CategoryId
  5. WHERE c.CategoryId=23794

2. 通过sys.dm_exec_cached_plans拿到sql和plan的指针(plan_handle),如下图

  1. SELECT * FROM sys.dm_exec_cached_plans

SqlServer的执行计划 - 图4
从图中你看到了两个adhoc(即时查询),分别是我在第一步执行的join查询和我在第二步执行的这个select。

3. 现在我们已经拿到了2个adhoc的plan_handle,然后通过dm_exec_sql_text查看他们的sql分别是怎样?

SqlServer的执行计划 - 图5

4. 看完text缓存,接下来我们继续看看sql的plan缓存在哪?可以通过dm_exec_query_plan来查看。

SqlServer的执行计划 - 图6
上面的query_plan字段就是所谓的执行计划,以xml的形式保存在字段中。。。所以说解析这个xml还是很费时间的。。。
SqlServer的执行计划 - 图7SqlServer的执行计划 - 图8SqlServer的执行计划 - 图9
好了,到现在你应该认识到重新生成执行计划是不容易的。。。下一篇我们讨论讨论重用,重编译,重新生成等相关情况。