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字段里有word1、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