可能是用MS SQL Server的时间比较长了，形成了一个根深蒂固的认识：在DB中，如果两个并行事务发生时，一个update事务，可能会阻塞另一个事务中的select的执行。
现在，主要是用mysql，认识还是以前形成的。在所做的应用中，出现一个现象：一个无条件的查询总会报超时失败，而设置查询条件后，勉强能完成查询，但也是相当慢。其实，全部查询出来的结果也没有多少数据行，数K而已。从经验上看，显然是select的执行受到了什么影响。代码是旧的，查看一下，发现一个问题，就是select处理的表会被另一个业务处理高频地更新。感觉这就找到原因了。无条件查询，自然是整表扫描了，它得拿到全部行的共享锁，才能最终完成select，而高频的update，会影响select获得共享锁，最终超时也没能收集完。而缩小查询范围，则可能勉强做到。
出于验证，还是做了一次试验。在两个不同的MySQL DB连接中，各自启动事务A，B。在A中执行update，但不提交；在B中执行select。按以往的经验，B中的select将被阻塞。不过，结果并非如此。B中的Select秒完，结果是update之前的。之后，测试在A不提交时，B中执行update，这次是被阻塞了。查看DB的隔离级别，是缺省的可重复读。
回到MS SQL Server再试验一下，经验仍是正确的。而MySQL中的现象也是事实。应用中呈现的现象似乎也的确是select受到update的影响，因为也试过没有高频更新时，应用中的查询也是如飞的。
回忆早年时使用Oracle中，接触到所谓的多版本快照，不知是不是mysql到了oracle那里，也加上这一技术。
最不确定的，是应用的运行环境，它采用了多主结构的db cluster。而且，实际运行时，极有可能是，更新发生在一个db server上，查询发生在另一个db server上。不知是否是如此结构，引起了前面的现象。没准同一个db上，反而工作正常了。可是现在暂时无法验证。