Bug #13709 | strange changing values in TABLE_ROWS of INFORMATION_SCHEMA.TABLES | ||
---|---|---|---|
Submitted: | 3 Oct 2005 11:30 | Modified: | 3 Nov 2005 0:59 |
Reporter: | Laurenz Albe | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Documentation | Severity: | S3 (Non-critical) |
Version: | 5.0.13-rc, 5.0.14-rc | OS: | Linux (Linux x86 (RHEL 3)) |
Assigned to: | Paul DuBois | CPU Architecture: | Any |
[3 Oct 2005 11:30]
Laurenz Albe
[3 Oct 2005 12:11]
Valeriy Kravchuk
Yes, the shell script provided gives strange results really on my 5.0.14-rc BK build of September 30th, running on Fedora Core 1: [openxs@Fedora 5.0]$ ./13709.sh table_rows 163 table_rows 163 table_rows 112 table_rows 82 Table Op Msg_type Msg_text test.test analyze status OK table_rows 70 table_rows 58 table_rows 58 table_rows 97 Description of the output: the first four lines are the value TABLE_ROWS of INFORMATION_SCHEMA.TABLES for our test table, queried four times with the same query. Then, an ANALYZE TABLE is issued. Then the value of TABLE_ROWS is queried for more times. Note: the actual row count is 100. At least, this should be documented, even if it is an intended behavior.
[3 Oct 2005 12:27]
Valeriy Kravchuk
Actually, this behaviour of InnoDB tables is documented in http://dev.mysql.com/doc/mysql/en/innodb-restrictions.html: "ANALYZE TABLE counts cardinality by doing eight random dives to each of the index trees and updating index cardinality estimates accordingly. Note that because these are only estimates, repeated runs of ANALYZE TABLE may produce different numbers. This makes ANALYZE TABLE fast on InnoDB tables but not 100% accurate as it doesn't take all rows into account." and later: "SHOW TABLE STATUS does not give accurate statistics on InnoDB tables, except for the physical size reserved by the table. The row count is only a rough estimate used in SQL optimization." But I think, the http://dev.mysql.com/doc/mysql/en/tables-table.html page should have this noted in the prominent place too. Changed the category accordingly.
[3 Oct 2005 12:44]
Laurenz Albe
The passages you quoted from the documentation do not explain the observed behaviour to me. They make me think that a) repeated ANALYZE TABLE will calculate different row counts and b) the TABLE_ROWS value will be inaccurate as a consequence. What I observe is that the value of TABLE_ROWS changes from query to query even if I do not issue an ANALYZE TABLE statement between the queries.
[3 Nov 2005 0:59]
Paul DuBois
Thank you for your bug report. This issue has been addressed in the documentation. The updated documentation will appear on our website shortly, and will be included in the next release of the relevant product(s).