必须在主库设binlog_transaction_dependency_tracking='WRITESET'，否则从库无法收到写集，slave_parallel_workers无效；从库需配slave_parallel_type='LOGICAL_CLOCK'，而非不存在的'WRITESET'。
主库没配 binlog_transaction_dependency_tracking=WRITESET，从库再多线程也白搭
MySQL 8.0 默认用 COMMIT_ORDER，只靠提交时间戳分组，对单 session 高并发事务几乎无法并行。必须在主库显式设为 WRITESET，否则从库收不到带写集（writeset）的 binlog 事件，slave_parallel_workers 就是摆设。
关键操作（主库执行）：
SET PERSIST binlog_transaction_dependency_tracking = 'WRITESET';-
SET PERSIST transaction_write_set_extraction = 'XXHASH64';（比XXHASH32冲突率更低） -
SET PERSIST binlog_transaction_dependency_history_size = 25000;（太小会挤掉旧写集，误判冲突）
注意：WRITESET_SESSION 只对当前会话生效，生产环境必须用全局 WRITESET；且该参数只在主库起作用，从库设了无效。
为什么 slave_parallel_type=WRITESET 会报错或静默失效
MySQL 根本没有 slave_parallel_type='WRITESET' 这个取值——这是常见误解。WRITESET 是主库的依赖追踪策略，不是从库的并行调度类型。
从库必须设为：
-
slave_parallel_type = 'LOGICAL_CLOCK'（MySQL 8.0.22+ 也支持'WRITESET'，但仅限于极少数内部场景，不推荐） -
slave_parallel_workers = 8～16（建议先设 8，观察performance_schema.replication_applier_status_by_worker中活跃 worker 数） -
slave_preserve_commit_order = ON（必须开，否则可能因乱序执行导致主键冲突）
如果误设 slave_parallel_type='WRITESET'，MySQL 会报错或直接忽略，回退到默认的 DATABASE 模式，实际只跑 1 个 worker。
表没主键或唯一键，WRITESET 自动降级且不报错
WRITESET 依赖行级写集哈希，而写集提取需要能唯一标识每一行——即表必须有 PRIMARY KEY 或 NOT NULL UNIQUE KEY。一旦遇到无主键表，事务自动 fallback 到 COMMIT_ORDER，且 MySQL 不报任何警告。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
排查方式：
- 查
SHOW CREATE TABLE tbl_name确认主键/唯一键存在 - 检查
binlog_row_image是否为FULL（MINIMAL或NOBLOB会导致写集信息缺失） - 确认无 DDL 混入事务流（如
ALTER TABLE会强制串行阻塞后续所有事务）
DDL 和无主键表是 WRITESET 失效最隐蔽的两个原因，它们不会触发错误，但会让并行能力归零。
从库 log_slave_updates=OFF 会悄悄破坏 WRITESET 并行
这个参数看似只影响级联复制，实则是 slave_preserve_commit_order=ON 能正确工作的前提。当它关闭时，从库 SQL 线程执行完 relay log 后不生成自己的 binlog 事件，导致 writeset 依赖链断裂，Coordinator 无法准确判断事务间冲突，最终退化为单线程回放。
必须确保从库配置中包含：
-
log_slave_updates = ON（写进 my.cnf 并重启，或动态设后重启复制） -
gtid_mode = ON且enforce_gtid_consistency = ON（主从都需开启） - 启动复制必须用
START SLAVE（不是只启 IO 线程）
验证是否真并发：别只看 Seconds_Behind_Master，要查 SHOW PROCESSLIST 是否有多个 Slave_worker 处于 Reading event from the relay log，同时查 performance_schema.replication_applier_status_by_worker 的 WORKERS_PROCESSED 是否持续增长。
