A. 如何解決sql查詢速度太慢
呵呵，這個問題很有趣不是嗎？
上面的同志們只是給出一些建議，以我的經驗來看（oracle），
如果數據量較大，索引的重復量盡量避免，最好的方式是建立非業務id（最好使用自增或是序列），把這個id建立索引。
你的最大的問題就是，建立了索引後，索引列必須出現在where中，否則索引就白白建立了，比如你的id是從1一直到383000，那麼你的語句可以寫成
select
*
from
hr_worktime
where
id>-1
還有就是，where條件中避免出現!=,or,between,等東西，否則索引實效。
B. 如何使用索引提高查詢速度
人們在使用SQL時往往會陷入一個誤區，即太關注於所得的結果是否正確，而忽略了不同的實現方法之間可能存在的
性能差異，這種性能差異在大型的或是復雜的資料庫環境中（如聯機事務處理OLTP或決策支持系統DSS）中表現得尤為明
顯。筆者在工作實踐中發現，不良的SQL往往來自於不恰當的索引設計、不充份的連接條件和不可優化的where子句。在對
它們進行適當的優化後，其運行速度有了明顯地提高！下面我將從這三個方面分別進行總結：
---- 為了更直觀地說明問題，所有實例中的SQL運行時間均經過測試，不超過1秒的均表示為（< 1秒）。
---- 測試環境--
---- 主機：HP LH II
---- 主頻：330MHZ
---- 內存：128兆
---- 操作系統：Operserver5.0.4
----資料庫：Sybase11.0.3
一、不合理的索引設計
----例：表record有620000行，試看在不同的索引下，下面幾個 SQL的運行情況：
---- 1.在date上建有一個非群集索引
select count(*) from record where date >'19991201' and date < '19991214'and amount >2000 (25秒)
select date,sum(amount) from record group by date(55秒)
select count(*) from record where date >'19990901' and place in ('BJ','SH') (27秒)
---- 分析：
----date上有大量的重復值，在非群集索引下，數據在物理上隨機存放在數據頁上，在范圍查找時，必須執行一次表掃描才能找到這一范圍內的全部行。
---- 2.在date上的一個群集索引
select count(*) from record where date >'19991201' and date < '19991214' and amount >2000（14秒）
select date,sum(amount) from record group by date（28秒）
select count(*) from record where date >'19990901' and place in ('BJ','SH')（14秒）
---- 分析：
---- 在群集索引下，數據在物理上按順序在數據頁上，重復值也排列在一起，因而在范圍查找時，可以先找到這個范圍的起末點，且只在這個范圍內掃描數據頁，避免了大范圍掃描，提高了查詢速度。
---- 3.在place，date，amount上的組合索引
select count(*) from record where date >'19991201' and date < '19991214' and amount >2000（26秒）
select date,sum(amount) from record group by date（27秒）
select count(*) from record where date >'19990901' and place in ('BJ, 'SH')（< 1秒）
---- 分析：
---- 這是一個不很合理的組合索引，因為它的前導列是place，第一和第二條SQL沒有引用place，因此也沒有利用上索引；第三個SQL使用了place，且引用的所有列都包含在組合索引中，形成了索引覆蓋，所以它的速度是非常快的。
---- 4.在date，place，amount上的組合索引
select count(*) from record where date >'19991201' and date < '19991214' and amount >2000(< 1秒)
select date,sum(amount) from record group by date（11秒）
select count(*) from record where date >'19990901' and place in ('BJ','SH')（< 1秒）
---- 分析：
---- 這是一個合理的組合索引。它將date作為前導列，使每個SQL都可以利用索引，並且在第一和第三個SQL中形成了索引覆蓋，因而性能達到了最優。
---- 5.總結：
---- 預設情況下建立的索引是非群集索引，但有時它並不是最佳的；合理的索引設計要建立在對各種查詢的分析和預測
上。一般來說：
---- ①.有大量重復值、且經常有范圍查詢
（between, >,< ，>=,< =）和order by
、group by發生的列，可考慮建立群集索引；
---- ②.經常同時存取多列，且每列都含有重復值可考慮建立組合索引；
---- ③.組合索引要盡量使關鍵查詢形成索引覆蓋，其前導列一定是使用最頻繁的列。
二、不充份的連接條件：
---- 例：表card有7896行，在card_no上有一個非聚集索引，表account有191122行，在 account_no上有一個非聚集索引，試看在不同的表連接條件下，兩個SQL的執行情況：
select sum(a.amount) from account a,card b where a.card_no = b.card_no（20秒）
---- 將SQL改為：
select sum(a.amount) from account a,card b where a.card_no = b.card_no and a.account_no=b.account_no（< 1秒）
---- 分析：
---- 在第一個連接條件下，最佳查詢方案是將account作外層表，card作內層表，利用card上的索引，其I/O次數可由以下公式估算為：
---- 外層表account上的22541頁+（外層表account的191122行*內層表card上對應外層表第一行所要查找的3頁）=595907次I/O
---- 在第二個連接條件下，最佳查詢方案是將card作外層表，account作內層表，利用account上的索引，其I/O次數可由以下公式估算為：
---- 外層表card上的1944頁+（外層表card的7896行*內層表account上對應外層表每一行所要查找的4頁）= 33528次I/O
---- 可見，只有充份的連接條件，真正的最佳方案才會被執行。
---- 總結：
---- 1.多表操作在被實際執行前，查詢優化器會根據連接條件，列出幾組可能的連接方案並從中找出系統開銷最小的最佳方案。連接條件要充份考慮帶有索引的表、行數多的表；內外表的選擇可由公式：外層表中的匹配行數*內層表中每一次查找的次數確定，乘積最小為最佳方案。
---- 2.查看執行方案的方法-- 用set showplanon，打開showplan選項，就可以看到連接順序、使用何種索引的信息；想
看更詳細的信息，需用sa角色執行dbcc(3604,310,302)。
三、不可優化的where子句
---- 1.例：下列SQL條件語句中的列都建有恰當的索引，但執行速度卻非常慢：
select * from record where substring(card_no,1,4)='5378'(13秒)
select * from record where amount/30< 1000（11秒）
select * from record where convert(char(10),date,112)='19991201'（10秒）
---- 分析：
---- where子句中對列的任何操作結果都是在SQL運行時逐列計算得到的，因此它不得不進行表搜索，而沒有使用該列上面的索引；如果這些結果在查詢編譯時就能得到，那麼就可以被SQL優化器優化，使用索引，避免表搜索，因此將SQL重寫成
下面這樣：
select * from record where card_no like '5378%'（< 1秒）
select * from record where amount < 1000*30（< 1秒）
select * from record where date= '1999/12/01' （< 1秒）
---- 你會發現SQL明顯快起來！
---- 2.例：表stuff有200000行，id_no上有非群集索引，請看下面這個SQL：
select count(*) from stuff where id_no in('0','1')（23秒）
---- 分析：
---- where條件中的'in'在邏輯上相當於'or'，所以語法分析器會將in ('0','1')轉化為id_no ='0' or id_no='1'來執行。我們期望它會根據每個or子句分別查找，再將結果相加，這樣可以利用id_no上的索引；但實際上（根據showplan）,它卻採用了"OR策略"，即先取出滿足每個or子句的行，存入臨時資料庫的工作表中，再建立唯一索引以去掉重復行，最後從這個臨時表中計算結果。因此，實際過程沒有利用id_no上索引，並且完成時間還要受tempdb資料庫性能的影響。
---- 實踐證明，表的行數越多，工作表的性能就越差，當stuff有620000行時，執行時間竟達到220秒！還不如將or子句分
開：
select count(*) from stuff where id_no='0'
select count(*) from stuff where id_no='1'
---- 得到兩個結果，再作一次加法合算。因為每句都使用了索引，執行時間只有3秒，在620000行下，時間也只有4秒。或者，用更好的方法，寫一個簡單的存儲過程：
create proc count_stuff as
declare @a int
declare @b int
declare @c int
declare @d char(10)
begin
select @a=count(*) from stuff where id_no='0'
select @b=count(*) from stuff where id_no='1'
end
select @c=@a+@b
select @d=convert(char(10),@c)
print @d
---- 直接算出結果，執行時間同上面一樣快！
---- 總結：
---- 可見，所謂優化即where子句利用了索引，不可優化即發生了表掃描或額外開銷。
---- 1.任何對列的操作都將導致表掃描，它包括資料庫函數、計算表達式等等，查詢時要盡可能將操作移至等號右邊。
---- 2.in、or子句常會使用工作表，使索引失效；如果不產生大量重復值，可以考慮把子句拆開；拆開的子句中應該包含索引。
---- 3.要善於使用存儲過程，它使SQL變得更加靈活和高效。
---- 從以上這些例子可以看出，SQL優化的實質就是在結果正確的前提下，用優化器可以識別的語句，充份利用索引，減少表掃描的I/O次數，盡量避免表搜索的發生。其實SQL的性能優化是一個復雜的過程，上述這些只是在應用層次的一種體現，深入研究還會涉及資料庫層的資源配置、網路層的流量控制以及操作系統層的總體設計。
C. 如何提高SQL查詢速度
1
你老師說的對，建立索引是可以提高查詢速度的。你插入了百萬條數據，可以測試。如果在C欄位上建立索引，那以該欄位為查詢條件，在建立後查詢和刪除索引後查詢比較一下就知道了。
2
關於視圖。是提高不了查詢速度的，因為視圖對應一個SQL語句，它只是存起來而已，最後需要進行視圖消解才能進行查詢，它和直接執行相應的語句是一樣的，理論上還要慢一點。
3
關於存儲過程，弄好了是可以提高查詢效率的，因為存儲過程會把一段查詢，也就是SQL語句進行賢編譯，然後將編譯後的代碼存在於伺服器上，在用戶查詢時節省了SQL的編譯時間，所以加快了查詢速度。
D. sqlserver索引查詢速度
大致也就這個速度了。
15萬的數據啊，光輸出也要花很長時間的。
E. 如何提高SQL查詢速度
索引對資料庫檢索優化時很重要的一個概念聚集索引在SQL中是唯一的也就是說聚集索引時一個很寶貴的資源但是SQL SERVER在自動分配索引的時候默認總是將ID主鍵分配為聚集索引其實是很浪費的通常情況下你可以通過語句創建聚集索引到你使用率最高的條件欄位上面去，當然你必須先分配聚集索引然後再去分配主鍵，否則主鍵創建時就會自動佔用聚集索引然後非聚集索引不能設置過濫，設置過濫會導致目錄增多最後反而導致查詢緩慢優化不是純粹理論上的東西，理論教會你怎麼去使用嘗試才能獲取經驗
F. sql資料庫中僅是否為聚集索引對查詢速度有影響嗎
不一樣，首先聚集索引在一張表上只能建立一個；其次聚集索引中的聚集是指的這張表中的數據在磁碟上的物理排序方式是以聚集索引排序；一個簡單的例子如下：
學號身份證號前4位學號為聚集索引身份證號為聚集索引
003710423
001 10811
009510132
在查詢中，主要是看你要以誰為where條件的前綴來進行查詢，比如你用身份證來做為聚集索引但是卻用學號范圍來進行查找，那這個索引就是無效的，你只會得到聚集索引掃描，而聚集索引掃描=堆表掃描；這是針對於聚集索引的情況。
非聚集的話，主要是看索引列的篩選性是否足夠高，並且where條件首句是否使用了這個列，如果沒有使用，就有可能用不到非聚集索引，這個是根據查詢優化器自己判斷的查詢成本來決定的。
G. 如何利用索引提高SQLServer數據處理的效率
在良好的資料庫設計基礎上，能有效地使用索引是SQL Server取得高性能的基礎，SQL Server採用基於代價的優化模型，它對每一個提交的有關表的查詢，決定是否使用索引或用哪一個索引。因為查詢執行的大部分開銷是磁碟I/O，使用索引提高性能的一個主要目標是避免全表掃描，因為全表掃描需要從磁碟上讀表的每一個數據頁，如果有索引指向數據值，則查詢只需讀幾次磁碟就可以了。
所以如果建立了合理的索引，優化器就能利用索引加速數據的查詢過程。但是，索引並不總是提高系統的性能，在增、刪、改操作中索引的存在會增加一定的工作量，因此，在適當的地方增加適當的索引並從不合理的地方刪除次優的索引，將有助於優化那些性能較差的SQL Server應用。實踐表明，合理的索引設計是建立在對各種查詢的分析和預測上的，只有正確地使索引與程序結合起來,才能產生最佳的優化方案。本文就SQL Server索引的性能問題進行了一些分析和實踐。
一、聚簇索引(clustered indexes)的使用
聚簇索引是一種對磁碟上實際數據重新組織以按指定的一個或多個列的值排序。由於聚簇索引的索引頁面指針指向數據頁面，所以使用聚簇索引查找數據幾乎總是比使用非聚簇索引快。每張表只能建一個聚簇索引，並且建聚簇索引需要至少相當該表120%的附加空間，以存放該表的副本和索引中間頁。建立聚簇索引的思想是：
1、大多數表都應該有聚簇索引或使用分區來降低對表尾頁的競爭，在一個高事務的環境中，對最後一頁的封鎖嚴重影響系統的吞吐量。
2、在聚簇索引下，數據在物理上按順序排在數據頁上，重復值也排在一起，因而在那些包含范圍檢查(between、<、<=、>、>=)或使用group by或order by的查詢時，一旦找到具有范圍中第一個鍵值的行，具有後續索引值的行保證物理上毗連在一起而不必進一步搜索，避免了大范圍掃描，可以大大提高查詢速度。
3、在一個頻繁發生插入操作的表上建立聚簇索引時，不要建在具有單調上升值的列(如IDENTITY)上，否則會經常引起封鎖沖突。
4、在聚簇索引中不要包含經常修改的列，因為碼值修改後，數據行必須移動到新的位置。
5、選擇聚簇索引應基於where子句和連接操作的類型。
聚簇索引的侯選列是：
1、主鍵列,該列在where子句中使用並且插入是隨機的。
2、按范圍存取的列，如pri_order > 100 and pri_order < 200。
3、在group by或order by中使用的列。
4、不經常修改的列。
5、在連接操作中使用的列。
二、非聚簇索引(nonclustered indexes)的使用
SQL Server預設情況下建立的索引是非聚簇索引，由於非聚簇索引不重新組織表中的數據，而是對每一行存儲索引列值並用一個指針指向數據所在的頁面。換句話說非聚簇索引具有在索引結構和數據本身之間的一個額外級。一個表如果沒有聚簇索引時,可有250個非聚簇索引。每個非聚簇索引提供訪問數據的不同排序順序。在建立非聚簇索引時，要權衡索引對查詢速度的加快與降低修改速度之間的利弊。另外，還要考慮這些問題：
1、索引需要使用多少空間。
2、合適的列是否穩定。
3、索引鍵是如何選擇的，掃描效果是否更佳。
4、是否有許多重復值。
對更新頻繁的表來說，表上的非聚簇索引比聚簇索引和根本沒有索引需要更多的額外開銷。對移到新頁的每一行而言，指向該數據的每個非聚簇索引的頁級行也必須更新，有時可能還需要索引頁的分理。從一個頁面刪除數據的進程也會有類似的開銷，另外，刪除進程還必須把數據移到頁面上部，以保證數據的連續性。所以，建立非聚簇索引要非常慎重。非聚簇索引常被用在以下情況：
1、某列常用於集合函數(如Sum,....)。
2、某列常用於join,order by,group by。
3、查尋出的數據不超過表中數據量的20%。
三、覆蓋索引(covering indexes)的使用
覆蓋索引是指那些索引項中包含查尋所需要的全部信息的非聚簇索引，這種索引之所以比較快也正是因為索引頁中包含了查尋所必須的數據,不需去訪問數據頁。如果非聚簇索引中包含結果數據,那麼它的查詢速度將快於聚簇索引。
但是由於覆蓋索引的索引項比較多,要佔用比較大的空間。而且update操作會引起索引值改變。所以如果潛在的覆蓋查詢並不常用或不太關鍵，則覆蓋索引的增加反而會降低性能。
四、索引的選擇技術
p_detail是住房公積金管理系統中記錄個人明細的表，有890000行，觀察在不同索引下的查詢運行效果，測試在C/S環境下進行，客戶機是IBM PII350(內存64M),伺服器是DEC Alpha1000A(內存128M),資料庫為SYBASE11.0.3。
1、 select count(*) from p_detail where
op_date>』19990101』 and op_date<』
19991231』 and pri_surplus1>300
2、 select count(*),sum(pri_surplus1) from p_detail
where op_date>』19990101』 and
pay_month between『199908』 and』199912』
不建任何索引查詢1 1分15秒
查詢2 1分7秒
在op_date上建非聚簇索引查詢1 57秒
查詢2 57秒
在op_date上建聚簇索引查詢1 <1秒
查詢2 52秒
在pay_month、op_date、pri_surplus1上建索引查詢1 34秒
查詢2 <1秒
在op_date、pay_month、pri_surplus1上建索引查詢1 <1秒
查詢2 <1秒
從以上查詢效果分析，索引的有無，建立方式的不同將會導致不同的查詢效果，選擇什麼樣的索引基於用戶對數據的查詢條件,這些條件體現於where從句和join表達式中。一般來說建立索引的思路是：
(1)主鍵時常作為where子句的條件，應在表的主鍵列上建立聚簇索引，尤其當經常用它作為連接的時候。
(2)有大量重復值且經常有范圍查詢和排序、分組發生的列，或者非常頻繁地被訪問的列，可考慮建立聚簇索引。
(3)經常同時存取多列，且每列都含有重復值可考慮建立復合索引來覆蓋一個或一組查詢，並把查詢引用最頻繁的列作為前導列，如果可能盡量使關鍵查詢形成覆蓋查詢。
(4)如果知道索引鍵的所有值都是唯一的，那麼確保把索引定義成唯一索引。
(5)在一個經常做插入操作的表上建索引時，使用fillfactor(填充因子)來減少頁分裂，同時提高並發度降低死鎖的發生。如果在只讀表上建索引，則可以把fillfactor置為100。
(6)在選擇索引鍵時，設法選擇那些採用小數據類型的列作為鍵以使每個索引頁能夠容納盡可能多的索引鍵和指針，通過這種方式，可使一個查詢必須遍歷的索引頁面降到最小。此外，盡可能地使用整數為鍵值，因為它能夠提供比任何數據類型都快的訪問速度。
五、索引的維護
上面講到,某些不合適的索引影響到SQL Server的性能,隨著應用系統的運行,數據不斷地發生變化,當數據變化達到某一個程度時將會影響到索引的使用。這時需要用戶自己來維護索引。索引的維護包括：
1、重建索引
隨著數據行的插入、刪除和數據頁的分裂，有些索引頁可能只包含幾頁數據，另外應用在執行大塊I/O的時候，重建非聚簇索引可以降低分片，維護大塊I/O的效率。重建索引實際上是重新組織B-樹空間。在下面情況下需要重建索引：
(1)數據和使用模式大幅度變化。
(2)排序的順序發生改變。
(3)要進行大量插入操作或已經完成。
(4)使用大塊I/O的查詢的磁碟讀次數比預料的要多。
(5)由於大量數據修改，使得數據頁和索引頁沒有充分使用而導致空間的使用超出估算。
(6)dbcc檢查出索引有問題。
當重建聚簇索引時，這張表的所有非聚簇索引將被重建。
2、索引統計信息的更新
當在一個包含數據的表上創建索引的時候，SQL Server會創建分布數據頁來存放有關索引的兩種統計信息：分布表和密度表。優化器利用這個頁來判斷該索引對某個特定查詢是否有用。但這個統計信息並不動態地重新計算。這意味著，當表的數據改變之後，統計信息有可能是過時的，從而影響優化器追求最有工作的目標。因此，在下面情況下應該運行update statistics命令：
(1)數據行的插入和刪除修改了數據的分布。
(2)對用truncate table刪除數據的表上增加數據行。
(3)修改索引列的值。
六、結束語
實踐表明，不恰當的索引不但於事無補，反而會降低系統的執行性能。因為大量的索引在插入、修改和刪除操作時比沒有索引花費更多的系統時間。例如下面情況下建立的索引是不恰當的：
1、在查詢中很少或從不引用的列不會受益於索引，因為索引很少或從來不必搜索基於這些列的行。
2、只有兩個或三個值的列，如男性和女性(是或否)，從不會從索引中得到好處。
另外，鑒於索引加快了查詢速度，但減慢了數據更新速度的特點。可通過在一個段上建表，而在另一個段上建其非聚簇索引，而這兩段分別在單獨的物理設備上來改善操作性能。
H. 如何解決mysql 查詢和更新速度慢
問題
我們有一個 SQL，用於找到沒有主鍵 / 唯一鍵的表，但是在 MySQL 5.7 上運行特別慢，怎麼辦?
實驗
我們搭建一個 MySQL 5.7 的環境，此處省略搭建步驟。
寫個簡單的腳本，製造一批帶主鍵和不帶主鍵的表：
可以看到執行時間變成了 0.67s。
整理
我們診斷的關鍵點如下：
1. 對於 information_schema 中的元數據表，執行計劃不能提供有效信息。
2. 通過查看 MySQL 改寫後的 SQL，我們猜測了優化器發生了誤判。
3. 我們增加了 hint，指導 MySQL 正確進行優化判斷。
但目前我們的實驗僅限於猜測，猜中了萬事大吉，猜不中就無法做出好的診斷。
I. 如何解決SQL查詢速度太慢
1. 執行計劃中明明有使用到索引，為什麼執行還是這么慢？
2. 執行計劃中顯示掃描行數為 644，為什麼 slow log 中顯示 100 多萬行？
a. 我們先看執行計劃，選擇的索引 「INDX_BIOM_ELOCK_TASK3(TASK_ID)」。結合 sql 來看，因為有 "ORDER BY TASK_ID DESC" 子句，排序通常很慢，如果使用了文件排序性能會更差，優化器選擇這個索引避免了排序。
那為什麼不選 possible_keys:INDX_BIOM_ELOCK_TASK 呢？原因也很簡單，TASK_DATE 欄位區分度太低了，走這個索引需要掃描的行數很大，而且還要進行額外的排序，優化器綜合判斷代價更大，所以就不選這個索引了。不過如果我們強制選擇這個索引（用 force index 語法），會看到 SQL 執行速度更快少於 10s，那是因為優化器基於代價的原則並不等價於執行速度的快慢；
b. 再看執行計劃中的 type:index，"index" 代表 「全索引掃描」，其實和全表掃描差不多，只是掃描的時候是按照索引次序進行而不是行，主要優點就是避免了排序，但是開銷仍然非常大。
Extra:Using where 也意味著掃描完索引後還需要回表進行篩選。一般來說，得保證 type 至少達到 range 級別，最好能達到 ref。
在第 2 點中提到的「慢日誌記錄Rows_examined: 1161559，看起來是全表掃描」，這里更正為「全索引掃描」，掃描行數確實等於表的行數；
c. 關於執行計劃中：「rows：644」，其實這個只是估算值，並不準確，我們分析慢 SQL 時判斷准確的掃描行數應該以 slow log 中的 Rows_examined 為准。
4. 優化建議：添加組合索引 IDX_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID)
優化過程：
TASK_DATE 欄位存在索引，但是選擇度很低，優化器不會走這個索引，建議後續可以刪除這個索引：
select count(*),count(distinct TASK_DATE) from T_BIOMA_ELOCK_TASK;+------------+---------------------------+| count(*) | count(distinct TASK_DATE) |+------------+---------------------------+| 1161559 | 223 |+------------+---------------------------+
在這個 sql 中 REL_DEVID 欄位從命名上看選擇度較高，通過下面 sql 來檢驗確實如此：
select count(*),count(distinct REL_DEVID) from T_BIOMA_ELOCK_TASK;+----------+---------------------------+| count(*) | count(distinct REL_DEVID) |+----------+---------------------------+| 1161559 | 62235 |+----------+---------------------------+
由於有排序，所以得把 task_id 也加入到新建的索引中，REL_DEVID,task_id 組合選擇度 100%：
select count(*),count(distinct REL_DEVID,task_id) from T_BIOMA_ELOCK_TASK;+----------+-----------------------------------+| count(*) | count(distinct REL_DEVID,task_id) |+----------+-----------------------------------+| 1161559 | 1161559 |+----------+-----------------------------------+
在測試環境添加 REL_DEVID，TASK_ID 組合索引，測試 sql 性能：alter table T_BIOMA_ELOCK_TASK add index idx_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID);
添加索引後執行計劃：
這里還要注意一點「隱式轉換」：REL_DEVID 欄位數據類型為 varchar，需要在 sql 中加引號：AND T.REL_DEVID = 000000025xxx >> AND T.REL_DEVID = '000000025xxx'
執行時間從 10s+ 降到 毫秒級別：
1 row in set (0.00 sec)
結論
一個典型的 order by 查詢的優化，添加更合適的索引可以避免性能問題：執行計劃使用索引並不意味著就能執行快。
J. sqlserver2005中查詢記錄，使用索引後反而速度更慢了
你要把語句全部列出來才可能找到原因。
如果你的where條件用到你添加的索引，並且你的select 欄位可以包含在索引裡面，速度肯定要快一些。