Category: InnoDB

They say the number of rows you see in PHPMyADMIN is approximate and not very precise for innodb tables, i can tell you that depending on how the table has been used, the results can be very very inaccurate and sometimes irrelevant.

phpmyadmin wants to display a row count with the list of tables, in myisam, a value is maintained within the database saying how many rows are in the database, INNODB does not maintain such a value so it has to either respond accurately without regard to the delay and scans required or give an approximate reading, it will depend on how you ask, read on for more details.

Q: why are innodb row counts innacurate in PHPMYADMIN ?

Well, innodb would return an accurate count if it were asked formally with a

SELECT COUNT(*) FROM tablename"

But phpmyadmin can not execute such a statement with every listing of a database, because it means the database engine will have to read the whole database and scan all rows.

Q: in that case how come it works for MyISAM ?

A: MyISAM maintains a number stating how many rows are in there that is incremented and decremented with every insert and delete, so the database engine does not need to scan the whole table to give us a row count.

Q: Then where does PHPMYADMIN get those approximate numbers ?

For speed, PHP MY ADMIN would execute something similar (If not exactly)

SHOW TABLE STATUS WHERE 1;

This is when MyISAM would read it’s internal row count value, and Innodb would return an estimate because it does not maintain such a value.

You can also use the command to see a subset of the tables like this

SHOW TABLE STATUS LIKE 'wp_%';

to see status of all tables starting with ‘wp_’

Q: Why does innodb not maintain such a number

A: probably for performance reasons, to avoid the need to update such a number with every insert and every delete.

Please note: most of you are probably visiting this post for the answer to whether you can use multiple disks with innoDB, the answer is, even though you can not move idb files around like when you move MYI MYD files, you can move an IDB file while the DB engine is not running, then create a symlink where the Innodb expected to find the original file, then start mysql again, so the short answer is that innodb does work with symlinks just like myisam.

The second answer is, you can not use more than one disk on the same table (even though you can for the same database by putting every table on a separate disk).

As you would probably know, innodb, by default stores all data into its central, single file data dictionary (on debian, /var/lib/mysql/ibdata1), you can ask innoDB to put every table’s data in a separate file (tablename.ibd) by simply adding the directive innodb_file_per_table anywhere under [mysqld] section.

Databases already in single file will stay there, the directive only affects the creation of new databases, InnoDB does not mind mixed mode regarding ibd files, dome tables in a single database can be in the shared file, and some can have their own files. files created while the directive is in effect will get separate files, you can then remove the directive from your my.cnf and the engine will start putting new databases back into the shared file.

Mind you, unlike ISAM tables, you can not move these files around, in MyISAM you can simply copy the 3 files that are any table, the .frm, .MYI and .MYD and you have your table elsewhere, in INNODB, this is not the case as much is still stored in INNODB’s ibdata1 , also, innodb files are connected to a certain database with internal strings, Yet, you can copy the whole data directory and have it work, remember, log files are also needed and must be kept.

To move an .ibd file and the associated table from one database to another, use a RENAME TABLE statement:

RENAME TABLE db1.tbl_name TO db2.tbl_name;

The main disadvantage of splitting data files per table is disk space, files in INNODB never get smaller, when in 1 file, other tables can use that space of deleted rows in another table, when split apart, you can only use the occupied space again if you add rows to the same table that had deleted rows.

The advantages are

1- You can utilize multiple disks for both space and performance (By using symlinks)
2- You can backup certain tables and leave others to add flexibility to your backup plan