打開慢查詢日誌
在my.cnf置文件中修改
log-slow-queries = 日誌文件路徑
（注：log-slow-queries在未來的版本將被刪除，儘量使用slow-query-log-file 重啓服務後會出現warning警告 [Warning] The syntax '--log-slow-queries' is deprecated and will be removed in a future release. Please use '--slow-query-log'/'--slow-query-log-file' instead.）
打開慢查詢日誌
long_query_time
設一個閥值，要大於這個值纔會記錄，等於該值時不記錄。
log_queries_not_using_indexes
如果運行的SQL語句沒有使用索引，則MySQl數據庫同樣會將這條SQL語句記錄到慢查詢日誌文件
show variables like "%slow%";
查看是否開啓慢查詢
show variables like "%long%";
慢查詢時間爲幾秒
查看慢查詢日誌
默認情況下，在數據庫目錄下，在數據庫運行時，可動態觀察
tail -f slow.log
……
# Time: 110523 9:58:35 時間
# User@Host: grid[grid] @ [203.100.192.66] 連接信息
# Query_time: 4 Lock_time: 0 Rows_sent: 1 Rows_examined: 4815
查詢時間 鎖時間 返回行數 總共查詢行數
select count(*) from table_name where ……
利用mysqldumpslow分析慢查詢日誌
mysqldumpslow -s c -t 10 輸出記錄次數最多的10條SQL語句
mysqldumpslow -s r -t 10 返回記錄集最多的10個查詢
mysqldumpslow -s t -t 10 -g 'left join' 按照時間排序的前10條裏面含有左連接的查詢語句
-s, 是表示按照何種方式排序
c 記錄次數、t 時間、l 查詢時間、r 返回的記錄數，ac、at、al、ar，表示相應的倒敘；
-t, 是top n的意思，即爲返回前面多少條的數據；
-g, 後邊可以寫一個正則匹配模式，大小寫不敏感的；
-s t | 按總query time排序 | -s at | 按平均query time排序 |
-s l | 按總locktime排序 | -s al | 按平均lock time排序 |
-s s | 按總row send排序 | -s as | 按平均row send排序 |
-s c | 按count排序 |
注意：在默認情況下
mysqlslowdump的輸出結果會使用N和S代替SQL中出現的數字和字符串
mysqlslowdump輸出結果是按照count（SQL出現的次數）排序的
mysqldumpslow結果分析
# mysqldumpslow -s c -t 10 slowquery.log
Reading mysql slow query log from slowquery.log
Count: 147973 Time=4.64s (686449s) Lock=0.34s (51032s) Rows=1.0 (147687), grid[grid]@[203.100.192.66]
select count(*) from table_name where ((newsT = 'S' and …………用S代表字符串
平均執行147973次，每次耗時4.64秒
分析問題
show create table table_name 查看錶結構
分析問題 查看當期表都有哪些索引
mysql> show index from t \G
*************************** 1. row ***************************
Table: t 索引所在的表名
Non_unique: 0 非唯一索引，0代表唯一，可以看到主鍵名字是PRIMARY，因此必須唯一。
Key_name: PRIMARY 索引的名稱，可以通過這個名稱來DROP INDEX
Seq_in_index: 1 索引中該列的位置（注意理解是“索引中”），參考聯合索引就容易理解了。
Column_name: a 索引的列
Collation: A 列以什麼方式存儲在索引中，可以是A或者NULL。B+樹索引總是A，即排序的。如果使用了heap存儲引擎，並建立了hash索引，這裏就會顯示NULL。因爲hash根據hash桶來存放數據，而不是對數據進行排序。
Cardinality: 5 非常關鍵的值！！！表示索引中唯一值的數據的估計值。Cardinality值/表的行數，應儘可能接近1，如果非常小，那麼考慮是否還需要這個索引？？？
Sub_part: NULL 是否是列的部分被索引，如果是整個列，則該字段爲NULL
Packed: NULL 關鍵字如何被壓縮，如果沒有被壓縮，則爲NULL
Null: 是否索引的列含有NULL值。
Index_type: BTREE 索引的類型。
Comment: 註釋
Index_comment:
Cardinality值（大概的值）非常關鍵，優化器會根據這個值來判斷是否使用這個索引。但是這個值並不是實時更新的，並非每次索引的更新都會更新該值，因爲代價太大。
更新索引的Cardinality信息
mysql> analyze table t \G
*************************** 1. row ***************************
Table: test.t
Op: analyze
Msg_type: status
Msg_text: OK
1 row in set (0.04 sec)
注意：不是每個系統上都得到同樣的結果，目前(MySQL5.1)，analyze table還存在一些問題。
建議：在非高峯時間，對應用程序下的幾張核心表做analyze table操作，這能使優化器和索引更好的工作。