數據庫優化

判斷問題SQL

判斷SQL是否有問題時可以通過兩個表象進行判斷：

• 系統級別表象

  <ul><li>
  	<div>CPU消耗嚴重</div>
  	</li>
  	<li>
  	<div>IO等待嚴重</div>
  	</li>
  	<li>
  	<div>頁面響應時間過長</div>
  	</li>
  	<li>
  	<div>應用的日誌出現超時等錯誤</div>
  	</li>
  </ul></li>
  

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

也可以通過Prometheus、Grafana等監控工具觀察系統狀態。（感興趣的可以翻看我之前的文章）

• SQL語句表象

  <ul><li>
  	<div>冗長</div>
  	</li>
  	<li>
  	<div>執行時間過長</div>
  	</li>
  	<li>
  	<div>從全表掃描獲取數據</div>
  	</li>
  	<li>
  	<div>執行計劃中的rows、cost很大</div>
  	</li>
  </ul></li>
  

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

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

獲取問題SQL

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

• MySQL

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

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優化的過程及優化技巧。

優化案例

• 表結構

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. 如果優化效果不明顯，重複第四步操作

 

系列文章

 

• 數據庫優化 - 實例優化
• 記一次對達夢數據庫的優化過程