問題描述

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

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

問題解答

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

我建議都不要用為好。

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

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

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

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

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