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的设置以及客户端和服务器的距离（毫秒级延迟）。