mysql之高性能索引
mysql之高性能索引
當db的量達到必定數量級以後，每次進行全表掃描效率就會很低，所以一個常見的方案是創建一些必要的索引做爲優化手段，那麼問題就來了：mysql
- 那麼什麼是索引呢？
- 索引的實現原理是怎樣的？
- 咱們一般說的彙集索引，非彙集索引的區別是什麼？
- 如何建立和使用索引呢？
I. 索引介紹
MySQL官方對索引的定義爲：索引是幫助MySQL高效獲取數據的數據結構。簡而言之,索引是數據結構git
1. 幾種樹的結構
a. B+樹
單來講就是一種爲磁盤或者其餘存儲設備而設計的一種平衡二叉樹,在B+tree中全部記錄都按照key的大小存放在葉子結點上，各葉子結點直接用指針鏈接github
b. 二叉樹
二叉樹的規則是父節點大於左孩子節點，小於右孩子節點算法
c. 平衡二叉樹
首先是一個二叉樹，可是要求任意一個節點的左右孩子節點的高度差不大於1sql
d. B樹
首先是一個平衡二叉樹，可是又要求每一個葉子節點到根節點的距離相等數據庫
那麼B樹和B+樹的區別是什麼呢？緩存
- B+樹的葉子節點能夠包含一個指針，指向另外一個葉子節點
- B+樹鍵值的拷貝存在非葉子節點；鍵值+記錄存儲在葉子節點
2. InnoDB引擎之B+樹
mysql的InnnoDB引擎採用的B+樹，只有葉子節點存儲對應的數據列，有如下好處服務器
- 葉子結點一般包含較多的記錄，具備較高的扇出性(可理解爲每一個節點對應的下層節點較多)，所以樹的高度較低(3~4)，而樹的高度也決定了磁盤IO的次數，從而影響了數據庫的性能。通常狀況下，IO次數與樹的高度是一致的
- 對於組合索引，B+tree索引是按照索引列名(從左到右的順序)進行順序排序的，所以能夠將隨機IO轉換爲順序IO提高IO效率;而且能夠支持order by \group等排序需求;適合範圍查詢
3. hash索引
hash索引，相比較於B樹而言，不須要從根節點到葉子節點的遍歷，能夠一次定位到位置，查詢效率更高，但缺點也很明顯數據結構
- 僅能知足"=","IN"和"<=>"查詢，不能使用範圍查詢
- 由於是經過hash值進行計算，因此只能精確查詢，hash值是沒什麼規律的，不能保證順序和原來一致，因此範圍查詢不行
- 沒法進行排序
- 緣由同上
- 不支持部分索引
- hash值的計算，是根據完整的幾個索引列計算，若是少了其中一個乃至幾個，這個hash值就無法計算了
- hash碰撞
4. 彙集索引與非彙集索引
a. 彙集索引
InnoDB的數據文件自己就是索引文件，B+Tree的葉子節點上的data就是數據自己，key爲主鍵，非葉子節點存放<key,address>，address就是下一層的地址hexo
聚簇索引的結構圖:
b. 非彙集索引
非聚簇索引，葉子節點上的data是主鍵(即聚簇索引的主鍵，因此聚簇索引的key，不能過長)。爲何存放的主鍵，而不是記錄所在地址呢，理由至關簡單，由於記錄所在地址並不能保證必定不會變，但主鍵能夠保證
非聚簇索引結構圖：
從非彙集索引的結構上，能夠看出這種場景下的定位流程：
- 先經過非彙集索引，定位到對應的葉子節點，找到對應的主鍵
- 根據上面找到的主鍵，在彙集索引中，定位到對應的葉子節點（獲取數據）
5. 索引的優勢
- 避免全表掃描（當走不到索引時，就只能一個一個的去匹配；若是走索引，則能夠根據B樹來定位）
- 使用索引能夠幫助服務器避免排序或者臨時表 （葉子節點上的指針，能夠有效的支持範圍查詢；此外葉子節點自己就是根據key進行排序的）
- 索引將隨機IO變成順序IO
6. 適用範圍
索引並非適用於任何狀況。對於中型、大型表適用。對於小型表全表掃描更高效。而對於特大型表，考慮」分區」技術
II. 索引的使用原則
通常咱們在建立表的時候，須要指定primary key, 這樣就能夠肯定彙集索引了，那麼如何添加非彙集索引呢？
1. 索引的幾個語法
建立索引
-- 建立索引
create index `idx_img` on newuser(`img`);
-- 查看
show create table newuser\G;
複製代碼
輸出
show create table newuser\G
*************************** 1. row ***************************
Table: newuser
Create Table: CREATE TABLE `newuser` (
`userId` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '用戶id',
`username` varchar(30) DEFAULT '' COMMENT '用戶登陸名',
`nickname` varchar(30) NOT NULL DEFAULT '' COMMENT '用戶暱稱',
`password` varchar(50) DEFAULT '' COMMENT '用戶登陸密碼 & 密文根式',
`address` text COMMENT '用戶地址',
`email` varchar(50) NOT NULL DEFAULT '' COMMENT '用戶郵箱',
`phone` bigint(20) NOT NULL DEFAULT '0' COMMENT '用戶手機號',
`img` varchar(100) DEFAULT '' COMMENT '用戶頭像',
`extra` text,
`isDeleted` tinyint(1) unsigned NOT NULL DEFAULT '0',
`created` int(11) NOT NULL,
`updated` int(11) NOT NULL,
PRIMARY KEY (`userId`),
KEY `idx_username` (`username`),
KEY `idx_nickname` (`nickname`),
KEY `idx_email` (`email`),
KEY `idx_phone` (`phone`),
KEY `idx_img` (`img`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8
複製代碼
另外一種常見的添加索引方式
alter table newuser add index `idx_extra_img`(`isDeleted`, `img`);
-- 查看索引
show index from newuser;
複製代碼
輸出結果
+---------+------------+---------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+---------+------------+---------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| newuser | 0 | PRIMARY | 1 | userId | A | 3 | NULL | NULL | | BTREE | | |
| newuser | 1 | idx_username | 1 | username | A | 3 | NULL | NULL | YES | BTREE | | |
| newuser | 1 | idx_nickname | 1 | nickname | A | 3 | NULL | NULL | | BTREE | | |
| newuser | 1 | idx_email | 1 | email | A | 3 | NULL | NULL | | BTREE | | |
| newuser | 1 | idx_phone | 1 | phone | A | 3 | NULL | NULL | | BTREE | | |
| newuser | 1 | idx_img | 1 | img | A | 3 | NULL | NULL | YES | BTREE | | |
| newuser | 1 | idx_extra_img | 1 | isDeleted | A | 3 | NULL | NULL | | BTREE | | |
| newuser | 1 | idx_extra_img | 2 | img | A | 3 | NULL | NULL | YES | BTREE | | |
+---------+------------+---------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
複製代碼
刪除索引
drop index `idx_extra_img` on newuser;
drop index `idx_img` on newuser;
-- 查看索引
show index from newuser;
複製代碼
輸出
show index from newuser;
+---------+------------+--------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+---------+------------+--------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| newuser | 0 | PRIMARY | 1 | userId | A | 3 | NULL | NULL | | BTREE | | |
| newuser | 1 | idx_username | 1 | username | A | 3 | NULL | NULL | YES | BTREE | | |
| newuser | 1 | idx_nickname | 1 | nickname | A | 3 | NULL | NULL | | BTREE | | |
| newuser | 1 | idx_email | 1 | email | A | 3 | NULL | NULL | | BTREE | | |
| newuser | 1 | idx_phone | 1 | phone | A | 3 | NULL | NULL | | BTREE | | |
+---------+------------+--------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
複製代碼
強制走索引的一種方式
語法： select * from table force index(索引) where xxx
explain select * from newuser force index(PRIMARY) where userId not in (3, 2, 5);
-- +----+-------------+---------+-------+---------------+---------+---------+------+------+-------------+
-- | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
-- +----+-------------+---------+-------+---------------+---------+---------+------+------+-------------+
-- | 1 | SIMPLE | newuser | range | PRIMARY | PRIMARY | 8 | NULL | 4 | Using where |
-- +----+-------------+---------+-------+---------------+---------+---------+------+------+-------------+
explain select * from newuser where userId not in (3, 2, 5);
-- +----+-------------+---------+------+---------------+------+---------+------+------+-------------+
-- | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
-- +----+-------------+---------+------+---------------+------+---------+------+------+-------------+
-- | 1 | SIMPLE | newuser | ALL | PRIMARY | NULL | NULL | NULL | 3 | Using where |
-- +----+-------------+---------+------+---------------+------+---------+------+------+-------------+
複製代碼
2. 索引使用規則
當一個表內有多個索引時，如何判斷本身的sql是否走到了索引，走的是哪一個索引呢？
能夠經過 explain 關鍵字來進行輔助判斷，固然在實際寫sql時，咱們也有必要了解下索引匹配的規則，避免設置了一些冗餘的索引，或者寫出一些走不到索引的sql
測試的表結構以下
*************************** 1. row ***************************
Table: newuser
Create Table: CREATE TABLE `newuser` (
`userId` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '用戶id',
`username` varchar(30) DEFAULT '' COMMENT '用戶登陸名',
`nickname` varchar(30) NOT NULL DEFAULT '' COMMENT '用戶暱稱',
`password` varchar(50) DEFAULT '' COMMENT '用戶登陸密碼 & 密文根式',
`address` text COMMENT '用戶地址',
`email` varchar(50) NOT NULL DEFAULT '' COMMENT '用戶郵箱',
`phone` bigint(20) NOT NULL DEFAULT '0' COMMENT '用戶手機號',
`img` varchar(100) DEFAULT '' COMMENT '用戶頭像',
`extra` text,
`isDeleted` tinyint(1) unsigned NOT NULL DEFAULT '0',
`created` int(11) NOT NULL,
`updated` int(11) NOT NULL,
PRIMARY KEY (`userId`),
KEY `idx_username` (`username`),
KEY `idx_nickname_email_phone` (`nickname`,`email`,`phone`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8
複製代碼
a. 最左前綴匹配原則
這個主要是針對多列非聚簇索引而言，好比有下面這個索引idx_nickname_email_phone(nickname, email, phone), nickname 定義在email的前面，那麼下面這幾個語句對應的狀況是
-- 走索引
explain select * from newuser where nickname='小灰灰' and email='greywolf@xxx.com';
-- 1. 匹配nickname，能夠走索引
explain select * from newuser where nickname='小灰灰';
-- 輸出:
-- +----+-------------+---------+------+--------------------+--------------------+---------+-------+------+-----------------------+
-- | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
-- +----+-------------+---------+------+--------------------+--------------------+---------+-------+------+-----------------------+
-- | 1 | SIMPLE | newuser | ref | idx_nickname_email | idx_nickname_email | 92 | const | 1 | Using index condition |
-- +----+-------------+---------+------+--------------------+--------------------+---------+-------+------+-----------------------+
-- 2. 雖然匹配了email, 可是不知足最左匹配，不走索引
explain select * from newuser where email='greywolf@xxx.com';
-- 輸出
-- +----+-------------+---------+------+---------------+------+---------+------+------+-------------+
-- | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
-- +----+-------------+---------+------+---------------+------+---------+------+------+-------------+
-- | 1 | SIMPLE | newuser | ALL | NULL | NULL | NULL | NULL | 3 | Using where |
-- +----+-------------+---------+------+---------------+------+---------+------+------+-------------+
複製代碼
b. 沒法跳過某個列使用後續索引列
即對索引idx_nickname_email_phone(nickname, email, phone), 若是你的sql中，只有 nickname 和 phone, 那麼phone走不到索引，由於不能跳過中間的email走索引
c. 範圍查詢後的列沒法使用索引
如 >, <, between, like這種就是範圍查詢，下面的sql中，email 和phone都沒法走到索引，由於nickname使用了範圍查詢
select * from newuser where nickname like '小灰%' and email='greywolf@xxx.com' and phone=15971112301 limit 10;
複製代碼
d. 列做爲函數參數或表達式的一部分
-- 走不到索引
explain select * from newuser where userId+1=2 limit 1;
-- 輸出
-- +----+-------------+---------+------+---------------+------+---------+------+------+-------------+
-- | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
-- +----+-------------+---------+------+---------------+------+---------+------+------+-------------+
-- | 1 | SIMPLE | newuser | ALL | NULL | NULL | NULL | NULL | 3 | Using where |
-- +----+-------------+---------+------+---------------+------+---------+------+------+-------------+
複製代碼
3. 索引缺點
- 雖然索引大大提升了查詢速度，同時卻會下降更新表的速度，如對錶進行INSERT、UPDATE和DELETE。由於更新表時，MySQL不只要保存數據，還要保存一下索引文件。
- 創建索引會佔用磁盤空間的索引文件。通常狀況這個問題不太嚴重，但若是你在一個大表上建立了多種組合索引，索引文件的會膨脹很快。
4. 注意事項
- 索引不會包含有NULL值的列
- 使用短索引
- 索引列排序
- MySQL查詢只使用一個索引，所以若是where子句中已經使用了索引的話，那麼order by中的列是不會使用索引的。所以數據庫默認排序能夠符合要求的狀況下不要使用排序操做；儘可能不要包含多個列的排序，若是須要最好給這些列建立複合索引
- like語句操做
- 通常狀況下不鼓勵使用like操做，若是非使用不可，如何使用也是一個問題。like 「%aaa%」 不會使用索引而like 「aaa%」可使用索引
- 不要在列上進行運算
- select * from users where YEAR(adddate)<2007;
- 儘可能不使用NOT IN和<>操做
5. sql使用策略
a. 使用一個sql代替多個sql
一般建議是使用一個sql來替代多個sql的查詢
固然若sql執行效率很低，或者出現delete等致使鎖表的操做時，也能夠採用多個sql，避免阻塞其餘sql
b. 分解關聯查詢
將關聯join儘可能放在應用中來作，儘可能執行小而簡單的的sql
- 分解後的sql簡單，利於使用mysql緩存
- 執行分解後的sql，減小鎖競爭
- 更好的擴展性和維護性（sql簡單）
- 關聯sql使用的是內嵌循環算法nestloop，而應用中可使用hashmap等結構處理數據，效率更高
c. count
- count(*) 統計的是行數
- count(列名) 統計的是列不爲null的數量
d. limit
- limit offset, size; 分頁查詢，會查詢出 offset + size 條數據，獲取最後的size條數據
如 limit 1000, 20 則會查詢出知足條件的1020條數據，而後將最後的20個返回，因此儘可能避免大翻頁查詢
e. union
須要將where、order by、limit 這些限制放入到每一個子查詢，才能重分提高效率。另外如非必須，儘可能使用Union all，由於union會給每一個子查詢的臨時表加入distinct，對每一個臨時表作惟一性檢查，效率較差。
6. mysql使用查詢
a. 查看索引
-- 單位爲GB
SELECT CONCAT(ROUND(SUM(index_length)/(1024*1024*1024), 6), ' GB') AS 'Total Index Size'
FROM information_schema.TABLES WHERE table_schema LIKE 'databaseName';
複製代碼
b. 查看錶空間
SELECT CONCAT(ROUND(SUM(data_length)/(1024*1024*1024), 6), ' GB') AS 'Total Data Size'
FROM information_schema.TABLES WHERE table_schema LIKE 'databaseName';
複製代碼
c. 查看數據庫中全部表的信息
SELECT CONCAT(table_schema,'.',table_name) AS 'Table Name',
table_rows AS 'Number of Rows',
CONCAT(ROUND(data_length/(1024*1024*1024),6),' G') AS 'Data Size',
CONCAT(ROUND(index_length/(1024*1024*1024),6),' G') AS 'Index Size' ,
CONCAT(ROUND((data_length+index_length)/(1024*1024*1024),6),' G') AS'Total'
FROM information_schema.TABLES
WHERE table_schema LIKE 'databaseName';
複製代碼
IV. 其餘
參考
我的博客： 一灰灰Blog
基於hexo + github pages搭建的我的博客，記錄全部學習和工做中的博文，歡迎你們前去逛逛
聲明
盡信書則不如，已上內容，純屬一家之言，因本人能力通常，見識有限，如發現bug或者有更好的建議，隨時歡迎批評指正
- 微博地址: 小灰灰Blog
- QQ： 一灰灰/3302797840
掃描關注
相關文章
- 1. Mysql之高性能索引
- 2. MySQL之高性能索引
- 3. MySQL探索之路——高性能索引
- 4. 高性能MYSQL--索引（三）
- 5. 高性能MYSQL---索引（一）
- 6. Mysql-高性能索引
- 7. MySQL 高性能索引
- 8. 高性能的MySQL索引
- 9. 高性能MySQL之--聚簇索引
- 10. Mysql之高性能的索引策略
- 更多相關文章...
- • MySQL索引簡介 - MySQL教程
- • MySQL創建索引（CREATE INDEX） - MySQL教程
- • 互聯網組織的未來：剖析GitHub員工的任性之源
- • 漫談MySQL的鎖機制
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
歡迎關注本站公眾號,獲取更多信息
相關文章
- 1. Mysql之高性能索引
- 2. MySQL之高性能索引
- 3. MySQL探索之路——高性能索引
- 4. 高性能MYSQL--索引（三）
- 5. 高性能MYSQL---索引（一）
- 6. Mysql-高性能索引
- 7. MySQL 高性能索引
- 8. 高性能的MySQL索引
- 9. 高性能MySQL之--聚簇索引
- 10. Mysql之高性能的索引策略