用MySQL复制功能，竟然能同时解决性能、备份和扩展三大难题

（引用来源：知乎专栏文章《MySQL复制：从入门到“放弃”？不，是入门到精通！》、MySQL官方文档8.0版本“复制”章节、个人技术博客“码农的日常”中《我用MySQL主从复制做了啥》一文）

直接用MySQL自带的复制功能,确实能同时应对性能、备份和扩展这三个让人头疼的大问题，这听起来好像很高级，其实道理并不复杂，就像是一个老师讲课，好几个学生同时在做笔记，只不过这些“学生”也是功能强大的数据库服务器。

它是怎么解决性能问题的？

想象一下,一个网站或者应用，所有的用户操作，不管是简单的查询余额，还是复杂的生成报表，都挤在唯一的一台数据库服务器上，这台服务器就像是一个超市里唯一的收银台，高峰期肯定排长队，用户体验非常差。

MySQL的复制功能允许我们设置一台“主”数据库和一台或多台“从”数据库，我们规定，所有涉及数据写入、更新、删除的操作（比如注册新用户、下订单），都必须去“主”数据库那里完成，而那些只读的操作，比如查看商品列表、查询订单状态、浏览文章，就可以分散到一台或多台“从”数据库上去执行。

这样做的好处立竿见影,主数据库从此可以专心处理“写操作”这块硬骨头，压力小了很多，而大量的、占据日常操作80%以上的“读请求”，被分摊到了几台从数据库上，每台服务器的负载都降下来了，处理速度自然就快了，整个应用的响应速度得到提升，能够同时服务的用户数也大大增加，这其实就是最简单的“读写分离”，是提升性能最直接有效的手段之一。

它又是如何解决备份难题的？

传统上,我们给数据库做备份是个挺麻烦的事，为了得到一份完整一致的数据快照，往往需要在夜深人静、业务量最小的时候，暂时锁住数据库不让写入，然后进行备份，这个过程不仅耗时，而且期间可能会影响线上服务的可用性。

有了复制功能,备份就变得轻松多了，我们可以专门拿出一台从数据库，它的唯一任务就是不停地从主数据库那里同步数据，当我们需要做备份时，根本不需要去打扰正在忙碌服务线上用户的主数据库，我们直接在这台专门用于备份的从数据库上进行操作就可以了，可以放心地把它暂停复制一会儿，然后慢慢悠悠、仔细地进行全量备份或增量备份，备份完成后再让它继续同步，整个过程对主数据库零影响，保证了7x24小时服务的连续性，相当于有了一个实时更新的数据副本，心里踏实多了。

它怎么还能帮忙做扩展？

这里的扩展,主要指的是“读扩展”，当你的业务不断增长，用户量越来越大，单纯的读写分离可能也不够用了，读请求的压力也会变得巨大，这时候，MySQL复制的扩展性就体现出来了，因为它非常灵活，你可以在需要的时候，几乎无限制地（理论上受网络和资源限制）增加从数据库的数量，一台从库扛不住读压力？那就再加两台、三台……通过负载均衡技术，把海量的读请求均匀地分发到这个“从数据库集群”中，这种水平扩展的能力，对于应对突发流量（比如电商秒杀、热点新闻）尤其有用，可以快速添加新的从库来分担压力。

这种架构还为更高阶的扩展打下了基础,可以做异地容灾，在不同的城市部署从库，让不同地区的用户访问离他们最近的数据库，速度更快，甚至可以把一些专门的计算分析任务（比如生成年度报表）放到特定的从库上去跑，避免这些耗时很长的操作拖累主库的性能。

MySQL复制也不是万能的银弹,它有一个最明显的“缺点”：数据同步到从库是有极短暂延迟的，也就是说，一个用户刚在主库上更新了信息，可能立刻去查询，请求被分配到了某个从库，会发现自己刚才的修改还没显示出来，但对于绝大多数对数据实时性要求不是百分之百苛刻的应用场景（比如晚零点几秒看到评论），这个延迟是完全可接受的，通过优化网络和服务器配置，这个延迟可以控制在非常低的水平。

MySQL复制是一个经过时间考验的、非常成熟和可靠的内置功能，它用相对简单的逻辑和低廉的成本（无非是多几台服务器），一举三得地解决了性能、备份和扩展这三个核心运维难题，是构建稳健、可扩展数据库架构的基石。