數據庫優化技巧 - SQL語句優化

點擊上方 藍色文字 關注咱們

  舒適提示：本文大概 3000 字，閱讀須要 5 分鐘。

拿到一段須要優化的慢查詢sql，不少人都感受無從下手。
其實SQL優化是有技巧與套路的，閱讀完本文你將學會這些優化套路，讓你成爲別人眼中的數據庫高手！

判斷問題SQL

判斷SQL是否有問題時能夠經過兩個表象進行判斷：

• 系統級別表象
• CPU消耗嚴重
• IO等待嚴重
• 頁面響應時間過長
• 應用的日誌出現超時等錯誤

可使用 sar命令，top命令查看當前系統狀態。

也能夠經過 Prometheus、Grafana等監控工具觀察服務器狀態。（感興趣的能夠翻看我以前的文章）

• SQL語句表象
• 冗長
• 執行時間過長
• 從全表掃描獲取數據
• 執行計劃中的rows、cost很大

冗長的SQL都好理解，一段SQL太長閱讀性確定會差，並且出現問題的頻率確定會更高。更進一步判斷SQL問題就得從執行計劃入手，以下所示：

執行計劃告訴咱們本次查詢走了全表掃描 Type=ALL，rows很大(9950400)基本能夠判斷這是一段"有味道"的SQL。

獲取問題SQL

不一樣數據庫有不一樣的獲取方法，如下爲目前主流數據庫的慢查詢SQL獲取工具

• MySQL
• 慢查詢日誌
• 測試工具loadrunner
• Percona公司的ptquery等工具
• Oracle
• AWR報告
• 測試工具loadrunner等
• 相關內部視圖如v 、 session_wait等
• GRID CONTROL監控工具
• 達夢數據庫
• AWR報告
• 測試工具loadrunner等
• 達夢性能監控工具（dem）
• 相關內部視圖如v 、 session_wait等

SQL編寫技巧

SQL編寫有如下幾個通用的技巧：

• 合理使用索引

索引少了查詢慢；
索引多了佔用空間大，執行增刪改語句的時候須要動態維護索引，影響性能 選擇率高（重複值少）且被where頻繁引用須要創建B樹索引；
通常join列須要創建索引；
複雜文檔類型查詢採用全文索引效率更好；
索引的創建要在查詢和DML性能之間取得平衡；
複合索引建立時要注意基於非前導列查詢的狀況

• 使用UNION ALL替代UNION

UNION ALL的執行效率比UNION高，UNION執行時須要排重；
UNION須要對數據進行排序

• 避免select * 寫法

執行SQL時優化器須要將 * 轉成具體的列；
每次查詢都要回表，不能走覆蓋索引。

• JOIN字段建議創建索引

通常JOIN字段都提早加上索引

• 避免複雜SQL語句

提高可閱讀性；避免慢查詢的機率；
能夠轉換成多個短查詢，用業務端處理

• 避免where 1=1寫法

• 避免order by rand()相似寫法

RAND()致使數據列被屢次掃描

SQL優化

執行計劃

完成SQL優化必定要先讀執行計劃，執行計劃會告訴你哪些地方效率低，哪裏能夠須要優化。咱們以MYSQL爲例，看看執行計劃是什麼。（每一個數據庫的執行計劃都不同，須要自行了解）explain sql

字段	解釋
id	每一個被獨立執行的操做標識，標識對象被操做的順序，id值越大，先被執行，若是相同，執行順序從上到下
select_type	查詢中每一個select 字句的類型
table	被操做的對象名稱，一般是表名，但有其餘格式
partitions	匹配的分區信息(對於非分區表值爲NULL)
type	鏈接操做的類型
possible_keys	可能用到的索引
key	優化器實際使用的索引(最重要的列) 從最好到最差的鏈接類型爲 const、eq_reg、ref、range、index和 ALL。當出現 ALL時表示當前SQL出現了「壞味道」
key_len	被優化器選定的索引鍵長度，單位是字節
ref	表示本行被操做對象的參照對象，無參照對象爲NULL
rows	查詢執行所掃描的元組個數（對於innodb，此值爲估計值）
filtered	條件表上數據被過濾的元組個數百分比
extra	執行計劃的重要補充信息，當此列出現 Using filesort , Using temporary 字樣時就要當心了，極可能SQL語句須要優化

接下來咱們用一段實際優化案例來講明SQL優化的過程及優化技巧。

優化案例

• 表結構

  CREATE TABLE `a`
  (
      `id`          int(11) NOT NULLAUTO_INCREMENT,
      `seller_id`   bigint(20)                                       DEFAULT NULL,
      `seller_name` varchar(100) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
      `gmt_create`  varchar(30)                                      DEFAULT NULL,
      PRIMARY KEY (`id`)
  );
  CREATE TABLE `b`
  (
      `id`          int(11) NOT NULLAUTO_INCREMENT,
      `seller_name` varchar(100) DEFAULT NULL,
      `user_id`     varchar(50)  DEFAULT NULL,
      `user_name`   varchar(100) DEFAULT NULL,
      `sales`       bigint(20)   DEFAULT NULL,
      `gmt_create`  varchar(30)  DEFAULT NULL,
      PRIMARY KEY (`id`)
  );
  CREATE TABLE `c`
  (
      `id`         int(11) NOT NULLAUTO_INCREMENT,
      `user_id`    varchar(50)  DEFAULT NULL,
      `order_id`   varchar(100) DEFAULT NULL,
      `state`      bigint(20)   DEFAULT NULL,
      `gmt_create` varchar(30)  DEFAULT NULL,
      PRIMARY KEY (`id`)
  );
  

• 查詢要求
  三張表關聯，查詢當前用戶在當前時間先後10個小時的訂單狀況，並根據訂單建立時間升序排列，具體SQL以下

  select a.seller_id,
         a.seller_name,
         b.user_name,
         c.state
  from a,
       b,
       c
  where a.seller_name = b.seller_name
    and b.user_id = c.user_id
    and c.user_id = 17
    and a.gmt_create
      BETWEEN DATE_ADD(NOW(), INTERVAL – 600 MINUTE)
      AND DATE_ADD(NOW(), INTERVAL 600 MINUTE)
  order by a.gmt_create；
  

• 查看數據量

• 原執行時間

• 原執行計劃

• 初步優化思路

1. SQL中 where條件字段類型要跟表結構一致，表中 user_id 爲varchar(50)類型，實際SQL用的int類型，存在隱式轉換，也未添加索引。將b和c表 user_id 字段改爲int類型。
2. 因存在b表和c表關聯，將b和c表 user_id 建立索引
3. 因存在a表和b表關聯，將a和b表 seller_name 字段建立索引
4. 利用複合索引消除臨時表和排序

• 初步優化SQL

  alter table b modify `user_id` int(10) DEFAULT NULL;
  alter table c modify `user_id` int(10) DEFAULT NULL;
  alter table c add index `idx_user_id`(`user_id`);
  alter table b add index `idx_user_id_sell_name`(`user_id`,`seller_name`);
  alter table a add index `idx_sellname_gmt_sellid`(`gmt_create`,`seller_name`,`seller_id`);
  

• 查看優化後執行時間

• 查看優化後執行計劃

• 查看warnings信息

• 繼續優化
  alter table a modify "gmt_create" datetime DEFAULT NULL;

• 查看執行時間

• 查看執行計劃經過觀察執行計劃，到了這一步已經再也不須要優化！

• 優化總結
  總結一下完成一段SQL優化的思路與過程：
  一、查看執行計劃 explain
  二、若是有告警信息，查看告警信息 show warnings;
  三、查看SQL涉及的表結構和索引信息
  四、根據執行計劃，思考可能的優化點
  五、按照可能的優化點執行表結構變動、增長索引、SQL改寫等操做
  六、查看優化後的執行時間和執行計劃
  七、若是優化效果不明顯，重複第四步操做

總結

這篇文章首先讓你瞭解慢查詢的表象，讓你能夠經過一些工具識別出慢查詢語句；
而後告訴你SQL優化的一些經常使用套路技巧，掌握這些套路技巧至少能夠解決80%的SQL優化問題；
最後經過一個示例從分析開始一步一步完成慢查詢語句的優化，其中查看執行計劃是優化過程當中最終要的操做，你們必定要掌握。

 

若是本文對你有幫助，

別忘記三連啊，

點贊、轉發、評論

。

我們下期見！

End

乾貨分享

這裏爲你們準備了一份小小的禮物，關注公衆號，輸入以下代碼，便可得到百度網盤地址，無套路領取！

001：《程序員必讀書籍》
002：《從無到有搭建中小型互聯網公司後臺服務架構與運維架構》
003：《互聯網企業高併發解決方案》
004：《互聯網架構教學視頻》
006：《SpringBoot實現點餐系統》
007：《SpringSecurity實戰視頻》
008：《Hadoop實戰教學視頻》
009：《騰訊2019Techo開發者大會PPT》

010： 微信交流羣

近期熱文top5

一、架構師之路 - 虛擬化技術與容器Docker

二、使用Hexo 搭建你的技術博客

我就知道你「在看」

本文分享自微信公衆號 - JAVA日知錄（javadaily）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。