mysql slow log query

Question

Question - When i am looking into mysql-slowquery.log then there i found queries having high query_time, even when one query has row examine = 1. This log is of a heavily populated database. From php website. Can you explain the reason and why are they used(if any idea about queries) ?

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

Yes it's returning 1 row but also see number of rows has been checked Rows_examined: 10636 . Also, it may take long time if by the time SELECT is executed there is an exclusive or write lock present on the table due to any DML operation. In such case SELECT has to wait until the lock is released (considering the fact that transaction isolation level is READ COMMITED )

Answer 2

Query type 1:

information_schema is not a real table. Instead, it is a view into various in-memory structures. Some of these structures are views into stuff that needs to be calculated or even fetched from disk. So... Some IS queries are fast, some are unexpectedly slow.

In your case, it had to touch 10K things, and that is what took time, apparently 198ms. That is reasonable.

The query looks like it is counting the number of tmp tables used by things like ALTER TABLE . (I can't think why it is useful.)

(Note: My Answer disagrees with Rahul's.)

Query type 2:

This took 7ms, and apparently made one probe into a table with at most one row. It seems to have done a table scan, but found nothing with that action . This is a 'reasonable' amount of time. After all, it had to locate and open the table, perhaps for the first time in this session, and read whatever it found.

The query is, however rather strange. It does a COUNT(*) and a GROUP BY , but it does not list what it is grouping by in the SELECT . If there were useful data, it would return a set of numbers (counts), but no clue of what each count refers to.

Addenda - From Amazon:

Type 1 is meant to identify leftover temporary tables in InnoDB dictionary, which is used as diagnostic aid in case of crashed ALTERs.
Type 2 is an internal check for features enabled on the instance.

To address the impact, we need to know the frequency of these queries, whether it is RDS or Aurora, the setting of log_queries_not_using_indexes , and how far apart the client and server are (milliseconds latency).