无主键表导致从库SQL线程卡住，因MySQL 5.7+并行回放依赖writeset，无主键时ROW格式无法精准定位行，退化为全表扫描，事务被强制串行且可能引发全表锁。
为什么无主键表会让从库SQL线程卡住
MySQL 5.7+ 启用 slave_parallel_type = LOGICAL_CLOCK 后，从库并行回放依赖事务间写集（writeset）的独立性。但若某张表没有主键或唯一索引，binlog_format = ROW 下 MySQL 无法精确识别被修改的行——它会退化为全表扫描匹配 WHERE 条件，导致该事务被标记为“不可并行”，强制串行执行。更糟的是，一个无主键的 UPDATE 或 DELETE 在从库可能触发全表锁或慢得离谱，直接拖垮整个 SQL 线程。
如何快速识别无主键且参与复制的表
别只查 SHOW CREATE TABLE，要结合复制链路实际行为：在从库上执行以下查询，找出近24小时被 binlog 回放过、却无主键的表：
SELECT DISTINCT
SUBSTRING_INDEX(event_info, ' ', 2) AS table_ref,
CONCAT(table_schema, '.', table_name) AS full_name
FROM performance_schema.events_statements_history_long
WHERE event_info LIKE 'UPDATE %' OR event_info LIKE 'DELETE %'
AND sql_text NOT REGEXP 'WHERE.*[=<>].*'
AND CONCAT(table_schema, '.', table_name) IN (
SELECT CONCAT(table_schema, '.', table_name)
FROM information_schema.tables
WHERE table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
AND table_type = 'BASE TABLE'
AND table_primary_key_columns IS NULL
)
ORDER BY full_name;
注意：table_primary_key_columns 是伪字段，真实判断需用：
- 检查
information_schema.key_column_usage中constraint_name = 'PRIMARY' - 或用
SELECT COUNT(*) FROM information_schema.statistics WHERE table_schema = ? AND table_name = ? AND index_name = 'PRIMARY'
修复方案：加主键 or 改写逻辑，不能只靠参数调优
加主键是最彻底解法，但线上大表加主键风险高；若业务允许，优先用以下组合策略：
- 对无主键表的写操作，强制带上显式唯一条件（如
WHERE id = ? AND create_time = ?），避免全表扫描 - 禁用该表的并行回放：在从库执行
SET GLOBAL slave_parallel_workers = 0仅临时规避，不推荐长期使用 - 若无法加主键，改用
pt-online-schema-change --alter "ADD COLUMN id BIGINT AUTO_INCREMENT PRIMARY KEY FIRST"，它能在线补主键且不锁表 - 确认主库已开启
binlog_transaction_dependency_tracking = WRITESET，否则即使有主键，writeset 也无法生效
容易被忽略的副作用：从库 read_only + 无主键 = 隐形死锁
当从库设了 read_only = ON，但应用仍通过某些中间件或误配置往从库写入（比如 INSERT IGNORE INTO 无主键表），会导致 Slave_SQL_Running_State 卡在 Waiting for dependent transaction to commit，而 Seconds_Behind_Master 却显示 0——因为 IO 线程正常，SQL 线程在等一个永远等不到的依赖事务。这种延迟不会报错，只会静默堆积。
