generate_series() 是内存临时数字序列，适用于补全、时间展开和测试数据填充，但不可作主键；需用 insert...select 插入表，起始/结束值类型须一致，步长不能为0，大数据量慎用。
generate_series() 在 PostgreSQL 里怎么用才不踩坑
它不是数据库里的“自增列”，只是内存里临时生成的一串数字，查完就丢。适合做补全、时间维度展开、测试数据填充，但不能当主键或唯一标识依赖。
-
generate_series()返回的是结果集，不是列值——想塞进表里得用INSERT ... SELECT，不能直接写在VALUES里 - 起始/结束值必须是同类型，
generate_series(1, 5)和generate_series('2024-01-01'::date, '2024-01-05'::date, '1 day')都行，混用会报function generate_series(integer, date) does not exist - 步长为 0 会无限循环（PostgreSQL 15+ 改成报错，老版本可能卡死），务必检查
- 大数据量慎用：
generate_series(1, 1000000)会构造百万行内存结构，比物理表扫描还慢
row_number() over() 为什么不能替代自增列
它只在查询时按排序动态编号，每次执行都可能变——特别是没写明确 ORDER BY 或排序字段有重复值时，序号不稳定，根本不可靠。
- 没
ORDER BY的row_number() over()行为未定义，不同执行计划下结果可能不同，PostgreSQL 甚至可能报window function requires an ordering clause - 即使写了
ORDER BY id，如果id是可变的（比如被 UPDATE 过），下次查出来的row_number就和上次对不上 - 它不占用存储空间，也不参与索引构建，所以无法加速基于序号的查询（比如“查第 10000 条”）
- 分页场景别用它模拟 limit+offset：偏移越大越慢，因为要算出前 N 行的序号
物理自增列（SERIAL / IDENTITY）真正管用在哪
只有它是写入时固化、全局唯一、带索引、支持并发安全的。所有需要“稳定身份”的地方——主键、外键、日志追踪、幂等判断——只能靠它。
-
SERIAL是语法糖，本质是CREATE SEQUENCE+DEFAULT nextval(...)，而GENERATED ALWAYS AS IDENTITY更严格，禁止手动插入（除非加OVERRIDING SYSTEM VALUE） - 序列值一旦分配就不会回收，删了行也不会重用，这是故意设计——避免并发冲突和唯一性风险
- 注意
cache参数：默认CACHE 1每次取一个，高并发插入可能成为瓶颈；设成CACHE 100能提速，但崩溃可能丢失最多 100 个值 - 迁移旧表加自增主键时，别直接
ALTER TABLE ADD COLUMN id SERIAL PRIMARY KEY——老数据id全是NULL，得先ADD COLUMN id BIGSERIAL再UPDATE补值，最后设PRIMARY KEY
什么时候该选哪个：三类典型场景对照
选错方案往往不是语法问题，而是没想清楚“这个‘序号’到底要承担什么职责”。临时计算用 generate_series()，查询时排序编号用 row_number()，需要持久身份就只能上物理自增列。
- 补全缺失日期：
generate_series()展开时间范围，再LEFT JOIN原表，缺的天数自然出来——这里不需要“唯一 ID”，要的是完整维度 - 给搜索结果标序号（如“第 1 名”“第 2 名”）：
row_number() over (ORDER BY score DESC)，但千万别存到表里——分数一变序号就废 - 订单表主键、用户表
user_id、日志表log_id：必须用GENERATED ALWAYS AS IDENTITY，否则后续加外键、分库分表、CDC 同步全要出事
最容易被忽略的是：row_number() 看似简单，但它依赖的 ORDER BY 字段如果有 NULL、有重复、没索引，结果就不可控；而物理自增列看着笨重，却是整个数据链路稳定的锚点。
