mysql慢查询日志

Question

问题-当我查看mysql-slowquery.log时，我发现查询的query_time很高，甚至当一个查询的行检查= 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行，但也可以查看number of rows has checked Rows_examined: 10636。此外，如果在执行SELECT时，由于任何DML操作而在表上存在exclusive或write锁，则可能需要很长时间。在这种情况下，SELECT必须等到锁被释放(考虑到事务隔离级别为READ COMMITED)

Answer 2

查询类型1：

information_schema不是一个真正的表。这些结构中的一些是需要计算甚至从磁盘获取的内容的视图。所以..。

在您的例子中，它必须接触10K的东西，这就是所需的时间，显然是198ms。这是合理的。

查询类型2：

这花费了7毫秒的时间，显然使一个探测器进入一个最多有一行的表。它似乎已经进行了表扫描，但在该action中什么也没有找到。这是一个“合理”的时间。毕竟，它必须定位并打开表，可能是在本会话中的第一次，并读取找到的任何内容。

然而，这个查询相当奇怪。它执行一个COUNT(*)和一个GROUP BY，但没有列出它在SELECT中的分组依据。如果有有用的数据，它将返回一组数字(计数)，但没有任何线索表明每个计数指的是什么。

附录-来自亚马逊：

类型1用于标识InnoDB字典中的剩余临时表，该表在发生崩溃的更改时用作诊断辅助工具。

类型2是对实例上启用的功能的内部检查。

为了解决影响，我们需要知道这些查询的频率，无论是RDS还是Aurora，log_queries_not_using_indexes的设置，以及客户端和服务器之间的距离(毫秒延迟)。