TIDB之间存在DML之间的锁问题么

🪐 TiDB 技术问题
1

【 TiDB 使用环境】 测试
【 TiDB 版本】v7.5.2
【复现路径】
表行数：亿级别
表字段个数：40+
隔离级别：rc
事务：未开启事务
1、sesson 1: select * from tab where col1 like ‘%%’ order by col2 #触发全表扫描
2、session 2: insert into tab values (col1,col2) #session 1执行过程中，session 2是否可以执行，不会卡主吧
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】

2

不会卡住

3

支持事务，默认快照级别隔离，没有问题。rc也没有问题

4

锁是存在TiKV中吧，Tidb是无状态的，后面的in-memory机制不知道，但数据保证一致性，肯定是有状态的，这个总归也就不是问题了

5

肯定不会卡住，读与写不冲突的

6

应该不会卡住 ， 没出现过这种情况，尴尬

7

这种没有对同一步数据进行加锁，不会卡住的

10

应该是不会的

11

select 和insert之间不会有什么冲突。

select for update和insert 在乐观事务下也不会阻止insert。而是会在提交的时候检查冲突。导致提交失败。

https://docs.pingcap.com/zh/tidb/stable/sql-statement-select#语法元素说明

在悲观事务下，这两者的情况，参考下面这个

有些 WHERE 子句中使用了 range，TiDB 在执行这类 DML 语句和 SELECT FOR UPDATE 语句时，不会阻塞 range 内并发的 DML 语句的执行。

https://docs.pingcap.com/zh/tidb/stable/pessimistic-transaction#和-mysql-innodb-的差异

12

不会的，不过亿级别的数据量的全表扫描是会影响性能的，有时候慢是因为性能被影响的

13

不会卡住，你可以测测。tidb底层是查询key和扫描key

14

不会有问题的