MySQL 8.0: The end of MyISAM
The story that started 20 years ago is coming to its end. I’m talking about the old MyISAM storage engine that was the only storage provided by MySQL in 1995, and was available in MySQL for 20+ years. Actually, part of my job as a MySQL consultant for 10+ years was to discover MyISAM tables and advise customers how to convert those to InnoDB.
(Check your MySQL installation, you may still have MyISAM tables).
MySQL 5.7 still used MyISAM storage for the system tables in the MySQL schema.
In MySQL 8.0 (DMR version as of writing), the MyISAM storage engine is still available. But in a very limited scope:
- After introducing the new data dictionary, the MyISAM tables are gone from the system schema (“mysql” db).
- Working with MyISAM is harder now (and discouraged): you can’t just copy MyISAM tables into a running MySQL server, they will not be discovered (unlike InnoDB, where you can use “ALTER TABLE … IMPORT TABLESPACE”)
- However, you can create a table engine=MyISAM, and it will work as before
InnoDB implemented all the older, missing features:
Feature | MyISAM | InnoDB |
Full Text Indexes | yes | Since MySQL 5.6 |
Portable tables (tablespaces) | yes | Since MySQL 5.6 |
Spatial Indexes/RTREE (GIS) | yes | Since MySQL 5.7 |
Last update for table | yes | Since MySQL 5.7
(http://dev.mysql.com/worklog/task/?id=6658)
|
Suitable for temp tables | yes | Since MySQL 5.7
Also complex selects uses InnoDBondisk temp tables
|
Faster count(*) | yes | *Faster in MySQL 5.7 but does not store counter |
So the only MyISAM advantages left are:
- Tables will be smaller on disk compared to uncompressed InnoDB tables.
- The count(*) is still much faster in MyISAM:
I would not use MyISAM unless there is a specific case, and for well-known reasons (MyISAM are non-transactional, table level locks, with no crash recovery, etc.)
My colleague Laurynas Biveinis also suggested converting MyISAM to an optional storage engine plugin.
No comments:
Post a Comment
Note: only a member of this blog may post a comment.