MYSQL系统的参数 read_only 是一个普通的控制数据库登录的普通用户对于数据库的数据的操作控制的权限。在percona 的版本中在MYSQL 5.6.21中他们添加了一个参数 super_read_only，官方的版本在 5.7.8后添加了这个功能。这里就会有一个问题，既然已经有了read_only 为什么还要添加一个super_read_only的功能。有么有多此一举。

在说这个问题就的扒一扒，MYSQL的“黑历史”，与其他的数据库复制的双重模式不同，MYSQL 的复制是通过逻辑复制的方式，对于从库的控制也属于“放飞自我的模式”， 主库的数据可以和从库的数据不同吗？  当然，当然，当然可以。如果使用其他数据库的DB 大多不会理解。  但事实上，这是一个优点，我可以让我的从库和主库的索引的数量和功能都不同，只要不碰上，主库和从库的 “G” 点，他们的复制还是能良好的进行，并且各做各的。

当然双刃剑，有些管理者是不希望从库这么的自由，并且在某些自由过头的情况下，对操作者有些限制，至少哪怕提醒一下。这些控制着估计说的就是那些DB，所以super_read_only 防止的是谁，不言而喻。

那么这个设置在某些情况下是不是鸡肋， 举例在使用mha的情况下，看你的mha的版本如果是0.56 及以下的，是采用在切换后，将从库变为read_only的方式。0.58的模式中则更换成super_read_only  ，那这又怎么样。

目前采用的流行的中间件产品，proxysql 对于MHA 类型的主库判断是基于read_only 来判断到底这个数据库中，那台是主库，那台是从库，并且依据read_only 来进行读写分离，以及切换数据的路由。当然proxysql 2.0 后的版本支持了 super_read_only  。

所以这个super_read_only的使用，还是要看你的所使用的中间件产品以及MHA的版本，来部分决定super_read_only到底是不是适合在你的mysql高可用的架构中使用。

当然也可以对于一些重要的数据库变更中，阻止所有数据库写入数据库将这个参数作为使用的一种灵活的命令，设置后，就有点 一夫当关万夫莫开的气势了。

另外需要提及的，read_only 和super_read_only 如果同时使用，那么super_read_only 打开 read_only 参数自动开， 同时super_read_only 关闭，read_only关闭， 呵呵此时倒是应该讨论read_only 的存在的必要性了。