超详细图解！【MySQL进阶篇】SQL优化-索引-存储引擎
1. Mysql的體系結構概覽
整個MySQL Server由以下組成
- Connection Pool : 連接池組件
- Management Services & Utilities : 管理服務和工具組件
- SQL Interface : SQL接口組件
- Parser : 查詢分析器組件
- Optimizer : 優化器組件
- Caches & Buffers : 緩沖池組件
- Pluggable Storage Engines : 存儲引擎
- File System : 文件系統
1） 連接層
最上層是一些客戶端和鏈接服務，包含本地sock 通信和大多數基于客戶端/服務端工具實現的類似于 TCP/IP的通信。主要完成一些類似于連接處理、授權認證、及相關的安全方案。在該層上引入了線程池的概念，為通過認證安全接入的客戶端提供線程。同樣在該層上可以實現基于SSL的安全鏈接。服務器也會為安全接入的每個客戶端驗證它所具有的操作權限。
2） 服務層
第二層架構主要完成大多數的核心服務功能，如SQL接口，并完成緩存的查詢，SQL的分析和優化，部分內置函數的執行。所有跨存儲引擎的功能也在這一層實現，如 過程、函數等。在該層，服務器會解析查詢并創建相應的內部解析樹，并對其完成相應的優化如確定表的查詢的順序，是否利用索引等， 最后生成相應的執行操作。如果是select語句，服務器還會查詢內部的緩存，如果緩存空間足夠大，這樣在解決大量讀操作的環境中能夠很好的提升系統的性能。
3） 引擎層
存儲引擎層， 存儲引擎真正的負責了MySQL中數據的存儲和提取，服務器通過API和存儲引擎進行通信。不同的存儲引擎具有不同的功能，這樣我們可以根據自己的需要，來選取合適的存儲引擎。
4）存儲層
數據存儲層， 主要是將數據存儲在文件系統之上，并完成與存儲引擎的交互。
和其他數據庫相比，MySQL有點與眾不同，它的架構可以在多種不同場景中應用并發揮良好作用。主要體現在存儲引擎上，插件式的存儲引擎架構，將查詢處理和其他的系統任務以及數據的存儲提取分離。這種架構可以根據業務的需求和實際需要選擇合適的存儲引擎。
2. 存儲引擎
2.1 存儲引擎概述
? 和大多數的數據庫不同, MySQL中有一個存儲引擎的概念, 針對不同的存儲需求可以選擇最優的存儲引擎。
? 存儲引擎就是存儲數據，建立索引，更新查詢數據等等技術的實現方式 。存儲引擎是基于表的，而不是基于庫的。所以存儲引擎也可被稱為表類型。
? Oracle，SqlServer等數據庫只有一種存儲引擎。MySQL提供了插件式的存儲引擎架構。所以MySQL存在多種存儲引擎，可以根據需要使用相應引擎，或者編寫存儲引擎。
? MySQL5.0支持的存儲引擎包含 ： InnoDB 、MyISAM 、BDB、MEMORY、MERGE、EXAMPLE、NDB Cluster、ARCHIVE、CSV、BLACKHOLE、FEDERATED等，其中InnoDB和BDB提供事務安全表，其他存儲引擎是非事務安全表。
可以通過指定 show engines ， 來查詢當前數據庫支持的存儲引擎 ：
創建新表時如果不指定存儲引擎，那么系統就會使用默認的存儲引擎，MySQL5.5之前的默認存儲引擎是MyISAM，5.5之后就改為了InnoDB。
查看Mysql數據庫默認的存儲引擎 ， 指令 ：
SQLshow variables like '%storage_engine%' ；2.2 各種存儲引擎特性
下面重點介紹幾種常用的存儲引擎， 并對比各個存儲引擎之間的區別， 如下表所示 ：
| 存儲限制 | 64TB | 有 | 有 | 沒有 | 有 |
| 事務安全 | 支持 | ||||
| 鎖機制 | 行鎖(適合高并發) | 表鎖 | 表鎖 | 表鎖 | 行鎖 |
| B樹索引 | 支持 | 支持 | 支持 | 支持 | 支持 |
| 哈希索引 | 支持 | ||||
| 全文索引 | 支持(5.6版本之后) | 支持 | |||
| 集群索引 | 支持 | ||||
| 數據索引 | 支持 | 支持 | 支持 | ||
| 索引緩存 | 支持 | 支持 | 支持 | 支持 | 支持 |
| 數據可壓縮 | 支持 | ||||
| 空間使用 | 高 | 低 | N/A | 低 | 低 |
| 內存使用 | 高 | 低 | 中等 | 低 | 高 |
| 批量插入速度 | 低 | 高 | 高 | 高 | 高 |
| 支持外鍵 | 支持 |
下面我們將重點介紹最長使用的兩種存儲引擎： InnoDB、MyISAM ， 另外兩種 MEMORY、MERGE ， 了解即可。
2.2.1 InnoDB
? InnoDB存儲引擎是Mysql的默認存儲引擎。InnoDB存儲引擎提供了具有提交、回滾、崩潰恢復能力的事務安全。但是對比MyISAM的存儲引擎，InnoDB寫的處理效率差一些，并且會占用更多的磁盤空間以保留數據和索引。
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;測試，發現在InnoDB中是存在事務的 ；
外鍵約束
? MySQL支持外鍵的存儲引擎只有InnoDB ， 在創建外鍵的時候， 要求父表必須有對應的索引 ， 子表在創建外鍵的時候， 也會自動的創建對應的索引。
? 下面兩張表中 ， 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);`在創建索引時， 可以指定在刪除、更新父表時，對子表進行的相應操作，包括 RESTRICT、CASCADE、SET NULL 和 NO ACTION。
RESTRICT和NO ACTION相同， 是指限制在子表有關聯記錄的情況下， 父表不能更新；
CASCADE表示父表在更新或者刪除時，更新或者刪除子表對應的記錄；
SET NULL 則表示父表在更新或者刪除的時候，子表的對應字段被SET NULL 。
針對上面創建的兩個表， 子表的外鍵指定是ON DELETE RESTRICT ON UPDATE CASCADE 方式的， 那么在主表刪除記錄的時候， 如果子表有對應記錄， 則不允許刪除， 主表在更新記錄的時候， 如果子表有對應記錄， 則子表對應更新 。
表中數據如下圖所示 ：
外鍵信息可以使用如下兩種方式查看 ：
SQL`show create table city_innodb ;`刪除country_id為1 的country數據：
SQLdelete from country_innodb where country_id = 1;更新主表country表的字段 country_id :
SQL`update country_innodb set country_id = 100 where country_id = 1;更新后， 子表的數據信息為 ：
存儲方式
InnoDB 存儲表和索引有以下兩種方式 ：
①. 使用共享表空間存儲， 這種方式創建的表的表結構保存在.frm文件中， 數據和索引保存在 innodb_data_home_dir 和 innodb_data_file_path定義的表空間中，可以是多個文件。
②. 使用多表空間存儲， 這種方式創建的表的表結構仍然存在 .frm 文件中，但是每個表的數據和索引單獨保存在 .ibd 中。
2.2.2 MyISAM
? MyISAM 不支持事務、也不支持外鍵，其優勢是訪問的速度快，對事務的完整性沒有要求或者以SELECT、INSERT為主的應用基本上都可以使用這個引擎來創建表 。有以下兩個比較重要的特點：
不支持事務
SQL`create table goods_myisam(id int NOT NULL AUTO_INCREMENT,name varchar(20) NOT NULL,primary key(id) )ENGINE=myisam DEFAULT CHARSET=utf8;通過測試，我們發現，在MyISAM存儲引擎中，是沒有事務控制的 ；
文件存儲方式
每個MyISAM在磁盤上存儲成3個文件，其文件名都和表名相同，但拓展名分別是 ：
.frm (存儲表定義)；
.MYD(MYData , 存儲數據)；
.MYI(MYIndex , 存儲索引)；
2.2.3 MEMORY
? Memory存儲引擎將表的數據存放在內存中。每個MEMORY表實際對應一個磁盤文件，格式是.frm ，該文件中只存儲表的結構，而其數據文件，都是存儲在內存中，這樣有利于數據的快速處理，提高整個表的效率。MEMORY 類型的表訪問非常地快，因為他的數據是存放在內存中的，并且默認使用HASH索引 ， 但是服務一旦關閉，表中的數據就會丟失。
2.2.4 MERGE
? MERGE存儲引擎是一組MyISAM表的組合，這些MyISAM表必須結構完全相同，MERGE表本身并沒有存儲數據，對MERGE類型的表可以進行查詢、更新、刪除操作，這些操作實際上是對內部的MyISAM表進行的。
? 對于MERGE類型表的插入操作，是通過INSERT_METHOD子句定義插入的表，可以有3個不同的值，使用FIRST 或 LAST 值使得插入操作被相應地作用在第一或者最后一個表上，不定義這個子句或者定義為NO，表示不能對這個MERGE表執行插入操作。
? 可以對MERGE表進行DROP操作，但是這個操作只是刪除MERGE表的定義，對內部的表是沒有任何影響的。
下面是一個創建和使用MERGE表的示例 ：
1）. 創建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張表中的數據。
order_1990中的數據 ：
order_1991中的數據 ：
order_all中的數據 ：
?
4）. 往order_all中插入一條記錄 ，由于在MERGE表定義時，INSERT_METHOD 選擇的是LAST，那么插入的數據會想最后一張表中插入。
SQLinsert into order_all values(100,10000.0,'西安')；2.3 存儲引擎的選擇
? 在選擇存儲引擎時，應該根據應用系統的特點選擇合適的存儲引擎。對于復雜的應用系統，還可以根據實際情況選擇多種存儲引擎進行組合。以下是幾種常用的存儲引擎的使用環境。
- InnoDB : 是Mysql的默認存儲引擎，用于事務處理應用程序，支持外鍵。如果應用對事務的完整性有比較高的要求，在并發條件下要求數據的一致性，數據操作除了插入和查詢意外，還包含很多的更新、刪除操作，那么InnoDB存儲引擎是比較合適的選擇。InnoDB存儲引擎除了有效的降低由于刪除和更新導致的鎖定， 還可以確保事務的完整提交和回滾，對于類似于計費系統或者財務系統等對數據準確性要求比較高的系統，InnoDB是最合適的選擇。
- MyISAM ： 如果應用是以讀操作和插入操作為主，只有很少的更新和刪除操作，并且對事務的完整性、并發性要求不是很高，那么選擇這個存儲引擎是非常合適的。
- MEMORY：將所有數據保存在RAM中，在需要快速定位記錄和其他類似數據環境下，可以提供幾塊的訪問。MEMORY的缺陷就是對表的大小有限制，太大的表無法緩存在內存中，其次是要確保表的數據可以恢復，數據庫異常終止后表中的數據是可以恢復的。MEMORY表通常用于更新不太頻繁的小表，用以快速得到訪問結果。
- MERGE：用于將一系列等同的MyISAM表以邏輯方式組合在一起，并作為一個對象引用他們。MERGE表的優點在于可以突破對單個MyISAM表的大小限制，并且通過將不同的表分布在多個磁盤上，可以有效的改善MERGE表的訪問效率。這對于存儲諸如數據倉儲等VLDB環境十分合適。
3. 優化SQL步驟
在應用的的開發過程中，由于初期數據量小，開發人員寫 SQL 語句時更重視功能上的實現，但是當應用系統正式上線后，隨著生產數據量的急劇增長，很多 SQL 語句開始逐漸顯露出性能問題，對生產的影響也越來越大，此時這些有問題的 SQL 語句就成為整個系統性能的瓶頸，因此我們必須要對它們進行優化，本章將詳細介紹在 MySQL 中優化 SQL 語句的方法。
當面對一個有 SQL 性能問題的數據庫時，我們應該從何處入手來進行系統的分析，使得能夠盡快定位問題 SQL 并盡快解決問題。
3.1 查看SQL執行頻率
MySQL 客戶端連接成功后，通過 show [session|global] status 命令可以提供服務器狀態信息。show [session|global] status 可以根據需要加上參數“session”或者“global”來顯示 session 級（當前連接）的計結果和 global 級（自數據庫上次啟動至今）的統計結果。如果不寫，默認使用參數是“session”。
下面的命令顯示了當前 session 中所有統計參數的值：
SQL`show status like 'Com_______'; SQL`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 存儲引擎的，累加的算法也略有不同。
3.2 定位低效率執行SQL
可以通過以下兩種方式定位執行效率較低的 SQL 語句。
- 慢查詢日志 : 通過慢查詢日志定位那些執行效率較低的 SQL 語句，用–log-slow-queries[=file_name]選項啟動時，mysqld 寫一個包含所有執行時間超過 long_query_time 秒的 SQL 語句的日志文件。具體可以查看本書第 26 章中日志管理的相關部分。
- show processlist : 慢查詢日志在查詢結束以后才紀錄，所以在應用反映執行效率出現問題的時候查詢慢查詢日志并不能定位問題，可以使用show processlist命令查看當前MySQL在進行的線程，包括線程的狀態、是否鎖表等，可以實時地查看 SQL 的執行情況，同時對一些鎖表操作進行優化。
3.3 explain分析執行計劃
通過以上步驟查詢到效率低的 SQL 語句后，可以通過 EXPLAIN或者 DESC命令獲取 MySQL如何執行 SELECT 語句的信息，包括在 SELECT 語句執行過程中表如何連接和連接的順序。
查詢SQL語句的執行計劃 ：
SQL`explain select * from tb_item where id = 1;` SQLexplain select * from tb_item where title = '阿爾卡特 (OT-979) 冰川白 聯通3G手機3';| 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 | 執行情況的說明和描述 |
3.3.1 環境準備
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','系統管理員'); 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查詢的序列號，是一組數字，表示的是查詢中執行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值越大，優先級越高，越先被執行。
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相同的可以認為是一組，從上往下順序執行；在所有的組中，id的值越大，優先級越高，越先執行。
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會遞歸執行這些子查詢，把結果放在臨時表中 |
| UNION | 若第二個SELECT出現在UNION之后，則標記為UNION ； 若UNION包含在FROM子句的子查詢中，外層SELECT將被標記為 ： DERIVED |
| UNION RESULT | 從UNION表獲取結果的SELECT |
3.3.4 explain 之 table
展示這一行的數據是關于哪一張表的
3.3.5 explain 之 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 | 將遍歷全表以找到匹配的行 |
結果值從最好到最壞以此是：
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 : 表示索引中使用的字節數， 該值為索引字段最大可能長度，并非實際使用長度，在不損失精確性的前提下， 長度越短越好 。`3.3.7 explain 之 rows
掃描行的數量。
3.3.8 explain 之 extra
其他的額外的執行計劃信息，在該列展示 。
| using filesort | 說明mysql會對數據使用一個外部的索引排序，而不是按照表內的索引順序進行讀取， 稱為 “文件排序”, 效率低。 |
| using temporary | 使用了臨時表保存中間結果，MySQL在對查詢結果排序時使用臨時表。常見于 order by 和 group by； 效率低 |
| using index | 表示相應的select操作使用了覆蓋索引， 避免訪問表的數據行， 效率不錯。 |
3.4 show profile分析SQL
Mysql從5.0.37版本開始增加了對 show profiles 和 show profile 語句的支持。show profiles 能夠在做SQL優化時幫助我們了解時間都耗費到哪里去了。
通過 have_profiling 參數，能夠看到當前MySQL是否支持profile：
默認profiling是關閉的，可以通過set語句在Session級別開啟profiling：
SQL`set profiling=1; //開啟profiling 開關；通過profile，我們能夠更清楚地了解SQL執行的過程。
首先，我們可以執行一系列的操作，如下圖所示：
SQL`show databases;use db01;show tables;select * from tb_item where id < 5;select count(*) from tb_item;`執行完上述命令之后，再執行show profiles 指令， 來查看SQL語句執行的耗時：
通過show profile for query query_id 語句可以查看到該SQL執行過程中每個線程的狀態和消耗的時間：
TEX`TIP ：Sending data 狀態表示MySQL線程開始訪問數據行并把結果返回給客戶端，而不僅僅是返回個客戶端。由于在Sending data狀態下，MySQL線程往往需要做大量的磁盤讀取操作，所以經常是整各查詢中耗時最長的狀態。在獲取到最消耗時間的線程狀態后，MySQL支持進一步選擇all、cpu、block io 、context switch、page faults等明細類型類查看MySQL在使用什么資源上耗費了過高的時間。例如，選擇查看CPU的耗費時間 ：
| Status | sql 語句執行的狀態 |
| Duration | sql 執行過程中每一個步驟的耗時 |
| CPU_user | 當前用戶占有的cpu |
| CPU_system | 系統占有的cpu |
3.5 trace分析優化器執行計劃
MySQL5.6提供了對SQL的跟蹤trace, 通過trace文件能夠進一步了解為什么優化器選擇A計劃, 而不是選擇B計劃。
打開trace ， 設置格式為 JSON，并設置trace最大能夠使用的內存大小，避免解析過程中因為默認內存過小而不能夠完整展示。
SQL`SET optimizer_trace="enabled=on",end_markers_in_json=on; set optimizer_trace_max_mem_size=1000000;`執行SQL語句 ：
SQL`select * from tb_item where id < 4;`最后， 檢查information_schema.optimizer_trace就可以知道MySQL是如何執行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. 索引的使用
索引是數據庫優化最常用也是最重要的手段之一, 通過索引通常可以幫助用戶解決大多數的MySQL的性能優化問題。
4.1 驗證索引提升查詢效率
在我們準備的表結構tb_item 中， 一共存儲了 300 萬記錄；
A. 根據ID查詢
SQL`select * from tb_item where id = 1999\G;查詢速度很快， 接近0s ， 主要的原因是因為id為主鍵， 有索引；
2). 根據 title 進行精確查詢【白嫖資料】
SQL`select * from tb_item where title = 'iphoneX 移動3G 32G941'\G;查看SQL語句的執行計劃 ：
處理方案 ， 針對title字段， 創建索引 ：
SQL`create index idx_item_title on tb_item(title);索引創建完成之后，再次進行查詢 ：
通過explain ， 查看執行計劃，執行SQL時使用了剛才創建的索引【白嫖資料】
4.2 索引的使用
4.2.1 準備環境
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). 全值匹配 ，對索引中所有列都指定具體值。
改情況下，索引生效，執行效率高。
SQLexplain select * from tb_seller where name='小米科技' and status='1' and address='北京市'\G;2). 最左前綴法則
如果索引了多列，要遵守最左前綴法則。指的是查詢從索引的最左前列開始，并且不跳過索引中的列。
匹配最左前綴法則，走索引：
違法最左前綴法則 ， 索引失效：
如果符合最左法則，但是出現跳躍某一列，只有最左列索引生效：
3). 范圍查詢右邊的列，不能使用索引 。
根據前面的兩個字段name ， status 查詢是走索引的， 但是最后一個條件address 沒有用到索引。
4). 不要在索引列上進行運算操作， 索引將失效。
5). 字符串不加單引號，造成索引失效。
由于，在查詢是，沒有對字符串加單引號，MySQL的查詢優化器，會自動的進行類型轉換，造成索引失效。
6). 盡量使用覆蓋索引，避免select *
盡量使用覆蓋索引（只訪問索引的查詢（索引列完全包含查詢列）），減少select * 。
如果查詢列，超出索引列，也會降低性能。
POWERSHELLTIP : using index ：使用覆蓋索引的時候就會出現using where：在查找使用索引的情況下，需要回表去查詢所需的數據using index condition：查找使用了索引，但是需要回表查詢數據using index ; using where：查找使用了索引，但是需要的數據都在索引列中能找到，所以不需要回表查詢數據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). 單列索引和復合索引。
盡量使用復合索引，而少使用單列索引 。
創建復合索引
SQL`create index idx_name_sta_address on tb_seller(name, status, address);就相當于創建了三個索引 ： namename + statusname + status + address創建單列索引
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);數據庫會選擇一個最優的索引（辨識度最高索引）來使用，并不會使用全部索引 。
4.3 查看索引使用情況
SQLshow status like 'Handler_read%'; show global status like 'Handler_read%'; PROPERTIESHandler_read_first：索引中第一條被讀的次數。如果較高，表示服務器正執行大量全索引掃描（這個值越低越好）。Handler_read_key：如果索引正在工作，這個值代表一個行被索引值讀的次數，如果值越低，表示索引得到的性能改善不高，因為索引不經常使用（這個值越高越好）。Handler_read_next ：按照鍵順序讀下一行的請求數。如果你用范圍約束或如果執行索引掃描來查詢索引列，該值增加。Handler_read_prev：按照鍵順序讀前一行的請求數。該讀方法主要用于優化ORDER BY ... DESC。Handler_read_rnd ：根據固定位置讀一行的請求數。如果你正執行大量查詢并需要對結果進行排序該值較高。你可能使用了大量需要MySQL掃描整個表的查詢或你的連接沒有正確使用鍵。這個值較高，意味著運行效率低，應該建立索引來補救。Handler_read_rnd_next：在數據文件中讀下一行的請求數。如果你正進行大量的表掃描，該值較高。通常說明你的表索引不正確或寫入的查詢沒有利用索引。`5. SQL優化
5.1 大批量插入數據
環境準備 ：
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 '用戶狀態',`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 命令導入數據的時候，適當的設置可以提高導入的效率。
對于 InnoDB 類型的表，有以下幾種方式可以提高導入的效率：
1） 主鍵順序插入
因為InnoDB類型的表是按照主鍵的順序保存的，所以將導入的數據按照主鍵的順序排列，可以有效的提高導入數據的效率。如果InnoDB表沒有主鍵，那么系統會自動默認創建一個內部列作為主鍵，所以如果可以給表創建一個主鍵，將可以利用這點，來提高導入數據的效率。
LUA`腳本文件介紹 :sql1.log ----> 主鍵有序sql2.log ----> 主鍵無序插入ID順序排列數據：
插入ID無序排列數據：
2） 關閉唯一性校驗
在導入數據前執行 SET UNIQUE_CHECKS=0，關閉唯一性校驗，在導入結束后執行SET UNIQUE_CHECKS=1，恢復唯一性校驗，可以提高導入的效率。
3） 手動提交事務
如果應用使用自動提交的方式，建議在導入前執行 SET AUTOCOMMIT=0，關閉自動提交，導入結束后再執行 SET AUTOCOMMIT=1，打開自動提交，也可以提高導入的效率。
5.2 優化insert語句
當進行數據的insert操作的時候，可以考慮采用以下幾種優化方案。
-
如果需要同時對一張表插入很多行數據時，應該盡量使用多個值表的insert語句，這種方式將大大的縮減客戶端與數據庫之間的連接、關閉等消耗。使得效率比分開執行的單個insert語句快。
示例， 原始方式為：
- 在事務中進行數據插入。
- 數據有序插入
5.3 優化order by語句
5.3.1 環境準備
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). 第一種是通過對返回數據進行排序，也就是通常說的 filesort 排序，所有不是通過索引直接返回排序結果的排序都叫 FileSort 排序。
2). 第二種通過有序索引順序掃描直接返回有序數據，這種情況即為 using index，不需要額外排序，操作效率高。
多字段排序
了解了MySQL的排序方式，優化目標就清晰了：盡量減少額外的排序，通過索引直接返回有序數據。where 條件和Order by 使用相同的索引，并且Order By 的順序和索引順序相同， 并且Order by 的字段都是升序，或者都是降序。否則肯定需要額外的操作，這樣就會出現FileSort。
5.3.3 Filesort 的優化
通過創建合適的索引，能夠減少 Filesort 的出現，但是在某些情況下，條件限制不能讓Filesort消失，那就需要加快 Filesort的排序操作。對于Filesort ， MySQL 有兩種排序算法：
1） 兩次掃描算法 ：MySQL4.1 之前，使用該方式排序。首先根據條件取出排序字段和行指針信息，然后在排序區 sort buffer 中排序，如果sort buffer不夠，則在臨時表 temporary table 中存儲排序結果。完成排序之后，再根據行指針回表讀取記錄，該操作可能會導致大量隨機I/O操作。
2）一次掃描算法：一次性取出滿足條件的所有字段，然后在排序區 sort buffer 中排序后直接輸出結果集。排序時內存開銷較大，但是排序效率比兩次掃描算法要高。
MySQL 通過比較系統變量 max_length_for_sort_data 的大小和Query語句取出的字段總大小， 來判定是否那種排序算法，如果max_length_for_sort_data 更大，那么使用第二種優化之后的算法；否則使用第一種。
可以適當提高 sort_buffer_size 和 max_length_for_sort_data 系統變量，來增大排序區的大小，提高排序的效率。
5.4 優化group by 語句
由于GROUP BY 實際上也同樣會進行排序操作，而且與ORDER BY 相比，GROUP BY 主要只是多了排序之后的分組操作。當然，如果在分組的時候還使用了其他的一些聚合函數，那么還需要一些聚合函數的計算。所以，在GROUP BY 的實現過程中，與 ORDER BY 一樣也可以利用到索引。
如果查詢包含 group by 但是用戶想要避免排序結果的消耗， 則可以執行order by null 禁止排序。如下 ：
SQL`drop index idx_emp_age_salary on emp;explain select age,count(*) from emp group by age;`優化后
SQLexplain select age,count(*) from emp group by age order by null;從上面的例子可以看出，第一個SQL語句需要進行"filesort"，而第二個SQL由于order by null 不需要進行 “filesort”， 而上文提過Filesort往往非常耗費時間。
創建索引 ：
SQLcreate index idx_emp_age_salary on emp(age,salary)；5.5 優化嵌套查詢
Mysql4.1版本之后，開始支持SQL的子查詢。這個技術可以使用SELECT語句來創建一個單列的查詢結果，然后把這個結果作為過濾條件用在另一個查詢中。使用子查詢可以一次性的完成很多邏輯上需要多個步驟才能完成的SQL操作，同時也可以避免事務或者表鎖死，并且寫起來也很容易。但是，有些情況下，子查詢是可以被更高效的連接（JOIN）替代。
示例 ，查找有角色的所有的用戶信息 :
SQL`explain select * from t_user where id in (select user_id from user_role );執行計劃為 :
優化后 :
SQL`explain select * from t_user u , user_role ur where u.id = ur.user_id;連接(Join)查詢之所以更有效率一些 ，是因為MySQL不需要在內存中創建臨時表來完成這個邏輯上需要兩個步驟的查詢工作。
5.6 優化OR條件
對于包含OR的查詢子句，如果要利用索引，則OR之間的每個條件列都必須用到索引 ， 而且不能使用到復合索引； 如果沒有索引，則應該考慮增加索引。
獲取 emp 表中的所有的索引 ：
示例 ：
SQL`explain select * from emp where id = 1 or age = 30;建議使用 union 替換 or ：
我們來比較下重要指標，發現主要差別是 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 要優于 OR 。
5.7 優化分頁查詢
一般分頁查詢時，通過創建覆蓋索引能夠比較好地提高性能。一個常見又非常頭疼的問題就是 limit 2000000,10 ，此時需要MySQL排序前2000010 記錄，僅僅返回2000000 - 2000010 的記錄，其他記錄丟棄，查詢排序的代價非常大 。
5.7.1 優化思路一
在索引上完成排序分頁操作，最后根據主鍵關聯回原表查詢所需要的其他列內容。
5.7.2 優化思路二
該方案適用于主鍵自增的表，可以把Limit 查詢轉換成某個位置的查詢 。
5.8 使用SQL提示
SQL提示，是優化數據庫的一個重要手段，簡單來說，就是在SQL語句中加入一些人為的提示來達到優化操作的目的。
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优化-索引-存储引擎的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 闪付卡和银行卡的区别？
- 下一篇： 汽车后挡风玻璃上一条条的“横线”到底是啥