某日同事丟給我一個看上去複雜的查詢（實際就涉及兩張表，套來套去）說只是換了日期條件，但一個查詢5秒出資料，一個根本查不出來。現在整理下解決過程，及涉及的知識點。
若有不正之處，請多多諒解並歡迎批評指正，不甚感激。
一.問題描述
環境：sqlserver 2008r2
現象：
查詢涉及到兩張表
ODS_TABLE_A 每日資料700萬現在總計60多億。 已建立索引+分割槽
MID_TABLE_B 每日資料20萬 總計3000萬。 已建立索引未分割槽
當etldate為 ‘2016-08-12’ 及以前的時間時，本查詢5秒出資料，
當etldate為 ‘2016-08-16’ 及以後的時間時，本查詢出不來資料。
貼上問題sql：做過資料欄位處理，針對本篇主題注意點放在查詢因為日期的選擇不同導致查詢時間變的超級慢，而不是改變sql寫法比如用臨時表，強制索引上。
———-《程式碼開始》
|
1 2 3 4 5 6 7 8 9 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 101 102 103 104 105 106 107 108 109 110 111 112 |
select COUNT(distinct(case when COL_USERID3 is null then COL_USERID6 end)) as 'aa', COUNT(distinct(case when COL_USERID3 is null and COL_USERID7 is not null then COL_USERID6 end)) as 'bb', COUNT(distinct(case when COL_USERID3 is not null then COL_USERID6 end)) as 'cc', COUNT(distinct(case when COL_USERID3 is not null and COL_USERID7 is not null then COL_USERID6 end)) as 'dd', SUM(case when COL_USERID3 IS not null then ee end) as 'ee' from ( select c.COL_USERID3,c.ee,g.COL_USERID6 from ( select b.COL_USERID2 as COL_USERID3,COUNT(b.COL_USERID2) as ee from ( select COL_USERID as COL_USERID1,min(EventTime) as time1 from ODS_TABLE_A where EtlDate = '2016-08-12' and colid LIKE 'heihei%' group by COL_USERID )as a join ( select COL_USERID as COL_USERID2,eventtime as time2 from ODS_TABLE_A where EtlDate = '2016-08-12' and ItemId = '1111111111101' and colid like 'haha-%' and colid not like 'haha-skill%' and colid not like 'haha-fine%' )as b on a.COL_USERID1 = b.COL_USERID2 and a.time1 > b.time2 group by b.COL_USERID2 )as c right join ( select DISTINCT d.COL_USERID4 as COL_USERID6 from ( select distinct COL_USERID as COL_USERID4 from MID_TABLE_B where etldate = '2016-08-12' )as d join ( select COL_USERID AS COL_USERID5 from ODS_TABLE_A where EtlDate = '2016-08-12' and colid LIKE 'heihei%' )as f on d.COL_USERID4 = f.COL_USERID5 )as g on c.COL_USERID3 = g.COL_USERID6 )as i left join ( select COL_USERID as COL_USERID7 from MID_TABLE_B where EtlDate = '2016-08-12' and IsTodayPay = '1' )as h on i.COL_USERID6 = h.COL_USERID7 |
———-《程式碼結束》
二。解決過程
1.先看了下上述程式碼的執行計劃如下圖初看上去需要用索引的地方都用到了。應該沒啥大問題。
可能你注意到系統提示的缺少索引資訊，加上去一樣效果，不能解決‘2016-08-16’ 查詢慢的問題。
2.在修改下日期 ，就是把 【所有】 etldate=‘2016-08-12’ 的改成 etldate=‘2016-08-16’
看下執行計劃：對不起跑了半個小時沒出來，檢視估計的執行執行和上面的圖類似。
減少涉及到資料集的量 加top 1 我再看執行計劃：
不貼圖了 結果就是比上面的圖少了個 【並行度】
初步以為是優化器因為估計行數等不準的原因沒選擇並行度，趕緊找程式碼讓它強行這樣走。
找到一篇宋大師的：強制SQL Server執行計劃使用並行提升在複雜查詢語句下的效能
http://www.cnblogs.com/CareySon/p/3851113.html
二話不說加關鍵字OPTION(querytraceon 8649)，可是應用到實際發現查詢效率無任何改善，久久不出結果。後來問宋大師（感謝宋大神）。他說有些操作是沒法並行的，更新統計資訊試試先。
執行如下程式碼：
update STATISTICS ODS_TABLE_A –（把ODS_TABLE_A 這個大表統計資訊更新）
預設情況下，查詢優化器已根據需要更新統計資訊以改進查詢計劃；但在某些情況下，你可以通過使用 UPDATE STATISTICS 或儲存過程 sp_updatestats 來比預設更新更頻繁地更新統計資訊，提高查詢效能。針對文中此種情況新插入的資料沒統計資訊，大表自動更新統計資訊觸發自動更新機制頻率不夠，最好定期更新。
關於update STATISTICS 就不累述了 ：給出相關技術貼連線
更新統計相關知識點傳送門：https://msdn.microsoft.com/zh-cn/library/ms187348.aspx
至此問題解決。
三、總結
對於大表新插入的資料沒及時更新統計資訊，導致出現上面文中的現象，一個日期導致查詢效率天壤之別的分水嶺（查12號前5秒出資料，查12號後死活不出來。）
解決辦法是大表自動更新統計資訊觸發自動更新機制頻率不夠，定期更新。