把執行時間較長的sql語句記錄下來.
(1)檢視是否開啟慢查詢
show variables like
'slow_query_log';
set
global log_queries_not_using_indexes=on;
show variables like
'long_query_time';//檢視慢查詢時間
setglobal long_query_time=0;//設定慢查詢時間
set
global slow_query_log=on;
show variables like
'slow_query_log_file';
#time:140606
12:30:17
#user@host:root[root]@localhost//執行sql的主機資訊
#query_time:0.000000031 lock_time:0.000000000 rows_sent:0 rows_examined:0
//sql的執行資訊
set timestamp=1402029017;//sql執行時間
show tables;//sql的內容
mysqldumpslow -t
3 慢查詢日誌路徑
pt-query
-digest 慢查詢日誌路徑
注意pt-query-digest 分析中的rows examine項
注意pt-query-digest 分析中rows examine 和 rows send 的對比
table:顯示這一行的資料是關於哪張表
type:這是重要的列,顯示連線使用了何種型別.從最好到最差的連線型別為:const、eq_reg、ref、range、index和all.
possible_keys:顯示可能應用在這張表中的索引.如果為空,沒有可能的索引.
key:實際使用的索引.如果為null,則沒有使用索引.
key_len:使用的索引長度.在不損失精確性的情況下,長度越短越好.
ref:顯示索引的哪一列被使用了,如果可能的話,是乙個常數.
rows:mysql認為必須檢查的用來返回請求資料的行數.
extra:
①using filesort:看到這個的時候,查詢就需要優化了.mysql需要進行額外的步驟來發現如何對返回的行排序.它根據連線型別及儲存排序鍵值和匹配條件的全部行的行指標來排序全部行.
②using temporary:看到這個的時候,查詢需要優化了.這裡,mysql需要建立乙個臨時表來儲存結果,這通常發生在對不同的列集進行order by上,而不是group by上.
//查詢最後支付的時間
//建立索引
count(*)包含null值 而count(id)不包含null值.
通常情況下,需要把子查詢優化為join查詢,但在優化時要注意關聯鍵是否有一對多的關係,要注意重複資料.
#七.優化group by查詢
優化後
explain select actor.first_name,actor.last_name,c.cnt from sakila.actor inner
join(select actor_id,count(*) as cnt from sakila.film_actor group
by actor_id) as c using(actor_id);
優化後
MySQL優化（二） 優化SQL語句
2.優化子查詢，派生表和檢視引用 3.優化information schema查詢 4.優化資料變更宣告 5.優化資料庫許可權 6.其他優化技巧 資料庫應用程式的核心邏輯是通過sql語句執行的，無論是直接通過直譯器發出還是通過api在後台提交。查詢以select 語句的形式執行資料庫中的所有查詢操作...
SQL 語句優化 OR 語句優化案例
從上海來到溫州，看了前幾天監控的sql語句和資料變化，發現有一條語句的io次數很大，達到了150萬次io，而兩個表的資料也就不到20萬，為何有如此多的io次數，下面是執行語句 select ws.nodeid,wi.laststepid,wi.curstepid from workflowinfo ...
sql語句優化！
1.不要使用in操作符，這樣資料庫會進行全表掃瞄，推薦方案 在業務密集的sql當中盡量不採用in操作符 a 改為 a 4.is null 或is not null操作 判斷字段是否為空 5.及 操作符 大於或小於操作符 大於或小於操作符一般情況下是不用調整的，因為它有索引就會採用索引查詢，但有的情況...