mysql慢日志查詢

Question

問題-當我查看mysql-slowquery.log時，我發現查詢的查詢時間很高，即使一個查詢的行檢查=1。此日志的數據庫也很密集。 從php網站。 您能否解釋使用它們的原因和原因（如果對查詢有任何想法）？

Query type 1 :

# Query_time: 0.198267  Lock_time: 0.000121 Rows_sent: 1  Rows_examined: 10636
use mysql;
SET timestamp=1490832000;
SELECT count(name) FROM information_schema.innodb_sys_tables
    WHERE name like '%/#sql-%';

Query type 2:

# Query_time: 0.007362  Lock_time: 0.000127 Rows_sent: 0  Rows_examined: 1
use mysql;
SET timestamp=1490835900;
SELECT count(*) from mysql.rds_history
    WHERE action = 'disable set master'
    GROUP BY action_timestamp, called_by_user, action, mysql_version ,master_host,
             master_port, master_user, master_log_file , master_log_pos,
             master_ssl
    ORDER BY action_timestamp LIMIT 1;

Answer 1

是的，它返回1行，但還檢查了行數Rows_examined: 10636 。 同樣，如果由於任何DML操作而在執行SELECT表上存在exclusive或write鎖定，則可能要花費很長時間。 在這種情況下， SELECT必須等待直到釋放鎖為止（考慮到事務隔離級別為READ COMMITED ）

Answer 2

查詢類型1：

information_schema不是真實的表。 相反，它是查看各種內存結構的視圖。 這些結構中的一些是需要計算甚至需要從磁盤獲取的內容的視圖。 所以...有些IS查詢很快，有些卻出乎意料地慢。

在您的情況下，它必須觸摸10K的東西，這就是時間，顯然是198ms。 那是合理的。

該查詢看起來像是在計數ALTER TABLE類的東西使用的tmp表的數量。 （我想不出為什么有用。）

（注意：“我的回答”與拉胡爾的觀點不同。）

查詢類型2：

這花費了7毫秒，並且顯然是將一個探針插入了最多一行的表中。 它似乎已經完成了表掃描，但是通過該action什么也沒發現。 這是一個“合理”的時間。 畢竟，它可能必須在本次會話中第一次定位並打開表，並讀取所找到的內容。

但是，查詢很奇怪。 它執行一個COUNT(*)和一個GROUP BY ，但是沒有在SELECT列出它的分組依據。 如果有有用的數據，它將返回一組數字（計數），但不知道每個計數指的是什么。

附錄 -來自亞馬遜：

類型1用於標識InnoDB詞典中剩余的臨時表，該表在ALTER崩潰時用作診斷輔助。
類型2是對實例上啟用的功能的內部檢查。

為了解決影響，我們需要知道這些查詢的頻率，無論是RDS還是Aurora， log_queries_not_using_indexes的設置以及客戶端和服務器的距離（毫秒級延遲）。