mysql數據庫索引相關

時間 2019-11-13

原文原文鏈接

一介紹

什麼是索引？

索引在MySQL中也叫作「鍵」，是存儲引擎用於快速找到記錄的一種數據結構。索引對於良好的性能
很是關鍵，尤爲是當表中的數據量愈來愈大時，索引對於性能的影響愈發重要。
索引優化應該是對查詢性能優化最有效的手段了。索引可以輕易將查詢性能提升好幾個數量級。
索引至關於字典的音序表，若是要查某個字，若是不使用音序表，則須要從幾百頁中逐頁去查。html

（建索引是讓mysql提供的一種數據結構）mysql

索引相關看法

索引是應用程序設計和開發的一個重要方面。若索引太多，應用程序的性能可能會受到影響。而索引太少，對查詢性能又會產生影響，要找到一個平衡點，這對應用程序的性能相當重要。一些開發人員老是在過後纔想起添加索引----我一直認爲，這源於一種錯誤的開發模式。若是知道數據的使用，從一開始就應該在須要處添加索引。開發人員每每對數據庫的使用停留在應用的層面，好比編寫SQL語句、存儲過程之類，他們甚至可能不知道索引的存在，或認爲過後讓相關DBA加上便可。DBA每每不夠了解業務的數據流，而添加索引須要經過監控大量的SQL語句進而從中找到問題，這個步驟所需的時間確定是遠大於初始添加索引所需的時間，而且可能會遺漏一部分的索引。固然索引也並非越多越好，我曾經遇到過這樣一個問題：某臺MySQL服務器iostat顯示磁盤使用率一直處於100%，通過分析後發現是因爲開發人員添加了太多的索引，在刪除一些沒必要要的索引以後，磁盤使用率立刻降低爲20%。可見索引的添加也是很是有技術含量的。ios

2、索引的原理

索引的目的在於提升查詢效率。sql

本質：經過不斷的縮小想要獲取數據的範圍來篩選出最終想要的結果，同時把隨機的事件變成順序的事件，也就是，有了這種索引機制，咱們能夠老是用同一種查找方式來鎖定數據。數據庫

3、索引的數據結構

須要這種數據結構可以作些什麼，其實很簡單，那就是：每次查找數據時把磁盤IO次數控制在一個很小的數量級，最好是常數數量級。那麼咱們就想到若是一個高度可控的多路搜索樹是否能知足需求呢？就這樣，b+樹應運而生（B+樹是經過二叉查找樹，再由平衡二叉樹，B樹演化而來）。vim

如上圖，是一顆b+樹，關於b+樹的定義能夠參見B+樹，這裏只說一些重點，淺藍色的塊咱們稱之爲一個磁盤塊，能夠看到每一個磁盤塊包含幾個數據項（深藍色所示）和指針（黃色所示），如磁盤塊1包含數據項17和35，包含指針P一、P二、P3，P1表示小於17的磁盤塊，P2表示在17和35之間的磁盤塊，P3表示大於35的磁盤塊。真實的數據存在於葉子節點即三、五、九、十、1三、1五、2八、2九、3六、60、7五、7九、90、99。非葉子節點只不存儲真實的數據，只存儲指引搜索方向的數據項，如1七、35並不真實存在於數據表中。性能優化

b+樹的查找過程
如圖所示，若是要查找數據項29，那麼首先會把磁盤塊1由磁盤加載到內存，此時發生一次IO，在內存中用二分查找肯定29在17和35之間，鎖定磁盤塊1的P2指針，內存時間由於很是短（相比磁盤的IO）能夠忽略不計，經過磁盤塊1的P2指針的磁盤地址把磁盤塊3由磁盤加載到內存，發生第二次IO，29在26和30之間，鎖定磁盤塊3的P2指針，經過指針加載磁盤塊8到內存，發生第三次IO，同時內存中作二分查找找到29，結束查詢，總計三次IO。真實的狀況是，3層的b+樹能夠表示上百萬的數據，若是上百萬的數據查找只須要三次IO，性能提升將是巨大的，若是沒有索引，每一個數據項都要發生一次IO，那麼總共須要百萬次的IO，顯然成本很是很是高。

b+樹的查找過程

b+樹性質
1.索引字段要儘可能的小：經過上面的分析，咱們知道IO次數取決於b+數的高度h，假設當前數據表的數據爲N，每一個磁盤塊的數據項的數量是m，則有h=㏒(m+1)N，當數據量N必定的狀況下，m越大，h越小；而m = 磁盤塊的大小 / 數據項的大小，磁盤塊的大小也就是一個數據頁的大小，是固定的，若是數據項佔的空間越小，數據項的數量越多，樹的高度越低。這就是爲何每一個數據項，即索引字段要儘可能的小，好比int佔4字節，要比bigint8字節少一半。這也是爲何b+樹要求把真實的數據放到葉子節點而不是內層節點，一旦放到內層節點，磁盤塊的數據項會大幅度降低，致使樹增高。當數據項等於1時將會退化成線性表。
2.索引的最左匹配特性：當b+樹的數據項是複合的數據結構，好比(name,age,sex)的時候，b+數是按照從左到右的順序來創建搜索樹的，好比當(張三,20,F)這樣的數據來檢索的時候，b+樹會優先比較name來肯定下一步的所搜方向，若是name相同再依次比較age和sex，最後獲得檢索的數據；但當(20,F)這樣的沒有name的數據來的時候，b+樹就不知道下一步該查哪一個節點，由於創建搜索樹的時候name就是第一個比較因子，必需要先根據name來搜索才能知道下一步去哪裏查詢。好比當(張三,F)這樣的數據來檢索時，b+樹能夠用name來指定搜索方向，但下一個字段age的缺失，因此只能把名字等於張三的數據都找到，而後再匹配性別是F的數據了， 這個是很是重要的性質，即索引的最左匹配特性。

b+樹性質

b+樹性質服務器

一、索引字段要儘可能的小數據結構

二、索引的最左匹配特性ide

3、常見的索引

索引分類:

一、普通索引INDEX：加速查找

　　惟一索引：
二、-主鍵索引PRIMARY KEY：加速查找+約束（不爲空、不能重複）
三、-惟一索引UNIQUE:加速查找+約束（不能重複）
四、-組合索引

　　組合索引是將n個列組合成一個索引

create table in3(
    nid int not null auto_increment primary key,
    name varchar(32) not null,
    email varchar(64) not null,
    extra text
)

建立表

建立組合索引

5、聯合索引：

    -PRIMARY KEY(id,name):聯合主鍵索引
    -UNIQUE(id,name):聯合惟一索引
    -INDEX(id,name):聯合普通索引

除此以外還有全文索引，即FULLTEXT，但其實對於全文搜索，咱們並不會使用MySQL自帶的該索引，而是會選擇第三方軟件如Sphinx，專門來作全文搜索。

2、索引類型

　　索引主要包括hash和btree兩大類型，咱們在建立索引時能夠爲其指定索引類型。其中hash類型的索引：查詢單條快，範圍查詢慢；btree類型的索引：b+樹，層數越多，數據量指數級增加（咱們就用它，由於innodb默認支持它）

#不一樣的存儲引擎支持的索引類型也不同
InnoDB 支持事務，支持行級別鎖定，支持 B-tree、Full-text 等索引，不支持 Hash 索引；
MyISAM 不支持事務，支持表級別鎖定，支持 B-tree、Full-text 等索引，不支持 Hash 索引；
Memory 不支持事務，支持表級別鎖定，支持 B-tree、Hash 等索引，不支持 Full-text 索引；
NDB 支持事務，支持行級別鎖定，支持 Hash 索引，不支持 B-tree、Full-text 等索引；
Archive 不支持事務，支持表級別鎖定，不支持 B-tree、Hash、Full-text 等索引；

3、建立與刪除索引

一、在建立表時建立索引

create table t1(
    id int,
    name char(5),
    age int,
    unique key uni_name(name),    # uni_name  爲索引名      
    index index_age(age),         # index_age 爲索引名，不須要key
    primary key(id)               # primary 不須要起索引名，起了也不顯示     
     );

二、建立完表後爲其添加索引

三、刪除索引

drop index indx_id on t3;

alter table t3 drop primary key;

　　上述第一個刪除語法中，因primary key 沒有名字，因此刪除方式爲：drop index ‘primary’ on t3，其餘有名字的索引刪除方式爲：drop index 索引名 on 表名

4、測試索引

　　按照以下sql語句建立表s1，後續全部測試均基於此表：

#1. 準備表
create table s1(
id int,
name varchar(20),
gender char(6),
email varchar(50)
);

#2. 建立存儲過程，實現批量插入記錄
delimiter $$ #聲明存儲過程的結束符號爲$$
create procedure auto_insert1()
BEGIN
    declare i int default 1;
    while(i<3000000)do
        insert into s1 values(i,'egon','male',concat('egon',i,'@oldboy'));
        set i=i+1;
    end while;
END$$ #$$結束
delimiter ; #從新聲明分號爲結束符號

#3. 查看存儲過程
show create procedure auto_insert1\G 

#4. 調用存儲過程
call auto_insert1();

一、加索引能夠加快查詢效率，可是會下降寫的效率

5、正確使用索引

　　但咱們必須知道，並非說咱們建立了索引就必定會加快查詢速度，若想利用索引達到預想的提升查詢速度的效果，咱們在添加索引時，必須遵循如下問題。

一、範圍問題，或者說條件不明確，條件中出現這些符號或關鍵字：>、>=、<、<=、!= 、between...and...、like

　　大於小於

不等於

between...and

二、儘可能選擇區分度高的字段做爲索引，區分度是指的字段中數據的重複性，越重複，區分度變低

咱們編寫存儲過程爲表s1批量添加記錄，name字段的值均爲egon，也就是說name這個字段的區分度很低（gender字段也是同樣的，咱們稍後再搭理它）

回憶b+樹的結構，查詢的速度與樹的高度成反比，要想將樹的高低控制的很低，須要保證：在某一層內數據項均是按照從左到右，從小到大的順序依次排開，即左1<左2<左3<...

而對於區分度低的字段，沒法找到大小關係，由於值都是相等的，毫無疑問，還想要用b+樹存放這些等值的數據，只能增長樹的高度，字段的區分度越低，則樹的高度越高。極端的狀況，索引字段的值都同樣，那麼b+樹幾乎成了一根棍。本例中就是這種極端的狀況，name字段全部的值均爲'egon'

#如今咱們得出一個結論：爲區分度低的字段創建索引，索引樹的高度會很高，然而這具體會帶來什麼影響呢？？？

#1：若是條件是name='xxxx',那麼確定是能夠第一時間判斷出'xxxx'是不在索引樹中的（由於樹中全部的值均爲'egon’），因此查詢速度很快

#2：若是條件正好是name='egon',查詢時，咱們永遠沒法從樹的某個位置獲得一個明確的範圍，只能往下找，往下找，往下找。。。這與全表掃描的IO次數沒有多大區別，因此速度很慢

三、索引字段不能夠參與計算

and or

#注意：
條件1 and 條件2:查詢原理是：首先條件1與條件2都成立的前提下，纔算匹配成功一條記錄；其次mysql會按先優先判斷索引字段的條件,若是按照該條件爲真，但鎖定的範圍很小，或者乾脆爲假，那咱們即使是沒有爲其餘條件的字段添加索引，最終的結果仍然很快

#例如：
若條件1的字段有索引，而條件2的字段沒有索引，那麼若是在按照條件1查出的結果不多的狀況下，即使咱們沒有爲條件2建立索引，最終的查詢速度依然很快

若條件1的字段沒有索引，而條件2的字段有索引，那麼若是在按照條件2查出的結果不多的狀況下，即使咱們沒有爲條件1建立索引，最終的查詢速度依然很快

在左邊條件成立可是索引字段的區分度低的狀況下（name與gender均屬於這種狀況），會依次往右找到一個區分度高的索引字段，加速查詢

通過分析，在條件爲name='egon' and gender='male' and id>333 and email='xxx'的狀況下，咱們徹底不必爲前三個條件的字段加索引，由於只能用上email字段的索引，前三個字段的索引反而會下降咱們的查詢效率。

五、最左前綴匹配原則，很是重要的原則，對於組合索引mysql會一直向右匹配直到遇到範圍查詢(>、<、between、like)就中止匹配(指的是範圍大了，有索引速度也慢)，好比a = 1 and b = 2 and c > 3 and d = 4 若是創建(a,b,c,d)順序的索引，d是用不到索引的，若是創建(a,b,d,c)的索引則均可以用到，a,b,d的順序能夠任意調整。

六、其餘狀況

- 使用函數
    select * from tb1 where reverse(email) = 'egon';
            
- 類型不一致
    若是列是字符串類型，傳入條件是必須用引號引發來，否則...
    select * from tb1 where email = 999;
    
#排序條件爲索引，則select字段必須也是索引字段，不然沒法命中
- order by
    select name from s1 order by email desc;
    當根據索引排序時候，select查詢的字段若是不是索引，則速度仍然很慢
    select email from s1 order by email desc;
    特別的：若是對主鍵排序，則仍是速度很快：
        select * from tb1 order by nid desc;
 
- 組合索引最左前綴
    若是組合索引爲：(name,email)
    name and email       -- 命中索引
    name                 -- 命中索引
    email                -- 未命中索引


- count(1)或count(列)代替count(*)在mysql中沒有差異了

- create index xxxx  on tb(title(19)) #text類型，必須制定長度

- 避免使用select *
- count(1)或count(列) 代替 count(*)
- 建立表時儘可能時 char 代替 varchar
- 表的字段順序固定長度的字段優先
- 組合索引代替多個單列索引（常用多個條件查詢時）
- 儘可能使用短索引
- 使用鏈接（JOIN）來代替子查詢(Sub-Queries)
- 連表時注意條件類型需一致
- 索引散列值（重複少）不適合建索引，例：性別不適合

6、索引合併與覆蓋

一、索引合併

#覆蓋索引：
    - 全部字段（條件的，查詢結果的等）都是索引字段
    http://blog.itpub.net/22664653/viewspace-774667/

#分析
select age from s1 where id=123 and name = 'egon'; #id字段有索引，可是name字段沒有索引
該sql命中了索引，但未覆蓋所有。
利用id=123到索引的數據結構中定位到了id字段，可是仍要判斷name字段，可是name字段沒有索引，並且查詢結果的字段age也沒有索引
最牛逼的狀況是，索引字段覆蓋了全部，那全程經過索引來加速查詢以及獲取結果就ok了

7、查詢優化神器explain

　　關於explain命令相信你們並不陌生，具體用法和字段含義能夠參考官網explain-output，這裏須要強調rows是核心指標，絕大部分rows小的語句執行必定很快（有例外，下面會講到）。因此優化語句基本上都是在優化rows。

8、慢日誌管理

慢日誌
            - 執行時間 > 10
            - 未命中索引
            - 日誌文件路徑
            
        配置：
            - 內存
                show variables like '%query%';
                show variables like '%queries%';
                set global 變量名 = 值
            - 配置文件
                mysqld --defaults-file='E:\wupeiqi\mysql-5.7.16-winx64\mysql-5.7.16-winx64\my-default.ini'
                
                my.conf內容：
                    slow_query_log = ON
                    slow_query_log_file = D:/....
                    
                注意：修改配置文件以後，須要重啓服務

View Code

MySQL日誌管理
========================================================
錯誤日誌: 記錄 MySQL 服務器啓動、關閉及運行錯誤等信息
二進制日誌: 又稱binlog日誌，以二進制文件的方式記錄數據庫中除 SELECT 之外的操做
查詢日誌: 記錄查詢的信息
慢查詢日誌: 記錄執行時間超過指定時間的操做
中繼日誌： 備庫將主庫的二進制日誌複製到本身的中繼日誌中，從而在本地進行重放
通用日誌： 審計哪一個帳號、在哪一個時段、作了哪些事件
事務日誌或稱redo日誌： 記錄Innodb事務相關的如事務執行時間、檢查點等
========================================================
1、bin-log
1. 啓用
# vim /etc/my.cnf
[mysqld]
log-bin[=dir\[filename]]
# service mysqld restart
2. 暫停
//僅當前會話
SET SQL_LOG_BIN=0;
SET SQL_LOG_BIN=1;
3. 查看
查看所有：
# mysqlbinlog mysql.000002
按時間：
# mysqlbinlog mysql.000002 --start-datetime="2012-12-05 10:02:56"
# mysqlbinlog mysql.000002 --stop-datetime="2012-12-05 11:02:54"
# mysqlbinlog mysql.000002 --start-datetime="2012-12-05 10:02:56" --stop-datetime="2012-12-05 11:02:54" 

按字節數：
# mysqlbinlog mysql.000002 --start-position=260
# mysqlbinlog mysql.000002 --stop-position=260
# mysqlbinlog mysql.000002 --start-position=260 --stop-position=930
4. 截斷bin-log（產生新的bin-log文件）
a. 重啓mysql服務器
b. # mysql -uroot -p123 -e 'flush logs'
5. 刪除bin-log文件
# mysql -uroot -p123 -e 'reset master' 


2、查詢日誌
啓用通用查詢日誌
# vim /etc/my.cnf
[mysqld]
log[=dir\[filename]]
# service mysqld restart

3、慢查詢日誌
啓用慢查詢日誌
# vim /etc/my.cnf
[mysqld]
log-slow-queries[=dir\[filename]]
long_query_time=n
# service mysqld restart
MySQL 5.6:
slow-query-log=1
slow-query-log-file=slow.log
long_query_time=3
查看慢查詢日誌
測試:BENCHMARK(count,expr)
SELECT BENCHMARK(50000000,2*3);

日誌管理