有两个表：tab1有字段id和maxRow tab2有字段tab1_id和foo
要执行代码
if (select count(*) from tab2 where tab1_id=1)<(select maxRow from tab1 where id=1)
insert tab2 values(1，'a')
作用是在insert tab2的时候，查一下tab1 里规定的数量，如果没达到就可以插入。因为怕insert之前、select之后，正好有别的连接也在插入记录。所以可能应该设隔离级别为串行。不过在简单实验的后就发现了问题。
实验如下：
首先在连接1上执行：
set transaction isolation level serializable --语句1
begin tran
if (select count(*) from tab2 where tab1_id=1)<(select maxRow from tab1 where id=1)
insert tab2 values(1，'a') --语句2
执行结果：(1行受影响)
然后在连接2和连接3上执行 语句1 到 语句2，同样没有提交。
下面是用活动监视器查看的锁的情况：
图中：2073058421是tab1的id，2089058478是tab2的id
在连接1上commit tran，显示“命令已成功完成。”
连接3 显示“(1行受影响)”
连接2 显示
"消息1205，级别13，状态56，第5 行
事务(进程ID 54)与另一个进程被死锁在锁资源上，并且已被选作死锁牺牲品。请重新运行该事务。"
这时候尚未提交的连接3锁的情况如下图。我的问题：
1、死锁是否因为连接2和连接3请求锁的顺序不同造成的吗?
2、S和IS锁应该是互相兼容的，是否因为接下来在tab2上的锁要升级为X锁，所以造成死锁？
3、要达到限制tab2中记录条数的目的应该怎么办？目前想到的办法是用在tab1里增加一个计数字段和check约束，在服务器这边写存储过程，然后把 insert tab2和update tab1放在一个事务里。这样可以吗？还有别的方法吗？
要执行代码
if (select count(*) from tab2 where tab1_id=1)<(select maxRow from tab1 where id=1)
insert tab2 values(1，'a')
作用是在insert tab2的时候，查一下tab1 里规定的数量，如果没达到就可以插入。因为怕insert之前、select之后，正好有别的连接也在插入记录。所以可能应该设隔离级别为串行。不过在简单实验的后就发现了问题。
实验如下：
首先在连接1上执行：
set transaction isolation level serializable --语句1
begin tran
if (select count(*) from tab2 where tab1_id=1)<(select maxRow from tab1 where id=1)
insert tab2 values(1，'a') --语句2
执行结果：(1行受影响)
然后在连接2和连接3上执行 语句1 到 语句2，同样没有提交。
下面是用活动监视器查看的锁的情况：
图中：2073058421是tab1的id，2089058478是tab2的id
在连接1上commit tran，显示“命令已成功完成。”
连接3 显示“(1行受影响)”
连接2 显示
"消息1205，级别13，状态56，第5 行
事务(进程ID 54)与另一个进程被死锁在锁资源上，并且已被选作死锁牺牲品。请重新运行该事务。"
这时候尚未提交的连接3锁的情况如下图。我的问题：
1、死锁是否因为连接2和连接3请求锁的顺序不同造成的吗?
2、S和IS锁应该是互相兼容的，是否因为接下来在tab2上的锁要升级为X锁，所以造成死锁？
3、要达到限制tab2中记录条数的目的应该怎么办？目前想到的办法是用在tab1里增加一个计数字段和check约束，在服务器这边写存储过程，然后把 insert tab2和update tab1放在一个事务里。这样可以吗？还有别的方法吗？
因为一个语句就是一个隐式事务,你的语句,从 if 开始,到 insert 结束,只是一条语句,因此没必要加事务.
2.你的这个实验没意义
你用了begin trean,可是事后不提交,然后再用同样的语句,那它当然会死锁,这是你自己制造出来的死锁,而实际上,由于隐式事务执行后立即提交了,因此不会遇到这么严重的死锁.
在客户端程序中先用select 查询,取回结果到客户端后,再判断是否能插入,再插入.这样的操作绝对不能加事务的.因为它们是两个不同的连接.后面的插入语句,本身就被前一句锁住了,根本没法操作.
这样的需求可以用存储过程来处理,在存储过程中传入要插入的东西,判断是否能插入,是插入便执行,否则返回一个不能执行的参数,让客户端去决定如何处理.
在客户端程序中先用select 查询,取回结果到客户端后,再判断是否能插入,再插入.这样的操作绝对不能加事务的.因为它们是两个不同的连接.后面的插入语句,本身就被前一句锁住了,根本没法操作.
这样的需求可以用存储过程来处理,在存储过程中传入要插入的东西,判断是否能插入,是插入便执行,否则返回一个不能执行的参数,让客户端去决定如何处理.
写了个java客户端，把程序分成3句: select tab1... (延时) select tab2...(延时) insert tab2...
开了两个线程执行，每个都开事务，隔离级别为串行，低级别的隔离级别不会出现死锁。
下面的图片是用 sql profiler 捕获的。deadlock chain 和 deadlock 条目显示的都是tab2上的IX锁(两个线程都是如此)， 似乎和select没关系？
begin tran
if (select count(*) from tab2 where tab1_id=1)<(select maxRow from tab1 where id=1)
insert tab2 values(1，'a')
commit
加上这个再试吧