采集带有unikey的到kafka处理时间还是长（最新代码） about gravity HOT 6 CLOSED

replace 产生的 delete 肯定会阻塞 insert

from gravity.

replace 产生的 delete 肯定会阻塞 insert

大佬 我之前过滤掉delete 操作数据恢复正常了， 但是今天突发这种更新很慢的问题 是为啥，还是类似同样的日志，数据是同步给kafka的

from gravity.

updatePrimaryKey 是有主键更新，会拆成先 delete 再 update
为什么慢要贴监控

from gravity.

updatePrimaryKey 是有主键更新，会拆成先 delete 再 update 为什么慢要贴监控

from gravity.

冲突队列很长。
给个最小复现的例子吧。表结构，执行什么样的 sql。

from gravity.

冲突队列很长。 给个最小复现的例子吧。表结构，执行什么样的 sql。

CREATE TABLE bigdatamk_api_label_user_detail_duplicate_4 (
id BIGINT ( 20 ) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'id',
label_id VARCHAR ( 32 ) COLLATE utf8mb4_bin NOT NULL COMMENT '标签ID',
customer_id VARCHAR ( 64 ) COLLATE utf8mb4_bin NOT NULL COMMENT '会员ID',
statistics_date date NOT NULL COMMENT '',
label_status INT ( 11 ) NOT NULL COMMENT '',
group_id BIGINT ( 20 ) NOT NULL COMMENT '',
seller_id BIGINT ( 20 ) DEFAULT NULL COMMENT '',
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
PRIMARY KEY ( id ),
UNIQUE KEY uniq_user_label ( customer_id, label_id ),
KEY idx_label_id ( label_id )) ENGINE = INNODB AUTO_INCREMENT = 917784618319240790 DEFAULT CHARSET = utf8mb4 COLLATE = utf8mb4_bin COMMENT = '标签用户明细数据'

数据是执行replace into 操作

from gravity.