概念簡介
我們平時所說的查詢在sqlserver 中主要有兩部分來實現：
編譯查詢，主要包括了五個環節（快取查詢、分析、代數化、優化、快取新計畫）
流程描述： 首先，在計畫快取中查詢是否包含新的查詢，如果包含則直接交由執行引擎來執行該快取計畫，跳過編譯階段。
其次，如果沒有匹配則執行分析階段（包括引數化、並將sql文字轉化成邏輯樹作為下乙個階段的輸入），
再次檢查快取後是否包含，包含則交給執行引擎，否則繼續下一步。
第三，代數化。
第四，優化並將新計畫交給執行引擎。
這裡需要有個概念的介紹：執行計畫快取，
sql server 有乙個用於儲存執行計畫和資料緩衝區的記憶體池。池內分配給執行計畫或資料緩衝區的百分比隨系統狀態動態波動。
記憶體池中用於儲存執行計畫的部分稱為過程快取。
執行計畫快取主要包含了查詢計畫和執行上下文。
編譯和重新編譯
sql server 有乙個高效的演算法，可查詢用於任何特定 sql 語句的現有執行計畫。sql server 將重新使用找到的任何現有計畫，從而節省重新編譯 sql 語句的開銷。如果沒有現有執行計畫，sql server 將為查詢生成新的執行計畫。
由此我們要做的就是如何高效的應用執行計畫的快取，又在合適重新編譯執行計畫，來提高查詢效率，減少效能的損耗。
首先我們要知道什麼情況下會有重新編譯產生新的執行計畫，我簡單總結了幾種比較常見的情況：
1.使用with repcompile 或者呼叫sp_repcompile,將不會快取計畫。
2.架構的變更比如表或試圖中新增索引，增加或者刪除列等。
如圖，當執行架構名稱不同的時候會引發重新編譯，執行計畫快取不能復用，這個問題需要開發人員注意，經常會有不自覺新增或者減少架構名稱的舉動。不僅會影響效能，當伺服器間移動**時會引起太多問題，建議使用schema.object(dbo.excutiontest)這樣的統一規範。
如果是增刪索引的話，根據實際情況會生成完全不同的執行計畫。如圖：
建立索引後有表掃瞄變為了索引查詢，這部分內容我在聚集索引的章節已經有過介紹這裡就不詳細展開了。
3.set選項，包括：ansi_nulls\ansi_warnings\cursor_close_on_commit_inplicit_transactions\ansi_padding\quoted_identifier,這些選項狀態的變化，會引起執行計畫的重新編譯。建議，盡量採用資料庫預設的設定，不要在儲存過程中假如不必要的set選項。
4.根據計畫的優化程度：如果對鍵的大量更改（對由查詢引用的表使用 insert 、update或 delete 語句所產生的修改）。
分析、代數化和優化
1.分析，會將sql文字轉換為邏輯樹，為每乙個語句建立邏輯樹。
2.代數化，主要完成檢查語義是否正確。
同時還會完成三個任務：
３.優化
查詢優化是處理查詢中最複雜部分，這部分由系統自動完成，如果說前面的環節告訴我們「做什麼」，那麼優化器就是描述「如何做」，查詢優化器希望盡可能選擇高效的執行計畫。這部分將在本系列最後做乙個專題。詳細的闡述這裡現提出流程（簡化－－探索－－實現）。
總結：
本篇系統的介紹了編譯查詢的流程，以及產生快取、復用快取、重新編譯等具體內容。對於優化我們的t-sql語句來說有不少值得注意的地方，執行計畫快取的命中越多相應的我們的查詢消耗也就越低，但是這種情況也不是絕對的。最後附加乙個用於重新編譯的工具和命令的超連結，裡面有不少便於查詢分析執行計畫是否高效甚至存在問題功能和方法，
T SQL效能調整（一） 編譯和重新編譯
概念簡介 我們平時所說的查詢在sqlserver 中主要有兩部分來實現 編譯查詢，主要包括了五個環節 快取查詢 分析 代數化 優化 快取新計畫 流程描述 首先，在計畫快取中查詢是否包含新的查詢，如果包含則直接交由執行引擎來執行該快取計畫，跳過編譯階段。其次，如果沒有匹配則執行分析階段 包括引數化 並...
SQL語句效能調整一例
公司開發同事發來一條語句，反應執行很慢，原語句如下 select count df.origrec it.scale as pcount,it.invcode as invcode,df.samplefrom as rasclientid from da finance pricesett df,d...
Mac下反編譯和重新編譯打包APK
解壓dex2jar壓縮包。終端中cd命令到dex2jar目錄。將apk檔案改字尾apk為zip，將其中的classes.dex檔案拷貝到dex2jar目錄 在終端執行.d2j dex2jar.sh classes.dex 出現permission denied異常，是哪個檔案報的就改哪個檔案的許可權...