Mysql索引詳解及優化(key和index區別)

MySQL索引的概念
    索引是一種特殊的文件(InnoDB數據表上的索引是表空間的一個組成部分)，它們包含着對數據表裏全部記錄的引用指針。更通俗的說，數據庫索引比如是一本書前面的目錄，能加快數據庫的查詢速度。
    索引分爲聚簇索引和非聚簇索引兩種，聚簇索引是按照數據存放的物理位置爲順序的，而非聚簇索引就不同了；聚簇索引能提升多行檢索的速度，而非聚簇索引對於單行的檢索很快
    要注意的是，創建太多的索引將會影響更新和插入的速度，由於它須要一樣更新每一個索引文件。對於一個常常須要更新和插入的表格，就沒有必要爲一個不多使用的where字句單獨創建索引了，對於比較小的表，排序的開銷不會很大，也沒有必要創建另外的索引。

1. 普通索引

    普通索引(由關鍵字KEY或INDEX定義的索引)的惟一任務是加快對數據的訪問速度。所以，應該只爲那些最常常出如今查詢條件(WHERE column = ...)或排序條件(ORDER BY column)中的數據列建立索引。只要有可能，就應該選擇一個數據最整齊、最緊湊的數據列(如一個整數類型的數據列)來建立索引。 

–直接建立索引(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將拒絕插入那條新記錄。也就是說，惟一索引能夠保證數據記錄的惟一性。事實上，在許多場合，人們建立惟一索引的目的每每不是爲了提升訪問速度，而只是爲了不數據出現重複。 

–建立惟一索引
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就會定義一個內部索引來幫助本身以最有效率的方式去管理和使用外鍵約束條件。 

5. 全文索引（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字段裏有word一、word2和word3的數據記錄所有查詢出來。 

–建立表的適合添加全文索引
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只能使用一個索引，會從多個索引中選擇一個限制最爲嚴格的索引。

5. 組合(複合)索引（最左前綴）

    平時用的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索引的注意事項和優化方法。

1. 什麼時候使用匯集索引或非彙集索引？

動做描述	使用匯集索引	使用非彙集索引
列常常被分組排序	使用	使用
返回某範圍內的數據	使用	不使用
一個或極少不一樣值	不使用	不使用
小數目的不一樣值	使用	不使用
大數目的不一樣值	不使用	使用
頻繁更新的列	不使用	使用
外鍵列	使用	使用
主鍵列	使用	使用
頻繁修改索引列	不使用	使用

2. 索引不會包含有NULL值的列

    只要列中包含有NULL值都將不會被包含在索引中，複合索引中只要有一列含有NULL值，那麼這一列對於此複合索引就是無效的。因此咱們在數據庫設計時不要讓字段的默認值爲NULL。

3. 使用短索引

    對串列進行索引，若是可能應該指定一個前綴長度。例如，若是有一個CHAR(255)的列，若是在前10個或20個字符內，多數值是唯一的，那麼就不要對整個列進行索引。短索引不只能夠提升查詢速度並且能夠節省磁盤空間和I/O操做。

4. 索引列排序

    MySQL查詢只使用一個索引，所以若是where子句中已經使用了索引的話，那麼order by中的列是不會使用索引的。所以數據庫默認排序能夠符合要求的狀況下不要使用排序操做；儘可能不要包含多個列的排序，若是須要最好給這些列建立複合索引。

5. like語句操做

    通常狀況下不鼓勵使用like操做，若是非使用不可，如何使用也是一個問題。like 「%aaa%」 不會使用索引而like 「aaa%」可使用索引。

6. 不要在列上進行運算

    例如：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%'，可是事實更慢了。我想知道這是爲何？哪位大師給我講講吧。

原文連接:https://www.cnblogs.com/jianmingyuan/p/6740090.html