sql索引包含哪幾種

『壹』 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"

『貳』 MYSQL資料庫索引類型都有哪些

在滿足語句需求的情況下，盡量少的訪問資源是資料庫設計的重要原則，這和執行的 SQL 有直接的關系，索引問題又是 SQL 問題中出現頻率最高的，常見的索引問題包括：無索引（失效）、隱式轉換。
1. SQL 執行流程看一個問題，在下面這個表 T 中，如果我要執行 select * from T where k between 3 and 5; 需要執行幾次樹的搜索操作，會掃描多少行？mysql> create table T ( -> ID int primary key, -> k int NOT NULL DEFAULT 0, -> s varchar(16) NOT NULL DEFAULT '', -> index k(k)) -> engine=InnoDB;mysql> insert into T values(100,1, 'aa'),(200,2,'bb'), (300,3,'cc'),(500,5,'ee'),(600,6,'ff'),(700,7,'gg');
這分別是 ID 欄位索引樹、k 欄位索引樹。

這條 SQL 語句的執行流程：

1. 在 k 索引樹上找到 k=3，獲得 ID=3002. 回表到 ID 索引樹查找 ID=300 的記錄，對應 R33. 在 k 索引樹找到下一個值 k=5，ID=5004. 再回到 ID 索引樹找到對應 ID=500 的 R4

5. 在 k 索引樹去下一個值 k=6，不符合條件，循環結束

這個過程讀取了 k 索引樹的三條記錄，回表了兩次。因為查詢結果所需要的數據只在主鍵索引上有，所以必須得回表。所以，我們該如何通過優化索引，來避免回表呢？
2. 常見索引優化2.1 覆蓋索引覆蓋索引，換言之就是索引要覆蓋我們的查詢請求，無需回表。

如果執行的語句是 select ID from T wherek between 3 and 5;，這樣的話因為 ID 的值在 k 索引樹上，就不需要回表了。

覆蓋索引可以減少樹的搜索次數，顯著提升查詢性能，是常用的性能優化手段。

但是，維護索引是有代價的，所以在建立冗餘索引來支持覆蓋索引時要權衡利弊。

2.2 最左前綴原則

B+ 樹的數據項是復合的數據結構，比如 (name,sex，age) 的時候，B+ 樹是按照從左到右的順序來建立搜索樹的，當 (張三,F,26) 這樣的數據來檢索的時候，B+ 樹會優先比較 name 來確定下一步的檢索方向，如果 name 相同再依次比較 sex 和 age，最後得到檢索的數據。

• # 有這樣一個表 P

• mysql> create table P (id int primary key, name varchar(10) not null, sex varchar(1), age int, index tl(name,sex,age)) engine=IInnoDB;

• mysql> insert into P values(1,'張三','F',26),(2,'張三','M',27),(3,'李四','F',28),(4,'烏茲','F',22),(5,'張三','M',21),(6,'王五','M',28);

• # 下面的語句結果相同

• mysql> select * from P where name='張三' and sex='F'; ## A1

• mysql> select * from P where sex='F' and age=26; ## A2

• # explain 看一下

• mysql> explain select * from P where name='張三' and sex='F';

• +----+-------------+-------+------------+------+---------------+------+---------+-------------+------+----------+-------------+

• | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |

• +----+-------------+-------+------------+------+---------------+------+---------+-------------+------+----------+-------------+

• | 1 | SIMPLE | P | NULL | ref | tl | tl | 38 | const,const | 1 | 100.00 | Using index |

• +----+-------------+-------+------------+------+---------------+------+---------+-------------+------+----------+-------------+

• mysql> explain select * from P where sex='F' and age=26;

• +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+--------------------------+

• | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |

• +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+--------------------------+

• | 1 | SIMPLE | P | NULL | index | NULL | tl | 43 | NULL | 6 | 16.67 | Using where; Using index |

• +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+--------------------------+

• 可以清楚的看到，A1 使用 tl 索引，A2 進行了全表掃描，雖然 A2 的兩個條件都在 tl 索引中出現，但是沒有使用到 name 列，不符合最左前綴原則，無法使用索引。所以在建立聯合索引的時候，如何安排索引內的欄位排序是關鍵。評估標準是索引的復用能力，因為支持最左前綴，所以當建立（a，b）這個聯合索引之後，就不需要給 a 單獨建立索引。原則上，如果通過調整順序，可以少維護一個索引，那麼這個順序往往就是需要優先考慮採用的。上面這個例子中，如果查詢條件里只有 b，就是沒法利用（a，b）這個聯合索引的，這時候就不得不維護另一個索引，也就是說要同時維護（a，b）、（b）兩個索引。這樣的話，就需要考慮空間佔用了，比如，name 和 age 的聯合索引，name 欄位比 age 欄位佔用空間大，所以創建（name，age）聯合索引和（age）索引佔用空間是要小於（age，name）、(name）索引的。

2.3 索引下推

• 以人員表的聯合索引（name, age）為例。如果現在有一個需求：檢索出表中「名字第一個字是張，而且年齡是26歲的所有男性」。那麼，SQL 語句是這么寫的mysql> select * from tuser where name like '張%' and age=26 and sex=M;


• 通過最左前綴索引規則，會找到 ID1，然後需要判斷其他條件是否滿足在 MySQL 5.6 之前，只能從 ID1 開始一個個回表。到主鍵索引上找出數據行，再對比欄位值。而 MySQL 5.6 引入的索引下推優化(index condition pushdown)，可以在索引遍歷過程中，對索引中包含的欄位先做判斷，直接過濾掉不滿足條件的記錄，減少回表次數。這樣，減少了回表次數和之後再次過濾的工作量，明顯提高檢索速度。

2.4 隱式類型轉化

• 隱式類型轉化主要原因是，表結構中指定的數據類型與傳入的數據類型不同，導致索引無法使用。所以有兩種方案：
• 修改表結構，修改欄位數據類型。

• 修改應用，將應用中傳入的字元類型改為與表結構相同類型。

• 3. 為什麼會選錯索引3.1 優化器選擇索引是優化器的工作，其目的是找到一個最優的執行方案，用最小的代價去執行語句。在資料庫中，掃描行數是影響執行代價的因素之一。掃描的行數越少，意味著訪問磁碟數據的次數越少，消耗的 CPU 資源越少。當然，掃描行數並不是唯一的判斷標准，優化器還會結合是否使用臨時表、是否排序等因素進行綜合判斷。

3.2 掃描行數

• MySQL 在真正開始執行語句之前，並不能精確的知道滿足這個條件的記錄有多少條，只能通過索引的區分度來判斷。顯然，一個索引上不同的值越多，索引的區分度就越好，而一個索引上不同值的個數我們稱為「基數」，也就是說，這個基數越大，索引的區分度越好。# 通過 show index 方法，查看索引的基數mysql> show index from t;+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+| t | 0 | PRIMARY | 1 | id | A | 95636 | NULL | NULL | | BTREE | | || t | 1 | a | 1 | a | A | 96436 | NULL | NULL | YES | BTREE | | || t | 1 | b | 1 | b | A | 96436 | NULL | NULL | YES | BTREE | | |+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+


• MySQL 使用采樣統計方法來估算基數：采樣統計的時候，InnoDB 默認會選擇 N 個數據頁，統計這些頁面上的不同值，得到一個平均值，然後乘以這個索引的頁面數，就得到了這個索引的基數。而數據表是會持續更新的，索引統計信息也不會固定不變。所以，當變更的數據行數超過 1/M 的時候，會自動觸發重新做一次索引統計。

在 MySQL 中，有兩種存儲索引統計的方式，可以通過設置參數 innodb_stats_persistent 的值來選擇：

• on 表示統計信息會持久化存儲。默認 N = 20，M = 10。

• off 表示統計信息只存儲在內存中。默認 N = 8，M = 16。

• 由於是采樣統計，所以不管 N 是 20 還是 8，這個基數都很容易不準確。所以，冤有頭債有主，MySQL 選錯索引，還得歸咎到沒能准確地判斷出掃描行數。

可以用 analyze table 來重新統計索引信息，進行修正。

• ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...


• 3.3 索引選擇異常和處理1. 採用 force index 強行選擇一個索引。2. 可以考慮修改語句，引導 MySQL 使用我們期望的索引。3. 有些場景下，可以新建一個更合適的索引，來提供給優化器做選擇，或刪掉誤用的索引。

『叄』 sql中什麼是索引 有哪兩種,有什麼特點

我只知道，index
on
意思就是表之間關聯起來，有聯系

『肆』 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的效率，就要考慮建立組合索引。
二：使用索引的注意事項
使用索引時，有以下一些技巧和注意事項：
1.索引不會包含有NULL值的列
只要列中包含有NULL值都將不會被包含在索引中，復合索引中只要有一列含有NULL值，那麼這一列對於此復合索引就是無效的。所以我們在資料庫設計時不要讓欄位的默認值為NULL。
2.使用短索引
對串列進行索引，如果可能應該指定一個前綴長度。例如，如果有一個CHAR(255)的列，如果在前10個或20個字元內，多數值是惟一的，那麼就不要對整個列進行索引。短索引不僅可以提高查詢速度而且可以節省磁碟空間和I/O操作。
3.索引列排序
MySQL查詢只使用一個索引，因此如果where子句中已經使用了索引的話，那麼order by中的列是不會使用索引的。因此資料庫默認排序可以符合要求的情況下不要使用排序操作；盡量不要包含多個列的排序，如果需要最好給這些列創建復合索引。
4.like語句操作
一般情況下不鼓勵使用like操作，如果非使用不可，如何使用也是一個問題。like 「%aaa%」 不會使用索引而like 「aaa%」可以使用索引。
5.不要在列上進行運算

select * from users where YEAR(adddate)<2007;
將在每個行上進行運算，這將導致索引失效而進行全表掃描，因此我們可以改成:

select * from users where adddate<『2007-01-01';

6.不使用NOT IN和<>操作。

三：sql優化原則
常見的簡化規則如下：
1.不要有超過5個以上的表連接（JOIN）
2.考慮使用臨時表或表變數存放中間結果。
3.少用子查詢
4.視圖嵌套不要過深,一般視圖嵌套不要超過2個為宜。
5.連接的表越多，其編譯的時間和連接的開銷也越大，性能越不好控制。
6.最好是把連接拆開成較小的幾個部分逐個順序執行。
7.優先執行那些能夠大量減少結果的連接。
8.拆分的好處不僅僅是減少SQL Server優化的時間，更使得SQL語句能夠以你可以預測的方式和順序執行。

如果一定需要連接很多表才能得到數據，那麼很可能意味著設計上的缺陷。

『伍』 sql中索引有幾種每種的定義是什麼如何添加索引添加索引的好處是什麼

聚集索引和非聚集索引 聚集索引存儲記錄是物理上連續存在 非聚集索引是邏輯上的連續，物理存儲並不連續
REATE [UNIQUE][CLUSTERED | NONCLUSTERED] INDEX index_name

ON {table_name | view_name} [WITH [index_property [,....n]]

說明：

UNIQUE: 建立唯一索引。

CLUSTERED: 建立聚集索引。

NONCLUSTERED: 建立非聚集索引。

Index_property: 索引屬性。

UNIQUE索引既可以採用聚集索引結構，也可以採用非聚集索引的結構，如果不指明採用的索引結構，則SQL Server系統默認為採用非聚集索引結構

『陸』 SQL SERVER中索引類型包括的三種類型分別是哪三種

SQL
SERVER中索引類型包括的三種類型分別是
唯一索引(UNIQUE)，聚集索引(CLUSTERED）
，非聚集索引(NONCLUSTERED）。
主鍵與唯一索引的區別
主鍵是一種約束，唯一索引是一種索引，兩者在本質上是不同的。
主鍵創建後一定包含一個唯一性索引，唯一性索引並不一定就是主鍵。
唯一性索引列允許空值，而主鍵列不允許為空值。
主鍵列在創建時，已經默認為空值
+
唯一索引了。
主鍵可以被其他表引用為外鍵，而唯一索引不能。
一個表最多隻能創建一個主鍵，但可以創建多個唯一索引。
主鍵更適合那些不容易更改的唯一標識，如自動遞增列、身份證號等。
在
RBO
模式下，主鍵的執行計劃優先順序要高於唯一索引。
兩者可以提高查詢的速度。

『柒』 sql索引分為幾類

聚集索引(CLUSTERED）和非聚集索引(NONCLUSTERED）。

『捌』 什麼是索引索引類型有幾種，各有什麼特點

索引分單列索引和組合索引。單列索引，即一個索引只包含單個列，一個表可以有多個單列索引，但這不是組合索引。
組合索引，即一個索引包含多個列。創建索引時，你需要確保該索引是應用在 SQL 查詢語句的條件(一般作為 WHERE 子句的條件)。
實際上，索引也是一張表，該表保存了主鍵與索引欄位，並指向實體表的記錄。上面都在說使用索引的好處，但過多的使用索引將會造成濫用。
因此索引也會有它的缺點：雖然索引大大提高了查詢速度，同時卻會降低更新表的速度，如對表進行INSERT、UPDATE和DELETE。
因為更新表時，MySQL不僅要保存數據，還要保存一下索引文件。建立索引會佔用磁碟空間的索引文件。

『玖』 sql中什麼是索引 有哪兩種,有什麼特點

微軟的SQL SERVER提供了兩種索引：聚集索引(clustered index，也稱聚類索引、簇集索引)和非聚集索引(nonclustered index，也稱非聚類索引、非簇集索引)。

下面，我們舉例來說明一下聚集索引和非聚集索引的區別：

其實，我們的漢語字典的正文本身就是一個聚集索引。比如，我們要查「安」字，就會很自然地翻開字典的前幾頁，因為「安」的拼音是「an」，而按照拼音排序漢字的字典是以英文字母「a」開頭並以「z」結尾的，那麼「安」字就自然地排在字典的前部。如果您翻完了所有以「a」開頭的部分仍然找不到這個字，那麼就說明您的字典中沒有這個字;同樣的，如果查「張」字，那您也會將您的字典翻到最後部分，因為「張」的拼音是「zhang」。也就是說，字典的正文部分本身就是一個目錄，您不需要再去查其他目錄來找到您需要找的內容。

我們把這種正文內容本身就是一種按照一定規則排列的目錄稱為「聚集索引」。

如果您認識某個字，您可以快速地從自典中查到這個字。但您也可能會遇到您不認識的字，不知道它的發音，這時候，您就不能按照剛才的方法找到您要查的字，而需要去根據「偏旁部首」查到您要找的字，然後根據這個字後的頁碼直接翻到某頁來找到您要找的字。但您結合「部首目錄」和「檢字表」而查到的字的排序並不是真正的正文的排序方法，比如您查「張」字，我們可以看到在查部首之後的檢字表中「張」的頁碼是672頁，檢字表中「張」的上面是「馳」字，但頁碼卻是63頁，「張」的下面是「弩」字，頁面是390頁。很顯然，這些字並不是真正的分別位於「張」字的上下方，現在您看到的連續的「馳、張、弩」三字實際上就是他們在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我們可以通過這種方式來找到您所需要的字，但它需要兩個過程，先找到目錄中的結果，然後再翻到您所需要的頁碼。

我們把這種目錄純粹是目錄，正文純粹是正文的排序方式稱為「非聚集索引」。