慢查詢日誌中long_query_time 與log_queries_not_using_indexes與min_examined_row_limit 關係分析 參數介紹: long_query_time:慢查詢日誌記錄超時的時間,無論是不是有索引,單位秒。 log_queries_not_usin ...
慢查詢日誌中long_query_time 與log_queries_not_using_indexes與min_examined_row_limit 關係分析 參數介紹: long_query_time:慢查詢日誌記錄超時的時間,無論是不是有索引,單位秒。 log_queries_not_using_indexes:慢查詢日誌記錄沒有使用索引的記錄,無論是否超時long_query_time。 min_examined_row_limit:慢查詢日誌僅僅記錄掃描行數超過行min_examined_row_limit的記錄(不包括該參數值本身,是大於該參數值的掃描行)。 綜合分析:
記錄日誌關係 = (long_query_time || log_queries_not_using_indexes)&& min_examined_row_limit
可見即使滿足超時條件,如果不滿足掃描行數條件,也不會記錄,因此這個參數要慎用。可見如果以上公式中三個參數都開啟,那麼滿足下麵2個條件其中之一才會被記錄。
1.我們有隻有超時 且 掃描行數大於min_examined_row_limit時候才會被記錄。
2.我們有隻有沒有使用索引 且 掃描行數大於min_examined_row_limit時候才會被記錄。 註意的問題: Tags1:min_examined_row_limit有會話變數和全局變數,動態改變參數值的時候需要分別進行修改,實測過程中改變全局變數(set global min_examined_row_limit=100)不會同步改變會話變數(set min_examined_row_limit=100),因此必須手動改變會話變數,才會對當前會話有效。
Tags2:需要註意的是min_examined_row_limit檢測的行數有時候與explain的有些出入,有時候同一個語句,explain顯示的select_type=simple的掃描行數rows與慢查詢日誌中記錄的Rows_examined:不一樣,後者會多500行左右,不知道為何 下麵是Mariadb 5.5.64伺服器上進行測試的相關代碼:
explain select * from hpx_member where u_id = 888444;#u_id 有索引測試
explain select * from hpx_member where major = '8881';#major沒有索引測試
explain select * from hpx_member where phone like '15933%';#phone有索引測試,測試掃描行數與min_examined_row_limit關係
select * from hpx_member where phone like '1593356%';
show global VARIABLES like '%index%'
show VARIABLES like '%index%'
show global VARIABLES like '%min_examined_row_limit%'
show VARIABLES like '%min_examined_row_limit%'
show VARIABLES like '%long_query_time%'
set global long_query_time=0.0001
set global log_queries_not_using_indexes=off
set global min_examined_row_limit=0
set min_examined_row_limit=50
select sleep(2),8888; 歡迎加我們微信wang1415035017進入微信高級技術群共同進步,或者掃碼加入我們哦(V_V)
歡迎加我們微信wang1415035017進入微信高級技術群共同進步,或者掃碼加入我們哦(V_V)