1. sql索引問題
表的索引與字典中的索引非常相似。它可以極大地提高查詢的速度。對一個較大的表來說，通過加索引，一個通常要花費幾個小時來完成的查詢只要幾分鍾就可以完成。（對於包含索引的資料庫，SQL Sever需要一個可觀的額外空間。例如，要建立一個聚簇索引，需要大約1.2倍於數據大小的空間。速度是需要付出代價的。）
聚簇索引和非聚簇索引
假設你已經通過字典的索引找到了一個字所在的頁碼。一旦已經知道了頁碼後，你很可能隨機的翻尋字典，直至找到正確的頁碼。這里還有一種找到頁碼的更有效的方法。
首先，把字典翻到大概一半的地方，如果要找的頁碼比半本字典處的頁碼小，就翻到四分之一處，否則，就把書翻到四分之三的地方。通過這種方法，你可以繼續把字典分成更小的部分，直至找到正確的頁碼附近。這是找到書頁的非常有效的一種方法。（呵呵，到處都是這個例子，跟Hello world有一拼）SQL Sever的表索引以類似的方式工作。一個表索引由一組頁組成，這些頁構成了一個樹形結構。根頁通過指向另外兩個頁，把一個表的記錄從邏輯上分成和兩個部分。而根頁所指向的兩個頁又分別把記錄分割成更小的部分。每個頁都把記錄分成更小的分割，直至到達葉級頁。
索引有兩種類型：聚簇索引和非聚簇索引。
在聚簇索引中，索引樹的葉級頁包含實際的數據：記錄的索引順序與物理順序相同。
在非聚簇索引中，葉級頁指向表中的記錄：記錄的物理順序與邏輯順序沒有必然的聯系。
聚簇索引非常象目錄表，目錄表的順序與實際的頁碼順序是一致的。非聚簇索引則更象書的標准索引表，索引表中的順序通常與實際的頁碼順序是不一致的。一本書也許有多個索引。例如，它也許同時有主題索引和作者索引。同樣，一個表可以有多個非聚簇索引。
通常情況下，你使用的是聚簇索引，但是你應該對兩種類型索引的優缺點都有所理解。
每個表只能有一個聚簇索引，因為一個表中的記錄只能以一種物理順序存放。通常你要對一個表按照標識欄位建立聚簇索引。但是，你也可以對其它類型的欄位建立聚簇索引，如字元型，數值型和日期時間型欄位。
從建立了聚簇索引的表中取出數據要比建立了非聚簇索引的錶快。當你需要取出一定范圍內的數據時，用聚簇索引也比用非聚簇索引好。例如，假設你用一個表來記錄訪問者在你網點上的活動。如果你想取出在一定時間段內的登錄信息，你應該對這個表的DATETIME型欄位建立聚簇索引。
對聚簇索引的主要限制是每個表只能建立一個聚簇索引。但是，一個表可以有不止一個非聚簇索引。實際上，對每個表你最多可以建立249個非聚簇索引。你也可以對一個表同時建立聚簇索引和非聚簇索引。
假如你不僅想根據日期，而且想根據用戶名從你的網點活動日誌中取數據。在這種情況下，同時建立一個聚簇索引和非聚簇索引是有效的。你可以對日期時間欄位建立聚簇索引，對用戶名欄位建立非聚簇索引。如果你發現你需要更多的索引方式，你可以增加更多的非聚簇索引。
非聚簇索引需要大量的硬碟空間和內存。另外，雖然非聚簇索引可以提高從表中取數據的速度，它也會降低向表中插入和更新數據的速度。每當你改變了一個建立了非聚簇索引的表中的數據時，必須同時更新索引。因此你對一個表建立非聚簇索引時要慎重考慮。如果你預計一個表需要頻繁地更新數據，那麼不要對它建立太多非聚簇索引。另外，如果硬碟和內存空間有限，也應該限制使用非聚簇索引的數量。
索引屬性
這兩種類型的索引都有兩個重要屬性：
你可以用兩者中任一種類型同時對多個欄位建立索引（復合索引）；
兩種類型的索引都可以指定為唯一索引。
你可以對多個欄位建立一個復合索引，甚至是復合的聚簇索引。假如有一個表記錄了你的網點訪問者的姓和名字。如果你希望根據完整姓名從表中取數據，你需要建立一個同時對姓欄位和名字欄位進行的索引。這和分別對兩個欄位建立單獨的索引是不同的。當你希望同時對不止一個欄位進行查詢時，你應該建立一個對多個欄位的索引。如果你希望對各個欄位進行分別查詢，你應該對各欄位建立獨立的索引。
兩種類型的索引都可以被指定為唯一索引。如果對一個欄位建立了唯一索引，你將不能向這個欄位輸入重復的值。一個標識欄位會自動成為唯一值欄位，但你也可以對其它類型的欄位建立唯一索引。假設你用一個表來保存你的網點的用戶密碼，你當然不希望兩個用戶有相同的密碼。通過強制一個欄位成為唯一值欄位，你可以防止這種情況的發生。
2. plsql為什麼查詢那麼快
查詢快和資料庫連接客戶端工具關系不大，要看sql的索引使用，是否有過優化，資料庫類型，資料庫表中數據量。PLSQL是連接Oracle的，這個資料庫本身查詢性能就很高。
3. 為什麼這個樣的sql速度快(oracle)，原因
where條件里對列盡量不要用函數處理，否則如果該列有索引將不會用索引查詢，而是改全表掃描查詢。
WHERE子句中，如果索引列是函數的一部分．優化器將不
使用索引而使用全表掃描．
舉例:
低效：
SELECT…
FROMDEPT
WHERESAL * 12 > 25000;
高效:
SELECT…
FROMDEPT
WHERESAL > 25000/12;
4. 一個SQL有時執行速度很快有時很慢，請問處理思路
原因有很多的。
主鍵約束。
當數據量達到百萬以上的時候，你用主鍵去搜索某一條數據時速度是極快的。但當你不用主鍵去搜索的時候速度就降了幾十倍甚至上百倍，這個是主鍵的好處。
索引。
當你的表欄位設置有索引的時候，搜索速度比不創建索引要快幾倍至幾十倍。
sql語句不夠優化。
在查詢某數據的時候，能不用*就盡量不用，想要哪個欄位就查哪個，多餘的不要，這樣就能達到數據傳輸精簡化，讓查詢速度也能快上許多。
多表聯合查詢。
在大數據量的時候這個多表查詢盡量不用，畢竟是很耗內存的，寧願用其他語言循環執行簡單的 select 欄位 from 表名 where 條件 這樣的簡單sql語句，這樣也能加快速度。
其他方面還有很多的，比如伺服器的原因呀，資料庫表結構類型呀。。。我就不多說了。
5. sql怎麼突出索引的優勢,並且比無索引快一個數量級
1、主鍵就是聚集索引
2、只要建立索引就能顯著提高查詢速度
3、把所有需要提高查詢速度的欄位都加進聚集索引，以提高查詢速度
6. 如何在 SQL 資料庫優化 索引，SQL索引優化
1、主鍵就是聚集索引
2、只要建立索引就能顯著提高查詢速度
3、把所有需要提高查詢速度的欄位都加進聚集索引，以提高查詢速度
(四)其他書上沒有的索引使用經驗總結
1、用聚合索引比用不是聚合索引的主鍵速度快
2、用聚合索引比用一般的主鍵作order by時速度快，特別是在小數據量情況下
3、使用聚合索引內的時間段，搜索時間會按數據占整個數據表的百分比成比例減少，而無論聚合索引使用了多少個
4 、日期列不會因為有分秒的輸入而減慢查詢速度
(五)其他注意事項
1. 不要索引常用的小型表
2. 不要把社會保障號碼(SSN)或身份證號碼(ID)選作鍵
3. 不要用用戶的鍵
4. 不要索引 memo/notes 欄位和不要索引大型文本欄位(許多字元)
5. 使用系統生成的主鍵
二、改善SQL語句
1、Like語句是否屬於SARG取決於所使用的通配符的類型
2、or 會引起全表掃描
3、非操作符、函數引起的不滿足SARG形式的語句
4、IN 的作用相當與OR
5、盡量少用NOT
6、exists 和 in 的執行效率是一樣的
7、用函數charindex()和前面加通配符%的LIKE執行效率一樣
8、union並不絕對比or的執行效率高
9、欄位提取要按照「需多少、提多少」的原則，避免「select *」
10、count(*)不比count(欄位)慢
11、order by按聚集索引列排序效率最高
12、高效的TOP
7. pl/sql什麼情況全表比索引快
當你的查詢後的結果大於全表記錄的10%的時候，用全表索引較快
8. sql效率優化通過索引
要看索引欄位的順序
如果a+b+c是唯一索引，那麼建再a+b索引，只會減慢修改表時的效率，對查詢沒有幫助。
如果建的是b+c或是c，而且查詢條件中也就只有b和c就有可能提高效率。
只要記得索引中欄位是有順序的，查詢時的條件如果沒有索引的第一個欄位，則不會再使用索引。
當然，SQL使不使用索引也跟表的行大小、數據量的實際大小以及重復數據的分布情況有關系，如果sqlserver分析出來掃描全表所需的時間比使用索引還快的話，就不會再使用索引了。
9. SQL查詢很快，插入很慢，為什麼
查詢很快，插入很慢就是典型的用空間換取時間的做法。
原因是因為你的查詢條件加了索引，就好比是你的門牌號，有了門牌號，查找起來就很容易，但是卻需要空間存儲門牌號，而且插入的時候一邊插數據一邊分配門牌號，所以會比較慢