【 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) 截图此页面
【附件:截图/日志/监控】
不会卡住
支持事务,默认快照级别隔离,没有问题。rc也没有问题
锁是存在TiKV中吧,Tidb是无状态的,后面的in-memory机制不知道,但数据保证一致性,肯定是有状态的,这个总归也就不是问题了
肯定不会卡住,读与写不冲突的
应该不会卡住 , 没出现过这种情况,尴尬
这种没有对同一步数据进行加锁,不会卡住的
应该是不会的
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-的差异
不会的,不过亿级别的数据量的全表扫描是会影响性能的,有时候慢是因为性能被影响的
不会卡住,你可以测测。tidb底层是查询key和扫描key
不会有问题的
放心大胆干,不会卡住的
不会卡住,读写是不会相互影响的,因为tidb 是快照读,dml锁是执行ddl操作的时候会产生的一种锁,解决了"schema not found " 这个问题
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。