前情提要：
数据库版本：5.7.32-35-log。就本人所知，执行set global read_only = 0 后，数据库应该是只读状态。然而在测试执行后的数据库状态后发现，依旧可以建账号，建库，建表，删账号，删库，删表，插入数据，删除数据。
检查read_only：
解题：
read_only查阅官方文档如下：
很显然还涉及账号本身的权限和另一个参数：super_read_only。
现在查看账号当前权限和另一个参数：
一个拥有SUPER权限的账号，在read_only = on & super_read_only = off的情况下，依旧能对数据库进行一系列的DDL和DML操作。
set global super_read_only = on; ：
结论：
一个拥有SUPER权限的账号，在read_only = on & super_read_only = off的情况下，依旧能对数据库进行一系列的DDL和DML操作，但在read_only = on & super_read_only = on时，则不能。
延展
设置read_only = on后，不会影响执行read_only = on前正在执行的事务或已持有的锁，其它空闲表会被执行read_only。执行read_only = on前正在执行的事务或已持有的锁，完成或释放后会被执行read_only。
官方文档原文：The attempt blocks while other clients have any ongoing statement, active LOCK TABLES WRITE, or ongoing commit, until the locks are released and the statements and transactions end. While the attempt to enable read_only is pending, requests by other clients for table locks or to begin transactions also block until read_only has been set.
验证的操作截图如下（图片顺序即步骤顺序）：
开启一个删除表A数据的事务：
此时for update查询表A报错锁等待：
打开read_only：
再for update查询表B，和表A，都是报错当前实例为只读：
之前删除表A数据的事务未提交也未回滚；
在回滚事务前先查询该条删除的数据，回滚，再查询，数据未被删除；因此，事务开始后再执行的read_only=on并未影响该事务
转载请知会，并标明出处。