這裡順便總結一下mysql的監控情況，linux的系統級別監控就不提了，因為mysql是io密集型應用，所以重點關注iowait，對於mysql本身，qps（每秒內查詢的次數）tps（每秒內提交的事務，可以理解為insert+update+update），thread running（當前處於活動狀態的資料庫連線數），最重點的就是rt，貌似mysql沒發直接檢視響應時間，這個dba寫工具解決，這個指標可以視為在緊急情況下首要關注的，其次還有innodb層的監控，這個作為開發就比較業餘了。
這裡抄襲一下索引設計的幾個原則：
a、設定索引項，應該是出現在where後面的列，或者連線字句中出現的列；
b、使用唯一索引，索引的基數越大，索引查詢的效果越好，舉例：查詢條件中含有索引欄位和非索引欄位的時候，會優先走索引篩選出資料，然後在資料中回表過濾沒有走索引的字段，但是mysql任務，如果索引篩選出的資料量大於20%，會認為此時走索引效果不如全表掃瞄，繼而放棄索引，走全表掃瞄來查詢；
c、使用短索引，例如乙個屬性200多位，其實索引只要建立前幾位效果會好；
d、最左原則，組合索引中，靈活運用最左字首；
e、不要過度使用索引，索引會占用空間，影響寫入的速度；
（1）慢sql如何獲取？
應用程式能夠感知到sql慢，因為慢了，提供服務就慢，系統吞吐自然就上不去。這時候可以在mysql上面檢視慢sql的日誌，這個檔案看起來不是很方便，dba通過工具把這些日誌加工成比較容易分析，能夠很直觀的看出慢sql是啥，以及sql執行花費的時間和執行的時間點。獲取了這些慢sql，就有了分析的依據。
（2）如何分析sql為啥慢了？
mysql提供了乙個工具來分析sql執行查詢的時候的情況，使用很簡單：explain select語句
輸出的結果是**，各個欄位的解釋如下：
select_type
******：簡單表，即不使用表連線或者子查詢；
primary：主查詢
union：union中的第二個或者後面的查詢語句
subquery：子查詢中的第乙個select
table
輸出結果集的表
type
表連線的型別
system：表中僅有一行，即常量表
const：單錶中最多有乙個匹配行，主鍵或者唯一索引
eq_ref：對於前面的每一行，在此表中只查詢一條記錄，簡單說就是多表查詢中使用主鍵或者唯一索引
ref：和eq_ref類似，區別在於使用的是普通的索引
ref_or_null：和ref類似，區別在於查詢總有null的查詢
index_merge：索引合併優化
unique_subquery：in後面是乙個查詢主鍵的子查詢
index_subquery:in後面的是乙個查詢普通索引的子查詢
range：單錶中的範圍查詢
index：前面的每一行，都通過查詢索引獲取資料
all:全表掃瞄，效能最差
possible_keys
查詢時可能用到的索引
key查詢時實際用到的索引
key_len
索引欄位的長度
refrows
掃瞄行的數量
extra
執**況的說明和描述
如何分析mysql的查詢語句
這裡順便總結一下mysql的監控情況，linux的系統級別監控就不提了，因為mysql是io密集型應用，所以重點關注iowait，對於mysql本身，qps 每秒內查詢的次數 tps 每秒內提交的事務，可以理解為insert update update thread running 當前處於活動狀態...
Mysql慢查詢語句分析
1.show full processlist 解釋 id 連線id，可以使用kill 連線id的方式關閉連線 user 當前使用者 host 當前連線客戶端 db 連線的資料庫 command 顯示當前連線的當前執行的狀態，sleep query connect time 持續時間 state s...
mysql 語句分析 MySQL語句執行分析
今天客戶那邊遇到乙個問題 多選檔案進行操作，資料量一大後台處理就特別慢，瀏覽器顯示504超時。為了驗證問題是否出在sql語句，所以用以下方法來分析 查詢sql執行記錄 explain 分析 mysql 語句執行時間 下面會分別介紹三個方法的開啟方法。查詢sql執行記錄 查詢日誌功能是否開啟 show...