京公网安备11010502063487号本机拿一段真实的JSON数组跑JSON_TABLE：加上NESTED PATH之后，真实把tags数组拆开变成了单独的行——效果和一次真实的一对多JOIN一模一样。
本机对4条真实文本建FULLTEXT索引，自然语言模式搜索真实按命中词数给出不同的相关度分数，同时命中两个词的行分数真实精确是只命中一个词的2倍。
本机存了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上。