卡卡其其
(Ti D Ber L Q Dgtw5l)
1
【 TiDB 使用环境】生产环境
【 TiDB 版本】6.5.2
【复现路径】jdbc、channel 、batchsize
【遇到的问题：问题现象及影响】写入突然降低
【附件：截图/日志/监控】
reader : hdfs reder
channel 10
batchsize : 1024
“jdbcUrl”: “jdbc:mysql://xxxx:4000/ads_global?useUnicode=true&characterEncoding=utf-8&useSSL=false&autoReconnect=true&useServerPrepStmts=true&cachePrepStmts=true&prepStmtCacheSize=1000&prepStmtCacheSqlLimit=2048000&useConfigs=maxPerformance&rewriteBatchedStatements=true&allowMultiQueries=true&useCursorFetch=true&netTimeoutForStreamingResults=28800&sessionVariables=wait_timeout=123456”
卡卡其其
(Ti D Ber L Q Dgtw5l)
6
CREATE TABLE ods_crm_biz_t_integral_account_log (
id bigint(64) NOT NULL AUTO_INCREMENT,
member_id bigint(64) NOT NULL COMMENT ‘会员ID’,
integral_type varchar(50) NOT NULL COMMENT ‘积分类型’,
integral_value decimal(12,2) DEFAULT NULL COMMENT ‘积分值’,
tran_id bigint(64) DEFAULT NULL COMMENT ‘交易ID’,
tran_no varchar(50) DEFAULT NULL COMMENT ‘交易号’,
update_type int(2) DEFAULT NULL COMMENT ‘变更类型（1:增加，2:扣减）’,
accruals_id bigint(64) DEFAULT NULL COMMENT ‘应计ID’,
oper_src int(2) DEFAULT ‘1’ COMMENT ‘来源(1:增加，2:扣减，4:初始化积分，5:手动调整 ，6 积分清零，7 积分兑优惠券,8 积分兑券）’,
repay_id varchar(10000) DEFAULT NULL COMMENT ‘偿还ID’,
tenant_id varchar(10) DEFAULT NULL COMMENT ‘租户ID’,
create_dept bigint(64) DEFAULT NULL COMMENT ‘创建部门’,
create_position bigint(64) DEFAULT NULL COMMENT ‘创建职位’,
create_user bigint(64) DEFAULT NULL COMMENT ‘创建人’,
create_time datetime DEFAULT NULL COMMENT ‘创建时间’,
update_user bigint(64) DEFAULT NULL COMMENT ‘修改人’,
update_time datetime DEFAULT NULL COMMENT ‘修改时间’,
status int(2) DEFAULT NULL COMMENT ‘状态’,
is_deleted int(2) DEFAULT ‘0’ COMMENT ‘是否删除(0:正常,1:删除)’,
original_member_id bigint(64) DEFAULT NULL COMMENT ‘合并原会员id’,
original_card_no varchar(100) DEFAULT NULL COMMENT ‘原会员卡号’,
original_member_comments varchar(2000) DEFAULT NULL COMMENT ‘合并会员备注’,
PRIMARY KEY (id) /*T![clustered_index] CLUSTERED */,
KEY t_integral_account_log_index1 (member_id,integral_type),
KEY t_integral_account_log_index2 (tran_id),
KEY t_integral_account_log_index3 (tran_no),
KEY t_integral_account_log_index4 (create_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin AUTO_INCREMENT=1594605659184571699 COMMENT=‘积分账户变更日志’
卡卡其其
(Ti D Ber L Q Dgtw5l)
7
是考虑热点问题么？之前测试过表下边加东西，让他打散，不太管用呢
应该就是热点问题，你去dashboard下面看下导入的时候这个表热点情况，我的建议是将建表语句中的 AUTO_INCREMENT 改为 AUTO_RANDOM
卡卡其其
(Ti D Ber L Q Dgtw5l)
11
其他任务目前都在以每秒1000条的速度写入，就这个任务，每秒200条。并且热点上找不到他
看你的表结构，可以看到 AUTO_INCREMENT 当前值是太大了，感觉是有问题的，建议检查下
另外，想问下，你这个数据迁移，id 这个字段是否带了值？
个人建议的话，可以带值，并且 batchsize 可以考虑改小一点
最后，我个人感觉是 AUTO_INCREMENT 的热点问题导致的 —— 比较这个自动增长，导致只能在一个 tidb 执行插入；其它 task 可以在不同的 tidb 执行插入的
卡卡其其
(Ti D Ber L Q Dgtw5l)
13
带值，每个批次200条，差别不大。目前每秒最高1300条/s
卡卡其其
(Ti D Ber L Q Dgtw5l)
15
乱序可能没办法了，我这个是同步上游的数据，他的就这样
北京大爷
(北京大爷)
16
如果确认未来数据一直是以 同步方式向 TIDB 写入数据，可以考虑把 AUTO_INCREMENT 属性去掉，并且将主键改成 member_id ,integral_type, id ，并且删除 member_id ,integral_type 这个 二级索引
好处是利用业务 member_id 的离散型来打散数据。
但注意数据查询需要 id 进行过滤时候，尽量将其他二级索引改成 tran_id+id 等等来加速查询效果减少回表带来的 时延
应该有什么操作影响了吧？或者将target端修改成Mysql，验证下是不是tidb问题
是不是下游压力大？