I have read that table index compression happens just in MyISAM, but I came across an article in dev.mysql that said: InnoDB supports table and index compression! So now what is the pros of MyISAM? Is there any reason left to use MyISAM? (except full-text search)
|
Recovering Disk SpaceAs far as recovering InnoDB diskspace goes, you only have to migrate data out of ibdata1 and import it back one time if you enable innodb_file_per_table. Once you do that, any InnoDB table that gets bloated can be shrunk. For example, if you have an InnoDB called
or
Restoring Databases@Craig is totally right on MyISAM. As for InnoDB, restoring tables individually can be a nightmare. This is the case because tables are either inside ibdata1 (innodb_file_per_table=0) or outside (innodb_file_per_table=1).
|
||||
|
|
|
Compression In InnoDB It exists in the InnoDB version at the table level as of MySQL 5.1. http://dev.mysql.com/doc/innodb-plugin/1.0/en/. Two advantages on the MyISAM side that I appreciate. Recovering Disk Space In MyISAM, you can delete a database on the File System without impacting the other databases and recover disk space. With InnoDB the ibdata file does not shrink when you remove databases. I have only been able to recover space in the ibdata file by deleting it and then restoring each remaining database. Perhaps someone knows a better way? Restoring Databases Another advantage to MyISAM is being able to restore a database using a backup system like bacula or Acronis. With MyISAM I can copy a database into and out of MySQL via file system commands, once again without affecting the other databases. With InnoDB, I have to do everything via the a MySQL client. So I think that MyISAM is simpler to manage in certain situations. In a database that had a mixture of MyISAM and InnoDB, you would probably only be able to restore specific tables, but I haven't tried that yet. As far as performance goes, a white paper from MySQL I recently read about 5.5 shows that InnoDB is better. |
|||
|
|