京公网安备11010502063487号本机存了4个真实中国城市的经纬度坐标，用ST_Distance_Sphere真实算出广州到深圳约105.7公里，跟真实地理距离对得上。给矩形范围做MBRContains查询，EXPLAIN真实显示走的是Index range scan。
本机真实从零搭了一主一从：两个独立的MySQL实例、开GTID、建复制账号，CHANGE REPLICATION SOURCE配上SOURCE_AUTO_POSITION=1，真实在source上插入的数据立刻在replica上查到了一模一样的结果。
本机真实单独停掉IO线程，往source插一行数据，replica上真实完全看不到；反过来单独停SQL线程，插入的数据真实被IO线程收进了relay log但没应用，直到重启SQL线程才真实落地。
本文原本想真实制造一次可观测的复制延迟，往source连续跑400次独立写入——结果Seconds_Behind_Source真实全程都是0，真实的瓶颈在source客户端连接开销，不在replica应用能力。
本机跑了一条UPDATE，用mysqlbinlog真实解码对应的binlog事件——里面真实没有SQL语句文本，只有改之前和改之后两组真实的列值。
本机一张5列的宽表只更新1个int列：binlog_row_image=FULL模式下事件真实占了1670字节；换成MINIMAL模式，同样的更新真实只占46字节，缩小了约36倍。
本机真实往replica注入一个空事务标记GTID已执行，之后source真实产生了同一GTID号的真实数据——重启复制后replica真实永久缺失这条数据，两边SQL线程却都显示健康。
本机真实装上半同步复制插件，replica在线时一次commit真实只要605微秒；真实把replica停掉再提交，这次commit真实卡住整整2005192微秒，精确对应配置的2秒超时。
本机把SOURCE_DELAY设成5秒，source插入数据后每秒查一次replica：第1到第4秒真实都查不到，第5秒真实精确出现，跟配置几乎分毫不差。
本机真实起了第三个MySQL实例作为第二个source，给replica配了独立channel——配置时真实撞上账号重名冲突，解决后验证两个channel的数据真实同时落到了同一个replica上。
本机真实搭3个节点尝试组建Group Replication集群，真实撞上通信栈自连接握手失败和SSL模式不一致两个坑，单节点真实bootstrap成功，但加入更多节点最终真实卡在视图变更超时，如实记录没有跑通的真实过程。
本机真实检查发现InnoDB Cluster依赖的MySQL Shell没有安装，真实只提供需要系统权限的.pkg安装包。诚实说明这篇没能跑出真实工作的集群，基于真实能验证的部分说明它和上一篇卡住的Group Replication的关系。