基于PostgreSQL的会话存储疑问：用随机4字节整数作会话ID

方案的明显缺陷 #

• 索引性能问题：随机主键会导致数据库索引页频繁分裂（插入位置不固定），随着会话表数据量积累，索引维护成本逐渐升高，查询和插入性能都会受影响。
• 冲突与重试缺失：random()生成的伪随机数在并发场景下冲突概率高于预期，且数据库不会自动处理冲突重试，一旦出现重复值直接抛出唯一约束错误。
• 可预测性风险：普通random()的伪随机序列存在被预测的可能，攻击者若能猜出规律，有机会伪造会话ID（虽用户量少风险低，但仍需注意）。

ID冲突时数据库会自动重试吗？ #

不会。DEFAULT子句在插入时仅计算一次随机值，若该值已存在（违反主键唯一约束），数据库直接返回错误，不会自动重新生成值重试。你需要在应用层捕获错误后重试插入，或者在数据库层面编写存储过程，循环生成值直到找到未被占用的ID。

临近耗尽唯一值时会发生什么？ #

4字节整数共有4294967296个唯一值，若会话ID没有过期清理机制，随着数据积累，可用值逐渐减少，插入时的冲突概率会急剧上升，导致大量插入失败、重试频率飙升，最终会因无可用唯一值完全无法插入。但只要配置了合理的会话过期清理策略（比如定期删除过期会话），这种情况几乎不会发生。

能否基于GENERATED ALWAYS AS类定义实现？ #

不行：

• GENERATED ALWAYS AS IDENTITY本质依赖序列，不符合你不想用序列的需求；
• GENERATED ALWAYS AS (expression) STORED要求表达式使用不可变函数，而random()是不稳定（VOLATILE）函数，每次调用返回不同值，无法满足该约束——数据库无法提前确定生成值，且存储生成列要求结果仅依赖行内字段或固定输入。

长期使用是否合适？ #

若应用用户量极少、并发极低，短期使用无明显问题，但长期来看存在隐患：

• 索引碎片会随数据量增加逐渐影响性能；
• 冲突概率随数据积累上升，需额外维护重试逻辑；
• 扩展性差，若后续用户量增长，需重构会话ID方案。

替代优化方案 #

如果坚持用4字节整数，可改用密码学安全的随机生成函数（如pgcrypto扩展的gen_random_bytes()）提升随机性，同时用存储过程自动处理冲突重试：

-- 先启用pgcrypto扩展
CREATE EXTENSION IF NOT EXISTS pgcrypto;

-- 生成唯一会话ID的函数
CREATE OR REPLACE FUNCTION generate_unique_session_id() RETURNS INTEGER AS $$
DECLARE
    new_id INTEGER;
BEGIN
    LOOP
        new_id := (gen_random_bytes(4))::integer;
        EXIT WHEN NOT EXISTS (SELECT 1 FROM sessions WHERE session_id = new_id);
    END LOOP;
    RETURN new_id;
END;
$$ LANGUAGE plpgsql VOLATILE;

-- 表定义
CREATE TABLE sessions (
    session_id INTEGER NOT NULL PRIMARY KEY DEFAULT generate_unique_session_id(),
    -- 其他字段：如user_id、expire_time等
);

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