問題描述

不止一次在各大論壇，文章中看到大多數人不推薦觸發器，統統推薦存儲過程。這是為什么呢？現在的場景是：1000萬數據，1萬并發的規模。疑問：我的理解是：觸發器本身就是特殊的存儲過程，那么如果業務邏輯本身不需要定義變量，不需要定義事務，僅僅需要for each row /update/delete/insert，僅僅需要觸發器的情況下，還要特定使用存儲過程嗎？

還是說觸發器本身具有特別大的性能問題呢？

問題解答

1.存儲過程和觸發器二者是有很大的聯系的，我的一般理解就是觸發器是一個隱藏的存儲過程，因為它不需要參數，不需要顯示調用，往往在你不知情的情況下已經做了很多操作。從這個角度來說，由于是隱藏的，無形中增加了系統的復雜性，非DBA人員理解起來數據庫就會有困難，因為它不執行根本感覺不到它的存在。2.再有，涉及到復雜的邏輯的時候，觸發器的嵌套是避免不了的，如果再涉及幾個存儲過程，再加上事務等等，很容易出現死鎖現象，再調試的時候也會經常性的從一個觸發器轉到另外一個，級聯關系的不斷追溯，很容易使人頭大。其實，從性能上，觸發器并沒有提升多少性能，只是從代碼上來說，可能在coding的時候很容易實現業務，所以我的觀點是：摒棄觸發器！觸發器的功能基本都可以用存儲過程來實現。3.在編碼中存儲過程顯示調用很容易閱讀代碼，觸發器隱式調用容易被忽略。存儲過程也有他的致命傷↓4.存儲過程的致命傷在于移植性，存儲過程不能跨庫移植，比如事先是在mysql數據庫的存儲過程，考慮性能要移植到oracle上面那么所有的存儲過程都需要被重寫一遍。

我建議都不要用為好。

這種東西只有在并發不高的項目，管理系統中用。

如果是面向用戶的高并發應用，都不要使用。

觸發器和存儲過程本身難以開發和維護，不能高效移植。

觸發器完全可以用事務替代。存儲過程可以用后端腳本替代。

我覺得來自兩方面的因素：1- 存儲過程需要顯式調用，意思是閱讀源碼的時候你能知道存儲過程的存在，而觸發器必須在數據庫端才能看到，容易被忽略。2- Mysql的觸發器本身不是很好，比如after delete無法鏈式反應的問題。我認為性能上其實還是觸發器占優勢的，但是基于以上原因不受青睞。