問題描述

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

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

問題解答

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

我建議都不要用為好。

這種東西只有在并發(fā)不高的項目，管理系統(tǒng)中用。

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

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

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

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