【性能调优】批量取表：单行查询与批量预载对比

实战应用：用在哪里

行会战报要列五十名成员的等级，旧实现循环里逐个查询引擎接口，一份战报生成耗时 500 毫秒，高峰期每场攻城生成几十份，卡顿肉眼可见。批量预载把循环内的查询搬到循环外：一次快照拿到全部等级，战报生成降到 30 毫秒。

批量快照的生成

快照函数对名单一次性遍历取值，空角色与离线角色过滤后跳过，产出一张名字到等级的对照表，后续全部读表。

local function snapshot(names)
    local snap = {}
    for _, nm in ipairs(names) do
        local p = getplayerbyname(nm)
        if p and isplayer(p) then
            snap[nm] = getbaseinfo(p, 6)
        end
    end
    return snap
end

战报生成使用快照

战报循环只读快照表不再触引擎接口，缺失成员补占位文案，整体拼接后一次输出。

local function buildReport(names)
    local snap = snapshot(names)
    local rows = {}
    for _, nm in ipairs(names) do
        table.insert(rows, nm .. " Lv." .. (snap[nm] or "?"))
    end
    return table.concat(rows, "\n")
end

验证与监控

五十人名单的战报生成耗时对比：单行查询 500 毫秒，批量预载 30 毫秒；名单含离线与退会成员时占位符正确；快照生成时间戳标注在战报末尾。同类优化推广到攻城战报与排行快照两处，循环内触引擎接口的写法全部替换。监控战报生成的耗时埋点，单份超过 100 毫秒说明名单规模超出了快照策略的适用范围。

踩坑记录

快照与战报生成之间隔着一次行会成员变动时，快照里的成员可能已退会，等级照旧展示，战报末尾补了快照时间戳声明数据时效。getplayerbyname 对离线角色返回空，快照静默丢行导致战报人数少于名单，缺失成员统一补问号占位。isplayer 校验漏掉时，快照把已删除角色也算了进去，等级读到脏数据，校验双条件缺一不可。快照接口每份战报都重新生成，同一批攻城连打三场就做三次快照，加了 60 秒结果缓存后接口压力再降一半。批量思路随后推广到行会捐献榜与师门贡献榜，两处榜单的生成耗时同步下降一个量级。快照的生成时机选在战报请求触发的瞬间，中途成员变动的窗口极短，配合时间戳标注足以满足战报的精度要求。