作者提出一个避免「状态列+事后无法追溯」困境的建模思路:从一开始就把每次状态变更单独记成一行,而不是不断更新 status 列。他给出完整的 user_statuses 表设计,用复合索引 (user_id, created_at DESC, id DESC) INCLUDE(status) 保证查询走 Index Only Scan。随后对比了四种取「每个用户当前状态」的写法——关联子查询、窗口函数、DISTINCT ON 与 LATERAL JOIN——并用 10 万用户、500 万条状态记录做实测:单用户与一页 15 用户时 LATERAL 最快(0.012ms / 0.07ms),而 DISTINCT ON 在翻页时灾难性地降级到 1.9 秒,因为 Postgres 无法把 LIMIT 下推到 Unique 节点,只能全表哈希连接并磁盘排序。
(user_id, created_at DESC, id DESC) INCLUDE(status) 让查询走 Index Only Scan。