Delphi 10.4.2 FireDac连接Informix时xiReadCommited隔离级别相关疑问

首先澄清文档描述中容易产生误解的点：

文档中提到的「提交读隔离级别不会加锁」，特指读取操作不会为读到的行添加长期持有的共享锁，不会阻塞其他事务的写入操作，符合你不希望造成数据库阻塞的要求。但读取过程仍然会校验行的锁状态，这是文档后续提到锁冲突的核心原因。

问题1：逐行遍历16000行的表时，数据库是否会逐行检查行锁？遇到锁定行是否会直接抛异常？ #

• 未开启LAST COMMITTED选项时：是的，数据库会逐行校验当前行是否存在其他事务未释放的排他写锁。遇到锁定行时会先进入锁等待，若等待时长超过实例配置的LOCK_TIMEOUT阈值，才会抛出锁冲突异常，整个查询直接终止，不会继续遍历后续行。
• 开启LAST COMMITTED选项时：不会等待锁，也不会抛异常，数据库会直接读取该行最后一次成功提交的历史版本数据，继续遍历流程。

问题2：遇到锁定行时是否会直接跳过，导致返回行数少于实际行数？ #

默认配置下（未开启特殊语法）不会发生该情况：

• 无LAST COMMITTED时要么等待锁释放后读取最新提交值，要么锁超时整个查询失败，不会中途跳过行。
• 有LAST COMMITTED时会读取锁定行的历史提交版本，行仍然会返回，不会出现行数缺失。
  只有你主动使用SKIP LOCKED语法执行查询时，数据库才会跳过所有被锁定的行，出现返回行数少于实际总行数的情况。

问题3：只读的提交读会话遇到死锁时，是否会被优先终止？ #

首先提交读的只读事务本身几乎不会持有任何锁，所以触发死锁的概率极低：死锁的前提是两个会话各自持有对方需要的锁，而只读会话不会添加排他锁，也不会长期持有共享锁，几乎不可能满足死锁的前置条件。
如果极端场景下真的触发死锁，Informix的死锁处理规则是终止回滚成本更低的会话，和会话的读写权限没有直接关联。只读事务因为没有未提交的修改操作，回滚成本通常远低于读写事务，确实大概率会被优先终止，但这不是固定规则，最终判断依据是回滚代价的计算结果。

内容的提问来源于stack exchange，提问作者user1937012