Is there a way to get rows_examined in MySQL without the slow log?

Question

I\'m building some profile information for a home grown app. I\'d like the debug page to show the query sent along with how many rows were examined without assuming that slo

Answer 1

It's slightly better than it was in 2006. You can issue SHOW SESSION STATUS before and after and then look at each of the Handler_read_* counts in order to be able to tell the number of rows examined.

There's really no other way.. While the server protocol has a flag to say if a table scan occurred, it doesn't expose rows_examined. Even tools like MySQL's Query Analyzer have to work by running SHOW SESSION STATUS before/after (although I think it only runs SHOW SESSION STATUS after, since it remembers the previous values).

I know it's not related to your original question, but there are other expensive components to queries besides rows_examined. If you choose to do this via the slow log, you should check out this patch:

http://www.percona.com/docs/wiki/patches:microslow_innodb#changes_to_the_log_format

I can recommend looking for "Disk_tmp_table: Yes" and "Disk_filesort: Yes".

Answer 2

Starting in 5.6.3, the MySQL performance_schema database also exposes statements statistics, in tables such as performance_schema.events_statements_current.

The statistics collected by statements include the 'ROWS_EXAMINED' column.

See http://dev.mysql.com/doc/refman/5.6/en/events-statements-current-table.html

From there, statistics are aggregated to provide summaries.

See http://dev.mysql.com/doc/refman/5.6/en/statement-summary-tables.html

Answer 3

Prepend the query with EXPLAIN. In MySQL that will show the query's execution path, which tables were examined as well as the number of rows examined for each table.

Here's the documentation.

Answer 4

From documentation:

Handler_read_rnd

The number of requests to read a row based on a fixed position. This value is high if you are doing a lot of queries that require sorting of the result. You probably have a lot of queries that require MySQL to scan entire tables or you have joins that don't use keys properly.

Handler_read_rnd_next

The number of requests to read the next row in the data file. This value is high if you are doing a lot of table scans. Generally this suggests that your tables are not properly indexed or that your queries are not written to take advantage of the indexes you have.

read_rnd* means reading actual table rows with a fullscan.

Note that it will show nothing if there is a index scan combined with a row lookup, it still counts as key read.

For the schema like this:

CREATE TABLE mytable (id INT NOT NULL PRIMARY KEY, data VARCHAR(50) NOT NULL)

INSERT
INTO    mytable
VALUES  …

SELECT  id
FROM    mytable
WHERE   id BETWEEN 100 AND 200

SELECT  *
FROM    mytable
WHERE   id BETWEEN 100 AND 200

, the latter two queries will both return 1 in read_key, 101 in read_next and 0 in both read_rnd and read_rnd_next, despite the fact that actual row lookups occur in the second query.