不止一次在各大论坛，文章中看到大多数人不推荐触发器，统统推荐存储过程。这是为什么呢？现在的场景是：1000万数据，1万并发的规模。疑问：我的理解是：触发器本身就是特殊的存储过程，那么如果业务逻辑本身不需要定义变量，不需要定义事务，仅仅需要for each row /update/delete/insert，仅仅需要触发器的情况下，还要特定使用存储过程吗？
还是说触发器本身具有特别大的性能问题呢？
ringa_lee
1.預存程序和觸發器二者是有很大的聯繫的，我的一般理解就是觸發器是一個隱藏的存儲過程，因為它不需要參數，不需要顯示調用，往往在你不知情的情況下已經做了很多操作。從這個角度來說，由於是隱藏的，無形中增加了系統的複雜性，非DBA人員理解起來資料庫就會有困難，因為它不執行根本感覺不到它的存在。 2.再有，涉及到複雜的邏輯的時候，觸發器的嵌套是避免不了的，如果再涉及幾個存儲過程，再加上事務等等，很容易出現死鎖現象，再調試的時候也會經常性的從一個觸發器轉到另外一個，級聯關係的不斷追溯，很容易使人頭大。其實，從效能上，觸發器並沒有提升太多效能，只是從程式碼上來說，可能在coding的時候很容易實現業務，所以我的觀點是：摒棄觸發器！觸發器的功能基本上都可以用預存程序來實現。 3.在編碼中預存程序顯示呼叫很容易閱讀程式碼，觸發器隱式呼叫容易被忽略。 預存程序也有他的致命傷↓4.存儲過程的致命傷在於移植性，存儲過程不能跨庫移植，比如事先是在mysql數據庫的存儲過程，考慮到性能要移植到oracle上面那麼所有的儲存過程都需要被重寫一遍。
我建議都不要用為好。
這種東西只有在並發不高的項目，管理系統中用。
如果是使用者導向的高並發應用，都不要使用。
觸發器和預存程序本身難以開發和維護，不能有效率地移植。
觸發器完全可以用事務替代。 預存程序可以用後端腳本取代。
我覺得來自兩方面的因素：1- 存儲過程需要明確調用，意思是閱讀源碼的時候你能知道存儲過程的存在，而觸發器必須在數據庫端才能看到，容易被忽略。 2- Mysql的觸發器本身不是很好，例如after delete無法鍊式反應的問題。 我認為性能上其實還是觸發器佔優勢的，但是基於以上原因不受青睞。
1.預存程序和觸發器二者是有很大的聯繫的，我的一般理解就是觸發器是一個隱藏的存儲過程，因為它不需要參數，不需要顯示調用，往往在你不知情的情況下已經做了很多操作。從這個角度來說，由於是隱藏的，無形中增加了系統的複雜性，非DBA人員理解起來資料庫就會有困難，因為它不執行根本感覺不到它的存在。
2.再有，涉及到複雜的邏輯的時候，觸發器的嵌套是避免不了的，如果再涉及幾個存儲過程，再加上事務等等，很容易出現死鎖現象，再調試的時候也會經常性的從一個觸發器轉到另外一個，級聯關係的不斷追溯，很容易使人頭大。其實，從效能上，觸發器並沒有提升太多效能，只是從程式碼上來說，可能在coding的時候很容易實現業務，所以我的觀點是：摒棄觸發器！觸發器的功能基本上都可以用預存程序來實現。
3.在編碼中預存程序顯示呼叫很容易閱讀程式碼，觸發器隱式呼叫容易被忽略。
預存程序也有他的致命傷↓
4.存儲過程的致命傷在於移植性，存儲過程不能跨庫移植，比如事先是在mysql數據庫的存儲過程，考慮到性能要移植到oracle上面那麼所有的儲存過程都需要被重寫一遍。
我建議都不要用為好。
這種東西只有在並發不高的項目，管理系統中用。
如果是使用者導向的高並發應用，都不要使用。
觸發器和預存程序本身難以開發和維護，不能有效率地移植。
觸發器完全可以用事務替代。
預存程序可以用後端腳本取代。
我覺得來自兩方面的因素：
1- 存儲過程需要明確調用，意思是閱讀源碼的時候你能知道存儲過程的存在，而觸發器必須在數據庫端才能看到，容易被忽略。
2- Mysql的觸發器本身不是很好，例如after delete無法鍊式反應的問題。
我認為性能上其實還是觸發器佔優勢的，但是基於以上原因不受青睞。