我理解有些错误的印象是一些无良的技术服务公司为了赚钱误导相关人员造成的。由于历史原因，有些问题是假象，但一切都是发展，也许有些问题在新版本中已经解决了。为此，笔者整理了一些常见的MySQL误区，希望开发者能够用发展的眼光看待事物。印象一：InnoDB存储引擎适合写密集型应用，MyISAM适合读密集型应用答：这个问题在8、9年前应该是论坛里争议很大的话题，也就是2005年的时候，而以上的回答，就是对那个时代的总结。其实这个答案只是回答了堆表和索引组织表更新时的区别，其他很多问题都没有考虑。到现在的MySQL5.6，InnoDB存储引擎已经彻底打败了MyISAM，其他任何应用程序都不需要再使用MyISAM了。当然，MyISAM存储引擎本身已经完全停止了开发。印象二：InnoDB存储引擎存在并发问题，大并发下性能较差答：InnoDB的并发问题一直是官方改进的重点，调优得很好。MySQL5.7下只读查询轻松达到50WQPS就是***的证明。此外，Oracle官方还对各种并发瓶颈进行了优化，比如SSD磁盘并行刷新优化、redolog优化、undo多线程purge优化等，所以InnoDB存储引擎本身的并发问题其实很少。如果是上层的并发瓶颈，比如笔者之前提到的电商秒杀问题（回复77可以查看），可以通过线程池技术进行优化。印象三：MySQL复制不可靠，经常导致数据丢失或复制失败答：确实，在MySQL5.6之前，MySQL复制存在一些问题，复制可能不可靠。不过在两年半前发布的MySQL5.6版本中，复制可靠性问题已经彻底解决。如果大家还是报错，基本可以定义为配置问题。有需要的可以联系作者帮你调。使用作者开源的MySQL版本InnoSQL，可以免费获得技术支持。印象四：MySQL复制是逻辑复制，所以速度慢，不如Oracle等物理复制答：逻辑复制一定比物理复制慢？不一定，有很多综合因素。之前MySQL的复制速度慢，因为它的复制是单线程的，延迟问题比较严重。不过MySQL5.7和MariaDB10.0已经支持并行复制功能，延迟问题基本解决。比如网易电商使用并行复制后，复制延迟从5小时降为0。印象五：MySQL复制不能保证主从数据的完全一致性，不适合数据严格的场景一致的MySQL已启动。MySQL5.7已经提供了一种零数据丢失的复制方式，可以通过配置一个参数来解决。类似PostgreSQL和Oracle也是通过先写入远程日志来保证数据零丢失，这本身并不是一个很新的技术。网易在云数据库中也已经使用了近3年的时间（InnoSQL早在5.5就支持了），可以说是完全通过在线应用考验的技术。只能说可能需要考虑一些细节问题，但是有什么问题也可以咨询作者。印象六：sync_binlog需要设置为0或2答：MySQL5.6之前存在组提交失败的问题，所以需要将此参数设置为0或2以提高性能。但这意味着潘多拉魔盒已经打开，其中隐藏着很多问题。MySQL5.6、InnoSQL5.5、MariaDB5.5都解决了组提交失效问题。所以，sync_binlog必须设置为1
