insert ... select 配合 row_number() 是最可靠的方式，直接在 select 中用 row_number() 生成序号，需明确 order by，不可用于 values 子句；mysql 5.7- 需谨慎用变量；postgresql 可用 generate_series() 或 with ordinality。
INSERT ... SELECT 配合 ROW_NUMBER() 是最可靠的方式
直接在 INSERT 语句里用 ROW_NUMBER() 生成序号，比先建临时表或靠应用层计数更可控。它不依赖表本身是否有自增主键，也不要求目标表已存在数据——只要源数据能被排序，序号就能稳定生成。
常见错误是把 ROW_NUMBER() 写在 VALUES 子句里，比如 INSERT INTO t VALUES (ROW_NUMBER() OVER(...), ...) —— 这会报错，因为 VALUES 不支持窗口函数。
正确做法是用 INSERT ... SELECT：
INSERT INTO orders (seq_no, product_name, amount)
SELECT ROW_NUMBER() OVER (ORDER BY product_name) AS seq_no,
product_name,
amount
FROM staging_orders;
注意：ORDER BY 必须明确指定，否则 ROW_NUMBER() 行为不可预测；如果只是要“按插入顺序编号”，且 staging_orders 有时间戳字段（如 created_at），就用它排序。
MySQL 8.0+ 可用 CTE + ROW_NUMBER()，但低版本得绕开
MySQL 5.7 及更早版本不支持 ROW_NUMBER()，强行用变量（如 @row := @row + 1）风险很高：在多行 INSERT 或并发场景下序号可能跳变、重复甚至乱序，官方文档也明确不保证用户变量在 SELECT 中的执行顺序。
如果你无法升级 MySQL，又必须用变量方案，请确保满足以下全部条件：
- 单线程执行该 SQL
- 源数据已用
ORDER BY显式排序（不能依赖隐式顺序） - 初始化变量写在同一个语句中，例如：
SELECT @row := 0放在UNION ALL前或用SET @row = 0单独执行
示例（仅限测试环境验证过顺序的场景）：
SET @row = 0; INSERT INTO logs (id, msg) SELECT @row := @row + 1, message FROM raw_log ORDER BY timestamp;
PostgreSQL 用 generate_series() + unnest() 更灵活
当你要插入固定数量的带序号行（比如补 100 条测试数据），不用构造源表，generate_series() 配合 unnest() 更直接：
INSERT INTO test_data (seq, tag) SELECT s.n, 'item_' || s.n FROM generate_series(1, 100) AS s(n);
这个方案不依赖现有数据，适合初始化或批量造数。但注意：generate_series() 返回的是整数序列，不能自动关联外部表的行顺序——如果要给已有数组字段编号，得用 WITH ORDINALITY：
INSERT INTO items (seq, name) SELECT ord, name FROM unnest(ARRAY['apple', 'banana', 'cherry']) WITH ORDINALITY AS t(name, ord);
序号起始值和步长容易被忽略
ROW_NUMBER() 总是从 1 开始，没法直接设起始值；generate_series() 虽然可以写 generate_series(1001, 1100)，但一旦源数据行数动态变化，硬编码上下界就失效。
真正健壮的做法是把偏移量作为计算项加入：
- 想从 1001 开始编号？用
1000 + ROW_NUMBER() OVER (...) - 需要步长为 10？用
(ROW_NUMBER() OVER (...) - 1) * 10 + 1001 - 目标表已有最大序号，新数据接着编？先查
SELECT COALESCE(MAX(seq_no), 0) FROM target，再在应用层拼进 SQL（注意防 SQL 注入）或用 CTE 包一层
别指望数据库自动“记住上次插到哪了”——序号逻辑必须显式表达，否则迁移、重跑、分批插入时极易出错。
