MyISAM表存在的问题及解决之道
MyISAM与InnoDB引擎对比
众所周知，MySQL一个非常重要的特点就是支持插件式存储引擎，其中使用广泛的两个引擎就是MyISAM和InnoDB。从MySQL5.5开始，默认存储引擎变为了InnoDB，在此之前默认引擎使用的是MyISAM。在早期MyISAM使用是非常普遍的，为MySQL流行立下了汗马功劳。但是随着InnoDB的推出，它已经完全替代了MyISAM，有关两者的区别见下表。
引擎 | 事务
| 锁机制
| 外键
| 并发性能
| 缓存
| 备份
| 系统表是否使用
| 引入GTID后的影响
|
MyISAM
| 不支持
| 表锁
| 不支持
| 低
| 索引
| 为了保持数据一致性，必须对表加读锁，影响业务写
| 使用
| 有问题(一个事务中同时使用事务引擎和非事务引擎)
|
InnoDB
| 支持
| 行锁
| 支持
| 高
| 索引和数据
| 不需要锁表，不影响业务读写
| 使用
| 无问题
|
除此之外，还有一些信息可以补充一下。
从MySQL5.5开始，默认存储引擎变为了InnoDB，在此之前默认引擎使用的是MyISAM.
很多系统表也使用了MyISAM。从MySQL5.7.8开始引入了disabled_storage_engines参数可以禁止用户使用MyISAM表。
从MySQL8.0开始，系统表也将采用InnoDB，完全放弃MyISAM。
MyISAM适合静态表，所以系统表采用了MyISAM。
MyISAM表可以直接将数据文件拷贝恢复。
MyISAM面临的主要问题
问题1：主从复制中断、主从数据不一致
由于MyISAM不支持事务，导致特别容易出现主备复制异常、主备数据不一致的情况。总结如下:
DELETE语句 | LOAD语句 | |||||||||||
BINLOG_FORMAT | 同步正常 | 数据一致 | 同步正常 | 数据一致 | ||||||||
STATEMENT | NO | NO | NO | NO | ||||||||
ROW | YES | YES | YES | YES | ||||||||
MIXED | NO | NO | YES | YES | ||||||||
这种现象很容易通过下面的测试步骤进行验证。
1. 建立主备复制关系，将binlog_format修改为STATEMENT或者MIXED。
2. 创建一个MyISAM测试表，导入一些数据
3. 执行delete操作或者load操作，当执行到中途时，突然ctrl+c强制中断。
问题2: 进行备份时，无论是采用mysqldump进行的逻辑备份还是使用extrabackup进行的物理备份，为了保证MyISAM表的数据一致性，必须对表进行加锁，导致阻塞写入。这对于重建主从是经常出现的问题。
这两个问题的存在让一些客户（主要是DBA们）对MyISAM深恶痛绝，都纷纷要求转成InnoDB。
华为云数据库的解决之道
很多云厂商也是考虑到MyISAM带来的问题，纷纷采取各种手段来劝诫用户不要使用MyISAM，要不就是官网上说明，不支持MyISAM，要不就会对MyISAM进行自动转换。
对于MyISAM转InnoDB，并不能简单的alter table…engine=InnoDB；因为两者在某些方面存在语法的不同，是不完全兼容的。这造成很多用户并不敢贸然将MyISAM转InnoDB。
华为云数据库对各种CASE进行了深入分析，测试了几百种用例，已经完成了对MyISAM转InnoDB，对用户完全透明。
当然，有的用户可能“中毒至深”，要求必须使用MyISAM，那也不用担心。MyISAM提供了一个参数disabled_storage_engines来进行修改，默认值为MyISAM，MEMORY，也就是会将MyISAM转换为InnoDB，如果需要修改的话，可以提工单修改为空。但是强烈建议，不要再迷信MyISAM了。
总结
MyISAM透明转换成InnoDB，对于一些深受MyISAM之痛的客户来讲是个福音，它无需你再去改造应用。该特性已经上线，敬请体验。
想了解更多精彩内容，请扫码关注【HW云数据库】
- 点赞
- 收藏
- 关注作者
评论（0）