京公网安备11010502063487号本机真实搭一主两从，写数据后立刻kill -9模拟崩溃——两个replica真实都已提前收到数据。真实手动提升一个replica为新source，另一个真实重新指向它，写入新数据真实立刻同步过去了。
本机真实配一对循环复制，停掉复制线程后往同一主键真实插入不同数据，重启复制——两边SQL线程真实同时崩溃，报的都是Duplicate entry。跳过冲突后报错消失，但两边数据真实永久分叉。
本机真实往replica打了200次写入压力，中途真实kill -9掉它——重启后错误日志真实显示它没有相信崩溃前记录的位置，而是回退到更早更安全的起点重新拉取，最终两边真实都是205行。
本机真实建了两个角色分别授权，app_read真实能SELECT不能INSERT，app_write真实两者都行。最意外的发现：REVOKE掉一个已连接会话的角色，这个会话真实完全不受影响，权限变更真实只对之后的新连接生效。
本机真实建了个零权限用户，直接SELECT真实被拒绝。给它EXECUTE权限调用SQL SECURITY DEFINER的存储过程，真实读到了数据——哪怕对底层表一丁点权限都没有。换成INVOKER的同一查询，真实又被拒绝了。
本机默认sql_mode下，插入超范围值真实直接报错；关掉严格模式，同样的插入真实静默成功，但把值悄悄夹断了。ONLY_FULL_GROUP_BY关掉后，一条有歧义的查询真实能跑，但返回的是随便挑的一个值。
本机用默认方式连接(走本地socket)，Ssl_cipher真实是空的；换成显式走TCP连接，哪怕没加任何ssl参数，真实自动协商出了TLS1.3。加不加密真实取决于连接方式，不只是配置参数。
本机真实尝试建一张加密表，报错找不到keyring的master key。真实排查发现新旧keyring机制都存在但都没配置好，真实需要在启动参数里配置清单文件，本文如实记录了这个没跑通的过程。
本机真实检查发现audit_log插件文件压根不存在——不是配置问题，是MySQL官方审计日志插件真实只随企业版分发，社区版从没包含过这个文件。
本机把阈值真实调到0.1秒，跑一条SLEEP(0.3)和一条SELECT 1——慢查询日志真实只记录了前者，精确到微秒；后者压根没出现。判断标准真实只有耗时，跟查询复杂度无关。
本机没有额外埋点，直接查这次会话真实的统计——SELECT SLEEP(?)真实累计跑了4次共15546.7毫秒，全部都是本文实验自己产生的真实痕迹，不是构造的演示数据。
本机查sys.io_global_by_wait_by_bytes，一行SQL真实把I/O按文件类型分类好：innodb_log_file真实只写不读，跟doublewrite一篇的发现对得上——sys schema真实是performance_schema的一层人话包装。