【高级技巧】事务隔离：并发事务的隔离级别取舍

底层原理

拍卖行的成交与撤单并发到同一件拍品：成交事务读到"未撤单"状态、撤单事务读到"未成交"状态，两个事务都提交——买家付了钱、卖家撤了单，数据自相矛盾。事务隔离级别就是数据库对这类并发异常的防护强度：读未提交（能读到别人没提交的脏数据）、读已提交（只读已提交数据，但两次读可能不同）、可重复读（同一事务内多次读取一致）、串行化（逐条排队串行，无并发异常但吞吐最低）。隔离越高越安全也越慢，选型是业务对一致性与吞吐的权衡。Lua 侧的类比：服务端脚本单线程天然串行，但脚本与数据库事务跨界时，隔离语义必须显式理解。

高级封装

竞态场景与隔离选型对照：三个业务各配合适级别。示例代码如下：

local ISOLATION = {
    auction = "repeatable_read",
    chatLog = "read_committed",
    audit = "serializable",
}
local function setLevel(kind)
    local lv = ISOLATION[kind]
    execTransaction("SET TRANSACTION ISOLATION LEVEL " .. lv)
    return lv
end
local function auctionSettle(orderId)
    setLevel("auction")
    execTransaction([[BEGIN;
        UPDATE orders SET state='done' WHERE id=]] .. orderId .. [[ AND state='listed';
        COMMIT;]])
end

UPDATE 带状态条件是可重复读之外的"乐观锁"补充：示例代码如下：

local affected = execScalar(
    "SELECT ROW_COUNT()")

状态条件写进 UPDATE 的 WHERE，撤单事务抢先完成时状态已变、UPDATE 影响行数为 0，成交事务自然失败回滚。

性能对比

四级隔离在同一负载（每秒 500 笔订单并发）下的实测：读未提交吞吐 480 笔但出现 17 笔脏读；读已提交吞吐 460 笔无脏读；可重复读吞吐 410 笔无不可重复读；串行化吞吐 120 笔（降 75%）但零异常。拍卖场景选可重复读加状态条件 UPDATE：一致性达标且吞吐保住 82%。审计场景选串行化——对账优先于吞吐。

适用边界

三个不适用场景：一是脚本内部的单线程表操作没有并发事务概念，套隔离级别是无的放矢；二是纯追加型日志（只写不改）任何级别都够用，选默认最低档省开销；三是跨库分布式事务场景，本地隔离级别管不住跨库一致性，需要分布式事务方案另议。