Has anyone run across federated tables causing the inability to report anything useful from information_schema?
What I have found is that *AnythinG* more complicated than a select table_name, table_schema, engine (no like statements, concat, or math on the fly will not work — see below for the concat ex)

I have and wonder if there is a good work around for 5.1.30
mysql Ver 14.14 Distrib 5.1.30, for unknown-linux-gnu (x86_64) using readline 5.1

All these wonderful ideas to monitor growth seem to get whacked when I run specific queries. Some queries to information_schema are ok though so it isn’t consistently and completely broken.

I’ve tried to dump the entire set of databases with triggers and functions (-R) to search for it and that won’t work even with –no-data and –force

One, this db.acct_set table does not exist because there is no database db. I assume it could be defined anywhere.
Two, the obscure error 1146 (select error) and 1431 (error on mysqldump) don’t get me very far

mysql> SELECT concat(table_schema,’.',table_name),concat(round(table_rows/1000000,2),’M') rows,concat(round(data_length/(1024*1024*1024),2),’G') DATA,concat(round(index_length/(1024*1024*1024),2),’G') idx,concat(round((data_length+index_length)/(1024*1024*1024),2),’G') total_size,round(index_length/data_length,2) idxfrac FROM information_schema.TABLES ORDER BY data_length+index_length DESC LIMIT 10;
ERROR 1431 (HY000): The foreign data source you are trying to reference does not exist. Data source error: error: 1146 ‘Table ‘db.acct_set’ doesn’t exist’

mysql> desc db.acct_set;
ERROR 1146 (42S02): Table ‘manhunt.v4_account_settings’ doesn’t exist

In the recent Innodb versions the NULL values are not simply not stored. Format will be something like column 1 value 2, column 10 value 3 skipping all 8 NULL columns in between.

For large tables the difference between reported size and physical size may be insignificant this is true.

However there are very different applications around the world. There are applications which have hundreds of thousands and millions of tables. For these this difference is significant.

On large tables I have found that the difference is insignificant. There’s always these one or two very large tables which consume most disk space, and when considering disk limitations, they are the one being taken into account.

Did you happen a lot on databases where there were many small tables, and which constituted the majority of disk space?