A. 同樣的sql語句在SQL2000中的執行效率反而大大高於SQL2008，不解！
呵呵,要看在什麼情況下做的.如果你本來就是sql 2000的語句,以前在sql 2000上運行過,那麼很正常的.sql server 對於陌生語句的執行是要花很多時間,可是如果你重復運行看看.那個時間叫一個短啊...
另外也要看索引是什麼樣子的?如果sql 2000上存在索引,而2008上沒有索引.那麼你得到的結論很正常的.
最後這種問題其實沒有必要問,mssql 開發組的人都不是sb,他們不會把sql 2008做的比2000還差.還有就是2000和20008完全就不是同一個核心.你;連2005都沒用,就直接跳躍到2008,太牛了.
B. 如何提高sql語句的執行效率
1、使用ordered提示
Oracle必須花費大量的時間來剖析多表的合並，用以確定表合並的最佳順序。SQL表達式涉及七個乃至更多的表合並，那麼有時就會需要超過30分鍾的時間來剖析，Ordered這個提示(hint)和其他的提示一起使用能夠產生合適的合並順序。
2、使用ordered_predicates
ordered_predicates提示在查詢的WHERE子句里指定的，並被用來指定布爾判斷(Booleanpredicate)被評估的順序。在沒有ordered_predicates的情況下，Oracle會使用下面這些步驟來評估SQL判斷的順序：子查詢的評估先於外層WHERE子句里的Boolean條件。
所有沒有內置函數或者子查詢的布爾條件都按照其在WHERE子句里相反的順序進行評估，即最後一條判斷最先被評估。每個判斷都帶有內置函數的布爾判斷都依據其預計的評估值按遞增排列。
3、限製表格合並評估的數量
提高SQL剖析性能的最後一種方法是強製取代Oracle的一個參數，這個參數控制著在評估一個查詢的時候，基於消耗的優化器所評估的可能合並數量。
(2)越復雜的sql執行效率越高擴展閱讀：
1、表設計的優化，數據行的長度不要超過8020位元組，如果超過這個長度的話在物理頁中這條數據會佔用兩行從而造成存儲碎片，降低查詢效率。
2、語句的查詢優化，保證在實現功能的基礎上，盡量減少對資料庫的訪問次數；
3、建立高效的索引創建索引一般有以下兩個目的：維護被索引列的唯一性和提供快速訪問表中數據的策略。
大型資料庫有兩種索引即簇索引和非簇索引，一個沒有簇索引的表是按堆結構存儲數據，所有的數據均添加在表的尾部，而建立了簇索引的表，其數據在物理上會按照簇索引鍵的順序存儲。個表只允許有一個簇索引。
4、強制查詢轉換，有時候oracle 的優化器未必能走正確的查詢路線，這個時候就需要添加一些hint 之類的來規定他的執行路線。當然了，這個未必是最好的處理方案。因為雖然現在走這個路線是對的，以為因為數據的變化到這這個HINT 變得不可取。
C. 這些SQL優化技巧握在手，面試可以橫著走……
一、SQL執行順序
二、基礎SQL優化
1、查詢SQL盡量不要使用select *，而是具體欄位
1）反例
2）正例
3）理由
2、避免在where子句中使用or來連接條件
查詢id為1或者薪水為3000的用戶：
1）反例
2）正例
使用union all：
分開兩條SQL寫：
3）理由
3、使用varchar代替char
1）反例
2）正例
3）理由
4、盡量使用數值替代字元串類型
5、查詢盡量避免返回大量數據
如果查詢返回數據量很大，就會造成查詢時間過長，網路傳輸時間過長。同時，大量數據返回也可能沒有實際意義。如返回上千條甚至更多，用戶也看不過來。
通常採用分頁，一頁習慣10/20/50/100條。
6、使用explain分析你SQL執行計劃
SQL很靈活，一個需求可以很多實現，那哪個最優呢？SQL提供了explain關鍵字，它可以分析你的SQL執行計劃，看它是否最佳。Explain主要看SQL是否使用了索引。
返回結果：
7、是否使用了索引及其掃描類型
type：
性能排行：
System > const > eq_ref > ref > range > index > ALL
possible_keys：
key：
8、創建name欄位的索引
提高查詢速度的最簡單最佳的方式。
9、優化like語句
模糊查詢，程序員最喜歡的就是使用like，但是like很可能讓你的索引失效。
1）反例
2）正例
3）理由
未使用索引，故意使用sex非索引欄位：
主鍵索引生效：
索引失效，type=ALL，全表掃描：
10、字元串怪現象
1）反例
2）正例
3）理由
為什麼第一條語句未加單引號就不走索引了呢？這是因為不加單引號時，是字元串跟數字的比較，它們類型不匹配，MySQL會做隱式的類型轉換，把它們轉換為數值類型再做比較。
11、索引不宜太多，一般5個以內
12、索引不適合建在有大量重復數據的欄位上
如性別欄位。因為SQL優化器是根據表中數據量來進行查詢優化的，如果索引列有大量重復數據，Mysql查詢優化器推算發現不走索引的成本更低，很可能就放棄索引了。
13、where限定查詢的數據
數據中假定就一個男的記錄。
1）反例
2）正例
3）理由
14、避免在索引列上使用內置函數
業務需求：查詢最近七天內新生兒（用學生表替代下）
給birthday欄位創建索引：
當前時間加7天：
1）反例
2）正例
3）理由
15、避免在where中對欄位進行表達式操作
1）反例
2）正例
3）理由
16、避免在where子句中使用!=或>操作符
應盡量避免在where子句中使用!=或>操作符，否則引擎將放棄使用索引而進行全表掃描。記住實現業務優先，實在沒辦法，就只能使用，並不是不能使用。如果不能使用，SQL也就無需支持了。
1）反例
2）理由
17、去重distinct過濾欄位要少
1）理由
18、where中使用默認值代替null
環境准備：
1）反例
2）正例
3）理由
三、高級SQL優化
1、批量插入性能提升
大量數據提交，上千，上萬，批量性能非常快，mysql獨有。
1）多條提交
2）批量提交
3）理由
2、批量刪除優化
避免同時修改或刪除過多數據，因為會造成cpu利用率過高，會造成鎖表操作，從而影響別人對資料庫的訪問。
1）反例
2）正例
3）理由
3、偽刪除設計
1）商品狀態（state）
2）理由
4、提高group by語句的效率
可以在執行到該語句前，把不需要的記錄過濾掉。
1）反例：先分組，再過濾
2）正例：先過濾，後分組
5、復合索引最左特性
創建復合索引，也就是多個欄位。
滿足復合索引的左側順序，哪怕只是部分，復合索引生效。
沒有出現左邊的欄位，則不滿足最左特性，索引失效。
復合索引全使用，按左側順序出現 name,salary，索引生效。
雖然違背了最左特性，但MYSQL執行SQL時會進行優化，底層進行顛倒優化。
1）理由
6、排序欄位創建索引
什麼樣的欄位才需要創建索引呢？原則就是where和order by中常出現的欄位就創建索引。
7、刪除冗餘和重復的索引
8、不要有超過5個以上的表連接
9、inner join 、left join、right join，優先使用inner join
三種連接如果結果相同，優先使用inner join，如果使用left join左邊表盡量小。
1）理由
10、in子查詢的優化
日常開發實現業務需求可以有兩種方式實現：
如需求：查詢所有部門的所有員工：
假設表A表示某企業的員工表，表B表示部門表，查詢所有部門的所有員工，很容易有以下程序實現，可以抽象成這樣的一個嵌套循環：
D. SQL2008或SQL2012 如何配置，使SQL的執行效率最高
提升數據插入速度，主要瓶頸在io上面。
1、採用固定內存分配，如果伺服器上只有SQLSERVER在運行，使用6G給系統，42G給SQLSERVER。
2、做磁碟陣列RAID10，第一個陣列放置系統，temp資料庫，第二個陣列放置數據文件，第三個陣列放置日誌文件。
E. 過於復雜的sql語句有哪些缺陷
過於復雜的sql語句有哪些缺陷
不同的資料庫甚至相同資料庫的不同版本都可能不一樣，具體可以查詢聯機幫助，或參閱產品規格說明。總的來說SQL語句的最大長度限制都是很大的，編寫SQL語句一般不需要考慮語句的長度問題。例如ACCESS的SQL最大長度約為6,4000個、MSSQL為65,536 * 網路數據包。像這樣的長度，足夠你寫下長篇大論了。但是話要說回來，一個太長的語句其執行效率變得會低下，盡量避免編寫太長和過於復雜的SQL語句還是非常必要的。