write_set_extraction 是 MySQL 8.0 控制组复制冲突检测精度的系统变量，默认值 XXHASH64，用于提取事务修改的主键或唯一键哈希值构成 write set；设为 OFF 会导致组复制启动失败；无主键表的 DML 不生成 write set，无法检测冲突，必须添加主键才能生效。
MySQL 8.0 组复制中 write_set_extraction 是什么
write_set_extraction 是 MySQL 8.0 引入的一个系统变量，控制组复制（Group Replication）如何提取事务的写集合（write set），即事务实际修改了哪些主键或唯一键。它不决定是否启用组复制，而是影响冲突检测的精度和开销。
默认值是 XXHASH64，表示用 XXHASH64 算法对主键/唯一键值哈希后生成 write set；另一个可选值是 OFF，此时完全跳过 write set 提取——但组复制要求必须开启，设为 OFF 会导致 START GROUP_REPLICATION 失败并报错：ER_GRP_RPL_WRITE_SET_EXTRACTION_OFF。
- 仅当表有主键或至少一个非空唯一索引时，行变更才会被纳入 write set
- 没有主键/唯一键的表，其 DML 不参与冲突检测，可能在不同节点产生不一致
-
write_set_extraction=XXHASH64是当前唯一安全可用的值，OFF和MURMUR32（已废弃）都不应使用
为什么 update 没主键时组复制不报冲突
组复制的冲突检测只作用于 write set 中的键值，而 write set 只从带主键或非空唯一索引的表中提取。如果一张表没主键，UPDATE t SET x=1 WHERE y=2 这类语句虽然能执行，但它的修改不会生成任何 write set 条目。
结果就是：两个节点同时更新同一行（逻辑上），组复制完全感知不到——因为两边的 write set 都为空，冲突检测直接跳过。
- 现象：两个节点各自成功提交，后续查数据发现不一致，且
SELECT * FROM performance_schema.replication_group_member_stats里CONFLICTS_DETECTED始终为 0 - 验证方式：检查
INFORMATION_SCHEMA.TABLES中TABLE_ROWS非零但TABLE_SCHEMA+TABLE_NAME在INFORMATION_SCHEMA.STATISTICS中无主键记录 - 修复不是改配置，而是加主键：
ALTER TABLE t ADD PRIMARY KEY (id)—— 否则无论怎么调write_set_extraction都无效
XXHASH64 对性能和兼容性的影响
XXHASH64 是目前 write set 提取的唯一实现，它在事务提交前对每行的主键/唯一键字段做哈希，再把哈希值加入 write set。这个过程发生在 binlog 写入前，属于事务提交路径的一部分。
影响集中在高并发小事务场景：大量单行更新（如计数器、状态位）会因哈希计算和 write set 构造带来轻微延迟，但通常低于 5% 的吞吐下降；大事务（上千行）则更明显，因为 write set 本身要序列化进 binlog event 的 transaction_context_log_event 字段。
- MySQL 8.0.27+ 对空字符串、NULL 值的哈希处理更稳定，旧版本（如 8.0.19）遇到
UNIQUE KEY (a,b)中某列为 NULL 时可能漏项 - 从库（replica）不需要
write_set_extraction生效，该变量只在组复制成员节点上有意义 - 不能通过
SET GLOBAL动态修改，必须重启 mysqld 才生效（但一般也不需要改）
常见错误：误以为 write_set_extraction 能解决所有冲突
有人看到文档说“write set 用于检测冲突”，就以为只要开了组复制、配好 write_set_extraction，就能拦住一切并发修改。其实它只管“键级冲突”，不管语义冲突或范围冲突。
比如两个事务都执行 UPDATE t SET status='done' WHERE created_at ，即使表有主键，只要它们影响的行互不重叠，write set 就不重合，组复制认为无冲突——哪怕业务上这本应是互斥操作。
- 错误日志里看不到冲突，但数据逻辑已错乱，这类问题无法靠调整
write_set_extraction解决 - 真正要防的是“同一行被两个节点同时改”，而不是“同条件被两个节点同时扫”
- 复杂业务逻辑的并发控制，还得靠应用层加分布式锁、或数据库层用
SELECT ... FOR UPDATE显式加锁
write set 机制很轻量，也正因为它只看键不看逻辑，所以才快；想让它覆盖业务规则，等于让哈希函数理解你的领域模型——它做不到。
