day041MySQL之索引原理與慢查詢優化，explain
阿新 • • 發佈：2018-12-16
本節內容：
1、介紹
2、索引的原理（目的：加速查詢）
3、索引的資料結構
4、聚集索引與輔助索引
5、MySQL索引管理
6、測試索引
7、正確使用索引
8、聯合索引與覆蓋索引
9、查詢優化神器--explain
10、慢查詢優化的基本步驟
11、慢日誌管理
一、介紹
1、什麼是索引
索引在MySQL中也叫做“鍵”或者"key"（primary key，unique key，還有一個index key），
是儲存引擎用於快速找到記錄的一種資料結構。
2、為什麼要有索引
一般的應用系統，讀寫比例在10:1左右, 我們更多的是需要去查詢，還有一些複雜的查詢操作， 因此對查詢語句的優化顯然是重中之重。 說起加速查詢，就不得不提到索引了。
3、索引的作用（加速查詢）
索引對於良好的效能非常關鍵，尤其是當表中的資料量越來越大時，
索引對於效能的影響愈發重要，減少io次數，加速查詢。
4、正確使用索引
1、建立索引的量要合理，
若索引太多，應用程式的效能可能會受到影響。
而索引太少，對查詢效能又會產生影響，
要找到一個平衡點，這對應用程式的效能至關重要。
不要建立太多索引，有些索引是沒有必要。
2、最好一開始就應該建立索引
如果知道資料的使用，從一開始就應該在需要處新增索引。 在建立的時候，你就要構思對資料的查詢，建立好良好的索引， 以應對後面的大資料，複雜資料查詢； 這就要求你對業務的資料流的瞭解。
二、索引的原理
1、索引的原理
索引的目的：提高查詢效率，加快查詢；
缺點：1.會降低寫入的效率，
（因為你但凡加入一些新的資料，都需要把索引或者說書的目錄重新做一個。）
2.在表中有大量資料的前提下，建立索引速度會很慢
2、磁碟IO與預讀
1、磁碟IO
磁碟讀取資料靠的是機械運動 每次讀取資料的時間組成：尋道時間、旋轉時間、傳輸時間 尋道時間：指的是磁臂移動到指定磁軌所需要的時間，主流磁碟一般在5ms以下 旋轉延遲：就是我們經常聽說的磁碟轉速，4.17m/s 傳輸時間：指的是從磁碟讀出或將資料寫入磁碟的時間，一般在零點幾毫秒，相對於前兩個時間可以忽略不計。 那麼訪問一次磁碟的時間，即一次磁碟IO的時間約等於5+4.17 = 9ms左右 但要知道一臺500 -MIPS（Million Instructions Per Second）的機器每秒可以執行5億條指令 這裡已經是對cpu的嚴重浪費了。 資料庫動輒十萬百萬乃至千萬級資料，每次9毫秒的時間，顯然是個災難，
2、預讀
考慮到磁碟IO是非常高昂的操作，計算機作業系統做了一些優化，
當一次IO時，不光把當前磁碟地址的資料，而是把相鄰的資料也都讀取到記憶體緩衝區內，
因為區域性預讀性原理告訴我們，當計算機訪問一個地址的資料的時候，與其相鄰的資料也會很快被訪問到。
三、索引的資料結構
前面講了索引的基本原理，資料庫的複雜性，又講了作業系統的相關知識，
目的就是讓大家瞭解，現在我們來看看索引怎麼做到減少IO，加速查詢的。
任何一種資料結構都不是憑空產生的，一定會有它的背景和使用場景，
知道的具體的使用場景；我們就根據使用需求，來控制查詢資料的IO
那就是：每次查詢資料時把磁碟IO次數控制在一個很小的數量級，最好是常數數量級。
b+樹應運而生
B+樹是通過二叉查詢樹，再由平衡二叉樹，B樹演化而來，等到後面講演算法的時候再深入，
1、b+樹，相關介紹
如上圖，是一顆b+樹，最上層是樹根，中間的是樹枝，最下面是葉子節點，
淺藍色的塊我們稱之為一個磁碟塊或者叫做一個block塊，
這是作業系統一次IO往記憶體中讀的內容，一個塊對應四個扇區，
可以看到每個磁碟塊包含幾個資料項
（深藍色所示，一個磁碟塊裡面包含多少資料，一個深藍色的塊表示一個數據，其實不是資料，後面有解釋）
和指標（黃色所示，看最上面一個，
p1表示比上面深藍色的那個17小的資料的位置在哪，
看它指標指向的左邊那個塊，裡面的資料都比17小，
p2指向的是比17大比35小的磁碟塊），
真實的資料存在於葉子節點即3、5、9、10、13、15、28、29、36、60、75、79、90、99。
非葉子節點只不儲存真實的資料，只儲存指引搜尋方向的資料項，如17、35並不真實存在於資料表中。
2、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+樹的性質
1.索引欄位要儘量的小：
好處：
可以多存資料，比如int佔4位元組，要比bigint8位元組少一半。
防止樹增高，太大還可能導致退化成線性表。
2.索引的最左匹配特性：
從資料塊的左邊開始匹配，再匹配右邊的，
當b+樹的資料項是複合的資料結構，比如(name,age,sex)的時候，
b+樹是按照從左到右的順序來建立搜尋樹的，
四、聚集索引和輔助索引
聚集索引是什麼呢，其實就是我們說的那個主鍵，
之前我們說Innodb儲存引擎的表，必須有一個主鍵，
資料庫中的B+樹索引可以分為聚集索引（clustered index）和輔助索引（secondary index），
在資料庫中，B+樹的高度一般都在2~4層，
這也就是說查詢某一個鍵值的行記錄時最多隻需要2到4次IO，這倒不錯。
因為當前一般的機械硬碟每秒至少可以做100次IO，
2~4次的IO意味著查詢時間只需要0.02~0.04秒。
聚集索引與輔助索引不同的是：葉子結點存放的是否是一整行的資訊
1、聚集索引（葉子節點存放著,行記錄資料）
InnoDB儲存引擎表示索引組織表，即表中資料按照主鍵順序存放。
而聚集索引（clustered index）就是按照每張表的主鍵構造一棵B+樹，
同時葉子結點存放的即為整張表的行記錄資料，也將聚集索引的葉子結點稱為資料頁。
1、聚集索引的優點
1.它對主鍵的排序查詢和範圍查詢速度非常快，
葉子節點的資料就是使用者所要查詢的資料。
如使用者需要查詢一張表，查詢最後的10位使用者資訊，由於B+樹索引是雙向連結串列，
所以使用者可以快速找到最後一個數據頁，並取出10條記錄
2.範圍查詢（range query），
即如果要查詢主鍵某一範圍內的資料，通過葉子節點的上層中間節點就可以得到頁的範圍，
之後直接讀取資料頁即可
2、輔助索引（通過條件來查詢）
表中除了聚集索引外其他索引都是輔助索引（Secondary Index，也稱為非聚集索引）
（unique key啊、index key啊），
與聚集索引的區別是：輔助索引的葉子節點不包含行記錄的全部資料。
就是我們在查詢的時候，where後面需要寫id之外的其他欄位名稱來進行查詢，
葉子節點存放的是對應的那條資料的主鍵欄位的值，
除了包含鍵值以外，每個葉子節點中的索引行中還包含一個書籤（bookmark），
其實這個書籤你可以理解為是一個{'name欄位'，name的值，主鍵id值}的這麼一個數據。
如果我們select 後面要的是name，我們直接就可以在輔助索引的葉子節點找到對應的name值，
這種我們也可以稱為覆蓋索引。
回表操作，
需要通過輔助索引的葉子節點中儲存的主鍵id的值再去通過聚集索引來找到完整的一條記錄，
然後從這個記錄裡面拿出age的值，
五、MySQL索引管理
1、功能
1. 索引的功能就是加速查詢
2. mysql中的primary key，unique，聯合唯一也都是索引，
這些索引除了加速查詢以外，還有約束的功能
2、MySQL常用的索引
普通索引INDEX：加速查詢
唯一索引：
-主鍵索引PRIMARY KEY：加速查詢+約束（不為空、不能重複）
-唯一索引UNIQUE:加速查詢+約束（不能重複）
聯合索引：
-PRIMARY KEY(id,name):聯合主鍵索引
-UNIQUE(id,name):聯合唯一索引
-INDEX(id,name):聯合普通索引
fe:各種索引的應用場景
各種索引的應用場景舉個例子來說，比如你在為某商場做一個會員卡的系統。
這個系統有一個會員表
有下列欄位：
會員編號 INT
會員姓名 VARCHAR(10)
會員身份證號碼 VARCHAR(18)
會員電話 VARCHAR(10) 會員住址 VARCHAR(50) 會員備註資訊 TEXT 那麼這個 會員編號，作為主鍵，使用 PRIMARY 會員姓名 如果要建索引的話，那麼就是普通的 INDEX 會員身份證號碼 如果要建索引的話，那麼可以選擇 UNIQUE （唯一的，不允許重複） #除此之外還有全文索引，即FULLTEXT 會員備註資訊 ， 如果需要建索引的話，可以選擇全文搜尋。 用於搜尋很長一篇文章的時候，效果最好。 用在比較短的文字，如果就一兩行字的，普通的 INDEX 也可以。 但其實對於全文搜尋，我們並不會使用MySQL自帶的該索引， 而是會選擇第三方軟體如Sphinx，專門來做全文搜尋。 #其他的如空間索引SPATIAL，瞭解即可，幾乎不用 3、索引的兩大型別hash與btree
1、兩大索引型別
我們可以在建立上述索引的時候，為其指定索引型別，分兩類
hash型別的索引：查詢單條快，範圍查詢慢
btree型別的索引：b+樹，層數越多，資料量指數級增長（我們就用它，因為innodb預設支援它）
2、不同的儲存引擎支援的索引型別也不一樣
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 等索引；
4、建立/刪除索引的語法
#方法一：建立表時
CREATE TABLE 表名 (
欄位名1 資料型別 [完整性約束條件…],
欄位名2 資料型別 [完整性約束條件…],
[UNIQUE | FULLTEXT | SPATIAL ] INDEX | KEY
[索引名] (欄位名[(長度)] [ASC |DESC])
);
#方法二：CREATE在已存在的表上建立索引
CREATE [UNIQUE | FULLTEXT | SPATIAL ] INDEX 索引名
ON 表名 (欄位名[(長度)] [ASC |DESC]) ;
#方法三：ALTER TABLE在已存在的表上建立索引
ALTER TABLE 表名 ADD [UNIQUE | FULLTEXT | SPATIAL ] INDEX
索引名 (欄位名[(長度)] [ASC |DESC]) ;
#刪除索引：DROP INDEX 索引名 ON 表名字;
fe:建立/刪除索引的具體示例
建立/刪除索引的具體示例#方式一
create table t1(
id int,
name char,
age int,
sex enum('male','female'), unique key uni_id(id), index ix_name(name) #index沒有key ); #方式二 create index ix_age on t1(age); #方式三 alter table t1 add index ix_sex(sex); #檢視 mysql> show create table t1; | t1 | CREATE TABLE `t1` ( `id` int(11) DEFAULT NULL, `name` char(1) DEFAULT NULL, `age` int(11) DEFAULT NULL, `sex` enum('male','female') DEFAULT NULL, UNIQUE KEY `uni_id` (`id`), KEY `ix_name` (`name`), KEY `ix_age` (`age`), KEY `ix_sex` (`sex`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 六、測試索引
1、準備，建立一個300萬的資料庫
準備表#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(); 2、在沒有索引的前提下測試查詢速度
#無索引：mysql根本就不知道到底是否存在id等於333333333的記錄，
也不知道存在幾條id=333333333的記錄，只能把資料表從頭到尾掃描一遍，
此時有多少個磁碟塊就需要進行多少IO操作，所以查詢速度很慢
mysql> select * from s1 where id=333333333;
Empty set (0.33 sec)
3、在表中已經存在大量資料的前提下，為某個欄位段建立索引，建立速度會很慢
在表中已經存在大量資料的前提下，
為某個欄位段建立索引，建立速度會很慢
或者用alter table s1 add primary key(id);加主鍵，建索引很慢的。
4、在索引建立完畢後，以該欄位為查詢條件時，查詢速度提升明顯
1. mysql先去索引表裡根據b+樹的搜尋原理很快搜索到id等於333333333的記錄不存在，
IO大大降低，因而速度明顯提升
2. 我們可以去mysql的data目錄下找到該表，可以看到佔用的硬碟空間多了
3. 需要注意，用沒有加索引的欄位去查詢，速度依然很慢
5、總結
1. 一定是為搜尋條件的欄位建立索引，
比如select * from s1 where id = 333;就需要為id加上索引
2. 在表中已經有大量資料的情況下，建索引會很慢，且佔用硬碟空間，
建完後查詢速度加快
3. 需要注意的是：innodb表的索引會存放於s1.ibd檔案中，
而myisam表的索引則會有單獨的索引檔案table1.MYI
七、正確使用索引
並不是說我們建立了索引就一定會加快查詢速度，
若想利用索引達到預想的提高查詢速度的效果，
我們在新增索引時，必須遵循以下問題
1、索引未命中
1、範圍問題，或者說條件不明確，條件中出現這些符號或關鍵字：
>、>=、<、<=、!= 、between...and...、like、
2、 儘量選擇區分度高的列作為索引,區分度的公式是count(distinct col)/count(*)，
表示欄位不重複的比例，比例越大我們掃描的記錄數越少，唯一鍵的區分度是1，
3、 =和in可以亂序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意順序，
mysql的查詢優化器會幫你優化成索引可以識別的形式
4、 索引列不能參與計算，保持列“乾淨”
所以語句應該寫成create_time = unix_timestamp(’2014-05-29’)
5、and的工作原理：對於連續多個and：mysql會按照聯合索引，找一個區分度高的索引欄位
(這樣便可以快速鎖定很小的範圍)，加速查詢，
6、or的工作原理：mysql會按照條件的順序，從左到右依次判斷，
7、最左字首匹配原則（詳見第八小節），非常重要的原則，
1、其他情況
其他情況- 使用函式
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型別，必須制定長度 2、其他注意事項
- 避免使用select *
- count(1)或count(列) 代替 count(*)
- 建立表時儘量時 char 代替 varchar
- 表的欄位順序固定長度的欄位優先
- 組合索引代替多個單列索引（經常使用多個條件查詢時）
- 儘量使用短索引
- 使用連線（JOIN）來代替子查詢(Sub-Queries)
- 連表時注意條件型別需一致
- 索引雜湊值（重複少）不適合建索引，例：性別不適合
八、聯合索引與覆蓋索引
1、聯合索引
聯合索引時指對錶上的多個列合起來做一個索引，
聯合索引的建立方法與單個索引的建立方法一樣，不同之處在僅在於有多個索引列，
mysql> create table t(
-> a int,
-> b int,
-> primary key(a), -> key idx_a_b(a,b) -> ); Query OK, 0 rows affected (0.11 sec) 1、注意建立聯合索引的一個原則：
索引是有個最左匹配的原則的，所以建聯合索引的時候，將區分度高的放在最左邊，
依次排下來，範圍查詢的條件儘可能的往後邊放。
2、聯合索引的第二個好處
是在第一個鍵相同的情況下，已經對第二個鍵進行了排序處理，
fe：聯合索引使用示例
示例#===========準備表==============
create table buy_log(
userid int unsigned not null,
buy_date date
); insert into buy_log values (1,'2009-01-01'), (2,'2009-01-01'), (3,'2009-01-01'), (1,'2009-02-01'), (3,'2009-02-01'), (1,'2009-03-01'), (1,'2009-04-01'); alter table buy_log add key(userid); alter table buy_log add key(userid,buy_date); #===========驗證============== mysql> show create table buy_log; | buy_log | CREATE TABLE `buy_log` ( `userid` int(10) unsigned NOT NULL, `buy_date` date DEFAULT NULL, KEY `userid` (`userid`), KEY `userid_2` (`userid`,`buy_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 | #可以看到possible_keys在這裡有兩個索引可以用，分別是單個索引userid與聯合索引userid_2, 但是優化器最終選擇了使用的key是userid因為該索引的葉子節點包含單個鍵值，所以理論上一個頁能存放的記錄應該更多 mysql> explain select * from buy_log where userid=2; +----+-------------+---------+------+-----------------+--------+---------+-------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+------+-----------------+--------+---------+-------+------+-------+ | 1 | SIMPLE | buy_log | ref | userid,userid_2 | userid | 4 | const | 1 | | +----+-------------+---------+------+-----------------+--------+---------+-------+------+-------+ 1 row in set (0.00 sec) #接著假定要取出userid為1的最近3次的購買記錄，用的就是聯合索引userid_2了， 因為在這個索引中，在userid=1的情況下，buy_date都已經排序好了 mysql> explain select * from buy_log where userid=1 order by buy_date desc limit 3; +----+-------------+---------+------+-----------------+----------+---------+-------+------+--------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+------+-----------------+----------+---------+-------+------+--------------------------+ | 1 | SIMPLE | buy_log | ref | userid,userid_2 | userid_2 | 4 | const | 4 | Using where; Using index | +----+-------------+---------+------+-----------------+----------+---------+-------+------+--------------------------+ 1 row in set (0.00 sec) #ps：如果extra的排序顯示是Using filesort，則意味著在查出資料後需要二次排序 (如下查詢語句，沒有先用where userid=3先定位範圍，於是即便命中索引也沒用，需要二次排序) mysql> explain select * from buy_log order by buy_date desc limit 3; +----+-------------+---------+-------+---------------+----------+---------+------+------+-----------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+-------+---------------+----------+---------+------+------+-----------------------------+ | 1 | SIMPLE | buy_log | index | NULL | userid_2 | 8 | NULL | 7 | Using index; Using filesort | +----+-------------+---------+-------+---------------+----------+---------+------+------+-----------------------------+ #對於聯合索引（a,b）,下述語句可以直接使用該索引，無需二次排序 select ... from table where a=xxx order by b; #然後對於聯合索引(a,b,c)來首，下列語句同樣可以直接通過索引得到結果 select ... from table where a=xxx order by b; select ... from table where a=xxx and b=xxx order by c; #但是對於聯合索引(a,b,c)，下列語句不能通過索引直接得到結果，還需要自己執行一次filesort操作，因為索引（a，c)並未排序 select ... from table where a=xxx order by c; 2、覆蓋索引
InnoDB儲存引擎支援覆蓋索引（covering index，或稱索引覆蓋），
即從輔助索引中就可以得到查詢記錄，而不需要查詢聚集索引中的記錄
使用覆蓋索引的一個好處是：輔助索引不包含整行記錄的所有資訊，
故其大小要遠小於聚集索引，因此可以減少大量的IO操作
fe:覆蓋索引查詢
名字select age from s1 where id=123 and name = 'egon'; #id欄位有索引，但是name欄位沒有索引,該sql命中了索引，但未覆蓋，需要去聚集索引中再查詢詳細資訊。 最牛逼的情況是，索引欄位覆蓋了所有，那全程通過索引來加速查詢以及獲取結果就ok了 mysql> desc s1; +--------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------+-------------+------+-----+---------+-------+ | id | int(11) | NO | | NULL | | | name | varchar(20) | YES | | NULL | | | gender | char(6) | YES | | NULL | | | email | varchar(50) | YES | | NULL | | +--------+-------------+------+-----+---------+-------+ 4 rows in set (0.21 sec) mysql> explain select name from s1 where id=1000; #沒有任何索引 +----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+-------------+ | 1 | SIMPLE | s1 | NULL | ALL | NULL | NULL | NULL | NULL | 2688336 | 10.00 | Using where | +----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+-------------+ 1 row in set, 1 warning (0.00 sec) mysql> create index idx_id on s1(id); #建立索引 Query OK, 0 rows affected (4.16 sec) Records: 0 Duplicates: 0 Warnings: 0 mysql> explain select name from s1 where id=1000; #命中輔助索引，但是未覆蓋索引，還需要從聚集索引中查詢name +----+-------------+-------+------------+------+---------------+--------+---------+-------+------+----------+-------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-------+------------+------+---------------+--------+---------+-------+------+----------+-------+ | 1 | SIMPLE | s1 | NULL | ref | idx_id | idx_id | 4 | const | 1 | 100.00 | NULL | +----+-------------+-------+------------+------+---------------+--------+---------+-------+------+----------+-------+ 1 row in set, 1 warning (0.08 sec) mysql> explain select id from s1 where id=1000; #在輔助索引中就找到了全部資訊，Using index代表覆蓋索引 +----+-------------+-------+------------+------+---------------+--------+---------+-------+------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-------+------------+------+---------------+--------+---------+-------+------+----------+-------------+ | 1 | SIMPLE | s1 | NULL | ref | idx_id | idx_id | 4 | const | 1 | 100.00 | Using index | +----+-------------+-------+------------+------+---------------+--------+---------+-------+------+----------+-------------+ 1 row in set, 1 warning (0.03 sec) 2、覆蓋索引的另外一個好處
是對某些統計問題而言的。基於上一小結建立的表buy_log,查詢計劃如下
mysql> explain select count(*) from buy_log; +----+-------------+---------+-------+---------------+--------+---------+------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+-------+---------------+--------+---------+------+------+-------------+ | 1 | SIMPLE | buy_log | index | NULL | userid | 4 | NULL | 7 | Using index | +----+-------------+---------+-------+---------------+--------+---------+------+------+-------------+ 1 row in set (0.00 sec) 九、查詢優化神器–explain
關於explain命令相信大家並不陌生，具體用法和欄位含義可以參考官網explain-output，
這裡需要強調rows是核心指標，絕大部分rows小的語句執行一定很快（有例外，下面會講到）。所以優化語句基本上都是在優化rows。
關於explain，如果大家有興趣，可以看看這篇部落格，他總結的挺好的：
關於explain
官網的explain
MySQL 執行計劃explain詳解
執行計劃：讓mysql預估執行操作(一般正確)
all < index < range < index_merge < ref_or_null < ref < eq_ref < system/const id,email 慢： select * from userinfo3 where name='alex' explain select * from userinfo3 where name='alex' type: ALL(全表掃描) select * from userinfo3 limit 1; 快： select * from userinfo3 where email='alex' type: const(走索引) 十、 慢查詢優化的基本步驟
0.先執行看看是否真的很慢，注意設定SQL_NO_CACHE
1.where條件單表查，鎖定最小返回記錄表。這句話的意思是把查詢語句的where都應用到表中返回的記錄數最小的表開始查起，單表每個欄位分別查詢，看哪個欄位的區分度最高
2.explain檢視執行計劃，是否與1預期一致（從鎖定記錄較少的表開始查詢）
3.order by limit 形式的sql語句讓排序的表優先查
4.瞭解業務方使用場景
5.加索引時參照建索引的幾大原則
6.觀察結果，不符合預期繼續從0分析
十一、慢日誌管理
慢日誌
- 執行時間 > 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:/....
注意：修改配置檔案之後，需要重啟服務
2、MySQL日誌管理
MySQL日誌管理MySQL日誌管理
======================================================== 錯誤日誌: 記錄 MySQL 伺服器啟動、關閉及執行錯誤等資訊 二進位制日誌: 又稱binlog日誌，以二進位制檔案的方式記錄資料庫中除 SELECT 以外的操作 查詢日誌: 記錄查詢的資訊 慢查詢日誌: 記錄執行時間超過指定時間的操作 中繼日誌： 備庫將主庫的二進位制日誌複製到自己的中繼日誌中，從而在本地進行重放 通用日誌： 審計哪個賬號、在哪個時段、做了哪些事件 事務日誌或稱redo日誌： 記錄Innodb事務相關的如事務執行時間、檢查點等 ======================================================== 一、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' 二、查詢日誌 啟用通用查詢日誌 # vim /etc/my.cnf [mysqld] log[=dir\[filename]] # service mysqld restart 三、慢查詢日誌 啟用慢查詢日誌 # 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);