數據庫優化 - SQL優化

前面一篇文章從實例的角度進行數據庫優化，經過配置一些參數讓數據庫性能達到最優。可是一些「很差」的SQL也會致使數據庫查詢變慢，影響業務流程。本文從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$sql、v$session_wait等
  • GRID CONTROL監控工具
• 達夢數據庫
  • AWR報告
  • 測試工具loadrunner等
  • 達夢性能監控工具（dem）
  • 相關內部視圖如v$sql、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;

• 查看執行時間

• 查看執行計劃

• 優化總結
  1. 查看執行計劃 explain
  2. 若是有告警信息，查看告警信息 show warnings;
  3. 查看SQL涉及的表結構和索引信息
  4. 根據執行計劃，思考可能的優化點
  5. 按照可能的優化點執行表結構變動、增長索引、SQL改寫等操做
  6. 查看優化後的執行時間和執行計劃

  7. 若是優化效果不明顯，重複第四步操做

     請關注我的公衆號:JAVA日知錄