Go后端SQL事务中能否并发执行两步数据库操作？

背景 #

现有一套针对书籍、作者及关联表的数据库插入流程，当前采用串行执行逻辑：插入书籍数据到books表→插入/更新作者数据到authors表→建立书籍与作者的关联到book_author_link表，所有操作通过SQL事务保证原子性。现希望将前两步（插入书籍、插入/更新作者）通过Goroutine并发执行，确认两者均成功后再执行第三步，此前尝试用sync/mutex未成功，需明确该方案的可行性及正确实现方式。

现有串行流程代码 #

1. 插入books表 #

query := `
    INSERT INTO books(book_id,title,publisher,year,page_count,genres)
    VALUES($1,$2,$3,$4,$5,$6)
    RETURNING id,book_id,title,publisher,year,page_count,genres
`

args := []interface{}{
    entry.Book.Hash,
    entry.Book.Title,
    entry.Book.Publisher,
    entry.Book.Year,
    entry.Book.PageCount,
    pq.Array(entry.Book.Genres)}

err := tx.QueryRowContext(ctx, query, args...).Scan(
    &read.Book.ID,
    &read.Book.Hash,
    &read.Book.Title,
    &read.Book.Publisher,
    &read.Book.Year,
    &read.Book.PageCount,
    pq.Array(&read.Book.Genres))

if err != nil {
    return err
}

2. 插入/更新authors表 #

query = `
    WITH filter1 AS(
        SELECT
        UNNEST($1::TEXT[]) AS name,
        UNNEST($2::TEXT[]) AS author_id,
        1 as books_authored
    ), finished AS(
        INSERT INTO authors(name,author_id,books_authored)
        SELECT name, author_id, books_authored FROM filter1
        ON CONFLICT (author_id) DO UPDATE
        SET books_authored = authors.books_authored + 1
        RETURNING id, name, author_id, books_authored
    )
    SELECT array_agg(id), array_agg(name), array_agg(author_id), array_agg(books_authored) FROM finished
`

args = []interface{}{pq.Array(entry.Authors.List), pq.Array(entry.Authors.Hash)}
err = tx.QueryRowContext(ctx, query, args...).Scan(
    pq.Array(&read.List.ID),
    pq.Array(&read.List.Name),
    pq.Array(&read.List.Identifier),
    pq.Array(&read.List.Books_authored),
)

if err != nil {
    return err
}

3. 插入book_author_link表 #

query = `
    WITH cte AS (
        SELECT book_id, author_id FROM
        UNNEST($1::TEXT[]) AS book_id,
        UNNEST($2::TEXT[]) AS author_id 
    ), finished AS (
        INSERT INTO book_author_link(book_id, author_id)
        SELECT book_id, author_id FROM cte
        ON CONFLICT (book_id, author_id) DO NOTHING
        RETURNING book_id, author_id
    )
    SELECT array_agg(book_id), array_agg(author_id) FROM finished
`

args = []interface{}{pq.Array([]string{entry.Book.Hash}), pq.Array(entry.Authors.Hash)}

return tx.QueryRowContext(ctx, query, args...).Scan(
    pq.Array(entry.Authors.List),
    pq.Array(entry.Authors.Hash),
)

可行性分析 #

如果要严格保证所有操作的原子性（要么全部成功，要么全部回滚），则无法通过Goroutine实现前两步的有效并发，核心原因有两点：

1. Go标准库的sql.Tx对象并非并发安全，不支持在多个Goroutine中调用其方法（如QueryRowContext），即使加sync/mutex锁，也会因Tx内部绑定的单个数据库连接的串行执行逻辑，无法获得实际并发性能提升，还可能引发不可预期的错误。
2. PostgreSQL同一事务内的所有操作本身就是串行执行的，即使在Go侧开启多个Goroutine，数据库端仍会按顺序处理请求，无法实现真正的并行执行。

正确实现方案 #

方案1：合并前两步为单SQL语句（推荐） #

将插入书籍和插入/更新作者的逻辑合并到一个SQL事务中，通过WITH子句实现单次数据库调用完成两个操作，既保证原子性，又避免并发安全问题，同时数据库端可优化执行效率。

示例合并SQL：

WITH insert_book AS (
    INSERT INTO books(book_id,title,publisher,year,page_count,genres)
    VALUES($1,$2,$3,$4,$5,$6)
    RETURNING id, book_id, title, publisher, year, page_count, genres
), update_authors AS (
    WITH filter1 AS(
        SELECT
        UNNEST($7::TEXT[]) AS name,
        UNNEST($8::TEXT[]) AS author_id,
        1 as books_authored
    )
    INSERT INTO authors(name,author_id,books_authored)
    SELECT name, author_id, books_authored FROM filter1
    ON CONFLICT (author_id) DO UPDATE
    SET books_authored = authors.books_authored + 1
    RETURNING id, name, author_id, books_authored
)
SELECT 
    (SELECT row_to_json(insert_book) FROM insert_book),
    (SELECT array_to_json(array_agg(row_to_json(update_authors))) FROM update_authors);

对应的Go代码可一次性执行该SQL，将结果扫描到对应的结构体中，后续再执行第三步关联操作即可。

方案2：放弃单事务的并发方案（不推荐） #

若一定要用Goroutine并发执行前两步，需为每个操作创建独立的数据库事务，再通过**两阶段提交（2PC）**保证原子性。但该方案复杂度极高，性能开销大，且Go标准库未提供原生支持，需依赖第三方分布式事务库，仅适用于复杂分布式场景，不推荐用于当前简单的单库操作。

方案3：Goroutine误用场景澄清 #

若仅想在Go侧用Goroutine“并行”触发操作，但实际数据库仍串行执行，即使使用sync.WaitGroup等待两个Goroutine完成，也不能共享同一个sql.Tx实例，否则会引发并发安全问题。这种方式不仅无法提升性能，还会增加代码复杂度，完全没有必要。

总结 #

• 若需保证原子性，优先选择合并前两步为单SQL语句，在同一事务中串行执行，这是最安全、高效的方案。
• 此前用sync/mutex失败的核心原因是sql.Tx不支持并发调用，锁无法解决Tx本身的串行执行限制。
• 追求Goroutine并发与单事务原子性不可兼得，需根据实际需求选择合适方案。

内容的提问来源于stack exchange，提问作者Gabriel López