Does INFORMATION_SCHEMA always contain up-to-date metadata? This query prints the size (in terms of data and indexes) of the tables in mydatabase:

SELECT table_name "Table name", 
round(((data_length)/1024/1024),2) "Data size",
round(((index_length)/1024/1024),2) "Index size" 
FROM information_schema.TABLES 
WHERE table_schema="mydatabase" AND data_length&gt;1000000 
order by table_name INTO OUTFILE '/tmp/mydatabase_values' 
FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n';


Sizes are printed in Mb, and only tables larger than 1Mb are considered. Tables are listed in alphabetical order and the output is saved into a CSV file.

Running this query at different points in time showed - obviously - different results as data changed in the database.  However, just in the last few weeks the query produced identical results.  Does it mean that the database hasn't changed much in size (as you can see, rounding is done at the 10Kb boundary) or is there something I am really missing?  The question might sound absurd, but do the views in INFORMATION_SCHEMA always hold up-to-date metadata?

Note: no, I am not reading each time the same CSV file by mistake.

Edit: all tables are InnoDB, and innodb_file_per_table=1.
Yes, the data is up-to-date.  But don't read too much into the numbers.

InnoDB, especially, preallocates space for future rows.  So, it is quite possible to look at the exact size of a table, insert dozens of rows (maybe even thousands), then look at the size again -- and see exactly the same Data_length and Index_length.

When you first create an InnoDB table and insert one small row, the data length will be 16384 bytes (one 16KB block).  As you add more rows, eventually that block will overflow, and another block will be added.  Later (as the table exceeds some threshold), the table will grow in units of (I think) 8MB (an "extent").  This will allow even more rows to be added with no change in disk footprint.

Also, was the table created with innodb_file_per_table ON or OFF?  This controls whether the stuff goes into the communal ibdata1 file or the table's own .ibd file.

And, as @jkavalik points out, DELETE and UPDATE and ALTER can mess with the size, again not necessarily in predictable ways.

Edit

Those are the "disk footprint" size.  Compare to what you can see looking at the filesystem.

A 1-row table with one 4-byte INT takes at least 16384 bytes of disk space.  If you are saying that "4" is the real size, then I have been answering the wrong question.  I say that 16KB is the real size.

There is overhead for each column, for each row, for each block, for BTree structure, for each extent, for indexes, etc.  And InnoDB allocates no less than 16KB at a time.  And room for 'undo' copies of rows.  Hence, "4" turns into "16384".

As a "Rule of Thumb", if you add up the data sizes (4 for INT, etc) of the columns in a row, multiply by the number of rows, then multiply by something between 2 and 3, you are likely to get the "size" of the table.  (The 1-col, 1-row example, of course, is an end-case that exceeds 3x)