Mysql索引詳解及優化(key和index區別)
MySQL索引的概念
索引是一種特殊的檔案(InnoDB資料表上的索引是表空間的一個組成部分)，它們包含著對資料表裡所有記錄的引用指標。更通俗的說，資料庫索引好比是一本書前面的目錄，能加快資料庫的查詢速度。
索引分為聚簇索引和非聚簇索引兩種，聚簇索引是按照資料存放的物理位置為順序的，而非聚簇索引就不一樣了；聚簇索引能提高多行檢索的速度，而非聚簇索引對於單行的檢索很快
要注意的是，建立太多的索引將會影響更新和插入的速度，因為它需要同樣更新每個索引檔案。對於一個經常需要更新和插入的表格，就沒有必要為一個很少使用的where字句單獨建立索引了，對於比較小的表，排序的開銷不會很大，也沒有必要建立另外的索引。
- 普通索引
普通索引(由關鍵字KEY或INDEX定義的索引)的唯一任務是加快對資料的訪問速度。因此，應該只為那些最經常出現在查詢條件(WHERE column = ...)或排序條件(ORDER BY column)中的資料列建立索引。只要有可能，就應該選擇一個數據最整齊、最緊湊的資料列(如一個整數型別的資料列)來建立索引。
[sql] view plain copy 在CODE上檢視程式碼片派生到我的程式碼片
–直接建立索引(length表示使用名稱前1ength個字元)
CREATE INDEX index_name ON table_name(column_name(length))
–修改表結構的方式新增索引
ALTER TABLE table_name ADD INDEX index_name ON (column_name)
–建立表的時候同時建立索引
CREATE TABLE table_name
id int(11) NOT NULL AUTO_INCREMENT ,title char(255) NOT NULL ,PRIMARY KEY (
id),INDEX index_name (title)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
–刪除索引
DROP INDEX index_name ON table_name;
建立複合索引 。
CREATE INDEX mytable_categoryid_userid ON mytable (category_id,user_id);
注意命名時的習慣了嗎？使用"表名_欄位1名_欄位2名"的方式
2. 唯一索引
與普通索引類似，不同的就是：索引列的值必須唯一，但允許有空值（注意和主鍵不同）。如果是組合索引，則列值的組合必須唯一，建立方法和普通索引類似。
如果能確定某個資料列將只包含彼此各不相同的值，在為這個資料列建立索引的時候就應該用關鍵字UNIQUE把它定義為一個唯一索引。這麼做的好處：一是簡化了MySQL對這個索引的管理工作，這個索引也因此而變得更有效率；二是MySQL會在有新記錄插入資料表時，自動檢查新記錄的這個欄位的值是否已經在某個記錄的這個欄位裡出現過了；如果是，MySQL將拒絕插入那條新記錄。也就是說，唯一索引可以保證資料記錄的唯一性。事實上，在許多場合，人們建立唯一索引的目的往往不是為了提高訪問速度，而只是為了避免資料出現重複。
[sql] view plain copy 在CODE上檢視程式碼片派生到我的程式碼片
–建立唯一索引
CREATE UNIQUE INDEX index_name ON table_name(column_name)
–修改表結構
ALTER TABLE table_name ADD UNIQUE index_name ON (column_name)
–建立表的時候直接指定
CREATE TABLE table_name (
id int(11) NOT NULL AUTO_INCREMENT ,
title char(255) NOT NULL ,
PRIMARY KEY (id),
UNIQUE index_name (title)
);
3.主索引
在前面已經反覆多次強調過：必須為主鍵欄位建立一個索引，這個索引就是所謂的"主索引"。主索引與唯一索引的唯一區別是：前者在定義時使用的關鍵字是PRIMARY而不是UNIQUE。
4.外來鍵索引
如果為某個外來鍵欄位定義了一個外來鍵約束條件，MySQL就會定義一個內部索引來幫助自己以最有效率的方式去管理和使用外來鍵約束條件。
- 全文索引（FULLTEXT）
MySQL從3.23.23版開始支援全文索引和全文檢索，fulltext索引僅可用於 MyISAM 表；他們可以從CHAR、VARCHAR或TEXT列中作為CREATE TABLE語句的一部分被建立，或是隨後使用ALTER TABLE 或CREATE INDEX被新增。////對於較大的資料集，將你的資料輸入一個沒有FULLTEXT索引的表中，然後建立索引，其速度比把資料輸入現有FULLTEXT索引的速度更為快。不過切記對於大容量的資料表，生成全文索引是一個非常消耗時間非常消耗硬碟空間的做法。
文字欄位上的普通索引只能加快對出現在欄位內容最前面的字串(也就是欄位內容開頭的字元)進行檢索操作。如果欄位裡存放的是由幾個、甚至是多個單詞構成的較大段文字，普通索引就沒什麼作用了。這種檢索往往以LIKE %word%的形式出現，這對MySQL來說很複雜，如果需要處理的資料量很大，響應時間就會很長。
這類場合正是全文索引(full-text index)可以大顯身手的地方。在生成這種型別的索引時，MySQL將把在文字中出現的所有單詞建立為一份清單，查詢操作將根據這份清單去檢索有關的資料記錄。全文索引即可以隨資料表一同建立，也可以等日後有必要時再使用下面這條命令新增：
ALTER TABLE table_name ADD FULLTEXT(column1, column2)
有了全文索引，就可以用SELECT查詢命令去檢索那些包含著一個或多個給定單詞的資料記錄了。下面是這類查詢命令的基本語法：
SELECT * FROM table_name
WHERE MATCH(column1, column2) AGAINST('word1', 'word2', 'word3')
上面這條命令將把column1和column2欄位裡有word1、word2和word3的資料記錄全部查詢出來。
[sql] view plain copy 在CODE上檢視程式碼片派生到我的程式碼片
–建立表的適合新增全文索引
CREATE TABLE table_name (
id int(11) NOT NULL AUTO_INCREMENT ,
content text CHARACTER SET utf8 COLLATE utf8_general_ci NULL ,
PRIMARY KEY (id),
FULLTEXT (content)
);
–修改表結構新增全文索引
ALTER TABLE table_name ADD FULLTEXT index_name(column_name)
–直接建立索引
CREATE FULLTEXT INDEX index_name ON table_name (column_name)
6. 單列索引、多列索引
多個單列索引與單個多列索引的查詢效果不同，因為執行查詢時，MySQL只能使用一個索引，會從多個索引中選擇一個限制最為嚴格的索引。
- 組合(複合)索引（最左字首）
平時用的SQL查詢語句一般都有比較多的限制條件，所以為了進一步榨取MySQL的效率，就要考慮建立組合索引。例如上表中針對title和time建立一個組合索引：ALTER TABLE article ADD INDEX index_titme_time (title(50),time(10))。建立這樣的組合索引，其實是相當於分別建立了下面兩組組合索引：
–title,time
–title
為什麼沒有time這樣的組合索引呢？這是因為MySQL組合索引“最左字首”的結果。簡單的理解就是隻從最左面的開始組合。並不是只要包含這兩列的查詢都會用到該組合索引，如下面的幾個SQL所示
–使用到上面的索引
SELECT * FROM article WHREE title='測試' AND time=1234567890;
SELECT * FROM article WHREE title='測試';
–不使用上面的索引
SELECT * FROM article WHREE time=1234567890;
MySQL索引的優化
上面都在說使用索引的好處，但過多的使用索引將會造成濫用。因此索引也會有它的缺點：雖然索引大大提高了查詢速度，同時卻會降低更新表的速度，如對錶進行INSERT、UPDATE和DELETE。因為更新表時，MySQL不僅要儲存資料，還要儲存一下索引檔案。建立索引會佔用磁碟空間的索引檔案。一般情況這個問題不太嚴重，但如果你在一個大表上建立了多種組合索引，索引檔案的會膨脹很快。索引只是提高效率的一個因素，如果你的MySQL有大資料量的表，就需要花時間研究建立最優秀的索引，或優化查詢語句。下面是一些總結以及收藏的MySQL索引的注意事項和優化方法。
-
何時使用聚集索引或非聚集索引？
動作描述 使用聚集索引 使用非聚集索引
列經常被分組排序 使用 使用
返回某範圍內的資料 使用 不使用
一個或極少不同值 不使用 不使用
小數目的不同值 使用 不使用
大數目的不同值 不使用 使用
頻繁更新的列 不使用 使用
外來鍵列 使用 使用
主鍵列 使用 使用
頻繁修改索引列 不使用 使用 -
索引不會包含有NULL值的列
只要列中包含有NULL值都將不會被包含在索引中，複合索引中只要有一列含有NULL值，那麼這一列對於此複合索引就是無效的。所以我們在資料庫設計時不要讓欄位的預設值為NULL。 -
使用短索引
對串列進行索引，如果可能應該指定一個字首長度。例如，如果有一個CHAR(255)的列，如果在前10個或20個字元內，多數值是惟一的，那麼就不要對整個列進行索引。短索引不僅可以提高查詢速度而且可以節省磁碟空間和I/O操作。 -
索引列排序
MySQL查詢只使用一個索引，因此如果where子句中已經使用了索引的話，那麼order by中的列是不會使用索引的。因此資料庫預設排序可以符合要求的情況下不要使用排序操作；儘量不要包含多個列的排序，如果需要最好給這些列建立複合索引。 -
like語句操作
一般情況下不鼓勵使用like操作，如果非使用不可，如何使用也是一個問題。like “%aaa%” 不會使用索引而like “aaa%”可以使用索引。 -
不要在列上進行運算
例如：select * from users where YEAR(adddate)<2007，將在每個行上進行運算，這將導致索引失效而進行全表掃描，因此我們可以改成：select * from users where adddate<’2007-01-01′。關於這一點可以圍觀：一個單引號引發的MYSQL效能損失。最後總結一下，MySQL只對一下操作符才使用索引：<,<=,=,>,>=,between,in,以及某些時候的like(不以萬用字元%或_開頭的情形)。而理論上每張表裡面最多可建立16個索引，不過除非是資料量真的很多，否則過多的使用索引也不是那麼好玩的，比如我剛才針對text型別的欄位建立索引的時候，系統差點就卡死了。
補充EXPLAIN 用法：
只有當資料庫裡已經有了足夠多的測試資料時，它的效能測試結果才有實際參考價值。如果在測試資料庫裡只有幾百條資料記錄，它們往往在執行完第一條查詢命令之後就被全部載入到記憶體裡，這將使後續的查詢命令都執行得非常快--不管有沒有使用索引。只有當資料庫裡的記錄超過了1000條、資料總量也超過了MySQL伺服器上的記憶體總量時，資料庫的效能測試結果才有意義。
在不確定應該在哪些資料列上建立索引的時候，人們從EXPLAIN SELECT命令那裡往往可以獲得一些幫助。這其實只是簡單地給一條普通的SELECT命令加一個EXPLAIN關鍵字作為字首而已。有了這個關鍵字，MySQL將不是去執行那條SELECT命令，而是去對它進行分析。MySQL將以表格的形式把查詢的執行過程和用到的索引(如果有的話)等資訊列出來。
在EXPLAIN命令的輸出結果裡，第1列是從資料庫讀取的資料表的名字，它們按被讀取的先後順序排列。type列指定了本資料表與其它資料表之間的關聯關係(JOIN)。在各種型別的關聯關係當中，效率最高的是system，然後依次是const、eq_ref、ref、range、index和All(All的意思是：對應於上一級資料表裡的每一條記錄，這個資料表裡的所有記錄都必須被讀取一遍--這種情況往往可以用一索引來避免)。
possible_keys資料列給出了MySQL在搜尋資料記錄時可選用的各個索引。key資料列是MySQL實際選用的索引，這個索引按位元組計算的長度在key_len資料列裡給出。比如說，對於一個INTEGER資料列的索引，這個位元組長度將是4。如果用到了複合索引，在key_len資料列裡還可以看到MySQL具體使用了它的哪些部分。作為一般規律，key_len資料列裡的值越小越好(意思是更快)。
ref資料列給出了關聯關係中另一個數據表裡的資料列的名字。row資料列是MySQL在執行這個查詢時預計會從這個資料表裡讀出的資料行的個數。row資料列裡的所有數字的乘積可以讓我們大致瞭解這個查詢需要處理多少組合。
8.key和index區別
mysql的key和index多少有點令人迷惑，這實際上考察對資料庫體系結構的瞭解的。
1).key 是資料庫的物理結構，它包含兩層意義，一是約束（偏重於約束和規範資料庫的結構完整性），二是索引（輔助查詢用的）。包括primary key, unique key, foreign key 等。
primary key 有兩個作用，一是約束作用（constraint），用來規範一個儲存主鍵和唯一性，但同時也在此key上建立了一個index；
unique key 也有兩個作用，一是約束作用（constraint），規範資料的唯一性，但同時也在這個key上建立了一個index；
foreign key也有兩個作用，一是約束作用（constraint），規範資料的引用完整性，但同時也在這個key上建立了一個index；
可見，mysql的key是同時具有constraint和index的意義，這點和其他資料庫表現的可能有區別。（至少在Oracle上建立外來鍵，不會自動建立index），因此建立key也有如下幾種方式：
（1）在欄位級以key方式建立， 如 create table t (id int not null primary key);
（2）在表級以constraint方式建立，如create table t(id int, CONSTRAINT pk_t_id PRIMARY key (id));
（3）在表級以key方式建立，如create table t(id int, primary key (id));
其它key建立類似，但不管那種方式，既建立了constraint，又建立了index，只不過index使用的就是這個constraint或key。
2).index是資料庫的物理結構，它只是輔助查詢的，它建立時會在另外的表空間（mysql中的innodb表空間）以一個類似目錄的結構儲存。索引要分類的話，分為字首索引、全文字索引等；
因此，索引只是索引，它不會去約束索引的欄位的行為（那是key要做的事情）。
如，create table t(id int, index inx_tx_id (id));
3).最後的釋疑：
(1).我們說索引分類，分為主鍵索引、唯一索引、普通索引(這才是純粹的index)等，也是基於是不是把index看作了key。
比如 create table t(id int, unique index inx_tx_id (id)); --index當作了key使用
(2).最重要的也就是，不管如何描述，理解index是純粹的index，還是被當作key，當作key時則會有兩種意義或起兩種作用。
我有個表，aid為char型別的。
例如
aid
0314
0314589
0128
0789
031475684
0987
我需要執行一個sql 來找出aid為0314開頭的總數
SELECT COUNT(*) AS count FROM aid_info WHERE aid LIKE '0314%';
aid上有索引，但是還是比較慢。於是我想用短索引提高速度 alter table aid_info add index aid(aid(4));
因為我想如果用4位的短索引，上面的記錄在索引中應該是：
0314
0314
0128
0789
0314
0987
我以為可以更快的找出LIKE '0314%'，但是事實更慢了。我想知道這是為什麼？哪位大師給我講講吧。