It it entirely possible that the table is corrupt. I do not mean that the data and/or index pages are damaged. There could be something very simple that is broken.
I recently experienced a problem with a backup script on a Slave Server when I parallel mysqldumped multiple databases. Running mysqldump on one of the databases resulted in a very small mysqldump. The DB had 80+ tables. However, the mysqldump stopped at the fifth table in the DB. When I ran
SHOW CREATE TABLE tblname\G on the table on the Slave, I got the error "Table Not Found". When I ran
SHOW CREATE TABLE tblname\G on the Master, the table description displayed as expected.
What happened was a little crazy: A client asked for a restore of table and an engineer restored the .ibd file of the InnoDB table from a disk backup. The tablespace id of the .ibd file (which was 25) did not match the tablespace id registered in ibdata1 (which was 28).
I fixed the problem by hosing the slave, mysqldumping the master, and setting up replication from scratch. Fortunately, the data and index spave totalled 7GB. Thus rstore process was not a big deal.
MORAL OF THE STORY
The basic problem is that mysqldump does not report an error on an InnoDB when the tablespace id is incorrect. When a mysqldump finishes and does not dump every table in alphabetical order, that indicates it terminated by an error and did so without printing an error message.
Check to make sure
- you can display the table's structure using
SHOW CREATE TABLE
- you can query everything about a table from INFORMATION_SCHEMA.TABLES