insert语句是否加锁

OceanBase 技术问题
#1

rt。
没看到相关文档说insert是否会对插入的行进行加锁，但是实际测试的情况：
事务A：
1.begin
2.insert into T…
3.commit
事务B：
1.begin
2.insert into T…（该语句与事务A的第二条语句完全相同，两条语句插入的主键值相同）
3.commit

执行顺序，A.1、B.1、A.2、B.2（此时B.2阻塞）、A.3（执行完该操作后，B.2结束阻塞）、B.3。
如果A.2没有对插入行加锁，那么B.2是如何检测到A正在插入的行与自己插入的行是一样的，从而陷入了阻塞？
如果A.2对插入行进行了加锁，那么加的是什么锁，与update时一样加的都是行锁吗？

#3

应该是表上加了意向锁没有加行锁，B.2语句到阻塞是因为数据库系统检查了唯一性约束， 发现事务B尝试插入的主键值与事务A已插入的主键值相同

1 个赞
#4

“发现事务B尝试插入的主键值与事务A已插入的主键值相同”，这句话里，是指事务B在事务A没提交之前就看到了事务A的插入数据了吗？那数据库岂不是读未提交级别？，但显然ob是读已提交，事务A没有提交，事务B看不到A的插入数据，那么他是怎么判断触发了唯一性约束的呢？
如果事务A是加了意向锁，没有加行锁。那么事务B到来，想插入，看到了A的意向锁，它知道事务A正在插入，但是它不知道事务A在插入哪些行，那么事务B是阻塞还是插入呢？照这样看，事务A肯定在没提交之前对所插入的行做了一定的标记，这个标记不是行锁，那是什么呢？
问题有点多，请见谅

#5

你看一下这个文档

OceanBase MySQL 模式和 MySQL 数据库显式加行锁表现差异

https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000210012?back=kb
表锁
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001052142
可以测试一下 这两个表可以查看你到锁的类型
SELECT b.* FROM oceanbase.__all_virtual_trans_stat a,oceanbase.GV$OB_LOCKS b where a.trans_id=b.trans_id;