我們做軟件開發(fā)的，大部分人都離不開跟數(shù)據(jù)庫打交道，特別是erp開發(fā)的，跟數(shù)據(jù)庫打交道更是頻繁，存儲過程動不動就是上千行，如果數(shù)據(jù)量大，人員流動大，那么我么還能保證下一段時間系統(tǒng)還能流暢的運行嗎？我么還能保證下一個人能看懂我么的存儲過程嗎？     要知道sql語句，我想我們有必要知道sqlserver查詢分析器怎么執(zhí)行我么sql語句的，我么很多人會看執(zhí)行計劃，或者用profile來監(jiān)視和調(diào)優(yōu)查詢語句或者存儲過程慢的原因，但是如果我們知道查詢分析器的執(zhí)行邏輯順序，下手的時候就胸有成竹，那么下手是不是有把握點呢？
   一：查詢的邏輯執(zhí)行順序
(1) FROM < left_table>  
(3) < join_type>  JOIN < right_table>   (2) ON < join_condition>  
(4) WHERE < where_condition>  
(5) GROUP BY < group_by_list>  
(6) WITH {cube | rollup}
(7) HAVING < having_condition>  
(8) SELECT  (9) DISTINCT (11) < top_specification>  < select_list>  
(10) ORDER BY < order_by_list>  
標準的SQL 的解析順序為:
(1).FROM 子句 組裝來自不同數(shù)據(jù)源的數(shù)據(jù)
(2).WHERE 子句 基于指定的條件對記錄進行篩選
(3).GROUP BY 子句 將數(shù)據(jù)劃分為多個分組
(4).使用聚合函數(shù)進行計算
(5).使用HAVING子句篩選分組
(6).計算所有的表達式
(7).使用ORDER BY對結果集進行排序
二 執(zhí)行順序：

1.FROM：對FROM子句中前兩個表執(zhí)行笛卡爾積生成虛擬表vt1
2.ON:對vt1表應用ON篩選器只有滿足< join_condition> 為真的行才被插入vt2
3.OUTER(join)：如果指定了 OUTER JOIN保留表(preserved table)中未找到的行將行作為外部行添加到vt2 生成t3如果from包含兩個以上表則對上一個聯(lián)結生成的結果表和下一個表重復執(zhí)行步驟和步驟直接結束
4.WHERE：對vt3應用 WHERE 篩選器只有使< where_condition> 為true的行才被插入vt4
5.GROUP BY：按GROUP BY子句中的列列表對vt4中的行分組生成vt5
6.CUBE|ROLLUP：把超組(supergroups)插入vt6 生成vt6
7.HAVING：對vt6應用HAVING篩選器只有使< having_condition> 為true的組才插入vt7
8.SELECT：處理select列表產(chǎn)生vt8
9.DISTINCT：將重復的行從vt8中去除產(chǎn)生vt9
10.ORDER BY：將vt9的行按order by子句中的列列表排序生成一個游標vc10
11.TOP：從vc10的開始處選擇指定數(shù)量或比例的行生成vt11 并返回調(diào)用者

         看到這里，那么用過linqtosql的語法有點相似??？如果我們我們了解了sqlserver執(zhí)行順序，那么我們就接下來進一步養(yǎng)成日常sql好習慣，也就是在實現(xiàn)功能同時有考慮性能的思想，數(shù)據(jù)庫是能進行集合運算的工具，我們應該盡量的利用這個工具，所謂集合運算實際就是批量運算，就是盡量減少在客戶端進行大數(shù)據(jù)量的循環(huán)操作，而用SQL語句或者存儲過程代替。
三、只返回需要的數(shù)據(jù)
  返回數(shù)據(jù)到客戶端至少需要數(shù)據(jù)庫提取數(shù)據(jù)、網(wǎng)絡傳輸數(shù)據(jù)、客戶端接收數(shù)據(jù)以及客戶端處理數(shù)據(jù)等環(huán)節(jié)，如果返回不需要的數(shù)據(jù)，就會增加服務器、網(wǎng)絡和客戶端的無效勞動，其害處是顯而易見的，避免這類事件需要注意：
  A、橫向來看，
  (1)不要寫SELECT *的語句，而是選擇你需要的字段。
  (2)當在SQL語句中連接多個表時, 請使用表的別名并把別名前綴于每個Column上.這樣一來,就可以減少解析的時間并減少那些由Column歧義引起的語法錯誤。
view sourceprint?