PHP 中實現 MySQL 嵌套事務：Doctrine 與 Laravel 兩大方案深度解析

問題本質

MySQL 原生不支援嵌套事務：

Transactions cannot be nested. 
Implicit COMMIT occurs when START TRANSACTION is issued inside a transaction.

場景：Service A 開啟事務 → 調用 Service B (內部也開啟事務) → 導致外層事務被隱式提交，原子性破壞。

方案一：Doctrine —— Savepoint 計數器模式

核心邏輯

• _transactionNestingLevel 計數嵌套層級。
• Level 1：真正 BEGIN TRANSACTION。
• Level > 1：創建 SAVEPOINT (命名規則：DOCTRINE_SAVEPOINT_$level)。

關鍵代碼還原

// beginTransaction()
++$this->_transactionNestingLevel;
if ($this->_transactionNestingLevel == 1) {
    $this->_conn->beginTransaction();
} elseif ($this->_nestTransactionsWithSavepoints) {
    $this->createSavepoint($this->_getNestedTransactionSavePointName());
}

// rollBack()
if ($this->_transactionNestingLevel == 1) {
    $this->_conn->rollback();
    $this->_transactionNestingLevel = 0;
} elseif ($this->_nestTransactionsWithSavepoints) {
    $this->rollbackSavepoint($this->_getNestedTransactionSavePointName());
    --$this->_transactionNestingLevel;
} else {
    $this->_isRollbackOnly = true; // 標記外層必須回滾
    --$this->_transactionNestingLevel;
}

// commit()
if ($this->_transactionNestingLevel == 1) {
    $this->_conn->commit();
} elseif ($this->_nestTransactionsWithSavepoints) {
    $this->releaseSavepoint($this->_getNestedTransactionSavePointName());
}
--$this->_transactionNestingLevel;

特點

• 真嵌套：內層可獨立回滾到 Savepoint，不影響外層已執行操作。
• 可配置：_nestTransactionsWithSavepoints 可關閉，退化為「僅標記回滾」模式。
• 資源成本：每層 Savepoint 消耗服務端資源，極深嵌套需謹慎。

方案二：Laravel —— 計數器扁平化模式

核心邏輯

• transactions 計數器，只有最外層真正操作數據庫事務。
• 內層 beginTransaction 僅計數 +1，不發送任何 SQL。
• 內層 rollBack 僅計數 -1，不真正回滾。
• 最外層 commit/rollBack 才真正提交/回滾整個事務塊。

關鍵代碼還原

// beginTransaction()
++$this->transactions;
if ($this->transactions == 1) {
    $this->pdo->beginTransaction();
}

// rollBack()
if ($this->transactions == 1) {
    $this->transactions = 0;
    $this->pdo->rollBack();
} else {
    --$this->transactions;
}

// commit()
if ($this->transactions == 1) {
    $this->pdo->commit();
}
--$this->transactions;

特點

• 偽嵌套：實際上只有一個大事務，內層邏輯異常只能拋異常由外層捕獲決定整體回滾。
• 零資源開銷：無 Savepoint，極輕量。
• 語義限制：內層無法獨立提交/回滾，業務邏輯必須配合「全有或全無」設計。

深度對比與選型建議

最佳實踐建議

1. 避免嵌套：架構層面設計「事務邊界」，Service 層統一開啟/提交，Repository 僅執行 SQL。
2. 必要時選 Doctrine：若確有「子操作可選、可獨立失敗」需求，Savepoint 是正解。
3. 警惕長事務：無論哪種模式，嵌套必然拉長事務持有時間，增加鎖競爭與死鎖概率。盡量縮小事務範圍，避免 RPC/HTTP 調用在事務內。
4. 測試驗證：單元測試覆蓋「內層拋異常、外層捕獲提交」與「外層拋異常、內層已執行」兩條關鍵路徑。

總結

Doctrine 選擇「功能完備」，Laravel 選擇「簡單實用」。理解 Savepoint 與計數器的本質差異，結合業務一致性要求與架構複雜度，才能在 PHP 專案中正確落地嵌套事務模擬。