Tatjana,
<cut>
> ChangeSet@stripped, 2007-11-02 15:59:34+01:00, tnurnberg@stripped +1 -0
> Bug#31700: thd->examined_row_count not incremented for 'const' type queries
>
> UNIQUE lookups are a special case in do_select() and don't go through the
> code-path that normally does the row-counting. CS adds counting to that
> case.
Please consider the following CSet comment:
The explanation IMO is: UNIQUE (eq-ref) lookups result in table being
considered as a "constant" table. Queries that consist of only constant
tables are processed in do_select() a special way, that doesn't invoke
evaluate_join_record(), and therefore doesn't increase the counters
join->examined_rows and join->thd->row_count.
The patch increases these counters in this special case.
NOTICE:
This behavior seems to contradict what the documentation says in Sect. 5.11.4:
"Queries handled by the query cache are not added to the slow query log, nor
are queries that would not benefit from the presence of an index because the
table has zero rows or one row."
>
> No test case as issue shows only in slow query log and other counters can
> give subtly different values (with regard to counting in create_sort_index(),
> synthetic rows in ROLLUP, etc.).
Please add a test case to 5.1 using the mysql.slow_log table as we discussed.
>
> sql/sql_select.cc@stripped, 2007-11-02 15:59:32+01:00, tnurnberg@stripped +12 -0
> Don't forget const tables when counting read records!
>
> diff -Nrup a/sql/sql_select.cc b/sql/sql_select.cc
> --- a/sql/sql_select.cc 2007-10-23 15:48:56 +02:00
> +++ b/sql/sql_select.cc 2007-11-02 15:59:32 +01:00
> @@ -10339,6 +10339,18 @@ do_select(JOIN *join,List<Item> *fields,
> error= (*end_select)(join,join_tab,0);
> if (error == NESTED_LOOP_OK || error == NESTED_LOOP_QUERY_LIMIT)
> error= (*end_select)(join,join_tab,1);
> +
> + /*
> + Count up examined_rows if key matches, no matter whether we
> + actually got to send the record in end_send() (due to HAVING
> + excluding it, failures, LIMIT, ...).
> + Make sure we count up row_count after the fact, otherwise any
> + warnings will contain row numbers that are off by one.
> + join->send_records is increased on success in end_send(), so
> + we don't touch it here.
> + */
We will get inside this block in other cases than just unique key lookups,
so it is not exact. There are a number of different cases when a query has
only constant tables. Please shorten and generalize the comment.
> + join->examined_rows++;
> + join->thd->row_count++;
I would consider adding here:
DBUG_ASSERT(join->examined_rows <= 1)
> }
> else if (join->send_row_on_empty_set())
> {
>
