❶ 請問下sql中索引有什麼限制，如何建立快速的索引
建立索引的時候需要看你的欄位，首先欄位要注意小於200，然後看你那些欄位需要比對或者統計，按使用頻率來建立索引順序
❷ mysql有幾種索引類型使用索引時都有那些地方要注意sql優化原則是什麼
mysql的索引類型及使用索引時的注意事項有：
一、普通索引。這是最基本的索引，它沒有任何限制。它有以下幾種創建方式：
1、創建索引
代碼如下:
CREATE INDEX indexName ON mytable(username(length));
如果是CHAR，VARCHAR類型，length可以小於欄位實際長度；如果是BLOB和TEXT類型，必須指定 length，下同。
2、修改表結構
代碼如下:
ALTER mytable ADD INDEX [indexName] ON (username(length)) -- 創建表的時候直接指定
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, INDEX [indexName] (username(length)) );
-- 刪除索引的語法：
DROP INDEX [indexName] ON mytable;
二、唯一索引。它與前面的普通索引類似，不同的就是：索引列的值必須唯一，但允許有空值。如果是組合索引，則列值的組合必須唯一。它有以下幾種創建方式：
代碼如下:
CREATE UNIQUE INDEX indexName ON mytable(username(length))
-- 修改表結構
ALTER mytable ADD UNIQUE [indexName] ON (username(length))
-- 創建表的時候直接指定
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, UNIQUE [indexName] (username(length)) );
三、主鍵索引。它是一種特殊的唯一索引，不允許有空值。一般是在建表的時候同時創建主鍵索引：
代碼如下:
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, PRIMARY KEY(ID) );
當然也可以用 ALTER 命令。記住：一個表只能有一個主鍵。
四、組合索引。為了形象地對比單列索引和組合索引，為表添加多個欄位：
代碼如下:
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, city VARCHAR(50) NOT NULL, age INT NOT NULL );
為了進一步榨取MySQL的效率，就要考慮建立組合索引。就是將 name, city, age建到一個索引里：
代碼如下:
ALTER TABLE mytable ADD INDEX name_city_age (name(10),city,age);[code]
建表時，usernname長度為 16，這里用 10。這是因為一般情況下名字的長度不會超過10，這樣會加速索引查詢速度，還會減少索引文件的大小，提高INSERT的更新速度。
如果分別在 usernname，city，age上建立單列索引，讓該表有3個單列索引，查詢時和上述的組合索引效率也會大不一樣，遠遠低於我們的組合索引。雖然此時有了三個索引，但MySQL只能用到其中的那個它認為似乎是最有效率的單列索引。
建立這樣的組合索引，其實是相當於分別建立了下面三組組合索引：usernname,city,age usernname,city usernname 為什麼沒有 city，age這樣的組合索引呢？這是因為MySQL組合索引「最左前綴」的結果。簡單的理解就是只從最左面的開始組合。並不是只要包含這三列的查詢都會用到該組合索引，下面的幾個SQL就會用到這個組合索引：
[code]
SELECT * FROM mytable WHREE username="admin" AND city="鄭州" SELECT * FROM mytable WHREE username="admin"
❸ 在SQL中怎樣用指定索引查詢
一般來說在條件中使用索引對應的第一個欄位就可能會用到該索引。
微軟的SQL SERVER提供了兩種索引：聚集索引（clustered index，也稱聚類索引、簇集索引）和非聚集索引（nonclustered index，也稱非聚類索引、非簇集索引）。
索引是資料庫中重要的數據結構，它的根本目的就是為了提高查詢效率。現在大多數的資料庫產品都採用IBM最先提出的ISAM索引結構。
數據搜索實現角度
索引也是另外一類文件/記錄，它包含著可以指示出相關數據記錄的各種記錄。其中，每一索引都有一個相對應的搜索碼，字元段的任意一個子集都能夠形成一個搜索碼。這樣，索引就相當於所有數據目錄項的一個集合，它能為既定的搜索碼值的所有數據目錄項提供定位所需的各種有效支持。
以上內容參考：網路-資料庫索引
❹ sql語句中什麼時候可以用索引什麼時候不可以用
樓上的說的正確：那我就給你個例子把---use students --<指定庫名>go/*--檢查資料庫是否存在索引（索引放在系統表中sysindexes中）--*/if exists(select name from sysindexes where name ='IX_stu_writtenexam') --<表名 --欄位>drop index stu .IX_stu_writtenexam --如果存在刪除索引gocreate nonclustered index ix_stu_writtenexam --創建非聚居索引 on stu(wriittenexam) with fillfactor =20 --填充因子go
❺ sql 什麼時候用聚集索引和非聚集索引
1 聚集索引：該索引中鍵值的邏輯順序決定了表中相應行的物理順序。
聚集索引確定表中數據的物理順序。聚集索引類似於電話簿，後者按姓氏排列數據。由於聚集索引規定數據在表中的物理存儲順序，因此一個表只能包含一個聚集索引。但該索引可以包含多個列（組合索引），就像電話簿按姓氏和名字進行組織一樣。
2 聚集索引使用注意事項
定義聚集索引鍵時使用的列越少越好。
• 包含大量非重復值的列。
.• 使用下列運算符返回一個范圍值的查詢：BETWEEN、>、>=、< 和 <=。
• 被連續訪問的列。
• 回大型結果集的查詢。
• 經常被使用聯接或 GROUP BY 子句的查詢訪問的列；一般來說，這些是外鍵列。對 ORDER BY 或
GROUP BY 子句中指定的列進行索引，可以使 SQL Server 不必對數據進行排序，因為這些行已經排序。這樣可以提高查詢性能。
• OLTP 類型的應用程序，這些程序要求進行非常快速的單行查找（一般通過主鍵）。應在主鍵上創建聚集索引。
3 聚集索引不適用於：
• 頻繁更改的列 。這將導致整行移動（因為 SQL Server
必須按物理順序保留行中的數據值）。這一點要特別注意，因為在大數據量事務處理系統中數據是易失的。
• 寬鍵 。來自聚集索引的鍵值由所有非聚集索引作為查找鍵使用，因此存儲在每個非聚集索引的葉條目內。
4 非聚集索引：數據存儲在一個地方，索引存儲在另一個地方，索引帶有指針指向數據的存儲位置。
非聚集索引中的項目按索引鍵值的順序存儲，而表中的信息按另一種順序存儲（這可以由聚集索引規定）。對於非聚集索引，可以為在表非聚集索引中查找數據時常
用的每個列創建一個非聚集索引。有些書籍包含多個索引。例如，一本介紹園藝的書可能會包含一個植物通俗名稱索引，和一個植物學名索引
❻ 在SQL資料庫中設置索引的原則是什麼（注意是設置不是創建）
其實索引的好壞還和你的查詢語句有關系,就是where後邊的列有關.如果兩者協調不好的話,同樣應用索引也得不到什麼好處.下邊的文章希望對你有益:
索引的設計
A:盡量避免表掃描檢查你的查詢語句的where子句，因為這是優化器重要關注的地方。包含在where裡面的每一列（column)都是可能的侯選索引，為能達到最優的性能，考慮在下面給出的例子：對於在where子句中給出了column1這個列。下面的兩個條件可以提高索引的優化查詢性能！第一：在表中的column1列上有一個單索引第二：在表中有多索引，但是column1是第一個索引的列避免定義多索引而column1是第二個或後面的索引，這樣的索引不能優化伺服器性能例如：下面的例子用了pubs資料庫。
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_lname = 'White'按下面幾個列上建立的索引將會是對優化器有用的索引
au_lname
au_lname, au_fname而在下面幾個列上建立的索引將不會對優化器起到好的作用
au_address
au_fname, au_lname考慮使用窄的索引在一個或兩個列上，窄索引比多索引和復合索引更能有效。用窄的索引，在每一頁上將會有更多的行和更少的索引級別（相對與多索引和復合索引而言），這將推進系統性能。對於多列索引，SQL Server維持一個在所有列的索引上的密度統計（用於聯合）和在第一個索引上的
histogram（柱狀圖）統計。根據統計結果，如果在復合索引上的第一個索引很少被選擇使用，那麼優化器對很多查詢請求將不會使用索引。有用的索引會提高select語句的性能，包括insert,uodate,delete。但是，由於改變一個表的內容，將會影響索引。每一個insert,update,delete語句將會使性能下降一些。實驗表明，不要在一個單表上用大量的索引，不要在共享的列上（指在多表中用了參考約束）使用重疊的索引。在某一列上檢查唯一的數據的個數，比較它與表中數據的行數做一個比較。這就是數據的選擇性，這比較結果將會幫助你決定是否將某一列作為侯選的索引列，如果需要，建哪一種索引。你可以用下面的查詢語句返回某一列的不同值的數目。
select count(distinct cloumn_name) from table_name假設column_name是一個10000行的表，則看column_name返回值來決定是否應該使用，及應該使用什麼索引。
Unique values Index
5000 Nonclustered index
20 Clustered index
3 No index
鏃索引和非鏃索引的選擇
<1:>鏃索引是行的物理順序和索引的順序是一致的。頁級，低層等索引的各個級別上都包含實際的數據頁。一個表只能是有一個鏃索引。由於update,delete語句要求相對多一些的讀操作，因此鏃索引常常能加速這樣的操作。在至少有一個索引的表中，你應該有一個鏃索引。在下面的幾個情況下，你可以考慮用鏃索引：例如：某列包括的不同值的個數是有限的（但是不是極少的）顧客表的州名列有50個左右的不同州名的縮寫值，可以使用鏃索引。例如：對返回一定范圍內值的列可以使用鏃索引，比如用between,>,>=,<,<=等等來對列進行操作的列上。
select * from sales where ord_date between Ƌ/1/93' and ƌ/1/93'例如：對查詢時返回大量結果的列可以使用鏃索引。
SELECT * FROM phonebook WHERE last_name = 'Smith'
當有大量的行正在被插入表中時，要避免在本表一個自然增長（例如，identity列）的列上建立鏃索引。如果你建立了鏃的索引，那麼insert的性能就會大大降低。因為每一個插入的行必須到表的最後，表的最後一個數據頁。當一個數據正在被插入（這時這個數據頁是被鎖定的），所有的其他插入行必須等待直到當前的插入已經結束。一個索引的葉級頁中包括實際的數據頁，並且在硬碟上的數據頁的次序是跟鏃索引的邏輯次序一樣的。
<2:>一個非鏃的索引就是行的物理次序與索引的次序是不同的。一個非鏃索引的葉級包含了指向行數據頁的指針。在一個表中可以有多個非鏃索引，你可以在以下幾個情況下考慮使用非鏃索引。在有很多不同值的列上可以考慮使用非鏃索引例如：一個part_id列在一個part表中select * from employee where emp_id = 'pcm9809f'查詢語句中用order by子句的列上可以考慮使用鏃索引
三、查詢語句的設計
SQL Server優化器通過分析查詢語句，自動對查詢進行優化並決定最有效的執行方案。優化器分析查詢語句來決定那個子句可以被優化，並針對可以被優化查詢的子句來選擇有用的索引。最後優化器比較所有可能的執行方案並選擇最有效的一個方案出來。在執行一個查詢時，用一個where子句來限制必須處理的行數，除非完全需要，否則應該避免在一個表中無限制地讀並處理所有的行。例如下面的例子，select qty from sales where stor_id=7131是很有效的比下面這個無限制的查詢select qty from sales避免給客戶的最後數據選擇返回大量的結果集。允許SQL Server運行滿足它目的的函數限制結果集的大小是更有效的。這能減少網路I/O並能提高多用戶的相關並發時的應用程序性能。因為優化器關注的焦點就是where子句的查詢，以利用有用的索引。在表中的每一個索引都可能成為包括在where子句中的侯選索引。為了最好的性能可以遵照下面的用於一個給定列column1的索引。第一：在表中的column1列上有一個單索引第二：在表中有多索引，但是column1是第一個索引的列不要在where子句中使用沒有column1列索引的查詢語句，並避免在where子句用一個多索引的非第一個索引的索引。這時多索引是沒有用的。
For example, given a multicolumn index on the au_lname, au_fname columns of the authors table in
the pubs database,下面這個query語句利用了au_lname上的索引
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_lname = 'White'
AND au_fname = 'Johnson'
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_lname = 'White'下面這個查詢沒有利用索引，因為他使用了多索引的非第一個索引的索引
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_fname = 'Johnson'
❼ mysql索引優化的規則注意事項
常見的簡化規則如下：
1）不要有超過5個以上的表連接（JOIN）
2）考慮使用臨時表或表變數存放中間結果。
3）少用子查詢
4）視圖嵌套不要過深,一般視圖嵌套不要超過2個為宜。
連接的表越多，其編譯的時間和連接的開銷也越大，性能越不好控制。最好是把連接拆開成較小的幾個部分逐個順序執行。優先執行那些能夠大量減少結果的連接。拆分的好處不僅僅是減少SQL Server優化的時間，更使得SQL語句能夠以你可以預測的方式和順序執行。
如果一定需要連接很多表才能得到數據，那麼很可能意味著設計上的缺陷。
連接是outer join，非常不好。因為outer join意味著必須對左表或右表查詢所有行。如果表很大而沒有相應的where語句，那麼outer join很容易導致table scan或index scan。要盡量使用inner join避免scan整個表。
優化建議：
1）使用臨時表存放t1表的結果,能大大減少logical reads（或返回行數）的操作要優先執行。 仔細分析語句，你會發現where中的條件全是針對表t1的，所以直接使用上面的where子句查詢表t1，然後把結果存放再臨時表＃t1中：
Select t1….. into #tt1 from t1 where…(和上面的where一樣)
2）再把＃tt1和其他表進行連接:
Select #t1…
Left outer join …
Left outer join…
3）修改 like 程序，去掉前置百分號。like語句卻因為前置百分號而無法使用索引
4）從系統設計的角度修改語句，去掉outer join。
5）考慮組合索引或覆蓋索引消除clustered index scan。
上面1和2點建議立即消除了worktable，性能提高了幾倍以上，效果非常明顯。
❽ sql使用復合索引要注意什麼
sql復合索引一定要注意搜索條件的設置。
還有就是看你用的是什麼資料庫，mysql和oracle，sqlserver都有各自的設定，需要自己去學