判斷問題SQL
判斷SQL是否有問題時可以通過兩個表象進行判斷：
1、系統(tǒng)級別表象
- CPU消耗嚴重
- IO等待嚴重
- 頁面響應時間過長
- 應用的日志出現超時等錯誤
可以使用sar命令，top命令查看當前系統(tǒng)狀態(tài)。
也可以通過Prometheus、Grafana等監(jiān)控工具觀察系統(tǒng)狀態(tài)。
2、SQL語句表象
- 冗長
- 執(zhí)行時間過長
- 從全表掃描獲取數據
- 執(zhí)行計劃中的rows、cost很大
冗長的SQL都好理解，一段SQL太長閱讀性肯定會差，而且出現問題的頻率肯定會更高。更進一步判斷SQL問題就得從執(zhí)行計劃入手，如下所示：
執(zhí)行計劃告訴我們本次查詢走了全表掃描Type=ALL，rows很大(9950400)基本可以判斷這是一段"有味道"的SQL。
獲取問題SQL
不同數據庫有不同的獲取方法，以下為目前主流數據庫的慢查詢SQL獲取工具
MySQL
- 慢查詢日志
- 測試工具loadrunner
- Percona公司的ptquery等工具
Oracle
- AWR報告
- 測試工具loadrunner等
- 相關內部視圖如v$、$session_wait等
- GRID CONTROL監(jiān)控工具
達夢數據庫
- AWR報告
- 測試工具loadrunner等
- 達夢性能監(jiān)控工具（dem）
- 相關內部視圖如v$、$session_wait等
SQL編寫技巧
SQL編寫有以下幾個通用的技巧：
合理使用索引
索引少了查詢慢；索引多了占用空間大，執(zhí)行增刪改語句的時候需要動態(tài)維護索引，影響性能 選擇率高（重復值少）且被where頻繁引用需要建立B樹索引；
一般join列需要建立索引；復雜文檔類型查詢采用全文索引效率更好；索引的建立要在查詢和DML性能之間取得平衡；復合索引創(chuàng)建時要注意基于非前導列查詢的情況
使用UNION ALL替代UNION
UNION ALL的執(zhí)行效率比UNION高，UNION執(zhí)行時需要排重；UNION需要對數據進行排序
避免select * 寫法
執(zhí)行SQL時優(yōu)化器需要將 * 轉成具體的列；每次查詢都要回表，不能走覆蓋索引。
JOIN字段建議建立索引
一般JOIN字段都提前加上索引
避免復雜SQL語句
提升可閱讀性；避免慢查詢的概率；可以轉換成多個短查詢，用業(yè)務端處理
避免where 1=1寫法
避免order by rand()類似寫法
RAND()導致數據列被多次掃描
SQL優(yōu)化
執(zhí)行計劃
完成SQL優(yōu)化一定要先讀執(zhí)行計劃，執(zhí)行計劃會告訴你哪些地方效率低，哪里可以需要優(yōu)化。我們以MYSQL為例，看看執(zhí)行計劃是什么。（每個數據庫的執(zhí)行計劃都不一樣，需要自行了解）explain sql
接下來我們用一段實際優(yōu)化案例來說明SQL優(yōu)化的過程及優(yōu)化技巧。
優(yōu)化案例
表結構
三張表關聯(lián)，查詢當前用戶在當前時間前后10個小時的訂單情況，并根據訂單創(chuàng)建時間升序排列，具體SQL如下
查看數據量
原執(zhí)行時間
原執(zhí)行計劃
初步優(yōu)化思路
- SQL中 where條件字段類型要跟表結構一致，表中user_id 為varchar(50)類型，實際SQL用的int類型，存在隱式轉換，也未添加索引。將b和c表user_id 字段改成int類型。
- 因存在b表和c表關聯(lián)，將b和c表user_id創(chuàng)建索引
- 因存在a表和b表關聯(lián)，將a和b表seller_name字段創(chuàng)建索引
- 利用復合索引消除臨時表和排序
初步優(yōu)化SQL
查看優(yōu)化后執(zhí)行時間
查看優(yōu)化后執(zhí)行計劃
查看warnings信息
繼續(xù)優(yōu)化alter table a modify "gmt_create" datetime DEFAULT NULL;
查看執(zhí)行時間
查看執(zhí)行計劃
總結
- 查看執(zhí)行計劃 explain
- 如果有告警信息，查看告警信息 show warnings;
- 查看SQL涉及的表結構和索引信息
- 根據執(zhí)行計劃，思考可能的優(yōu)化點
- 按照可能的優(yōu)化點執(zhí)行表結構變更、增加索引、SQL改寫等操作
- 查看優(yōu)化后的執(zhí)行時間和執(zhí)行計劃
- 如果優(yōu)化效果不明顯，重復第四步操作
