Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 6964549
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: May 27, 20262026-05-27T15:56:20+00:00 2026-05-27T15:56:20+00:00

I know that you shouldn’t rely on the values returned by InnoDB’s SHOW TABLE

  • 0

I know that you shouldn’t rely on the values returned by InnoDB’s SHOW TABLE STATUS.
In particular, the row count and avg data length.

But I thought maybe it was an accurate value taken at some point, and then innodb only refreshes it during an ANALYZE table or maybe some other infrequent event.

Instead what Im seeing is that I can run a SHOW TABLE STATUS on the same table 5 times in 5 seconds, and just get completely different numbers each time (despite the table not having any insert/delete activity in between)

Where are these values actually coming from? Are they just corrupt in innodb?

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-05-27T15:56:21+00:00Added an answer on May 27, 2026 at 3:56 pm

    The official MySQL 5.1 documentation acknowledges that InnoDB does not give accurate statistics with SHOW TABLE STATUS. Whereas MYISAM tables specifically keep an internal cache of meta-data such as number of rows etc, the InnoDB engine stores both table data and indexes in */var/lib/mysql/ibdata**

    InnoDB has no expedient index file allowing a quick query of row numbers.

    Inconsistent table row numbers are reported by SHOW TABLE STATUS because InnoDB dynamically estimates the ‘Rows’ value by sampling a range of the table data (in */var/lib/mysql/ibdata**) and then extrapolates the approximate number of rows. So much so that the InnoDB documentation acknowledges row number inaccuracy of up to 50% when using SHOW TABLE STATUS

    MySQL documentation suggests using the MySQL query cache to get consistent row number queries, but the docs don’t specify how. A succinct explanation of how this can be done follows.

    First, check that query caching is enabled:

    mysql> SHOW VARIABLES LIKE 'have_query_cache';
    

    If the value of have_query_cache is NO then enable the query cache by adding the following lines to /etc/my.cnf and then restart mysqld.

    have_query_cache=1    # added 2017 08 24 wh
    query_cache_size  = 1048576
    query_cache_type  = 1
    query_cache_limit = 1048576
    

    (for more information see http://dev.mysql.com/doc/refman/5.1/en/query-cache.html)

    Query the contents of the cache with

    mysql> SHOW STATUS LIKE 'Qcache%';
    

    Now use the SQL_CALC_FOUND_ROWS statement in a SELECT query:

    SELECT SQL_CALC_FOUND_ROWS COUNT(*) FROM my_innodb_table
    

    SQL_CALC_FOUND_ROWS will attempt a read from cache and, should this query not be found, execute the query against the specified table and then commit the number of table rows to the query cache. Additional executions of the above query (or other ‘cachable’ SELECT statements – see below) will consult the cache and return the correct result.

    Subsequent ‘cachable’ SELECT queries – even if they LIMIT the result – will consult the query cache and allow you to get (once-off only) the total table row numbers with

    SELECT FOUND_ROWS();
    

    which returns the previous cached query’s correct table row total.

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

I know that we shouldn't being using the registry to store Application Data anymore,
Yes I know that it shouldn't be abused and that C# is primariy used
I know this shouldn't be that hard, but I couldn't find the answer on
I know that I should have schema of a table before calling NewRow method
I know that the following code should show and hide a tiny circular progress
So I know that you shouldn't use UrlWriter methods in a model, but I
I know that I shouldn't throw exceptions from a destructor. If my destructor calls
I know that I shouldn't be building a new associated image for my gallery
First of all, I know that you shouldn't try to use regex to modify
I know that such general questions shouldn't be asked, but can someone help me

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.