超详细图解！【MySQL进阶篇】SQL优化-索引-存储引擎
1. Mysql的體系結構概覽
整個MySQL Server由以下組成
- Connection Pool : 連接池組件
- Management Services & Utilities : 管理服務和工具組件
- SQL Interface : SQL接口組件
- Parser : 查詢分析器組件
- Optimizer : 優(yōu)化器組件
- Caches & Buffers : 緩沖池組件
- Pluggable Storage Engines : 存儲引擎
- File System : 文件系統(tǒng)
1） 連接層
最上層是一些客戶端和鏈接服務，包含本地sock 通信和大多數(shù)基于客戶端/服務端工具實現(xiàn)的類似于 TCP/IP的通信。主要完成一些類似于連接處理、授權認證、及相關的安全方案。在該層上引入了線程池的概念，為通過認證安全接入的客戶端提供線程。同樣在該層上可以實現(xiàn)基于SSL的安全鏈接。服務器也會為安全接入的每個客戶端驗證它所具有的操作權限。
2） 服務層
第二層架構主要完成大多數(shù)的核心服務功能，如SQL接口，并完成緩存的查詢，SQL的分析和優(yōu)化，部分內置函數(shù)的執(zhí)行。所有跨存儲引擎的功能也在這一層實現(xiàn)，如 過程、函數(shù)等。在該層，服務器會解析查詢并創(chuàng)建相應的內部解析樹，并對其完成相應的優(yōu)化如確定表的查詢的順序，是否利用索引等， 最后生成相應的執(zhí)行操作。如果是select語句，服務器還會查詢內部的緩存，如果緩存空間足夠大，這樣在解決大量讀操作的環(huán)境中能夠很好的提升系統(tǒng)的性能。
3） 引擎層
存儲引擎層， 存儲引擎真正的負責了MySQL中數(shù)據(jù)的存儲和提取，服務器通過API和存儲引擎進行通信。不同的存儲引擎具有不同的功能，這樣我們可以根據(jù)自己的需要，來選取合適的存儲引擎。
4）存儲層
數(shù)據(jù)存儲層， 主要是將數(shù)據(jù)存儲在文件系統(tǒng)之上，并完成與存儲引擎的交互。
和其他數(shù)據(jù)庫相比，MySQL有點與眾不同，它的架構可以在多種不同場景中應用并發(fā)揮良好作用。主要體現(xiàn)在存儲引擎上，插件式的存儲引擎架構，將查詢處理和其他的系統(tǒng)任務以及數(shù)據(jù)的存儲提取分離。這種架構可以根據(jù)業(yè)務的需求和實際需要選擇合適的存儲引擎。
2. 存儲引擎
2.1 存儲引擎概述
? 和大多數(shù)的數(shù)據(jù)庫不同, MySQL中有一個存儲引擎的概念, 針對不同的存儲需求可以選擇最優(yōu)的存儲引擎。
? 存儲引擎就是存儲數(shù)據(jù)，建立索引，更新查詢數(shù)據(jù)等等技術的實現(xiàn)方式 。存儲引擎是基于表的，而不是基于庫的。所以存儲引擎也可被稱為表類型。
? Oracle，SqlServer等數(shù)據(jù)庫只有一種存儲引擎。MySQL提供了插件式的存儲引擎架構。所以MySQL存在多種存儲引擎，可以根據(jù)需要使用相應引擎，或者編寫存儲引擎。
? MySQL5.0支持的存儲引擎包含 ： InnoDB 、MyISAM 、BDB、MEMORY、MERGE、EXAMPLE、NDB Cluster、ARCHIVE、CSV、BLACKHOLE、FEDERATED等，其中InnoDB和BDB提供事務安全表，其他存儲引擎是非事務安全表。
可以通過指定 show engines ， 來查詢當前數(shù)據(jù)庫支持的存儲引擎 ：
創(chuàng)建新表時如果不指定存儲引擎，那么系統(tǒng)就會使用默認的存儲引擎，MySQL5.5之前的默認存儲引擎是MyISAM，5.5之后就改為了InnoDB。
查看Mysql數(shù)據(jù)庫默認的存儲引擎 ， 指令 ：
SQLshow variables like '%storage_engine%' ；2.2 各種存儲引擎特性
下面重點介紹幾種常用的存儲引擎， 并對比各個存儲引擎之間的區(qū)別， 如下表所示 ：
| 存儲限制 | 64TB | 有 | 有 | 沒有 | 有 |
| 事務安全 | 支持 | ||||
| 鎖機制 | 行鎖(適合高并發(fā)) | 表鎖 | 表鎖 | 表鎖 | 行鎖 |
| B樹索引 | 支持 | 支持 | 支持 | 支持 | 支持 |
| 哈希索引 | 支持 | ||||
| 全文索引 | 支持(5.6版本之后) | 支持 | |||
| 集群索引 | 支持 | ||||
| 數(shù)據(jù)索引 | 支持 | 支持 | 支持 | ||
| 索引緩存 | 支持 | 支持 | 支持 | 支持 | 支持 |
| 數(shù)據(jù)可壓縮 | 支持 | ||||
| 空間使用 | 高 | 低 | N/A | 低 | 低 |
| 內存使用 | 高 | 低 | 中等 | 低 | 高 |
| 批量插入速度 | 低 | 高 | 高 | 高 | 高 |
| 支持外鍵 | 支持 |
下面我們將重點介紹最長使用的兩種存儲引擎： InnoDB、MyISAM ， 另外兩種 MEMORY、MERGE ， 了解即可。
2.2.1 InnoDB
? InnoDB存儲引擎是Mysql的默認存儲引擎。InnoDB存儲引擎提供了具有提交、回滾、崩潰恢復能力的事務安全。但是對比MyISAM的存儲引擎，InnoDB寫的處理效率差一些，并且會占用更多的磁盤空間以保留數(shù)據(jù)和索引。
InnoDB存儲引擎不同于其他存儲引擎的特點 ：
事務控制
`create table goods_innodb(id int NOT NULL AUTO_INCREMENT,name varchar(20) NOT NULL,primary key(id) )ENGINE=innodb DEFAULT CHARSET=utf8;` SQL`start transaction;insert into goods_innodb(id,name)values(null,'Meta20');commit;測試，發(fā)現(xiàn)在InnoDB中是存在事務的 ；
外鍵約束
? MySQL支持外鍵的存儲引擎只有InnoDB ， 在創(chuàng)建外鍵的時候， 要求父表必須有對應的索引 ， 子表在創(chuàng)建外鍵的時候， 也會自動的創(chuàng)建對應的索引。
? 下面兩張表中 ， country_innodb是父表 ， country_id為主鍵索引，city_innodb表是子表，country_id字段為外鍵，對應于country_innodb表的主鍵country_id 。
SQL`create table country_innodb(country_id int NOT NULL AUTO_INCREMENT,country_name varchar(100) NOT NULL,primary key(country_id) )ENGINE=InnoDB DEFAULT CHARSET=utf8;create table city_innodb(city_id int NOT NULL AUTO_INCREMENT,city_name varchar(50) NOT NULL,country_id int NOT NULL,primary key(city_id),key idx_fk_country_id(country_id),CONSTRAINT `fk_city_country` FOREIGN KEY(country_id) REFERENCES country_innodb(country_id) ON DELETE RESTRICT ON UPDATE CASCADE )ENGINE=InnoDB DEFAULT CHARSET=utf8;insert into country_innodb values(null,'China'),(null,'America'),(null,'Japan'); insert into city_innodb values(null,'Xian',1),(null,'NewYork',2),(null,'BeiJing',1);`在創(chuàng)建索引時， 可以指定在刪除、更新父表時，對子表進行的相應操作，包括 RESTRICT、CASCADE、SET NULL 和 NO ACTION。
RESTRICT和NO ACTION相同， 是指限制在子表有關聯(lián)記錄的情況下， 父表不能更新；
CASCADE表示父表在更新或者刪除時，更新或者刪除子表對應的記錄；
SET NULL 則表示父表在更新或者刪除的時候，子表的對應字段被SET NULL 。
針對上面創(chuàng)建的兩個表， 子表的外鍵指定是ON DELETE RESTRICT ON UPDATE CASCADE 方式的， 那么在主表刪除記錄的時候， 如果子表有對應記錄， 則不允許刪除， 主表在更新記錄的時候， 如果子表有對應記錄， 則子表對應更新 。
表中數(shù)據(jù)如下圖所示 ：
外鍵信息可以使用如下兩種方式查看 ：
SQL`show create table city_innodb ;`刪除country_id為1 的country數(shù)據(jù)：
SQLdelete from country_innodb where country_id = 1;更新主表country表的字段 country_id :
SQL`update country_innodb set country_id = 100 where country_id = 1;更新后， 子表的數(shù)據(jù)信息為 ：
存儲方式
InnoDB 存儲表和索引有以下兩種方式 ：
①. 使用共享表空間存儲， 這種方式創(chuàng)建的表的表結構保存在.frm文件中， 數(shù)據(jù)和索引保存在 innodb_data_home_dir 和 innodb_data_file_path定義的表空間中，可以是多個文件。
②. 使用多表空間存儲， 這種方式創(chuàng)建的表的表結構仍然存在 .frm 文件中，但是每個表的數(shù)據(jù)和索引單獨保存在 .ibd 中。
2.2.2 MyISAM
? MyISAM 不支持事務、也不支持外鍵，其優(yōu)勢是訪問的速度快，對事務的完整性沒有要求或者以SELECT、INSERT為主的應用基本上都可以使用這個引擎來創(chuàng)建表 。有以下兩個比較重要的特點：
不支持事務
SQL`create table goods_myisam(id int NOT NULL AUTO_INCREMENT,name varchar(20) NOT NULL,primary key(id) )ENGINE=myisam DEFAULT CHARSET=utf8;通過測試，我們發(fā)現(xiàn)，在MyISAM存儲引擎中，是沒有事務控制的 ；
文件存儲方式
每個MyISAM在磁盤上存儲成3個文件，其文件名都和表名相同，但拓展名分別是 ：
.frm (存儲表定義)；
.MYD(MYData , 存儲數(shù)據(jù))；
.MYI(MYIndex , 存儲索引)；
2.2.3 MEMORY
? Memory存儲引擎將表的數(shù)據(jù)存放在內存中。每個MEMORY表實際對應一個磁盤文件，格式是.frm ，該文件中只存儲表的結構，而其數(shù)據(jù)文件，都是存儲在內存中，這樣有利于數(shù)據(jù)的快速處理，提高整個表的效率。MEMORY 類型的表訪問非常地快，因為他的數(shù)據(jù)是存放在內存中的，并且默認使用HASH索引 ， 但是服務一旦關閉，表中的數(shù)據(jù)就會丟失。
2.2.4 MERGE
? MERGE存儲引擎是一組MyISAM表的組合，這些MyISAM表必須結構完全相同，MERGE表本身并沒有存儲數(shù)據(jù)，對MERGE類型的表可以進行查詢、更新、刪除操作，這些操作實際上是對內部的MyISAM表進行的。
? 對于MERGE類型表的插入操作，是通過INSERT_METHOD子句定義插入的表，可以有3個不同的值，使用FIRST 或 LAST 值使得插入操作被相應地作用在第一或者最后一個表上，不定義這個子句或者定義為NO，表示不能對這個MERGE表執(zhí)行插入操作。
? 可以對MERGE表進行DROP操作，但是這個操作只是刪除MERGE表的定義，對內部的表是沒有任何影響的。
下面是一個創(chuàng)建和使用MERGE表的示例 ：
1）. 創(chuàng)建3個測試表 order_1990, order_1991, order_all , 其中order_all是前兩個表的MERGE表 ：
SQLcreate table order_1990(order_id int ,order_money double(10,2),order_address varchar(50),primary key (order_id) )engine = myisam default charset=utf8;create table order_1991(order_id int ,order_money double(10,2),order_address varchar(50),primary key (order_id) )engine = myisam default charset=utf8;create table order_all(order_id int ,order_money double(10,2),order_address varchar(50),primary key (order_id) )engine = merge union = (order_1990,order_1991) INSERT_METHOD=LAST default charset=utf8;` ```2）. 分別向兩張表中插入記錄 ```xc SQLinsert into order_1990 values(1,100.0,'北京'); insert into order_1990 values(2,100.0,'上海');insert into order_1991 values(10,200.0,'北京'); insert into order_1991 values(11,200.0,'上海')3）. 查詢3張表中的數(shù)據(jù)。
order_1990中的數(shù)據(jù) ：
order_1991中的數(shù)據(jù) ：
order_all中的數(shù)據(jù) ：
?
4）. 往order_all中插入一條記錄 ，由于在MERGE表定義時，INSERT_METHOD 選擇的是LAST，那么插入的數(shù)據(jù)會想最后一張表中插入。
SQLinsert into order_all values(100,10000.0,'西安')；2.3 存儲引擎的選擇
? 在選擇存儲引擎時，應該根據(jù)應用系統(tǒng)的特點選擇合適的存儲引擎。對于復雜的應用系統(tǒng)，還可以根據(jù)實際情況選擇多種存儲引擎進行組合。以下是幾種常用的存儲引擎的使用環(huán)境。
- InnoDB : 是Mysql的默認存儲引擎，用于事務處理應用程序，支持外鍵。如果應用對事務的完整性有比較高的要求，在并發(fā)條件下要求數(shù)據(jù)的一致性，數(shù)據(jù)操作除了插入和查詢意外，還包含很多的更新、刪除操作，那么InnoDB存儲引擎是比較合適的選擇。InnoDB存儲引擎除了有效的降低由于刪除和更新導致的鎖定， 還可以確保事務的完整提交和回滾，對于類似于計費系統(tǒng)或者財務系統(tǒng)等對數(shù)據(jù)準確性要求比較高的系統(tǒng)，InnoDB是最合適的選擇。
- MyISAM ： 如果應用是以讀操作和插入操作為主，只有很少的更新和刪除操作，并且對事務的完整性、并發(fā)性要求不是很高，那么選擇這個存儲引擎是非常合適的。
- MEMORY：將所有數(shù)據(jù)保存在RAM中，在需要快速定位記錄和其他類似數(shù)據(jù)環(huán)境下，可以提供幾塊的訪問。MEMORY的缺陷就是對表的大小有限制，太大的表無法緩存在內存中，其次是要確保表的數(shù)據(jù)可以恢復，數(shù)據(jù)庫異常終止后表中的數(shù)據(jù)是可以恢復的。MEMORY表通常用于更新不太頻繁的小表，用以快速得到訪問結果。
- MERGE：用于將一系列等同的MyISAM表以邏輯方式組合在一起，并作為一個對象引用他們。MERGE表的優(yōu)點在于可以突破對單個MyISAM表的大小限制，并且通過將不同的表分布在多個磁盤上，可以有效的改善MERGE表的訪問效率。這對于存儲諸如數(shù)據(jù)倉儲等VLDB環(huán)境十分合適。
3. 優(yōu)化SQL步驟
在應用的的開發(fā)過程中，由于初期數(shù)據(jù)量小，開發(fā)人員寫 SQL 語句時更重視功能上的實現(xiàn)，但是當應用系統(tǒng)正式上線后，隨著生產(chǎn)數(shù)據(jù)量的急劇增長，很多 SQL 語句開始逐漸顯露出性能問題，對生產(chǎn)的影響也越來越大，此時這些有問題的 SQL 語句就成為整個系統(tǒng)性能的瓶頸，因此我們必須要對它們進行優(yōu)化，本章將詳細介紹在 MySQL 中優(yōu)化 SQL 語句的方法。
當面對一個有 SQL 性能問題的數(shù)據(jù)庫時，我們應該從何處入手來進行系統(tǒng)的分析，使得能夠盡快定位問題 SQL 并盡快解決問題。
3.1 查看SQL執(zhí)行頻率
MySQL 客戶端連接成功后，通過 show [session|global] status 命令可以提供服務器狀態(tài)信息。show [session|global] status 可以根據(jù)需要加上參數(shù)“session”或者“global”來顯示 session 級（當前連接）的計結果和 global 級（自數(shù)據(jù)庫上次啟動至今）的統(tǒng)計結果。如果不寫，默認使用參數(shù)是“session”。
下面的命令顯示了當前 session 中所有統(tǒng)計參數(shù)的值：
SQL`show status like 'Com_______'; SQL`show status like 'Innodb_rows_%';Com_xxx 表示每個 xxx 語句執(zhí)行的次數(shù)，我們通常比較關心的是以下幾個統(tǒng)計參數(shù)。
| Com_select | 執(zhí)行 select 操作的次數(shù)，一次查詢只累加 1。 |
| Com_insert | 執(zhí)行 INSERT 操作的次數(shù)，對于批量插入的 INSERT 操作，只累加一次。 |
| Com_update | 執(zhí)行 UPDATE 操作的次數(shù)。 |
| Com_delete | 執(zhí)行 DELETE 操作的次數(shù)。 |
| Innodb_rows_read | select 查詢返回的行數(shù)。 |
| Innodb_rows_inserted | 執(zhí)行 INSERT 操作插入的行數(shù)。 |
| Innodb_rows_updated | 執(zhí)行 UPDATE 操作更新的行數(shù)。 |
| Innodb_rows_deleted | 執(zhí)行 DELETE 操作刪除的行數(shù)。 |
| Connections | 試圖連接 MySQL 服務器的次數(shù)。 |
| Uptime | 服務器工作時間。 |
| Slow_queries | 慢查詢的次數(shù)。 |
Com_*** : 這些參數(shù)對于所有存儲引擎的表操作都會進行累計。
Innodb_*** : 這幾個參數(shù)只是針對InnoDB 存儲引擎的，累加的算法也略有不同。
3.2 定位低效率執(zhí)行SQL
可以通過以下兩種方式定位執(zhí)行效率較低的 SQL 語句。
- 慢查詢日志 : 通過慢查詢日志定位那些執(zhí)行效率較低的 SQL 語句，用–log-slow-queries[=file_name]選項啟動時，mysqld 寫一個包含所有執(zhí)行時間超過 long_query_time 秒的 SQL 語句的日志文件。具體可以查看本書第 26 章中日志管理的相關部分。
- show processlist : 慢查詢日志在查詢結束以后才紀錄，所以在應用反映執(zhí)行效率出現(xiàn)問題的時候查詢慢查詢日志并不能定位問題，可以使用show processlist命令查看當前MySQL在進行的線程，包括線程的狀態(tài)、是否鎖表等，可以實時地查看 SQL 的執(zhí)行情況，同時對一些鎖表操作進行優(yōu)化。
3.3 explain分析執(zhí)行計劃
通過以上步驟查詢到效率低的 SQL 語句后，可以通過 EXPLAIN或者 DESC命令獲取 MySQL如何執(zhí)行 SELECT 語句的信息，包括在 SELECT 語句執(zhí)行過程中表如何連接和連接的順序。
查詢SQL語句的執(zhí)行計劃 ：
SQL`explain select * from tb_item where id = 1;` SQLexplain select * from tb_item where title = '阿爾卡特 (OT-979) 冰川白 聯(lián)通3G手機3';| id | select查詢的序列號，是一組數(shù)字，表示的是查詢中執(zhí)行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 | 掃描行的數(shù)量 |
| extra | 執(zhí)行情況的說明和描述 |
3.3.1 環(huán)境準備
SQL`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','系統(tǒng)管理員'); 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') ;`3.3.2 explain 之 id
id 字段是 select查詢的序列號，是一組數(shù)字，表示的是查詢中執(zhí)行select子句或者是操作表的順序。id 情況有三種 ：
1） id 相同表示加載表的順序是從上到下。
SQL`explain select * from t_role r, t_user u, user_role ur where r.id = ur.role_id and u.id = ur.user_id ;`2） id 不同id值越大，優(yōu)先級越高，越先被執(zhí)行。
SQL`EXPLAIN SELECT * FROM t_role WHERE id = (SELECT role_id FROM user_role WHERE user_id = (SELECT id FROM t_user WHERE username = 'stu1'))`3） id 有相同，也有不同，同時存在。id相同的可以認為是一組，從上往下順序執(zhí)行；在所有的組中，id的值越大，優(yōu)先級越高，越先執(zhí)行。
SQL`EXPLAIN SELECT * FROM t_role r , (SELECT * FROM user_role ur WHERE ur.`user_id` = '2') a WHERE r.id = a.role_id ;`3.3.3 explain 之 select_type
表示 SELECT 的類型，常見的取值，如下表所示：
| SIMPLE | 簡單的select查詢，查詢中不包含子查詢或者UNION |
| PRIMARY | 查詢中若包含任何復雜的子查詢，最外層查詢標記為該標識 |
| SUBQUERY | 在SELECT 或 WHERE 列表中包含了子查詢 |
| DERIVED | 在FROM 列表中包含的子查詢，被標記為 DERIVED（衍生） MYSQL會遞歸執(zhí)行這些子查詢，把結果放在臨時表中 |
| UNION | 若第二個SELECT出現(xiàn)在UNION之后，則標記為UNION ； 若UNION包含在FROM子句的子查詢中，外層SELECT將被標記為 ： DERIVED |
| UNION RESULT | 從UNION表獲取結果的SELECT |
3.3.4 explain 之 table
展示這一行的數(shù)據(jù)是關于哪一張表的
3.3.5 explain 之 type
type 顯示的是訪問類型，是較為重要的一個指標，可取值為：
| NULL | MySQL不訪問任何表，索引，直接返回結果 |
| system | 表只有一行記錄(等于系統(tǒng)表)，這是const類型的特例，一般不會出現(xiàn) |
| const | 表示通過索引一次就找到了，const 用于比較primary key 或者 unique 索引。因為只匹配一行數(shù)據(jù)，所以很快。如將主鍵置于where列表中，MySQL 就能將該查詢轉換為一個常亮。const于將 “主鍵” 或 “唯一” 索引的所有部分與常量值進行比較 |
| eq_ref | 類似ref，區(qū)別在于使用的是唯一索引，使用主鍵的關聯(lián)查詢，關聯(lián)查詢出的記錄只有一條。常見于主鍵或唯一索引掃描 |
| ref | 非唯一性索引掃描，返回匹配某個單獨值的所有行。本質上也是一種索引訪問，返回所有匹配某個單獨值的所有行（多個） |
| range | 只檢索給定返回的行，使用一個索引來選擇行。 where 之后出現(xiàn) between ， < , > , in 等操作。 |
| index | index 與 ALL的區(qū)別為 index 類型只是遍歷了索引樹， 通常比ALL 快， ALL 是遍歷數(shù)據(jù)文件。 |
| all | 將遍歷全表以找到匹配的行 |
結果值從最好到最壞以此是：
PERL`NULL > system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALLsystem > const > eq_ref > ref > range > index > ALL`一般來說， 我們需要保證查詢至少達到 range 級別， 最好達到ref 。
3.3.6 explain 之 key
PROPERTIES`possible_keys : 顯示可能應用在這張表的索引， 一個或多個。 key ： 實際使用的索引， 如果為NULL， 則沒有使用索引。key_len : 表示索引中使用的字節(jié)數(shù)， 該值為索引字段最大可能長度，并非實際使用長度，在不損失精確性的前提下， 長度越短越好 。`3.3.7 explain 之 rows
掃描行的數(shù)量。
3.3.8 explain 之 extra
其他的額外的執(zhí)行計劃信息，在該列展示 。
| using filesort | 說明mysql會對數(shù)據(jù)使用一個外部的索引排序，而不是按照表內的索引順序進行讀取， 稱為 “文件排序”, 效率低。 |
| using temporary | 使用了臨時表保存中間結果，MySQL在對查詢結果排序時使用臨時表。常見于 order by 和 group by； 效率低 |
| using index | 表示相應的select操作使用了覆蓋索引， 避免訪問表的數(shù)據(jù)行， 效率不錯。 |
3.4 show profile分析SQL
Mysql從5.0.37版本開始增加了對 show profiles 和 show profile 語句的支持。show profiles 能夠在做SQL優(yōu)化時幫助我們了解時間都耗費到哪里去了。
通過 have_profiling 參數(shù)，能夠看到當前MySQL是否支持profile：
默認profiling是關閉的，可以通過set語句在Session級別開啟profiling：
SQL`set profiling=1; //開啟profiling 開關；通過profile，我們能夠更清楚地了解SQL執(zhí)行的過程。
首先，我們可以執(zhí)行一系列的操作，如下圖所示：
SQL`show databases;use db01;show tables;select * from tb_item where id < 5;select count(*) from tb_item;`執(zhí)行完上述命令之后，再執(zhí)行show profiles 指令， 來查看SQL語句執(zhí)行的耗時：
通過show profile for query query_id 語句可以查看到該SQL執(zhí)行過程中每個線程的狀態(tài)和消耗的時間：
TEX`TIP ：Sending data 狀態(tài)表示MySQL線程開始訪問數(shù)據(jù)行并把結果返回給客戶端，而不僅僅是返回個客戶端。由于在Sending data狀態(tài)下，MySQL線程往往需要做大量的磁盤讀取操作，所以經(jīng)常是整各查詢中耗時最長的狀態(tài)。在獲取到最消耗時間的線程狀態(tài)后，MySQL支持進一步選擇all、cpu、block io 、context switch、page faults等明細類型類查看MySQL在使用什么資源上耗費了過高的時間。例如，選擇查看CPU的耗費時間 ：
| Status | sql 語句執(zhí)行的狀態(tài) |
| Duration | sql 執(zhí)行過程中每一個步驟的耗時 |
| CPU_user | 當前用戶占有的cpu |
| CPU_system | 系統(tǒng)占有的cpu |
3.5 trace分析優(yōu)化器執(zhí)行計劃
MySQL5.6提供了對SQL的跟蹤trace, 通過trace文件能夠進一步了解為什么優(yōu)化器選擇A計劃, 而不是選擇B計劃。
打開trace ， 設置格式為 JSON，并設置trace最大能夠使用的內存大小，避免解析過程中因為默認內存過小而不能夠完整展示。
SQL`SET optimizer_trace="enabled=on",end_markers_in_json=on; set optimizer_trace_max_mem_size=1000000;`執(zhí)行SQL語句 ：
SQL`select * from tb_item where id < 4;`最后， 檢查information_schema.optimizer_trace就可以知道MySQL是如何執(zhí)行SQL的 ：
SQL`select * from information_schema.optimizer_trace\G;` JSON`*************************** 1. row *************************** QUERY: select * from tb_item where id < 4 TRACE: {"steps": [{"join_preparation": {"select#": 1,"steps": [{"expanded_query": "/* select#1 */ select `tb_item`.`id` AS `id`,`tb_item`.`title` AS `title`,`tb_item`.`price` AS `price`,`tb_item`.`num` AS `num`,`tb_item`.`categoryid` AS `categoryid`,`tb_item`.`status` AS `status`,`tb_item`.`sellerid` AS `sellerid`,`tb_item`.`createtime` AS `createtime`,`tb_item`.`updatetime` AS `updatetime` from `tb_item` where (`tb_item`.`id` < 4)"}] /* steps */} /* join_preparation */},{"join_optimization": {"select#": 1,"steps": [{"condition_processing": {"condition": "WHERE","original_condition": "(`tb_item`.`id` < 4)","steps": [{"transformation": "equality_propagation","resulting_condition": "(`tb_item`.`id` < 4)"},{"transformation": "constant_propagation","resulting_condition": "(`tb_item`.`id` < 4)"},{"transformation": "trivial_condition_removal","resulting_condition": "(`tb_item`.`id` < 4)"}] /* steps */} /* condition_processing */},{"table_dependencies": [{"table": "`tb_item`","row_may_be_null": false,"map_bit": 0,"depends_on_map_bits": [] /* depends_on_map_bits */}] /* table_dependencies */},{"ref_optimizer_key_uses": [] /* ref_optimizer_key_uses */},{"rows_estimation": [{"table": "`tb_item`","range_analysis": {"table_scan": {"rows": 9816098,"cost": 2.04e6} /* table_scan */,"potential_range_indices": [{"index": "PRIMARY","usable": true,"key_parts": ["id"] /* key_parts */}] /* potential_range_indices */,"setup_range_conditions": [] /* setup_range_conditions */,"group_index_range": {"chosen": false,"cause": "not_group_by_or_distinct"} /* group_index_range */,"analyzing_range_alternatives": {"range_scan_alternatives": [{"index": "PRIMARY","ranges": ["id < 4"] /* ranges */,"index_dives_for_eq_ranges": true,"rowid_ordered": true,"using_mrr": false,"index_only": false,"rows": 3,"cost": 1.6154,"chosen": true}] /* range_scan_alternatives */,"analyzing_roworder_intersect": {"usable": false,"cause": "too_few_roworder_scans"} /* analyzing_roworder_intersect */} /* analyzing_range_alternatives */,"chosen_range_access_summary": {"range_access_plan": {"type": "range_scan","index": "PRIMARY","rows": 3,"ranges": ["id < 4"] /* ranges */} /* range_access_plan */,"rows_for_plan": 3,"cost_for_plan": 1.6154,"chosen": true} /* chosen_range_access_summary */} /* range_analysis */}] /* rows_estimation */},{"considered_execution_plans": [{"plan_prefix": [] /* plan_prefix */,"table": "`tb_item`","best_access_path": {"considered_access_paths": [{"access_type": "range","rows": 3,"cost": 2.2154,"chosen": true}] /* considered_access_paths */} /* best_access_path */,"cost_for_plan": 2.2154,"rows_for_plan": 3,"chosen": true}] /* considered_execution_plans */},{"attaching_conditions_to_tables": {"original_condition": "(`tb_item`.`id` < 4)","attached_conditions_computation": [] /* attached_conditions_computation */,"attached_conditions_summary": [{"table": "`tb_item`","attached": "(`tb_item`.`id` < 4)"}] /* attached_conditions_summary */} /* attaching_conditions_to_tables */},{"refine_plan": [{"table": "`tb_item`","access_type": "range"}] /* refine_plan */}] /* steps */} /* join_optimization */},{"join_execution": {"select#": 1,"steps": [] /* steps */} /* join_execution */}] /* steps */ }4. 索引的使用
索引是數(shù)據(jù)庫優(yōu)化最常用也是最重要的手段之一, 通過索引通常可以幫助用戶解決大多數(shù)的MySQL的性能優(yōu)化問題。
4.1 驗證索引提升查詢效率
在我們準備的表結構tb_item 中， 一共存儲了 300 萬記錄；
A. 根據(jù)ID查詢
SQL`select * from tb_item where id = 1999\G;查詢速度很快， 接近0s ， 主要的原因是因為id為主鍵， 有索引；
2). 根據(jù) title 進行精確查詢【白嫖資料】
SQL`select * from tb_item where title = 'iphoneX 移動3G 32G941'\G;查看SQL語句的執(zhí)行計劃 ：
處理方案 ， 針對title字段， 創(chuàng)建索引 ：
SQL`create index idx_item_title on tb_item(title);索引創(chuàng)建完成之后，再次進行查詢 ：
通過explain ， 查看執(zhí)行計劃，執(zhí)行SQL時使用了剛才創(chuàng)建的索引【白嫖資料】
4.2 索引的使用
4.2.1 準備環(huán)境
SQL`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);`4.2.2 避免索引失效
1). 全值匹配 ，對索引中所有列都指定具體值。
改情況下，索引生效，執(zhí)行效率高。
SQLexplain select * from tb_seller where name='小米科技' and status='1' and address='北京市'\G;2). 最左前綴法則
如果索引了多列，要遵守最左前綴法則。指的是查詢從索引的最左前列開始，并且不跳過索引中的列。
匹配最左前綴法則，走索引：
違法最左前綴法則 ， 索引失效：
如果符合最左法則，但是出現(xiàn)跳躍某一列，只有最左列索引生效：
3). 范圍查詢右邊的列，不能使用索引 。
根據(jù)前面的兩個字段name ， status 查詢是走索引的， 但是最后一個條件address 沒有用到索引。
4). 不要在索引列上進行運算操作， 索引將失效。
5). 字符串不加單引號，造成索引失效。
由于，在查詢是，沒有對字符串加單引號，MySQL的查詢優(yōu)化器，會自動的進行類型轉換，造成索引失效。
6). 盡量使用覆蓋索引，避免select *
盡量使用覆蓋索引（只訪問索引的查詢（索引列完全包含查詢列）），減少select * 。
如果查詢列，超出索引列，也會降低性能。
POWERSHELLTIP : using index ：使用覆蓋索引的時候就會出現(xiàn)using where：在查找使用索引的情況下，需要回表去查詢所需的數(shù)據(jù)using index condition：查找使用了索引，但是需要回表查詢數(shù)據(jù)using index ; using where：查找使用了索引，但是需要的數(shù)據(jù)都在索引列中能找到，所以不需要回表查詢數(shù)據(jù)7). 用or分割開的條件， 如果or前的條件中的列有索引，而后面的列中沒有索引，那么涉及的索引都不會被用到。
示例，name字段是索引列 ， 而createtime不是索引列，中間是or進行連接是不走索引的 ：
SQLexplain select * from tb_seller where name='黑馬程序員' or createtime = '2088-01-01 12:00:00'\G;8). 以%開頭的Like模糊查詢，索引失效。
如果僅僅是尾部模糊匹配，索引不會失效。如果是頭部模糊匹配，索引失效。
解決方案 ：
通過覆蓋索引來解決
9). 如果MySQL評估使用索引比全表更慢，則不使用索引。
10). is NULL ， is NOT NULL 有時索引失效。
11). in 走索引， not in 索引失效。
12). 單列索引和復合索引。
盡量使用復合索引，而少使用單列索引 。
創(chuàng)建復合索引
SQL`create index idx_name_sta_address on tb_seller(name, status, address);就相當于創(chuàng)建了三個索引 ： namename + statusname + status + address創(chuàng)建單列索引
SQLcreate 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);數(shù)據(jù)庫會選擇一個最優(yōu)的索引（辨識度最高索引）來使用，并不會使用全部索引 。
4.3 查看索引使用情況
SQLshow status like 'Handler_read%'; show global status like 'Handler_read%'; PROPERTIESHandler_read_first：索引中第一條被讀的次數(shù)。如果較高，表示服務器正執(zhí)行大量全索引掃描（這個值越低越好）。Handler_read_key：如果索引正在工作，這個值代表一個行被索引值讀的次數(shù)，如果值越低，表示索引得到的性能改善不高，因為索引不經(jīng)常使用（這個值越高越好）。Handler_read_next ：按照鍵順序讀下一行的請求數(shù)。如果你用范圍約束或如果執(zhí)行索引掃描來查詢索引列，該值增加。Handler_read_prev：按照鍵順序讀前一行的請求數(shù)。該讀方法主要用于優(yōu)化ORDER BY ... DESC。Handler_read_rnd ：根據(jù)固定位置讀一行的請求數(shù)。如果你正執(zhí)行大量查詢并需要對結果進行排序該值較高。你可能使用了大量需要MySQL掃描整個表的查詢或你的連接沒有正確使用鍵。這個值較高，意味著運行效率低，應該建立索引來補救。Handler_read_rnd_next：在數(shù)據(jù)文件中讀下一行的請求數(shù)。如果你正進行大量的表掃描，該值較高。通常說明你的表索引不正確或寫入的查詢沒有利用索引。`5. SQL優(yōu)化
5.1 大批量插入數(shù)據(jù)
環(huán)境準備 ：
SQLCREATE TABLE `tb_user_2` (`id` int(11) NOT NULL AUTO_INCREMENT,`username` varchar(45) NOT NULL,`password` varchar(96) NOT NULL,`name` varchar(45) NOT NULL,`birthday` datetime DEFAULT NULL,`sex` char(1) DEFAULT NULL,`email` varchar(45) DEFAULT NULL,`phone` varchar(45) DEFAULT NULL,`qq` varchar(32) DEFAULT NULL,`status` varchar(32) NOT NULL COMMENT '用戶狀態(tài)',`create_time` datetime NOT NULL,`update_time` datetime DEFAULT NULL,PRIMARY KEY (`id`),UNIQUE KEY `unique_user_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ;當使用load 命令導入數(shù)據(jù)的時候，適當?shù)脑O置可以提高導入的效率。
對于 InnoDB 類型的表，有以下幾種方式可以提高導入的效率：
1） 主鍵順序插入
因為InnoDB類型的表是按照主鍵的順序保存的，所以將導入的數(shù)據(jù)按照主鍵的順序排列，可以有效的提高導入數(shù)據(jù)的效率。如果InnoDB表沒有主鍵，那么系統(tǒng)會自動默認創(chuàng)建一個內部列作為主鍵，所以如果可以給表創(chuàng)建一個主鍵，將可以利用這點，來提高導入數(shù)據(jù)的效率。
LUA`腳本文件介紹 :sql1.log ----> 主鍵有序sql2.log ----> 主鍵無序插入ID順序排列數(shù)據(jù)：
插入ID無序排列數(shù)據(jù)：
2） 關閉唯一性校驗
在導入數(shù)據(jù)前執(zhí)行 SET UNIQUE_CHECKS=0，關閉唯一性校驗，在導入結束后執(zhí)行SET UNIQUE_CHECKS=1，恢復唯一性校驗，可以提高導入的效率。
3） 手動提交事務
如果應用使用自動提交的方式，建議在導入前執(zhí)行 SET AUTOCOMMIT=0，關閉自動提交，導入結束后再執(zhí)行 SET AUTOCOMMIT=1，打開自動提交，也可以提高導入的效率。
5.2 優(yōu)化insert語句
當進行數(shù)據(jù)的insert操作的時候，可以考慮采用以下幾種優(yōu)化方案。
-
如果需要同時對一張表插入很多行數(shù)據(jù)時，應該盡量使用多個值表的insert語句，這種方式將大大的縮減客戶端與數(shù)據(jù)庫之間的連接、關閉等消耗。使得效率比分開執(zhí)行的單個insert語句快。
示例， 原始方式為：
- 在事務中進行數(shù)據(jù)插入。
- 數(shù)據(jù)有序插入
5.3 優(yōu)化order by語句
5.3.1 環(huán)境準備
SQLCREATE TABLE `emp` (`id` int(11) NOT NULL AUTO_INCREMENT,`name` varchar(100) NOT NULL,`age` int(3) NOT NULL,`salary` int(11) DEFAULT NULL,PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;insert into `emp` (`id`, `name`, `age`, `salary`) values('1','Tom','25','2300'); insert into `emp` (`id`, `name`, `age`, `salary`) values('2','Jerry','30','3500'); insert into `emp` (`id`, `name`, `age`, `salary`) values('3','Luci','25','2800'); insert into `emp` (`id`, `name`, `age`, `salary`) values('4','Jay','36','3500'); insert into `emp` (`id`, `name`, `age`, `salary`) values('5','Tom2','21','2200'); insert into `emp` (`id`, `name`, `age`, `salary`) values('6','Jerry2','31','3300'); insert into `emp` (`id`, `name`, `age`, `salary`) values('7','Luci2','26','2700'); insert into `emp` (`id`, `name`, `age`, `salary`) values('8','Jay2','33','3500'); insert into `emp` (`id`, `name`, `age`, `salary`) values('9','Tom3','23','2400'); insert into `emp` (`id`, `name`, `age`, `salary`) values('10','Jerry3','32','3100'); insert into `emp` (`id`, `name`, `age`, `salary`) values('11','Luci3','26','2900'); insert into `emp` (`id`, `name`, `age`, `salary`) values('12','Jay3','37','4500');create index idx_emp_age_salary on emp(age,salary);5.3.2 兩種排序方式
1). 第一種是通過對返回數(shù)據(jù)進行排序，也就是通常說的 filesort 排序，所有不是通過索引直接返回排序結果的排序都叫 FileSort 排序。
2). 第二種通過有序索引順序掃描直接返回有序數(shù)據(jù)，這種情況即為 using index，不需要額外排序，操作效率高。
多字段排序
了解了MySQL的排序方式，優(yōu)化目標就清晰了：盡量減少額外的排序，通過索引直接返回有序數(shù)據(jù)。where 條件和Order by 使用相同的索引，并且Order By 的順序和索引順序相同， 并且Order by 的字段都是升序，或者都是降序。否則肯定需要額外的操作，這樣就會出現(xiàn)FileSort。
5.3.3 Filesort 的優(yōu)化
通過創(chuàng)建合適的索引，能夠減少 Filesort 的出現(xiàn)，但是在某些情況下，條件限制不能讓Filesort消失，那就需要加快 Filesort的排序操作。對于Filesort ， MySQL 有兩種排序算法：
1） 兩次掃描算法 ：MySQL4.1 之前，使用該方式排序。首先根據(jù)條件取出排序字段和行指針信息，然后在排序區(qū) sort buffer 中排序，如果sort buffer不夠，則在臨時表 temporary table 中存儲排序結果。完成排序之后，再根據(jù)行指針回表讀取記錄，該操作可能會導致大量隨機I/O操作。
2）一次掃描算法：一次性取出滿足條件的所有字段，然后在排序區(qū) sort buffer 中排序后直接輸出結果集。排序時內存開銷較大，但是排序效率比兩次掃描算法要高。
MySQL 通過比較系統(tǒng)變量 max_length_for_sort_data 的大小和Query語句取出的字段總大小， 來判定是否那種排序算法，如果max_length_for_sort_data 更大，那么使用第二種優(yōu)化之后的算法；否則使用第一種。
可以適當提高 sort_buffer_size 和 max_length_for_sort_data 系統(tǒng)變量，來增大排序區(qū)的大小，提高排序的效率。
5.4 優(yōu)化group by 語句
由于GROUP BY 實際上也同樣會進行排序操作，而且與ORDER BY 相比，GROUP BY 主要只是多了排序之后的分組操作。當然，如果在分組的時候還使用了其他的一些聚合函數(shù)，那么還需要一些聚合函數(shù)的計算。所以，在GROUP BY 的實現(xiàn)過程中，與 ORDER BY 一樣也可以利用到索引。
如果查詢包含 group by 但是用戶想要避免排序結果的消耗， 則可以執(zhí)行order by null 禁止排序。如下 ：
SQL`drop index idx_emp_age_salary on emp;explain select age,count(*) from emp group by age;`優(yōu)化后
SQLexplain select age,count(*) from emp group by age order by null;從上面的例子可以看出，第一個SQL語句需要進行"filesort"，而第二個SQL由于order by null 不需要進行 “filesort”， 而上文提過Filesort往往非常耗費時間。
創(chuàng)建索引 ：
SQLcreate index idx_emp_age_salary on emp(age,salary)；5.5 優(yōu)化嵌套查詢
Mysql4.1版本之后，開始支持SQL的子查詢。這個技術可以使用SELECT語句來創(chuàng)建一個單列的查詢結果，然后把這個結果作為過濾條件用在另一個查詢中。使用子查詢可以一次性的完成很多邏輯上需要多個步驟才能完成的SQL操作，同時也可以避免事務或者表鎖死，并且寫起來也很容易。但是，有些情況下，子查詢是可以被更高效的連接（JOIN）替代。
示例 ，查找有角色的所有的用戶信息 :
SQL`explain select * from t_user where id in (select user_id from user_role );執(zhí)行計劃為 :
優(yōu)化后 :
SQL`explain select * from t_user u , user_role ur where u.id = ur.user_id;連接(Join)查詢之所以更有效率一些 ，是因為MySQL不需要在內存中創(chuàng)建臨時表來完成這個邏輯上需要兩個步驟的查詢工作。
5.6 優(yōu)化OR條件
對于包含OR的查詢子句，如果要利用索引，則OR之間的每個條件列都必須用到索引 ， 而且不能使用到復合索引； 如果沒有索引，則應該考慮增加索引。
獲取 emp 表中的所有的索引 ：
示例 ：
SQL`explain select * from emp where id = 1 or age = 30;建議使用 union 替換 or ：
我們來比較下重要指標，發(fā)現(xiàn)主要差別是 type 和 ref 這兩項
type 顯示的是訪問類型，是較為重要的一個指標，結果值從好到壞依次是：
PERL`system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALLUNION 語句的 type 值為 ref，OR 語句的 type 值為 range，可以看到這是一個很明顯的差距
UNION 語句的 ref 值為 const，OR 語句的 type 值為 null，const 表示是常量值引用，非常快
這兩項的差距就說明了 UNION 要優(yōu)于 OR 。
5.7 優(yōu)化分頁查詢
一般分頁查詢時，通過創(chuàng)建覆蓋索引能夠比較好地提高性能。一個常見又非常頭疼的問題就是 limit 2000000,10 ，此時需要MySQL排序前2000010 記錄，僅僅返回2000000 - 2000010 的記錄，其他記錄丟棄，查詢排序的代價非常大 。
5.7.1 優(yōu)化思路一
在索引上完成排序分頁操作，最后根據(jù)主鍵關聯(lián)回原表查詢所需要的其他列內容。
5.7.2 優(yōu)化思路二
該方案適用于主鍵自增的表，可以把Limit 查詢轉換成某個位置的查詢 。
5.8 使用SQL提示
SQL提示，是優(yōu)化數(shù)據(jù)庫的一個重要手段，簡單來說，就是在SQL語句中加入一些人為的提示來達到優(yōu)化操作的目的。
5.8.1 USE INDEX
在查詢語句中表名的后面，添加 use index 來提供希望MySQL去參考的索引列表，就可以讓MySQL不再考慮其他可用的索引。
SQLcreate index idx_seller_name on tb_seller(name);5.8.2 IGNORE INDEX
如果用戶只是單純的想讓MySQL忽略一個或者多個索引，則可以使用 ignore index 作為 hint 。
SQLexplain select * from tb_seller ignore index(idx_seller_name) where name = '小米科技';5.8.3 FORCE INDEX
為強制MySQL使用一個特定的索引，可在查詢中使用 force index 作為hint 。
SQLcreate index idx_seller_address on tb_seller(address);最后，祝大家早日學有所成，拿到滿意offer
總結
以上是生活随笔為你收集整理的超详细图解！【MySQL进阶篇】SQL优化-索引-存储引擎的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 闪付卡和银行卡的区别？
- 下一篇： 超详细图解！【MySQL进阶篇】存储过程