顯然graphQL突變是依次執行的。graphQL多重突變事務
來源：
在GraphQL，突變爲順序的順序執行。否則，很難用 來檢測錯誤，例如一次又一次添加同一作者。
這完全取決於GraphQL服務器實現來執行這樣的 突變。 Python和Scala的參考NodeJS實現和其他 社區實現遵循此。
如果我的理解是正確的，這並不這樣防止：
使用交易的執行請求這背後的基本原理設計決定？ 有沒有其他項目做不同？
實際上，GraphQL高度鼓勵請求併發。請求可以並行處理。每個請求都以串行方式執行該請求的單個突變，但可以同時處理多個請求。
表示突變和請求之間的差異很重要，特別是關於併發性。
表示GraphQL告訴你如何在單個請求之外應用編輯，這也很重要。這是您的代碼抽象，您決定是否使用SQL begin ... commit來阻止數據庫寫入，或者直接進行更新調用並擲骰子。
對事務的串行編輯處理是數據庫設計中非常普遍的做法，在大多數數據庫語言中都可以看到一系列的命令。
在SQL中，突變通常被BEGIN和COMMIT括起來。 在Redis中，MULTI EXEC塊提供了此功能。
這主要是我見過的。但是，只要確保結果與路徑無關並且可以找到保證所有ACID屬性的方法，無序的並行編輯處理就是可能的。
有很多方法可以在很多語言中做到這一點，但是我只能想到在Redis中的一個示例實現。
您可以將編輯映射到一組簡短的Lua腳本，該腳本檢查其序列化自我的事務密鑰的值，如果他們找到匹配，他們會在應用之前返回。否則，他們將應用編輯，並將序列化的編輯附加到交易主體。
注意：如果您有相關編輯（創建表格，將條目推入表格），您可以真正在腳中自我拍攝，避免串行編輯執行。
就多個請求的交易而言？我從來沒有真正使用它們，這個線程更適合這個問題。
Multi-step database transaction split across multiple HTTP requests