【黑馬程序員】2020最新MySQL高級教程 學習筆記
優化SQL步驟
在應用的的開發過程中,由於初期數據量小,開發人員寫 SQL 語句時更重視功能上的實現,但是當應用系統正式上線後,隨着生產數據量的急劇增長,很多 SQL 語句開始逐漸顯露出性能問題,對生產的影響也越來越大,此時這些有問題的 SQL 語句就成爲整個系統性能的瓶頸,因此我們必須要對它們進行優化。
當面對一個有 SQL 性能問題的數據庫時,我們應該從何處入手來進行系統的分析,使得能夠儘快定位問題 SQL 並儘快解決問題。
1. 查看SQL執行頻率
MySQL 客戶端連接成功後,通過show [session|global] status
命令可以提供服務器狀態信息。show [session|global] status
可以根據需要加上參數“session”
或者“global”
來顯示session 級(當前連接)
的計結果和 global 級(自數據庫上次啓動至今)
的統計結果。如果不寫,默認使用參數是“session”
。
數據庫統計信息
show status like 'Com_______'; //七個_
inno_db統計信息
## 查看innodb的統計信息,可以根據該信息判斷當前數據庫是 讀爲主 還是 寫爲主;
show status like 'Innodb_rows_%';
統計參數說明
Com_xxx 表示每個 xxx 語句執行的次數,我們通常比較關心的是以下幾個統計參數。
參數 | 含義 |
---|---|
Com_select | 執行 select 操作的次數,一次查詢只累加 1。 |
Com_insert | 執行 INSERT 操作的次數,對於批量插入的 INSERT 操作,只累加一次。 |
Com_update | 執行 UPDATE 操作的次數。 |
Com_delete | 執行 DELETE 操作的次數。 |
Innodb_rows_read | select 查詢返回的行數。 |
Innodb_rows_inserted | 執行 INSERT 操作插入的行數。 |
Innodb_rows_updated | 執行 UPDATE 操作更新的行數。 |
Innodb_rows_deleted | 執行 DELETE 操作刪除的行數。 |
Connections | 試圖連接 MySQL 服務器的次數。 |
Uptime | 服務器工作時間。 |
Slow_queries | 慢查詢的次數。 |
Com_***
: 這些參數對於所有存儲引擎的表操作都會進行累計。
Innodb_***
: 這幾個參數只是針對InnoDB 存儲引擎的,累加的算法也略有不同。 表示每個 xxx 語句執行的次數,我們通常比較關心的是以下幾個統計參數。
2. 定位低效率SQL
可以通過以下兩種方式定位執行效率較低的 SQL 語句。
慢查詢日誌
: 通過慢查詢日誌定位那些執行效率較低的 SQL 語句,用--log-slow-queries[=file_name]
選項啓動時,mysqld 寫一個包含所有執行時間超過 long_query_time 秒的 SQL 語句
的日誌文件。---- 後續講解。show processlist
: 慢查詢日誌在查詢結束以後才紀錄,所以在應用反映執行效率出現問題的時候查詢慢查詢日誌並不能定位問題,可以使用show processlist
命令查看當前MySQL在進行的線程,包括線程的狀態、是否鎖表等
,可以實時地查看 SQL 的執行情況,同時對一些鎖表操作進行優化。
show processlist
id列
,用戶登錄mysql時,系統分配的"connection_id",可以使用函數connection_id()查看user列
,顯示當前用戶。如果不是root,這個命令就只顯示用戶權限範圍的sql語句host列
,顯示這個語句是從哪個ip的哪個端口上發的,可以用來跟蹤出現問題語句的用戶db列
,顯示這個進程目前連接的是哪個數據庫command列
,顯示當前連接的執行的命令,一般取值爲休眠(sleep),查詢(query),連接(connect)等time列
,顯示這個狀態持續的時間,單位是秒
state列
,顯示使用當前連接的sql語句的狀態,很重要的列。state描述的是語句執行中的某一個狀態。一個sql語句,以查詢爲例,可能需要經過copying to tmp table、sorting result、sending data
等狀態纔可以完成info列
,顯示這個sql語句,是判斷問題語句的一個重要依據
3. explain分析執行計劃
通過以上步驟查詢到效率低的 SQL 語句後,可以通過 EXPLAIN或者 DESC命令獲取 MySQL如何執行 SELECT 語句的信息,包括在 SELECT 語句執行過程中表如何連接和連接的順序。
查詢SQL語句的執行計劃
explain select * from goods_myisam;
字段 | 含義 |
---|---|
id | select查詢的序列號,是一組數字,表示的是查詢中執行select子句或者是操作表的順序。 |
select_type | 表示 SELECT 的類型,常見的取值有 SIMPLE(簡單表,即不使用表連接或者子查詢)、PRIMARY(主查詢,即外層的查詢)、UNION(UNION 中的第二個或者後面的查詢語句)、SUBQUERY(子查詢中的第一個 SELECT)等 |
table | 輸出結果集的表 |
type | 表示表的連接類型,性能由好到差的連接類型爲( system ---> const -----> eq_ref ------> ref -------> ref_or_null----> index_merge ---> index_subquery -----> range -----> index ------> all ) |
possible_keys | 表示查詢時,可能使用的索引 |
key | 表示實際使用的索引 |
key_len | 索引字段的長度 |
rows | 掃描行的數量 |
extra | 執行情況的說明和描述 |
環境準備
CREATE TABLE `t_role` (
`id` varchar(32) NOT NULL,
`role_name` varchar(255) DEFAULT NULL,
`role_code` varchar(255) DEFAULT NULL,
`description` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `unique_role_name` (`role_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `t_user` (
`id` varchar(32) NOT NULL,
`username` varchar(45) NOT NULL,
`password` varchar(96) NOT NULL,
`name` varchar(45) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `unique_user_username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `user_role` (
`id` int(11) NOT NULL auto_increment ,
`user_id` varchar(32) DEFAULT NULL,
`role_id` varchar(32) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `fk_ur_user_id` (`user_id`),
KEY `fk_ur_role_id` (`role_id`),
CONSTRAINT `fk_ur_role_id` FOREIGN KEY (`role_id`) REFERENCES `t_role` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION,
CONSTRAINT `fk_ur_user_id` FOREIGN KEY (`user_id`) REFERENCES `t_user` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
insert into `t_user` (`id`, `username`, `password`, `name`) values('1','super','$2a$10$TJ4TmCdK.X4wv/tCqHW14.w70U3CC33CeVncD3SLmyMXMknstqKRe','超級管理員');
insert into `t_user` (`id`, `username`, `password`, `name`) values('2','admin','$2a$10$TJ4TmCdK.X4wv/tCqHW14.w70U3CC33CeVncD3SLmyMXMknstqKRe','系統管理員');
insert into `t_user` (`id`, `username`, `password`, `name`) values('3','itcast','$2a$10$8qmaHgUFUAmPR5pOuWhYWOr291WJYjHelUlYn07k5ELF8ZCrW0Cui','test02');
insert into `t_user` (`id`, `username`, `password`, `name`) values('4','stu1','$2a$10$pLtt2KDAFpwTWLjNsmTEi.oU1yOZyIn9XkziK/y/spH5rftCpUMZa','學生1');
insert into `t_user` (`id`, `username`, `password`, `name`) values('5','stu2','$2a$10$nxPKkYSez7uz2YQYUnwhR.z57km3yqKn3Hr/p1FR6ZKgc18u.Tvqm','學生2');
insert into `t_user` (`id`, `username`, `password`, `name`) values('6','t1','$2a$10$TJ4TmCdK.X4wv/tCqHW14.w70U3CC33CeVncD3SLmyMXMknstqKRe','老師1');
INSERT INTO `t_role` (`id`, `role_name`, `role_code`, `description`) VALUES('5','學生','student','學生');
INSERT INTO `t_role` (`id`, `role_name`, `role_code`, `description`) VALUES('7','老師','teacher','老師');
INSERT INTO `t_role` (`id`, `role_name`, `role_code`, `description`) VALUES('8','教學管理員','teachmanager','教學管理員');
INSERT INTO `t_role` (`id`, `role_name`, `role_code`, `description`) VALUES('9','管理員','admin','管理員');
INSERT INTO `t_role` (`id`, `role_name`, `role_code`, `description`) VALUES('10','超級管理員','super','超級管理員');
INSERT INTO user_role(id,user_id,role_id) VALUES(NULL, '1', '5'),(NULL, '1', '7'),(NULL, '2', '8'),(NULL, '3', '9'),(NULL, '4', '8'),(NULL, '5', '10') ;
explain 之 id
id 字段是 select查詢的序列號
,是一組數字,表示的是查詢中執行select子句或者是操作表的順序。id 情況有三種 :
id 相同表示加載表的順序是從上到下。
explain select * from t_role r, t_user u, user_role ur where r.id = ur.role_id and u.id = ur.user_id ;
id 不同id值越大,優先級越高,越先被執行。
EXPLAIN SELECT * FROM t_role WHERE id = (SELECT role_id FROM user_role WHERE user_id = (SELECT id FROM t_user WHERE username = 'stu1'))
id 有相同,也有不同,同時存在。id相同的可以認爲是一組,從上往下順序執行;在所有的組中,id的值越大,優先級越高,越先執行。
EXPLAIN SELECT * FROM t_role r , (SELECT * FROM user_role ur WHERE ur.`user_id` = '2') a WHERE r.id = a.role_id ;
explain 之 select_type
表示 SELECT 的類型,常見的取值,如下表所示:
select_type | 含義 |
---|---|
SIMPLE | 簡單的select查詢,查詢中不包含子查詢或者UNION |
PRIMARY | 查詢中若包含任何複雜的子查詢,最外層查詢標記爲該標識 |
SUBQUERY | 在SELECT 或 WHERE 列表中包含了子查詢 |
DERIVED | 在FROM 列表中包含的子查詢 ,被標記爲 DERIVED(衍生) MYSQL會遞歸執行這些子查詢,把結果放在臨時表中 |
UNION | 若第二個SELECT出現在UNION之後,則標記爲UNION ; 若UNION包含在FROM子句的子查詢中,外層SELECT將被標記爲 : DERIVED |
UNION RESULT | 從UNION表獲取結果的SELECT |
** explain 之 table**
展示這一行的數據是關於哪一張表的 .
** explain 之 type**
type 顯示的是訪問類型,是較爲重要的一個指標,可取值爲:
type | 含義 |
---|---|
NULL | MySQL不訪問任何表,索引,直接返回結果 |
system | 表只有一行記錄(等於系統表),這是const類型的特例,一般不會出現 |
const | 表示通過索引一次就找到了,const 用於比較primary key 或者 unique 索引。因爲只匹配一行數據,所以很快。如將主鍵置於where列表中,MySQL 就能將該查詢轉換爲一個常量。const於將 “主鍵” 或 “唯一” 索引的所有部分與常量值進行比較 |
eq_ref | 類似ref,區別在於使用的是唯一索引 ,使用主鍵的關聯查詢,關聯查詢出的記錄只有一條。常見於主鍵或唯一索引掃描 |
ref | 非唯一性索引掃描,返回匹配某個單獨值的所有行。本質上也是一種索引訪問,返回所有匹配某個單獨值的所有行(多個) |
range | 只檢索給定返回的行,使用一個索引來選擇行。 where 之後出現between , < , > , in 等操作。 |
index | index 與 ALL的區別爲index 類型只是遍歷了索引樹 , 通常比ALL 快, ALL 是遍歷數據文件。 |
all | 將遍歷全表以找到匹配的行 |
結果值從最好到最壞以此是:
NULL > system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
system > const > eq_ref > ref > range > index > ALL
一般來說, 我們需要保證查詢至少達到 range 級別, 最好達到ref 。
** explain 之 key**
possible_keys
: 顯示可能應用在這張表的索引, 一個或多個。key
: 實際使用的索引, 如果爲NULL, 則沒有使用索引。key_len
: 表示索引中使用的字節數, 該值爲索引字段最大可能長度,並非實際使用長度,在不損失精確性的前提下, 長度越短越好
。
explain 之 rows
掃描行的數量。
explain 之 extra
其他的額外的執行計劃信息,在該列展示 。
extra | 含義 |
---|---|
using filesort | 說明mysql會對數據使用一個外部的索引排序,而不是按照表內的索引順序進行讀取,稱爲 “文件排序”, 效率低。 |
using temporary | 使用了臨時表保存中間結果,MySQL在對 查詢結果排序時使用臨時表 。常見於 order by 和 group by; 效率低 |
using index | 表示相應的select操作使用了覆蓋索引 , 避免訪問表的數據行, 效率不錯 |
4. show profile分析SQL
Mysql從5.0.37版本開始增加了對 show profiles
和 show profile
語句的支持。show profiles 能夠在做SQL優化時幫助我們瞭解時間都耗費到哪裏去了。
**have_profiling **
通過have_profiling
參數,能夠看到當前MySQL是否支持profile:
profiling
默認profiling是關閉的,可以通過set語句在Session級別開啓profiling:set profiling=1; //開啓profiling 開關;
通過profile,我們能夠更清楚地瞭解SQL執行的過程。
首先,我們可以執行一系列的操作,如下圖所示:
show databases;
use db01;
select * from tb_item where id < 5;
select count(*) from tb_item;
**show profiles **
執行完上述命令之後,再執行show profiles
指令, 來查看SQL語句執行的耗時:
show profile for query query_id
通過show profile for query query_id
語句可以查看到該SQL執行過程中每個線程的狀態和消耗的時間:
Sending data
狀態表示MySQL線程開始訪問數據行並把結果返回給客戶端
,而不僅僅是返回個客戶端。
由於在Sending data狀態下,MySQL線程往往需要做大量的磁盤讀取操作,所以經常是整各查詢中耗時最長的狀態。
show profile [all | cpu | block io | context switch | page faults] for query query_id
在獲取到最消耗時間的線程狀態後,MySQL支持進一步選擇all、cpu、block io 、context switch、page faults等明細類型類查看MySQL在使用什麼資源上耗費了過高的時間。例如,選擇查看CPU的耗費時間
:
字段 | 含義 |
---|---|
Status | sql 語句執行的狀態 |
Duration | sql 執行過程中每一個步驟的耗時 |
CPU_user | 當前用戶佔有的cpu |
CPU_system | 系統佔有的cpu |
5. trace分析器優化執行計劃
MySQL5.6提供了對SQL的跟蹤trace, 通過trace文件能夠進一步瞭解爲什麼優化器選擇A計劃, 而不是選擇B計劃。
打開trace , 設置格式爲 JSON,並設置trace最大能夠使用的內存大小,避免解析過程中因爲默認內存過小而不能夠完整展示。
SET optimizer_trace="enabled=on",end_markers_in_json=on;
set optimizer_trace_max_mem_size=1000000;
執行SQL語句 :
select * from tb_item where id < 4;
最後, 檢查information_schema.optimizer_trace就可以知道MySQL是如何執行SQL的 :
select * from information_schema.optimizer_trace\G;
索引的使用
索引是數據庫優化最常用也是最重要的手段之一, 通過索引通常可以幫助用戶解決大多數的MySQL的性能優化問題。
驗證索引提升查詢效率
在我們準備的表結構tb_item 中, 一共存儲了 300 萬記錄;
使用ID來查詢
查詢速度很快, 接近0s , 主要的原因是因爲id爲主鍵, 有索引;
根據 title 進行精確查詢
查詢速度很慢,效率低下。處理方案 , 針對title字段, 創建索引 :
create index idx_item_title on tb_item(title);
將300w條數據 創建索引的過程非常耗時
索引創建完成之後,再次進行查詢 :
索引的使用
環境準備
create table `tb_seller` (
`sellerid` varchar (100),
`name` varchar (100),
`nickname` varchar (50),
`password` varchar (60),
`status` varchar (1),
`address` varchar (100),
`createtime` datetime,
primary key(`sellerid`)
)engine=innodb default charset=utf8mb4;
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('alibaba','阿里巴巴','阿里小店','e10adc3949ba59abbe56e057f20f883e','1','北京市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('baidu','百度科技有限公司','百度小店','e10adc3949ba59abbe56e057f20f883e','1','北京市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('huawei','華爲科技有限公司','華爲小店','e10adc3949ba59abbe56e057f20f883e','0','北京市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('itcast','傳智播客教育科技有限公司','傳智播客','e10adc3949ba59abbe56e057f20f883e','1','北京市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('itheima','黑馬程序員','黑馬程序員','e10adc3949ba59abbe56e057f20f883e','0','北京市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('luoji','羅技科技有限公司','羅技小店','e10adc3949ba59abbe56e057f20f883e','1','北京市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('oppo','OPPO科技有限公司','OPPO官方旗艦店','e10adc3949ba59abbe56e057f20f883e','0','北京市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('ourpalm','掌趣科技股份有限公司','掌趣小店','e10adc3949ba59abbe56e057f20f883e','1','北京市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('qiandu','千度科技','千度小店','e10adc3949ba59abbe56e057f20f883e','2','北京市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('sina','新浪科技有限公司','新浪官方旗艦店','e10adc3949ba59abbe56e057f20f883e','1','北京市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('xiaomi','小米科技','小米官方旗艦店','e10adc3949ba59abbe56e057f20f883e','1','西安市','2088-01-01 12:00:00');
insert into `tb_seller` (`sellerid`, `name`, `nickname`, `password`, `status`, `address`, `createtime`) values('yijia','宜家家居','宜家家居旗艦店','e10adc3949ba59abbe56e057f20f883e','1','北京市','2088-01-01 12:00:00');
// 創建聯合索引
create index idx_seller_name_sta_addr on tb_seller(name,status,address);
避免索引失效
-
全值匹配 ,對索引中所有列都指定具體值。— 該情況下,索引生效,執行效率高。
-
最左前綴法則 — 如果索引了多列,要遵守最左前綴法則。指的是查詢從索引的最左前列開始,並且不跳過索引中的列。
匹配最左前綴法則,走索引:
違法最左前綴法則 , 索引失效:
如果符合最左法則,但是出現跳躍某一列,只有最左列索引生效:
-
範圍查詢右邊的列,不能使用索引 。
根據前面的兩個字段name , status
查詢是走索引的, 但是最後一個條件address 沒有用到索引。 -
不要在索引列上進行運算操作, 索引將失效。
-
字符串不加單引號,造成索引失效。
-
儘量使用覆蓋索引,避免
select *
– 儘量使用覆蓋索引(只訪問索引的查詢(索引列完全包含查詢列
)),減少select *
。
using index
:使用覆蓋索引的時候就會出現using where
:在查找使用索引的情況下,需要回表去查詢所需的數據.using index condition
:查找使用了索引,但是需要回表查詢數據.using index ; using where
:查找使用了索引,但是需要的數據都在索引列中能找到,所以不需要回表查詢數據
- 用or分割開的條件, 如果
or前的條件中的列有索引,而後面的列中沒有索引
,那麼涉及的索引都不會被用到。
//示例,name字段是索引列 , 而createtime不是索引列,中間是or進行連接是不走索引的 :
explain select * from tb_seller where name='黑馬程序員' or createtime = '2088-01-01 12:00:00';
- 以%開頭的Like模糊查詢,索引失效。 — 如果僅僅是
尾部模糊匹配,索引不會失效
。如果是頭部模糊匹配,索引失效
。
解決方案: 通過覆蓋索引解決
9. 如果MySQL評估使用索引比全表更慢,則不使用索引。
10. is NULL , is NOT NULL
有時索引失效。
11. in 走索引
, not in 索引失效
。 != 索引失效
12. 單列索引和複合索引。 ---- 儘量使用複合索引,而少使用單列索引 。
13. 同是varchar
,不同字符集不走索引
## 複合索引
create index idx_name_sta_address on tb_seller(name, status, address);
就相當於創建了三個索引 :
name
name + status
name + status + address
## 單索引
create index idx_seller_name on tb_seller(name);
create index idx_seller_status on tb_seller(status);
create index idx_seller_address on tb_seller(address);
數據庫會選擇一個最優的索引(辨識度最高索引)來使用,並不會使用全部索引
。
查看索引使用情況
show status like 'Handler_read%';
show global status like 'Handler_read%';
Handler_read_first
:索引中第一條被讀的次數。如果較高,表示服務器正執行大量全索引掃描(這個值越低越好)。Handler_read_key
:如果索引正在工作,這個值代表一個行被索引值讀的次數,如果值越低,表示索引得到的性能改善不高,因爲索引不經常使用(這個值越高越好)。Handler_read_next
:按照鍵順序讀下一行的請求數。如果你用範圍約束或如果執行索引掃描來查詢索引列,該值增加。Handler_read_prev
:按照鍵順序讀前一行的請求數。該讀方法主要用於優化ORDER BY … DESC。Handler_read_rnd
:根據固定位置讀一行的請求數。如果你正執行大量查詢並需要對結果進行排序該值較高。你可能使用了大量需要MySQL掃描整個表的查詢或你的連接沒有正確使用鍵。這個值較高,意味着運行效率低,應該建立索引來補救。Handler_read_rnd_next
:在數據文件中讀下一行的請求數。如果你正進行大量的表掃描,該值較高。通常說明你的表索引不正確或寫入的查詢沒有利用索引。