我们知道sql在底层的执行给我们上层人员开了一个窗口，那就是执行计划，有了执行计划之后，我们就清楚了那些烂sql是怎么执行的，这样

就可以方便的找到sql的缺陷和优化点。

一：执行计划生成过程

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

1. 分析过程

　　这三个比较容易理解，首先我们要保证sql的语法不能错误，select和join的表是必须存在的，以及你是有执行这个sql的权限，对不对。。。

这样我们就走完了执行计划生命周期的第一个流程。

2. 编译过程

      保证了上面sql这三点的话，引擎就必须硬着头皮看你这么一大坨烂sql，该删的删，该改的改，该转换的转换，比如说你的“子查询”会转化为

“表连接”等等。。。其实也挺难为引擎的，举个例子吧。

<1>子查询生成的sql：

<2>join生成的sql：

 

从上面的两个结果中，你可以看到，大家都是玩join的，如果你仔细看的话，会发现一个是“哈希匹配”，一个是“嵌套循环”，为什么不一样，这

当然是引擎根据很多情况综合评选出来的，比如说：磁盘IO，逻辑读，资源占用，硬件环境等等。。。这也是所谓的“计划选优”操作。

 

3.执行过程

　　既然执行计划都选出来了，理所当然就要执行了，执行完后会把sql和执行计划放入缓存，这样下次有同样的sql过来的时候就可以直接从

Cache中提取了，不需要再次生成计划了，你也看到，生成执行计划还是比较消耗CPU时间的。

 

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

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

sqlserver还是比较能够满足我们G点的。

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

DBCC freeproccacheSELECT c.* FROM dbo.Category AS cJOIN dbo.Product AS pON c.CategoryId=p.CategoryIdWHERE c.CategoryId=23794

2. 通过sys.dm_exec_cached_plans拿到sql和plan的指针（plan_handle），如下图

SELECT * FROM sys.dm_exec_cached_plans

从图中你看到了两个adhoc（即时查询），分别是我在第一步执行的join查询和我在第二步执行的这个select。

 

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

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

上面的query_plan字段就是所谓的执行计划，以xml的形式保存在字段中。。。所以说解析这个xml还是很费时间的。。。

1 
        2 
      
         3     
       
          4         
        
           5             
         
            6                 
          
            10                     
            11                     
           
             12 
            
              13 
             
               14 
              
                15 
               
                 16 
                 17 
                18 
               19 
              20 
             
               21 
              
                22 
               
                 23 
                 24 
                25 
               26 
              27 
             28 
            
              29 
             
               30 
               31 
               32 
               33 
              34 
             
               35 
              
                36 
               
                 37 
                 38 
                 39 
                 40 
                41 
               
                 42 
                
                  43 
                 
                   44 
                   45 
                  46 
                 
                   47 
                   48 
                  49 
                 
                   50 
                   51 
                  52 
                 53 
                 54 
                
                  55 
                 
                   56 
                  
                    57 
                   
                     58 
                    
                      59 
                      60 
                     61 
                    
                      62 
                     
                       63 
                       64 
                      65 
                     66 
                    67 
                   68 
                  69 
                 70 
                71 
               72 
              
                73 
                74 
               
                 75 
                 76 
                 77 
                
                  78 
                 
                   79 
                  
                    80 
                   
                     81 
                    
                      82 
                      83 
                     84 
                    85 
                   
                     86 
                     87 
                    88 
                   89 
                  90 
                 91 
                92 
               93 
              94 
             95 
            96                 
           97             
          98         
         99     
       100 
      

 

　　好了，到现在你应该认识到重新生成执行计划是不容易的。。。下一篇我们讨论讨论重用，重编译，重新生成等相关情况。