1.關(guān)于SQL查詢效率，100w數(shù)據(jù)，查詢只要1秒，與您分享:

機(jī)器情況
p4: 2.4
內(nèi)存: 1 G
os: windows 2003
數(shù)據(jù)庫: ms sql server 2000
目的: 查詢性能測試,比較兩種查詢的性能

SQL查詢效率 step by step

-- setp 1.
-- 建表
create table t_userinfo
(
userid int identity(1,1) primary key nonclustered,
nick varchar(50) not null default '',
classid int not null default 0,
writetime datetime not null default getdate()
)
go

-- 建索引
create clustered index ix_userinfo_classid on t_userinfo(classid)
go

-- step 2.

declare @i int?
declare @k int
declare @nick varchar(10)
set @i = 1
while @i<1000000
begin
set @k = @i % 10
set @nick = convert(varchar,@i)
insert into t_userinfo(nick,classid,writetime) values(@nick,@k,getdate())
set @i = @i + 1
end
-- 耗時(shí) 08:27 ，需要耐心等待

-- step 3.
select top 20 userid,nick,classid,writetime from t_userinfo?
where userid not in
(
select top 900000 userid from t_userinfo order by userid asc
)

-- 耗時(shí) 8 秒 ,夠長的

-- step 4.
select a.userid,b.nick,b.classid,b.writetime from
(
select top 20 a.userid from?
(
select top 900020 userid from t_userinfo order by userid asc
) a order by a.userid desc
) a inner join t_userinfo b on a.userid = b.userid?
order by a.userid asc

-- 耗時(shí) 1 秒，太快了吧，不可以思議

-- step 5 where 查詢
select top 20 userid,nick,classid,writetime from t_userinfo?
where classid = 1 and userid not in
(
select top 90000 userid from t_userinfo?
where classid = 1
order by userid asc
)
-- 耗時(shí) 2 秒

-- step 6 where 查詢
select a.userid,b.nick,b.classid,b.writetime from
(
select top 20 a.userid from?
(
select top 90000 userid from t_userinfo
where classid = 1
order by userid asc
) a order by a.userid desc
) a inner join t_userinfo b on a.userid = b.userid?
order by a.userid asc

-- 查詢分析器顯示不到 1 秒.

查詢效率分析：
子查詢?yōu)榇_保消除重復(fù)值，必須為外部查詢的每個(gè)結(jié)果都處理嵌套查詢。在這種情況下可以考慮用聯(lián)接查詢來取代。
如果要用子查詢，那就用EXISTS替代IN、用NOT EXISTS替代NOT IN。因?yàn)镋XISTS引入的子查詢只是測試是否存在符合子查詢中指定條件的行，效率較高。無論在哪種情況下,NOT IN都是最低效的。因?yàn)樗鼘ψ硬樵冎械谋韴?zhí)行了一個(gè)全表遍歷。

建立合理的索引,避免掃描多余數(shù)據(jù)，避免表掃描！
幾百萬條數(shù)據(jù)，照樣幾十毫秒完成查詢.
2.?
SQL提高查詢效率
2008-05-12 21:20
1.對查詢進(jìn)行優(yōu)化，應(yīng)盡量避免全表掃描，首先應(yīng)考慮在 where 及 order by 涉及的列上建立索引。

2.應(yīng)盡量避免在 where 子句中對字段進(jìn)行 null 值判斷，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描，如：
select id from t where num is null?
可以在num上設(shè)置默認(rèn)值0，確保表中num列沒有null值，然后這樣查詢：?
select id from t where num=0

3.應(yīng)盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進(jìn)行全表掃描。

4.應(yīng)盡量避免在 where 子句中使用 or 來連接條件，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描，如：?
select id from t where num=10 or num=20?
可以這樣查詢：?
select id from t where num=10?
union all?
select id from t where num=20

5.in 和 not in 也要慎用，否則會(huì)導(dǎo)致全表掃描，如：?
select id from t where num in(1,2,3)?
對于連續(xù)的數(shù)值，能用 between 就不要用 in 了：?
select id from t where num between 1 and 3

6.下面的查詢也將導(dǎo)致全表掃描：?
select id from t where name like '%abc%'?
若要提高效率，可以考慮全文檢索。

7.如果在 where 子句中使用參數(shù)，也會(huì)導(dǎo)致全表掃描。因?yàn)镾QL只有在運(yùn)行時(shí)才會(huì)解析局部變量，但優(yōu)化程序不能將訪問計(jì)劃的選擇推遲到運(yùn)行時(shí)；它必須在編譯時(shí)進(jìn)行選擇。然而，如果在編譯時(shí)建立訪問計(jì)劃，變量的值還是未知的，因而無法作為索引選擇的輸入項(xiàng)。如下面語句將進(jìn)行全表掃描：?
select id from t where?num=@num?
可以改為強(qiáng)制查詢使用索引：?
select id from t with(index(索引名)) where?num=@num

8.應(yīng)盡量避免在 where 子句中對字段進(jìn)行表達(dá)式操作，這將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描。如：?
select id from t where num/2=100?
應(yīng)改為:?
select id from t where num=100*2

9.應(yīng)盡量避免在where子句中對字段進(jìn)行函數(shù)操作，這將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描。如：?
select id from t where substring(name,1,3)='abc'--name以abc開頭的id?
select id from t where datediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id?
應(yīng)改為:?
select id from t where name like 'abc%'?
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'

10.不要在 where 子句中的“=”左邊進(jìn)行函數(shù)、算術(shù)運(yùn)算或其他表達(dá)式運(yùn)算，否則系統(tǒng)將可能無法正確使用索引。

11.在使用索引字段作為條件時(shí)，如果該索引是復(fù)合索引，那么必須使用到該索引中的第一個(gè)字段作為條件時(shí)才能保證系統(tǒng)使用該索引，否則該索引將不會(huì)被使用，并且應(yīng)盡可能的讓字段順序與索引順序相一致。

12.不要寫一些沒有意義的查詢，如需要生成一個(gè)空表結(jié)構(gòu)：?
select col1,col2 into #t from t where 1=0?
這類代碼不會(huì)返回任何結(jié)果集，但是會(huì)消耗系統(tǒng)資源的，應(yīng)改成這樣：?
create table #t(...)

13.很多時(shí)候用 exists 代替 in 是一個(gè)好的選擇：?
select num from a where num in(select num from b)?
用下面的語句替換：?
select num from a where exists(select 1 from b where num=a.num)

14.并不是所有索引對查詢都有效，SQL是根據(jù)表中數(shù)據(jù)來進(jìn)行查詢優(yōu)化的，當(dāng)索引列有大量數(shù)據(jù)重復(fù)時(shí)，SQL查詢可能不會(huì)去利用索引，如一表中有字段sex，male、female幾乎各一半，那么即使在sex上建了索引也對查詢效率起不了作用。

15.索引并不是越多越好，索引固然可以提高相應(yīng)的 select 的效率，但同時(shí)也降低了 insert 及 update 的效率，因?yàn)?insert 或 update 時(shí)有可能會(huì)重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個(gè)表的索引數(shù)最好不要超過6個(gè)，若太多則應(yīng)考慮一些不常使用到的列上建的索引是否有必要。

16.應(yīng)盡可能的避免更新 clustered 索引數(shù)據(jù)列，因?yàn)?clustered 索引數(shù)據(jù)列的順序就是表記錄的物理存儲(chǔ)順序，一旦該列值改變將導(dǎo)致整個(gè)表記錄的順序的調(diào)整，會(huì)耗費(fèi)相當(dāng)大的資源。若應(yīng)用系統(tǒng)需要頻繁更新 clustered 索引數(shù)據(jù)列，那么需要考慮是否應(yīng)將該索引建為 clustered 索引。

17.盡量使用數(shù)字型字段，若只含數(shù)值信息的字段盡量不要設(shè)計(jì)為字符型，這會(huì)降低查詢和連接的性能，并會(huì)增加存儲(chǔ)開銷。這是因?yàn)橐嬖谔幚聿樵兒瓦B接時(shí)會(huì)逐個(gè)比較字符串中每一個(gè)字符，而對于數(shù)字型而言只需要比較一次就夠了。

18.盡可能的使用 varchar/nvarchar 代替 char/nchar ，因?yàn)槭紫茸冮L字段存儲(chǔ)空間小，可以節(jié)省存儲(chǔ)空間，其次對于查詢來說，在一個(gè)相對較小的字段內(nèi)搜索效率顯然要高些。

19.任何地方都不要使用 select * from t ，用具體的字段列表代替“*”，不要返回用不到的任何字段。

20.盡量使用表變量來代替臨時(shí)表。如果表變量包含大量數(shù)據(jù)，請注意索引非常有限（只有主鍵索引）。

21.避免頻繁創(chuàng)建和刪除臨時(shí)表，以減少系統(tǒng)表資源的消耗。

22.臨時(shí)表并不是不可使用，適當(dāng)?shù)厥褂盟鼈兛梢允鼓承├谈行?#xff0c;例如，當(dāng)需要重復(fù)引用大型表或常用表中的某個(gè)數(shù)據(jù)集時(shí)。但是，對于一次性事件，最好使用導(dǎo)出表。

23.在新建臨時(shí)表時(shí)，如果一次性插入數(shù)據(jù)量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果數(shù)據(jù)量不大，為了緩和系統(tǒng)表的資源，應(yīng)先create table，然后insert。

24.如果使用到了臨時(shí)表，在存儲(chǔ)過程的最后務(wù)必將所有的臨時(shí)表顯式刪除，先 truncate table ，然后 drop table ，這樣可以避免系統(tǒng)表的較長時(shí)間鎖定。

25.盡量避免使用游標(biāo)，因?yàn)橛螛?biāo)的效率較差，如果游標(biāo)操作的數(shù)據(jù)超過1萬行，那么就應(yīng)該考慮改寫。

26.使用基于游標(biāo)的方法或臨時(shí)表方法之前，應(yīng)先尋找基于集的解決方案來解決問題，基于集的方法通常更有效。

27.與臨時(shí)表一樣，游標(biāo)并不是不可使用。對小型數(shù)據(jù)集使用 FAST_FORWARD 游標(biāo)通常要優(yōu)于其他逐行處理方法，尤其是在必須引用幾個(gè)表才能獲得所需的數(shù)據(jù)時(shí)。在結(jié)果集中包括“合計(jì)”的例程通常要比使用游標(biāo)執(zhí)行的速度快。如果開發(fā)時(shí)間允許，基于游標(biāo)的方法和基于集的方法都可以嘗試一下，看哪一種方法的效果更好。

28.在所有的存儲(chǔ)過程和觸發(fā)器的開始處設(shè)置 SET NOCOUNT ON ，在結(jié)束時(shí)設(shè)置 SET NOCOUNT OFF 。無需在執(zhí)行存儲(chǔ)過程和觸發(fā)器的每個(gè)語句后向客戶端發(fā)送 DONE_IN_PROC 消息。

29.盡量避免大事務(wù)操作，提高系統(tǒng)并發(fā)能力。

30.盡量避免向客戶端返回大數(shù)據(jù)量，若數(shù)據(jù)量過大，應(yīng)該考慮相應(yīng)需求是否合理
1、避免將字段設(shè)為“允許為空”
2、數(shù)據(jù)表設(shè)計(jì)要規(guī)范
3、深入分析數(shù)據(jù)操作所要對數(shù)據(jù)庫進(jìn)行的操作
4、盡量不要使用臨時(shí)表
5、多多使用事務(wù)
6、盡量不要使用游標(biāo)
7、避免死鎖
8、要注意讀寫鎖的使用
9、不要打開大的數(shù)據(jù)集
10、不要使用服務(wù)器端游標(biāo)
11、在程序編碼時(shí)使用大數(shù)據(jù)量的數(shù)據(jù)庫
12、不要給“性別”列創(chuàng)建索引
13、注意超時(shí)問題
14、不要使用Select *
15、在細(xì)節(jié)表中插入紀(jì)錄時(shí)，不要在主表執(zhí)行Select MAX(ID)
16、盡量不要使用TEXT數(shù)據(jù)類型
17、使用參數(shù)查詢
18、不要使用Insert導(dǎo)入大批的數(shù)據(jù)
19、學(xué)會(huì)分析查詢
20、使用參照完整性
21、用INNER JOIN 和LEFT JOIN代替Where?
///
http://blog.sina.com.cn/s/blog_4b3d79a9010006gv.html
提高SQL查詢效率（要點(diǎn)與技巧）：
??技巧一：
問題類型：ACCESS數(shù)據(jù)庫字段中含有日文片假名或其它不明字符時(shí)查詢會(huì)提示內(nèi)存溢出。
解決方法：修改查詢語句
sql="select * from tablename where column like '%"&word&"%'"
改為
sql="select * from tablename"
rs.filter = " column like '%"&word&"%'"
===========================================================
技巧二：
問題類型：如何用簡易的辦法實(shí)現(xiàn)類似百度的多關(guān)鍵詞查詢（多關(guān)鍵詞用空格或其它符號(hào)間隔）。
解決方法：
'//用空格分割查詢字符串
ck=split(word," ")
'//得到分割后的數(shù)量
sck=UBound(ck)
sql="select * tablename where"
在一個(gè)字段中查詢
For i = 0 To sck
SQL = SQL & tempJoinWord & "(" & _
"column like '"&ck(i)&"%')"
tempJoinWord = " and "
Next
在二個(gè)字段中同時(shí)查詢
For i = 0 To sck
SQL = SQL & tempJoinWord & "(" & _
"column like '"&ck(i)&"%' or " & _
"column1 like '"&ck(i)&"%')"
tempJoinWord = " and "
Next
===========================================================
技巧三：大大提高查詢效率的幾種技巧

1. 盡量不要使用 or，使用or會(huì)引起全表掃描，將大大降低查詢效率。
2. 經(jīng)過實(shí)踐驗(yàn)證，charindex()并不比前面加%的like更能提高查詢效率，并且charindex()會(huì)使索引失去作用（指sqlserver數(shù)據(jù)庫）
3. column like '%"&word&"%' 會(huì)使索引不起作用
column like '"&word&"%' 會(huì)使索引起作用（去掉前面的%符號(hào)）
（指sqlserver數(shù)據(jù)庫）
4. '%"&word&"%' 與'"&word&"%' 在查詢時(shí)的區(qū)別：
比如你的字段內(nèi)容為 一個(gè)容易受傷的女人
'%"&word&"%' ：會(huì)通配所有字符串，不論查“受傷”還是查“一個(gè)”，都會(huì)顯示結(jié)果。
'"&word&"%' ：只通配前面的字符串，例如查“受傷”是沒有結(jié)果的，只有查“一個(gè)”，才會(huì)顯示結(jié)果。
5. 字段提取要按照“需多少、提多少”的原則，避免“select *”，盡量使用“select 字段1,字段2,字段3........”。實(shí)踐證明：每少提取一個(gè)字段，數(shù)據(jù)的提取速度就會(huì)有相應(yīng)的提升。提升的速度還要看您舍棄的字段的大小來判斷。
6. order by按聚集索引列排序效率最高。一個(gè)sqlserver數(shù)據(jù)表只能建立一個(gè)聚集索引，一般默認(rèn)為ID，也可以改為其它的字段。
7. 為你的表建立適當(dāng)?shù)乃饕?#xff0c;建立索引可以使你的查詢速度提高幾十幾百倍。（指sqlserver數(shù)據(jù)庫）
??以下是建立索引與不建立索引的一個(gè)查詢效率分析：
Sqlserver索引與查詢效率分析。
表 News
字段
Id：自動(dòng)編號(hào)
Title：文章標(biāo)題
Author：作者
Content：內(nèi)容
Star：優(yōu)先級
Addtime：時(shí)間
記錄：100萬條
測試機(jī)器：P4 2.8/1G內(nèi)存/IDE硬盤
=======================================================
方案1：
主鍵Id，默認(rèn)為聚集索引，不建立其它非聚集索引
select * from News where Title like '%"&word&"%' or Author like '%"&word&"%' order by Id desc
從字段Title和Author中模糊檢索，按Id排序
查詢時(shí)間：50秒
=======================================================
方案2：
主鍵Id，默認(rèn)為聚集索引
在Title、Author、Star上建立非聚集索引
select * from News where Title like '"&word&"%' or Author like '"&word&"%' order by Id desc
從字段Title和Author中模糊檢索，按Id排序
查詢時(shí)間：2 - 2.5秒
=======================================================
方案3：
主鍵Id，默認(rèn)為聚集索引
在Title、Author、Star上建立非聚集索引
select * from News where Title like '"&word&"%' or Author like '"&word&"%' order by Star desc
從字段Title和Author中模糊檢索，按Star排序
查詢時(shí)間：2 秒
=======================================================
方案4：
主鍵Id，默認(rèn)為聚集索引
在Title、Author、Star上建立非聚集索引
select * from News where Title like '"&word&"%' or Author like '"&word&"%'
從字段Title和Author中模糊檢索，不排序
查詢時(shí)間：1.8 - 2 秒
=======================================================
方案5：
主鍵Id，默認(rèn)為聚集索引
在Title、Author、Star上建立非聚集索引
select * from News where Title like '"&word&"%'
或
select * from News where Author like '"&word&"%'
從字段Title 或 Author中檢索，不排序
查詢時(shí)間：1秒
??如何提高SQL語言的查詢效率?
問：請問我如何才能提高SQL語言的查詢效率呢？
答：這得從頭說起：
?? 由于SQL是面向結(jié)果而不是面向過程的查詢語言，所以一般支持SQL語言的大型關(guān)系型數(shù)據(jù)庫都使用一個(gè)基于查詢成本的優(yōu)化器，為即時(shí)查詢提供一個(gè)最佳的執(zhí)行策略。對于優(yōu)化器，輸入是一條查詢語句，輸出是一個(gè)執(zhí)行策略。
??? 一條SQL查詢語句可以有多種執(zhí)行策略，優(yōu)化器將估計(jì)出全部執(zhí)行方法中所需時(shí)間最少的所謂成本最低的那一種方法。所有優(yōu)化都是基于用記所使用的查詢語句中的where子句，優(yōu)化器對where子句中的優(yōu)化主要用搜索參數(shù)(Serach Argument)。
??? 搜索參數(shù)的核心思想就是數(shù)據(jù)庫使用表中字段的索引來查詢數(shù)據(jù)，而不必直接查詢記錄中的數(shù)據(jù)。
??? 帶有 =、<、<=、>、>= 等操作符的條件語句可以直接使用索引，如下列是搜索參數(shù)：
??? emp_id = "10001" 或 salary > 3000 或? a =1 and c = 7
??? 而下列則不是搜索參數(shù)：
??? salary = emp_salary 或 dep_id != 10 或 salary * 12 >= 3000 或 a=1 or c=7
??? 應(yīng)當(dāng)盡可能提供一些冗余的搜索參數(shù)，使優(yōu)化器有更多的選擇余地。請看以下3種方法：
??? 第一種方法：
??? select employee.emp_name,department.dep_name from department,employee where (employee.dep_id = department.dep_id) and (department.dep_code="01") and (employee.dep_code="01");
??? 它的搜索分析結(jié)果如下：
??? Estimate 2 I/O operations
??? Scan department using primary key
??? for rows where dep_code equals "01"
??? Estimate getting here 1 times
??? Scan employee sequentially
??? Estimate getting here 5 times
??? 第二種方法：
??? select employee.emp_name,department.dep_name from department,employee where (employee.dep_id = department.dep_id) and (department.dep_code="01");
??? 它的搜索分析結(jié)果如下：
??? Estimate 2 I/O operations
??? Scan department using primary key
??? for rows where dep_code equals "01"
??? Estimate getting here 1 times
??? Scan employee sequentially
??? Estimate getting here 5 times
??? 第一種方法與第二種運(yùn)行效率相同，但第一種方法最好，因?yàn)樗鼮閮?yōu)化器提供了更多的選擇機(jī)會(huì)。
??? 第三種方法：
??? select employee.emp_name,department.dep_name from department,employee where (employee.dep_id = department.dep_id) and (employee.dep_code="01");
??? 這種方法最不好，因?yàn)樗鼰o法使用索引，也就是無法優(yōu)化……
使用SQL語句時(shí)應(yīng)注意以下幾點(diǎn)：
??? 1、避免使用不兼容的數(shù)據(jù)類型。例如，Float和Integer，Char和Varchar，Binary和Long Binary不兼容的。數(shù)據(jù)類型的不兼容可能使優(yōu)化器無法執(zhí)行一些本可以進(jìn)行的優(yōu)化操作。例如：
??? select emp_name form employee where salary > 3000;
??? 在此語句中若salary是Float類型的，則優(yōu)化器很難對其進(jìn)行優(yōu)化，因?yàn)?000是個(gè)整數(shù)，我們應(yīng)在編程時(shí)使用3000.0而不要等運(yùn)行時(shí)讓DBMS進(jìn)行轉(zhuǎn)化。
??? 2、盡量不要使用表達(dá)式，因它在編繹時(shí)是無法得到的，所以SQL只能使用其平均密度來估計(jì)將要命中的記錄數(shù)。
??? 3、避免對搜索參數(shù)使用其他的數(shù)學(xué)操作符。如：
?????? select emp_name from employee where salary * 12 > 3000;
?????? 應(yīng)改為：
?????? select emp_name from employee where salary? > 250;
??? 4、避免使用 != 或 <> 等這樣的操作符，因?yàn)樗鼤?huì)使系統(tǒng)無法使用索引，而只能直接搜索表中的數(shù)據(jù)。
??ORACAL中的應(yīng)用
一個(gè)1600萬數(shù)據(jù)表－－短信上行表TBL_SMS_MO
結(jié)構(gòu)：
CREATE TABLE TBL_SMS_MO
(
?SMS_ID NUMBER,
?MO_ID VARCHAR2(50),
?MOBILE VARCHAR2(11),
?SPNUMBER VARCHAR2(20),
?MESSAGE VARCHAR2(150),
?TRADE_CODE VARCHAR2(20),
?LINK_ID VARCHAR2(50),
?GATEWAY_ID NUMBER,
?GATEWAY_PORT NUMBER,
?MO_TIME DATE DEFAULT SYSDATE
);
CREATE INDEX IDX_MO_DATE ON TBL_SMS_MO (MO_TIME)
? PCTFREE 10
? INITRANS 2
? MAXTRANS 255
? STORAGE
? (
??? INITIAL 1M
??? NEXT 1M
??? MINEXTENTS 1
??? MAXEXTENTS UNLIMITED
??? PCTINCREASE 0
? );
CREATE INDEX IDX_MO_MOBILE ON TBL_SMS_MO (MOBILE)
? PCTFREE 10
? INITRANS 2
? MAXTRANS 255
? STORAGE
? (
??? INITIAL 64K
??? NEXT 1M
??? MINEXTENTS 1
??? MAXEXTENTS UNLIMITED
??? PCTINCREASE 0
? );
　　問題：從表中查詢某時(shí)間段內(nèi)某手機(jī)發(fā)送的短消息，如下SQL語句：
SELECT MOBILE,MESSAGE,TRADE_CODE,MO_TIME
FROM TBL_SMS_MO
WHERE MOBILE='130XXXXXXXX'
AND MO_TIME BETWEEN TO_DATE('2006-04-01','YYYY-MM-DD HH24:MI:SS') AND TO_DATE('2006-04-07','YYYY-MM-DD HH24:MI:SS')
ORDER BY MO_TIME DESC
返回結(jié)果大約需要10分鐘，應(yīng)用于網(wǎng)頁查詢，簡直難以忍受。
分析：
在PL/SQL Developer，點(diǎn)擊“Explain Plan”按鈕（或F5鍵），對SQL進(jìn)行分析，發(fā)現(xiàn)缺省使用的索引是IDX_MO_DATE。問題可能出在這里，因?yàn)橄鄬τ诳倲?shù)量1600萬數(shù)據(jù)來說，都mobile的數(shù)據(jù)是很少的，如果使用IDX_MO_MOBILE比較容易鎖定數(shù)據(jù)。
如下優(yōu)化：
SELECT /*+ index(TBL_SMS_MO IDX_MO_MOBILE) */ MOBILE,MESSAGE,TRADE_CODE,MO_TIME
FROM TBL_SMS_MO
WHERE MOBILE='130XXXXXXXX'
AND MO_TIME BETWEEN TO_DATE('2006-04-01','YYYY-MM-DD HH24:MI:SS') AND TO_DATE('2006-04-07','YYYY-MM-DD HH24:MI:SS')
ORDER BY MO_TIME DESC
測試：
按F8運(yùn)行這個(gè)SQL，哇～... ... 2.360s，這就是差別。
用索引提高SQL Server性能
特別說明
　　在微軟的SQL Server系統(tǒng)中通過有效的使用索引可以提高數(shù)據(jù)庫的查詢性能，但是性能的提高取決于數(shù)據(jù)庫的實(shí)現(xiàn)。在本文中將會(huì)告訴你如何實(shí)現(xiàn)索引并有效的提高數(shù)據(jù)庫的性能?！?br />　　
　　在關(guān)系型數(shù)據(jù)庫中使用索引能夠提高數(shù)據(jù)庫性能，這一點(diǎn)是非常明顯的。用的索引越多，從數(shù)據(jù)庫系統(tǒng)中得到數(shù)據(jù)的速度就越快。然而，需要注意的是，用的索引越多，向數(shù)據(jù)庫系統(tǒng)中插入新數(shù)據(jù)所花費(fèi)的時(shí)間就越多。在本文中，你將了解到微軟的SQL Server數(shù)據(jù)庫所支持的各種不同類型的索引，在這里你將了解到如何使用不同的方法來實(shí)現(xiàn)索引，通過這些不同的實(shí)現(xiàn)方法，你在數(shù)據(jù)庫的讀性能方面得到的遠(yuǎn)比在數(shù)據(jù)庫的整體性能方面的損失要多得多。
　　
　　索引的定義
　　索引是數(shù)據(jù)庫的工具，通過使用索引，在數(shù)據(jù)庫中獲取數(shù)據(jù)的時(shí)候，就可以不用掃描數(shù)據(jù)庫中的所有數(shù)據(jù)記錄，這樣能夠提高系統(tǒng)獲取數(shù)據(jù)的性能。使用索引可以改變數(shù)據(jù)的組織方式，使得所有的數(shù)據(jù)都是按照相似的結(jié)構(gòu)來組織的，這樣就可以很容易地實(shí)現(xiàn)數(shù)據(jù)的檢索訪問。索引是按照列來創(chuàng)建的，這樣就可以根據(jù)索引列中的值來幫助數(shù)據(jù)庫找到相應(yīng)的數(shù)據(jù)。
　　
　　索引的類型
　　微軟的SQL Server 支持兩種類型的索引：clustered 索引和nonclustered索引。Clustered 索引在數(shù)據(jù)表中按照物理順序存儲(chǔ)數(shù)據(jù)。因?yàn)樵诒碇兄挥幸粋€(gè)物理順序，所以在每個(gè)表中只能有一個(gè)clustered索引。在查找某個(gè)范圍內(nèi)的數(shù)據(jù)時(shí)，Clustered索引是一種非常有效的索引，因?yàn)檫@些數(shù)據(jù)在存儲(chǔ)的時(shí)候已經(jīng)按照物理順序排好序了。
　　
　　Nonclustered索引不會(huì)影響到下面的物理存儲(chǔ)，但是它是由數(shù)據(jù)行指針構(gòu)成的。如果已經(jīng)存在一個(gè)clustered索引，在nonclustered中的索引指針將包含clustered索引的位置參考。這些索引比數(shù)據(jù)更緊促，而且對這些索引的掃描速度比對實(shí)際的數(shù)據(jù)表掃描要快得多。
　　
　　如何實(shí)現(xiàn)索引
　　數(shù)據(jù)庫可以自動(dòng)創(chuàng)建某些索引。例如，微軟的SQL Server系統(tǒng)通過自動(dòng)創(chuàng)建唯一索引來強(qiáng)制實(shí)現(xiàn)UNIQUE約束，這樣可以確保在數(shù)據(jù)庫中不會(huì)插入重復(fù)數(shù)據(jù)。也可以使用CREATE INDEX語句或者通過SQL Server Enterprise Manager來創(chuàng)建其他索引，SQL Server Enterprise Manager還有一個(gè)索引創(chuàng)建模板來指導(dǎo)你如何創(chuàng)建索引。
　　
　　得到更好的性能
　　雖然索引可以帶來性能上的優(yōu)勢，但是同時(shí)也將帶來一定的代價(jià)。雖然SQL Server系統(tǒng)允許你在每個(gè)數(shù)據(jù)表中創(chuàng)建多達(dá)256個(gè)nonclustered索引，但是建議不要使用這么多的索引。因?yàn)樗饕枰趦?nèi)存和物理磁盤驅(qū)動(dòng)器上使用更多的存儲(chǔ)空間。在執(zhí)行插入聲明的過程中可能會(huì)在一定程度上導(dǎo)致系統(tǒng)性能的下降，因?yàn)樵诓迦霐?shù)據(jù)的時(shí)候是需要根據(jù)索引的順序插入，而不是在第一個(gè)可用的位置直接插入數(shù)據(jù)，這樣一來，存在的索引越多將導(dǎo)致插入或者更新聲明所需要的時(shí)間就越多。
　　
　　在使用SQL Server系統(tǒng)創(chuàng)建索引的時(shí)候，建議參照下面的創(chuàng)建準(zhǔn)則來實(shí)現(xiàn)：
　　
　　正確的選擇數(shù)據(jù)類型
　　在索引中使用某些數(shù)據(jù)類型可以提高數(shù)據(jù)庫系統(tǒng)的效率，例如，Int，bigint， smallint，和tinyint等這些數(shù)據(jù)類型都非常適合于用在索引中，因?yàn)樗麄兌颊加孟嗤笮〉目臻g并且可以很容易地實(shí)現(xiàn)比較操作。其他的數(shù)據(jù)類型如char和varchar的效率都非常低，因?yàn)檫@些數(shù)據(jù)類型都不適合于執(zhí)行數(shù)學(xué)操作，并且執(zhí)行比較操作的時(shí)間都比上面提到數(shù)據(jù)類型要長。
　　
　　確保在使用的過程中正確的利用索引值
　　在執(zhí)行查詢操作時(shí)，可能所使用的列只是clustered的一部分，這時(shí)尤其要注意的是如何使用這些數(shù)據(jù)。當(dāng)用這些數(shù)據(jù)列作為參數(shù)調(diào)用函數(shù)時(shí)，這些函數(shù)可能會(huì)使現(xiàn)有的排序優(yōu)勢失效。例如，使用日期值作為索引，而為了實(shí)現(xiàn)比較操作，可能需要將這個(gè)日期值轉(zhuǎn)換為字符串，這樣將導(dǎo)致在查詢過程中無法用到這個(gè)日期索引值。
　　
　　在創(chuàng)建多列索引時(shí)，需要注意列的順序
　　數(shù)據(jù)庫將根據(jù)第一列索引的值來排列記錄，然后進(jìn)一步根據(jù)第二列的值來排序，依次排序直到最后一個(gè)索引排序完畢。哪一列唯一數(shù)據(jù)值較少，哪一列就應(yīng)該為第一個(gè)索引，這樣可以確保數(shù)據(jù)可以通過索引進(jìn)一步交叉排序。
　　
　　在clustered索引中限制列的數(shù)量
　　在clustered索引中用到的列越多，在nonclustered索引中包含的clustered索引參考位置就越多，需要存儲(chǔ)的數(shù)據(jù)也就越多。這樣將增加包含索引的數(shù)據(jù)表的大小，并且將增加基于索引的搜索時(shí)間。
　　
　　避免頻繁更新clustered索引數(shù)據(jù)列
　　由于nonclustered 索引依賴于clustered 索引，所以如果構(gòu)成clustered 索引的數(shù)據(jù)列頻繁更新，將導(dǎo)致在nonclustered中存儲(chǔ)的行定位器也將隨之頻繁更新。對于所有與這些列相關(guān)的查詢來說，如果發(fā)生記錄被鎖定的情況時(shí)，這將可能導(dǎo)致性能成本的增加。
　　
　　分開操作（如果可能的話）
　　對于一個(gè)表來說，如果需要進(jìn)行頻繁的執(zhí)行插入、更新操作，同時(shí)還有大量讀操作的話，在可能的情況下嘗試將這個(gè)表分開操作。所有的插入和更新操作可以在一個(gè)沒有索引的表中操作，然后將其復(fù)制到另外一個(gè)表中，在這個(gè)表里有大量的索引可以優(yōu)化讀數(shù)據(jù)的能力。
　　
　　適當(dāng)?shù)闹亟ㄋ饕?br />　　Nonclustered索引包含clustered索引的指針，這樣一來Nonclustered索引將從屬于clustered 索引。當(dāng)重建clustered索引時(shí)，首先是丟棄原來的索引，然后再使用CREATE INDEX 來創(chuàng)建索引，或者在使用CREATE INDEX 聲明的同時(shí)將DROP_EXISTING 子句作為重建索引的一部分。將丟棄和創(chuàng)建分為幾步將會(huì)導(dǎo)致多次重建nonclustered 索引，而不象使用DROP_EXISTING 子句那樣，只重建一次nonclustered 索引。
　　
　　明智的使用填充因子
　　數(shù)據(jù)存儲(chǔ)在那些具有固定大小的連續(xù)內(nèi)存頁面內(nèi)。隨著新的記錄行的加入，數(shù)據(jù)內(nèi)存頁將逐漸被填滿，系統(tǒng)就必須執(zhí)行數(shù)據(jù)頁的拆分工作，通過這個(gè)拆分工作將部分?jǐn)?shù)據(jù)轉(zhuǎn)移到下一個(gè)新的頁面當(dāng)中。這樣的拆分之后，將加重系統(tǒng)的負(fù)擔(dān)，并且會(huì)導(dǎo)致存儲(chǔ)的數(shù)據(jù)支離破碎。填充因子可以維護(hù)數(shù)據(jù)之間的缺口，一般在創(chuàng)建索引的時(shí)候，該索引的填充因子就已經(jīng)被設(shè)置好了。這樣一來，可以減少插入數(shù)據(jù)所引起的頁面分裂的次數(shù)。因?yàn)橹皇窃趧?chuàng)建索引的時(shí)候才維護(hù)空間的大小，在增加數(shù)據(jù)或者更新數(shù)據(jù)時(shí)不會(huì)去維護(hù)空間的大小。因此，要想能夠充分的利用填充因子，就必須周期性的重建索引。由填充因子所造成的缺口將導(dǎo)致讀性能的下降，因?yàn)殡S著數(shù)據(jù)庫的擴(kuò)張，越來越多的磁盤存取工作需要讀取數(shù)據(jù)。所以，在讀的次數(shù)超過寫的次數(shù)的時(shí)候，很重要的一點(diǎn)是考慮使用填充因子還是使用缺省方式合適。
　　
　　管理層的決策
　　通過有效的使用索引，可以在微軟的SQL Server系統(tǒng)中實(shí)現(xiàn)很好的查詢功能，但是使用索引的效率取決于幾種不同的實(shí)現(xiàn)決策。在索引的性能平衡方面，要做出正確的數(shù)據(jù)庫管理決策意味著需要在良好的性能和困境中抉擇。在特定的情況下，本文給出的一些建議將有助于你做出正確的決策

轉(zhuǎn)自：http://blog.163.com/dreamman_yx/blog/static/26526894201052413052253/

轉(zhuǎn)載于:https://www.cnblogs.com/WindBlog/archive/2011/07/06/2099254.html

總結(jié)

以上是生活随笔為你收集整理的SQL语句执行效率及分析(note)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。