4 、日期列不會因為有分秒的輸入而減慢查詢速度
下面的例子中，共有100萬條數據，2004年1月1日以後的數據有50萬條，但只有兩個不同的日期，日期精確到日；之前有數據50萬條，有5000個不同的日期，日期精確到秒。
select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>'2004-1-1' order by fariqi
用時：6390毫秒
select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi<'2004-1-1' order by fariqi
用時：6453毫秒
（五）其他注意事項
“水可載舟，亦可覆舟”，索引也一樣。索引有助於提高檢索性能，但過多或不當的索引也會導致系統低效。因為用戶在表中每加進一個索引，數據庫就要做更多的工作。過多的索引甚至會導致索引碎片。
所以說，我們要建立一個“適當”的索引體系，特別是對聚合索引的創建，更應精益求精，以使您的數據庫能得到高性能的發揮。
當然，在實踐中，作為一個盡職的數據庫管理員，您還要多測試一些方案，找出哪種方案效率最高、最為有效。
二、改善SQL語句 很多人不知道SQL語句在SQL SERVER中是如何執行的，他們擔心自己所寫的SQL語句會被SQL Server誤解。比如：
select * from table1 where name='zhangsan' and tID > 10000
和執行:
select * from table1 where tID > 10000 and name='zhangsan'
一些人不知道以上兩條語句的執行效率是否一樣，因為如果簡單的從語句先後上看，這兩個語句的確是不一樣，如果tID是一個聚合索引，那麼後一句僅僅從表的10000條以後的記錄中查找就行了；而前一句則要先從全表中查找看有幾個name='zhangsan'的，而後再根據限制條件條件tID>10000來提出查詢結果。
事實上，這樣的擔心是不必要的。SQL Server中有一個“查詢分析優化器”，它可以計算出where子句中的搜索條件並確定哪個索引能縮小表掃描的搜索空間，也就是說，它能實現自動優化。
雖然查詢優化器可以根據where子句自動的進行查詢優化，但大家仍然有必要了解一下“查詢優化器”的工作原理，如非這樣，有時查詢優化器就會不按照您的本意進行快速查詢。
在查詢分析階段，查詢優化器查看查詢的每個階段並決定限制需要掃描的數據量是否有用。如果一個階段可以被用作一個掃描參數（SARG），那麼就稱之為可優化的，並且可以利用索引快速獲得所需數據。
SARG的定義：用於限制搜索的一個操作，因為它通常是指一個特定的匹配，一個值得范圍內的匹配或者兩個以上條件的AND連接。形式如下：
列名 操作符 <常數 或 變量>
或
<常數 或 變量> 操作符列名
列名可以出現在操作符的一邊，而常數或變量出現在操作符的另一邊。如：
Name=’張三’
價格>5000
5000<價格
Name=’張三’ and 價格>5000
如果一個表達式不能滿足SARG的形式，那它就無法限制搜索的范圍了，也就是SQL Server必須對每一行都判斷它是否滿足WHERE子句中的所有條件。所以一個索引對於不滿足SARG形式的表達式來說是無用的。
介紹完SARG後，我們來總結一下使用SARG以及在實踐中遇到的和某些資料上結論不同的經驗：
1、Like語句是否屬於SARG取決於所使用的通配符的類型
如：name like ‘張%’ ，這就屬於SARG
而：name like ‘%張’ ,就不屬於SARG。
原因是通配符%在字符串的開通使得索引無法使用。
2、or 會引起全表掃描
Name=’張三’ and 價格>5000 符號SARG，而：Name=’張三’ or 價格>5000 則不符合SARG。使用or會引起全表掃描。
