MySQL并行复制已经是老生常谈，笔者从2010年开始就着手处理线上这个问题，刚开始两三年也乐此不疲分享，现在再提这个话题本来是难免“炒冷饭”嫌疑。 最近触发再谈这个话题，是因为有些同学觉得“5.7的并行复制终于彻底解决了复制并发性问题”, 感觉还是有必要

很多时候，RDS用户经常会问如何调优RDS MySQL的参数，为了回答这个问题，写一篇blog来进行解释： 哪一些参数不能修改，那一些参数可以修改； 这些提供修改的参数是不是已经是最佳设置，如何才能利用好这些参数； 哪些参数可以改 细心的用户在购买RDS的

来自DBA+社群MySQL领域原创专家李海翔分享的MySQL优化案例，关于MySQL V5.6.x/5.7.x SQL查询性能问题。

bug 触发条件如下： 优化器先选择了 where 条件中字段的索引，该索引过滤性较好； SQL 中必须有 order by limit 从而引导优化器尝试使用 order by 字段上的索引进行优化，最终因代价问题没有成功。 复现case 表结构 create table

最近学习了赵海平的演讲，了解到facebook的mysql查询可以进行异步化，从而提高性能。由于facebook实现的比较早，他们不得不对php进行hack才得以实现。现在的php5.5，已经无需hack就可以实现了。 对于一个web网站的性能来说，瓶颈多半是来自于&

我们知道MySQL的主备同步是通过binlog在备库重放进行的，IO线程把主库binlog拉过去存入relaylog，然后SQL线程重放 relaylog 中的event，然而这种模式有一个问题就是SQL线程只有一个，在主库压力大的时候，备库单个SQL线程是跑不过主库的多个用户线程的，这样备库延迟是不可避免的。为了解决这种n对1造成v

MySQL 主备之间数据同步是通过binlog进行的，当主库更新产生binlog时，备库需要同步主库的数据，通过binlog协议从主库拉取binlog进行数据同步，以达到主备数据一致性的目的。但当主库tps较高时会产生大量的binlog，以致备库拉取主库产生的binlog时占用较多的网络带宽，引起以下问题： 在MySQL中，Q