目錄
一、優化概述
二、查詢與索引優化分析
1性能瓶頸定位
Show命令
慢查詢日志
explain分析查詢
profiling分析查詢
2索引及查詢優化
一、優化概述
MySQL數據庫是常見的兩個瓶頸是CPU和I/O的瓶頸，CPU在飽和的時候一般發生在數據裝入內存或從磁盤上讀取數據時候。磁盤I/O瓶頸發生在裝入數據遠大於內存容量的時候，如果應用分布在網絡上，那么查詢量相當大的時候那么平瓶頸就會出現在網絡上，我們可以用mpstat, iostat, sar和vmstat來查看系統的性能狀態。
除了服務器硬件的性能瓶頸，對於MySQL系統本身，我們可以使用工具來優化數據庫的性能，通常有三種：使用索引，使用EXPLAIN分析查詢以及調整MySQL的內部配置。
二、查詢與索引優化分析
在優化MySQL時，通常需要對數據庫進行分析，常見的分析手段有慢查詢日志，EXPLAIN 分析查詢，profiling分析以及show命令查詢系統狀態及系統變量，通過定位分析性能的瓶頸，才能更好的優化數據庫系統的性能。
show 命令
我們可以通過show命令查看MySQL狀態及變量，找到系統的瓶頸：
Mysql> show status ——顯示狀態信息(擴展show status like ‘XXX’)
Mysql> show variables ——顯示系統變量(擴展show variables like ‘XXX’)show variables like "slow%"
Mysql> show innodb status ——顯示InnoDB存儲引擎的狀態
Mysql> show processlist ——查看當前SQL執行，包括執行狀態、是否鎖表等
Shell> mysqladmin variables -u username -p password——顯示系統變量
Shell> mysqladmin extended-status -u username -p password——顯示狀態信息
慢查詢日志
慢查詢 可以記錄執行時間比較慢的語句 和 未使用索引的語句
一、MySQL數據庫有幾個配置選項可以幫助我們及時捕獲低效SQL語句
1，slow_query_log 這個參數設置為ON，可以捕獲執行時間超過一定數值的SQL語句。
2，long_query_time 當SQL語句執行時間超過此數值時，就會被記錄到日志中，建議設置為1或者更短(單位秒)。
3，slow_query_log_file 記錄日志的文件名。
4，log_queries_not_using_indexes 這個參數設置為ON，可以捕獲到所有未使用索引的SQL語句，盡管這個SQL語句有可能執行得挺快。
explain分析查詢
使用 EXPLAIN 關鍵字可以模擬優化器執行SQL查詢語句，從而知道MySQL是如何處理你的SQL語句的。這可以幫你分析你的查詢語句或是表結構的性能瓶頸。通過explain命令可以得到:
– 表的讀取順序
– 數據讀取操作的操作類型
– 哪些索引可以使用
– 哪些索引被實際使用
– 表之間的引用
– 每張表有多少行被優化器查詢
SQL
|
1
2
3
4
5
6
7
|
mysql> explain select * from user;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
|
1
| SIMPLE | user | NULL | ALL | NULL | NULL | NULL | NULL |
85
|
100.00
| NULL |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
1
row in set,
1
warning (
0.01
sec)
|
EXPLAIN字段：
id: 查詢序號即為sql語句執行的順序
select_type
select類型，它有以下幾種值
2.1 simple 它表示簡單的select,沒有union和子查詢
2.2 primary 最外面的select,在有子查詢的語句中，最外面的select查詢就是primary,上圖中就是這樣
2.3 union union語句的第二個或者說是后面那一個.現執行一條語句，explain
Table：顯示這一行的數據是關於哪張表的
possible_keys：顯示可能應用在這張表中的索引。如果為空，沒有可能的索引。可以為相關的域從WHERE語句中選擇一個合適的語句
key：實際使用的索引。如果為NULL，則沒有使用索引。MYSQL很少會選擇優化不足的索引，此時可以在SELECT語句中使用USE INDEX(index)來強制使用一個索引或者用IGNORE INDEX(index)來強制忽略索引
key_len：使用的索引的長度。在不損失精確性的情況下，長度越短越好
ref：顯示索引的哪一列被使用了，如果可能的話，是一個常數
rows：MySQL認為必須檢索的用來返回請求數據的行數
type：這是最重要的字段之一，顯示查詢使用了何種類型。從最好到最差的連接類型為system、const、eq_reg、ref、range、index和ALL
Extra：關於MYSQL如何解析查詢的額外信息，主要有以下幾種
Extra:參數說明
using index：只用到索引,可以避免訪問表.
using where：使用到where來過慮數據. 不是所有的where clause都要顯示using where. 如以=方式訪問索引.
using tmporary：用到臨時表
using filesort：用到額外的排序. (當使用order by v1,而沒用到索引時,就會使用額外的排序)
range checked for eache record(index map:N)：沒有好的索引.
type：參數說明
system、const：可以將查詢的變量轉為常量. 如id=1; id為 主鍵或唯一鍵.
eq_ref：訪問索引,返回某單一行的數據.(通常在聯接時出現，查詢使用的索引為主鍵或惟一鍵)
ref：訪問索引,返回某個值的數據.(可以返回多行) 通常使用=時發生
range：這個連接類型使用索引返回一個范圍中的行，比如使用>或<查找東西，並且該字段上建有索引時發生的情況(注:不一定好於index)
index：以索引的順序進行全表掃描，優點是不用排序,缺點是還要全表掃描
ALL：全表掃描，應該盡量避免
profiling分析查詢
通過慢日志查詢可以知道哪些SQL語句執行效率低下，通過explain我們可以得知SQL語句的具體執行情況，索引使用等，還可以結合show命令查看執行狀態。
如果覺得explain的信息不夠詳細，可以同通過profiling命令得到更准確的SQL執行消耗系統資源的信息。
profiling默認是關閉的。可以通過以下語句查看 select @@profiling;
打開功能： mysql>set profiling=1; 執行需要測試的sql 語句：
開啟后執行了sql語句 就可以通過show profiles;命令查看執行時間
SQL
|
1
2
3
4
5
6
7
8
|
mysql> show profiles;
+----------+------------+---------------------------+
| Query_ID | Duration | Query |
+----------+------------+---------------------------+
|
1
|
0.00417000
| select * from user |
|
2
|
0.00214700
| select count(*) from user |
+----------+------------+---------------------------+
2
rows in set,
1
warning (
0.00
sec)
|
mysql> show profiles\G; 可以得到被執行的SQL語句的時間和ID
mysql>show profile for query 1; 得到對應SQL語句執行的詳細信息
Bash