2. 程式人生 > >【mysql優化五】——sql語句優化查詢

【mysql優化五】——sql語句優化查詢

阿新 • • 發佈：2018-10-31

前言

上篇講解了索引搜尋優化，其實索引只是sql查詢優化的一部分，本篇主要講解的是sql優化主要要優化的部分！

內容

一.order by 優化

  • orderby最好使用index排序方式，避免使用FileSort方式排序；
  • 在索引列上完成排序，遵照索引最佳做字首
  • orderby最好不要使用select *；
  • 如果使用fileSort方式，嘗試提高sort_buffer_size
  • 如果使用fileSort方式，嘗試提高max_length_for_sort_data

使用filesort排序優化策略

orderby最好不要使用select *；
提高max_length_for_sort_data
提高sort_buffer_size

【解答】：

1.為什麼不用select *？
當query的欄位大小總和小於max_length_sort_data，而且排序欄位不是text|blob型別，會用改進後的演算法單路排序，否則多路排序。

1.雙路排序，兩次掃描磁碟，最終得到資料；讀取行指標和orderby列，對他們進行排序，然後掃描已經排序好的列表，按照列表中的資料從磁碟中取排序的欄位，在buffer進行排序，再從磁碟中去其他欄位（mysql4.1之前）

2.單路排序，從磁碟讀取需要的所有列，按照order by列在buffer對他們進行排序，然後掃描排序後的列表進行輸出，它的效率更快一些，避免了第二次讀取資料，並且報隨機I/O變成了順序I/O，但是它會使用更多的空間。

2.為什麼要提高sort_buffer_size?
上訴兩種演算法的資料都有可能超出sort_buffer的容量，超出之後，會建立tmp檔案進行合併排序，導致多次的i/O操作，但是單路排序的演算法風險會更大一些,所以提高sort_buffer_size.
3.如何提高sort_buffer_size和max_length_for_sort_data引數值？

檢視本sql的sort_buffer_size;

show variables like '%sort_buffer%';
+-------------------------+---------+
| Variable_name           | Value   |
+-------------------------+---------+
| innodb_sort_buffer_size | 1048576 |
| myisam_sort_buffer_size | 8388608 |
| sort_buffer_size        | 262144  |
+-------------------------+---------+

其中以後位元組為單位的，所以sort_buffer_size=262144/1024=256KB
設定本sql的中sort_buffer_size:

SET GLOBAL sort_buffer_size = 1024*1024; //2MB的buffer大小

3.是不是buffer的大小越大越好？
Sort_Buffer_Size 並不是越大越好，由於是connection級的引數，過大的設定+高併發可能會耗盡系統記憶體資源。

參考部落格：
http://www.cnblogs.com/wy123/p/7744171.html
https://blog.csdn.net/mydriverc2/article/details/79026337

order by索引方式優化策略

orderby最好不要使用select *；
在索引列上完成排序，遵照索引最佳做字首

建立複合索引：

create index idx_three on tblA(age,birth,addr);

1.索引最左字首，orderby 使用索引有效

   select * from tblA  order by age;
   select * from tblA  order by age,birth;
   select * from tblA  order by age, birth,addr;

2.where索引的最左字首為常量，orderby 使用索引有效

第一種情況最普遍：

 explain select * from tblA where age=24 order by birth,addr;

第二種情況，如果birth使用了範圍，但是由於頭索引生效了，所以order by使用索引生效。

mysql> explain select * from tblA where age=24 and birth >'2018-07-11 18:09:10' order by birth,addr;
| id | select_type | table | partitions | type  | possible_keys            | key       | key_len | ref  | rows | filtered | Extra                    |
+----+-------------+-------+------------+-------+--------------------------+-----------+---------+------+------+----------+--------------------------+
|  1 | SIMPLE      | tblA  | NULL       | range | idx_A_ageBirth,idx_three | idx_three | 9       | NULL |    1 |   100.00 | Using where; Using index |

【注意】
三種情況導致索引失效：
1.複合索引頭索引不存在；

explain select * from tblA order by  birth,addr;
+----+-------------+-------+------------+-------+---------------+-----------+---------+------+------+----------+-----------------------------+
| id | select_type | table | partitions | type  | possible_keys | key       | key_len | ref  | rows | filtered | Extra                       |
+----+-------------+-------+------------+-------+---------------+-----------+---------+------+------+----------+-----------------------------+
|  1 | SIMPLE      | tblA  | NULL       | index | NULL          | idx_three | 100     | NULL |    3 |   100.00 | Using index; Using filesort |
+----+-------------+-------+------------+-------+---------------+-----------+---------+------+------+----------+-----------------------------+

1.複合索引中間的索引不存在

explain select * from tblA where age=24 and birth >'2018-07-11 18:09:10' order by addr;

+----+-------------+-------+------------+-------+---------------+-----------+---------+------+------+----------+-----------------------------+
| id | select_type | table | partitions | type  | possible_keys | key       | key_len | ref  | rows | filtered | Extra                       |
+----+-------------+-------+------------+-------+---------------+-----------+---------+------+------+----------+-----------------------------+
|  1 | SIMPLE      | tblA  | NULL       | index | NULL          | idx_three | 100     | NULL |    3 |   100.00 | Using index; Using filesort |
+----+-------------+-------+------------+-------+---------------+-----------+---------+------+------+----------+-----------------------------+

報告中分析extra指標中存在 using filesort說明這條語句寫的糟糕

3.order by中存在了不是複合索引中的欄位

explain select * from tblA order by  age,birth,addr,xing1;

4.範圍查詢也會導致索引失效;

explain select * from tblA where age in (22,24) order by  birth,addr;

+----+-------------+-------+------------+-------+--------------------------+-----------+---------+------+------+----------+------------------------------------------+
| id | select_type | table | partitions | type  | possible_keys            | key       | key_len | ref  | rows | filtered | Extra                                    |
+----+-------------+-------+------------+-------+--------------------------+-----------+---------+------+------+----------+------------------------------------------+
|  1 | SIMPLE      | tblA  | NULL       | range | idx_A_ageBirth,idx_three | idx_three | 5       | NULL |    2 |   100.00 | Using where; Using index; Using filesort |
+----+-------------+-------+------------+-------+--------------------------+-----------+---------+------+------+----------+------------------------------------------+

檢視分析中type為range，說明是範圍查詢，實際用了idx_three，但是依舊存在filesort說明語句還是糟糕。像這種情況我們只能根據需求的不同，建立合適的索引了。
優化原則：

小表驅動大表，小的資料集驅動大的資料集。

【分析】：
子查詢結果集必須要比主查詢結果集大，因為in和exists本質是一個for迴圈，內部多次迴圈可以減少從內部到外部的時間，減少執行的時間。
in和exists語句中，in 後面的語句先執行，所以是外迴圈，必須要保證in後面的表比in前面的表小；exists前面的語句先執行，所以是外迴圈，必須要保證前面表的資料集小於後面的表：
這裡寫圖片描述

select * from tb1_emp e where e.deptId in (select id from tb1_dept d);
select * from  tb1_emp e where exists(select 1 from tb1_dept d where d.id=e.deptiD);

二.索引優化

可以參照我之前部落格：【mysql學習三】——索引搜尋優化

三.group by

  • 本質排序好了進行分組，遵照索引建的最佳前索引
  • 使用filesort方式時，增大max_length_for_sort_data引數設定
  • 使用filesort方式時，增大sort_buffer_size引數設定
  • where高於having，能寫where限定條件就不要去寫having的限定
    【分析】
    由圖中中可以看出來，執行的順序依次是from,on,(join,where),group by ,having,select ,order by limit;
    這裡寫圖片描述

四.join優化 

1，儘可能減少Join 語句中的Nested Loop 的迴圈總次數，用小結果集驅動大結果集； 注意不是：小表連線大的快，而是結果集 
2，優先優化Nested Loop 的內層迴圈； 做索引 
3，保證Join 語句中被驅動表上Join 條件欄位已經被索引； 
4，擴大join buffer的大小；

五.limit優化

資料量少的時候我們可以使用

Select * from A order by id limit 1,10;

但是資料量大的時候，可以在id上建立一個索引，寫成如下的方式：

Select * from A where id>=(Select id from a limit 10000000,1) limit 10;

或者寫成如下：

Select * from A where id between 10000000and 10000010;

六.where子句優化

相關推薦

【mysql優化五】——sql語句優化查詢

前言 上篇講解了索引搜尋優化，其實索引只是sql查詢優化的一部分，本篇主要講解的是sql優化主要要優化的部分！ 內容 一.order by 優化 orderby最好使用index排序方式，避免使

【解決方案 五】---sql語句模糊替換

最近做的專案中，發現一列year資料都帶有”年”，而我想過濾這個字來和其它表來進行聯表查詢，那麼就用到了sql中的函式 update mhi set year = REPLACE(year,substring(year, LOCATE(year,’年

【庫房】——SQL語句優化

前言 前段時間接手庫房專案之後，有很多地方需要優化，從中也學到了很多東西，將在部落格中一一整理出來分享給大家。 實際案例：庫房系統中管理員許可權下的入庫管理中的入庫記錄頁面每次開啟時都載入的非常慢，長達三十多秒，網速慢的時候會達到一分鐘左右，這個問題非常影響庫房系統的功能使用，首先需要解

【mysql學習三】——索引搜尋優化

前言 索引是sql語句優化的一部分，在實際的應用中當我們存在大量的資料需要查詢的時候，提升查詢效率最好的方式就是建立有效的索引，那索引是什麼，如何用，並且如何去建立一個有效的索引，這些問題本篇可以給你解惑！ 索引的基本操作 1.查詢表中所含有的索引： show index

【MySQL技術內幕】64-效能優化

效能優化不是一項簡單的工作,但也不是複雜的難事,關鍵在於對 InnoDB儲存引擎特性的瞭解。如果之前各章的內容讀者已經完全理解並掌握了,那就應該基本掌握瞭如何使 InnoDB儲存引擎更好地工作。本章將從以下幾個方面集中講解 InnodB儲存引擎的效能問題: 選擇合適的CPU

【SQLite資料庫小結】sql語句的兩種形式以及你不能不知的事務

android中對sql語句進行了兩種封裝。本質上都是封裝了sql語句，都需要通過SQLiteDtabase類使用其例項方法. NO.1 insert方法： 向資料庫新增一條記錄 dele

MySQL 使用explain分析sql語句的查詢效率

Explain命令在解決資料庫效能上是第一推薦使用命令，大部分的效能問題可以通過此命令來簡單的解決，Explain可以用來檢視SQL語句的執行效 果，可以幫助選擇更好的索引和優化查詢語句，寫出更好的優化語句。Explain語法：EXPLAIN tbl_name或：EXPLAI

MySQL 使用explain分析sql語句的查詢效率（一）

MySQL explain用於分析sql 語句的執行及資料庫索引的使用。本文將致力於幫助大家充分理解explain所返回的各項引數，從而使大家快速掌握explain用法技巧。如果你在看其他教程或視訊後仍覺得雲裡霧裡。那麼請通讀本文。 用法 explain的用法相當簡潔

MySQL 使用explain分析sql語句的查詢效率（二）

本文將繼續上文講解其他與效率相關的引數 explain所返回的其他引數key為使用的索引，而使用的索引又影響著連線型別type，它們共同決定了可能掃描行數rows 引數解析 （4）type （重點） 聯接型別。查詢效率的關鍵，下面按照從最佳型

mysql limit分頁 SQL語句模糊查詢

limit函式： 在資料庫中經常要取表中記錄中間的記錄，在sql語句中使用limit 可以實現此功能 select * from a limit 5,20 理解：從表中的第五行資料開始

MySQL優化（五） SQL 語句的優化

一、索引 1、分類 （1）主鍵索引：當一張表的某個欄位設定為主鍵時，該欄位就是主鍵索引； （2）唯一索引：索引列中的值必須是唯一的，但是允許為空值（可以存在多個null）； （3）普通索引：基本索引型別，沒有什麼限制，允許在定義索引的列中插入重複值和空值，純粹為了查詢資料更快一點； （4）全文索引：

SQL語句優化 -- 以Mysql為例

也不會 無法使用 order url all body 條件查詢 參與 優化 本文參考下面的文章: 1: 【真·幹貨】MySQL 索引及優化實戰 2: Mysql語句的執行過程 3: sql優化的幾種方法 我將 sql語句優化分為三個方面,(此處不包括 業

mysql優化和sql語句優化總結

結構 沒有 sele 大量 unsigned 他還 判斷 pla 可能 mysql性能優化 1、 EXPLAIN 你的 SELECT 查詢。使用 EXPLAIN 關鍵字可以讓你知道MySQL是如何處理你的SQL語句的。這可以幫你分析你的查詢語句或是表結構的性能瓶頸。 2、為

MySQL(二) —— MySQL效能優化之 SQL語句優化

　　　　　　　　　　SQL語句優化   MySQL優化的目的 　　1、避免出現頁面訪問錯誤：或由於資料庫連線超時 timeout 產生頁面5xx錯誤；或由於慢查詢造成頁面無法載入；或由於阻　　      塞造成資料無法提交；

【轉】MySQL使用者管理及SQL語句詳解

【轉】MySQL使用者管理及SQL語句詳解 1.1 MySQL使用者管理 1.1.1 使用者的定義 　　使用者名稱+主機域 mysql> select user,host,password from mysql.user; +--------+------------+---------

MySQL之SQL語句優化步驟

MySQL查詢擷取分析步驟： 一、開啟慢查詢日誌，捕獲慢SQL 二、explain+慢SQL分析 三、show profile查詢SQL語句在伺服器中的執行細節和生命週期 四、SQL資料庫伺服器引數調優 一、開啟慢查詢日誌，捕獲慢SQL 1、檢視慢查詢日誌是否開啟 SHO

mysql優化–explain分析sql語句執行效率

  Explain命令在解決資料庫效能上是第一推薦使用命令，大部分的效能問題可以通過此命令來簡單的解決，Explain可以用來檢視SQL語句的執行效 果，可以幫助選擇更好的索引和優化查詢語句，寫出更好的優化語句。 Explain語法：explain select … from …

MySQL(二) —— MySQL效能優化之 SQL語句優化

　　　　　　　　　　SQL語句優化 MySQL優化的目的 　　1、避免出現頁面訪問錯誤：或由於資料庫連線超時 timeout 產生頁面5xx錯誤；或由於慢查詢造成頁面無法載入；或由於阻　　      塞造成資料無法提交； 　　2、增加資料庫的穩定性：避免由於低效查詢

mysql資料庫優化大全--sql語句優化大全

一，SQL語句效能優化 1， 對查詢進行優化，應儘量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索 引。 2，應儘量避免在 where 子句中對欄位進行 null 值判斷，建立表時NULL是預設值，但大多數時候 應該使用NOT N

mysql sql 語句 優化 常用的30種方法

mysql sql 語句 優化 常用的30種方法 1、應儘量避免在 where 子句中使用!