关于使用Elixir Ecto批量插入100万条数据库记录的问题咨询及优化方案探讨

让我逐个拆解你遇到的问题和疑问：

1. Enum.chunk_every/2的表现是否正常？ #

完全正常。你遇到的问题不是chunk_every的问题，而是没考虑每条记录对应的参数数量。PostgreSQL的协议限制单条SQL的参数总数最多是65535，而你插入的每条Users记录有3个字段（points、inserted_at、updated_at），所以当你分块大小设为65535时，总参数数是65535 × 3 = 196605，直接超过了PostgreSQL的参数上限，才会报错。

Enum.chunk_every/2只是单纯按你指定的条目数拆分列表，它不会感知数据库的参数限制，也不会自动计算每条记录的参数个数。所以你需要自己根据表的字段数来计算合适的分块大小：比如用65535 // 字段数（取整数除法），对你的场景来说就是65535 // 3 = 21845，这样每块的总参数数刚好是65535，不会触发报错。

2. 当前分块结合Ecto.Multi的批量插入是否正确且性能最优？ #

这个方式是正确的，但算不上性能最优：

• 正确性：通过分块规避了参数数量限制，并且用Repo.transaction()保证了每块插入的原子性——要么整块成功，要么整块回滚，不会出现部分插入的情况。
• 性能短板：你现在每个分块都单独启动一个事务，事务的开启和提交会带来额外的开销。如果把多个insert_all操作放在同一个Ecto.Multi里（只要总参数数不超过65535），可以减少事务的次数，提升效率。另外，单纯做批量插入的话，其实Ecto.Multi不是必须的——直接调用Repo.insert_all(Users, rows)（配合分块）也能工作，Multi更适合需要组合多个数据库操作（比如插入后更新关联表）的场景。

3. 是否存在更快的数据库批量插入实现方法？ #

当然有，这里给你几个更高效的方案：

方案一：使用PostgreSQL的COPY命令 #

这是PostgreSQL批量插入最快的方式，因为它跳过了常规SQL解析的流程，直接将数据写入数据库存储层。你可以通过Ecto执行原生SQL来调用COPY：

alias Remote.Repo
alias Ecto.Adapters.SQL

datetime = DateTime.utc_now() |> DateTime.to_iso8601()
# 生成CSV格式的数据字符串
csv_data = Enum.map(1..1_000_000, fn _ -> "0,#{datetime},#{datetime}" end) |> Enum.join("\n")

SQL.query!(Repo, "COPY users (points, inserted_at, updated_at) FROM STDIN WITH (FORMAT csv)", [], [copy_data: csv_data])

如果数据量极大，还可以生成临时CSV文件，然后用COPY users FROM '/path/to/file.csv'的方式导入，效率更高。

方案二：优化分块策略 #

按照之前说的，根据字段数计算精准的分块大小（65535 // 字段数），这样每次分块都用满参数上限，减少分块和事务的次数，能显著提升插入速度。

方案三：临时关闭非必要约束 #

如果是一次性批量导入（比如初始化数据），可以临时关闭外键约束、触发器等，插入完成后再重新开启：

# 关闭外键约束和触发器
SQL.query!(Repo, "ALTER TABLE users DISABLE TRIGGER ALL;")

# 执行批量插入逻辑...

# 恢复约束和触发器
SQL.query!(Repo, "ALTER TABLE users ENABLE TRIGGER ALL;")

注意：这个方法要确保插入的数据是合法的，不会破坏数据一致性，只适合可控的批量导入场景。

方案四：调整Ecto插入选项 #

在调用insert_all时，确保使用最精简的选项：

• 不需要返回插入记录的话，保持returning: false（默认值）；
• 如果不需要处理冲突，加上on_conflict: :nothing，避免数据库做冲突检查的额外开销。

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