不懂就问
(zhouyueyue)
2019 年8 月 7 日 09:24
24
tidb.yml 里面这个参数确认是 stmt-count-limit: 5000 这样的吗?
AndyHoo
(AndyHoo)
2019 年8 月 7 日 09:27
25
我们没有修改那个默认配置的,我刚才看了下,我们的tidb.toml中的stmt-count-limit 为5000
不懂就问
(zhouyueyue)
2019 年8 月 7 日 09:35
28
不需要什么脚本 ,设置 autocommit =0 之后,同一个session 写入 5000+ 数据,在 commit ,自然就有结果。
AndyHoo
(AndyHoo)
2019 年8 月 7 日 09:51
29
我们看了是因为我们开了悲观锁的问题,我们使用乐观锁后单个事务超过5000条sql会报错,悲观锁下面的stmt_count_limit 是没有限制吗?
AndyHoo
(AndyHoo)
2019 年8 月 8 日 01:50
31
你好,大事务里面有一条是
我建了如下一张表
CREATE TABLE
t_test` (
id
bigint(20) NOT NULL AUTO_INCREMENT COMMENT ‘id’,
name
varchar(20) NOT NULL COMMENT ‘姓名’,
create_time
timestamp DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (id
),
KEY idx_name
(name
),
KEY idx_ncreate_time
(create_time
),
UNIQUE KEY uni_idx_name
(name
)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=2001357
COMMENT=‘test’;`
我插入75001条记录就会报
Cause: java.sql.SQLException: transaction too large, len:300001
请问我们的30w的限制如果转换成记录条数或者说affected rows是这样算的吗:
record_count_limit = 30w / (1+index的个数)
1 个赞
hongchao
(Hong chao)
2019 年8 月 8 日 02:13
32
在TiDB里面,每一行数据会是一个KV记录,每一个索引也是一个KV记录。
你的表结构有3个索引,所以每插入一行数据,实际会有4个KV记录。
75000 * 4 = 300000.
所以在插入75001条数据的时候就超过了限制。
1 个赞
AndyHoo
(AndyHoo)
2019 年8 月 8 日 02:22
33
嗯嗯,大事务的限制你们有什么应对方案吗(尽量减少对现有的逻辑的改动的)?
当事务提交发生写入冲突时,乐观锁可以进行事务的重试。需要重试的语句在重试前都要保存在 TiDB server 中,如果事务语句太多,会对 TiDB server 造成很大负担,所以,我们设置了 5000 这个语句条数限制。
开启悲观锁后,因为事务不会出现写入冲突错误,提交几乎必定成功。所以,我们对于它去掉了事务中语句条数的限制。
关于大事务限制,我们将会在 4.0 中,去掉 30 万 kv 的限制,并将事务大小限制从 100 MB 提升至 10 GB。对于没有开启重试的乐观事务,也将去掉 5000 行语句的限制。4.0 大概在年底发布。
ebin1983
(ebin1983)
2019 年11 月 6 日 04:16
36
赶紧啊 兄弟 我们现在的场景都是大事务操作,其实我们是不用事务的 就是都是这种 几百万 几千万数据 update
或者 delete这种的
system
(system)
关闭
2022 年10 月 31 日 19:10
37
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。