Thanks for explanation. So how this tool will count pages allocated in extents to given index. Will it simply consider these pages empty ? Though I’m not sure the “level” for such pages should be known yet.

Hmm…
Simply, “estimated statistics in dictionary:” shows same values to the INNODB TABLE MONITOR.
(“appr.key vals %lu, leaf pages %lu, size pages %lu” : http://dev.mysql.com/doc/refman/5.0/en/innodb-monitors.html#innodb-table-monitor )
So, honestly, I don’t grasp what is the “size pages” exactly yet…

And, I will add information about “recs/page” and “contiguousness”.
(contiguousness like http://www.percona.com/docs/wiki/patches:innodb_check_fragmentation ?)

What is leaf pages vs size pages ? “key vals: 1204830, leaf pages 133869, size pages 153984″ It looks like size pages could be larger than sum of number of pages on all levels. Is this because there could be some pages which are allocated to the index because of extent allocation but never used or something else ?

This actually tells about 2 different issues with full space utilization – partially filled pages and empty pages in allocated extents.

Another thing I think it would be nice to see values per page as well. This can be computed from the rest of data but it is good if it can be seen. I would use it to understand how efficient range scans could be.

Another thing – how is this stats computed – doing file scan or scanning indexes in the order. It may be good to see information similar to what “filefrag” gives – how badly each index leaf space is fragmented – in perfect world we would prefer to see each of them sequential if we do not use SSDs