使用 MySQL 觸發器或事務？
我想詢問您對在網站中使用 MySQL 觸發器或事務的意見。
其實我有一個歷史
payment表 -UserId | OperationId | Comment | Credits | Sign (debit or credit)。所以每個支付操作都插入到這個表中。然而，每次計算使用者每次操作的總信用額度將是耗時的。所以我認為將每個使用者的總信用額度保留在使用者
profile表中可能是一個好主意。這是問題所在。我如何確定表格中的總信用額
profile將與歷史表格中的操作保持同步payment？我想用2種方法：
- MySQL 觸發器或
- 原始碼中編碼的事務
哪個更可靠？如果我有大型數據庫（超過 100.000 個使用者）怎麼辦？
你有什麼建議嗎？
BD MySQL 引擎是 InnoDB。
毫無疑問，我會排除觸發因素並嚴格遵守交易。
觸發器本質上是儲存過程。他們的行動幾乎是難以回滾的。即使所有底層表都是 InnoDB，您也會遇到成比例的共享行鎖和排他行鎖帶來的煩人的間歇性。如果觸發器正在操作表，其中**INSERT 和 UPDATE 被停滯以在每次呼叫觸發器時執行重型 MVCC，**就會出現這種情況。
再加上 MySQL 的儲存過程語言中沒有實現正確的數據驗證協議這一事實。只要儲存過程語言可以處理事務環境，商業智能就可以包含在數據庫中。作為一名 MySQL DBA，我不得不誠實地說，MySQL 並非如此。Oracle (PL/SQL)、PostgreSQL (PL/pgSQL) 和 SQL Server (T-SQL) 比 MySQL 具有這一優勢。
關於事務，MySQL 將 InnoDB 作為其主要的 ACID 兼容儲存引擎（MySQL 5.5 中的預設儲存引擎）。它具有出色的崩潰恢復能力並遵守 ACID 合規性協議。
我每次都會選擇事務而不是觸發器。