【性能调优】表布局：数组部分与哈希部分的迁移代价

实战应用：用在哪里

一张任务进度表先用数字键存了一千条顺序进度，后来又往里塞了几百个字符串键，读写耗时悄悄翻了三倍。根因在 Lua 表的内部布局：数组部分与哈希部分的迁移有隐性代价，混用的键会把表在两种布局之间反复搬运。理解了表布局，才知道为什么同一份逻辑换个键型就慢了一截。

混合键的迁移行为

顺序数字键走数组部分，插入字符串键触发布局调整；先建数组段再追加哈希键的写法，比交错插入的写法省一半初始化耗时。

local ok = {}
for i = 1, 10000 do
    ok[i] = i
end
ok["meta"] = "沙巴克战况"

分表策略与遍历优化

数组型数据与映射型数据拆成两张表各自存放，数组表保持纯数字键享受最快遍历，映射表承担查找职责，互不干扰。拆分后两类数据各自满速读写，进度查询与排名统计的耗时都回到了个位毫秒。

local seqData, mapData = {}, {}
local function put(idx, name, value)
    seqData[idx] = value
    mapData[name] = idx
end
local function scanAll()
    local sum = 0
    for i = 1, #seqData do
        sum = sum + seqData[i]
    end
    return sum
end

验证与监控

一万条纯数字键与一万条混合键的插入耗时对比，混合版慢出一倍以上；遍历一千次纯数组表与混合表对比，纯数组快出三成；删除中途元素后用取长度语句核对边界。监控大表的取长度调用频次，高频取长度的代码点都是优化的候选。

踩坑记录

表中段插入 nil 制造出空洞后，取长度返回值变成不可预期的截断点，依赖取长度做边界判断的代码随之出错，空洞表一律不依赖取长度。遍历顺序不保证与插入顺序一致，依赖顺序的展示逻辑改用显式排序。哈希段的键删除后空间并不立即归还，大批量删除后表容量维持高位，超大规模表用重建新表的方式真正缩容。构造表时先写数字后写字符串的顺序被代码格式化工具打乱过一次，混写顺序纳入了代码评审检查项。任务进度表拆分成顺序段与映射段后，读写在各自最优的布局上进行，两端通过序号关联互查。