問(wèn)題描述

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

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

問(wèn)題解答

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

我建議都不要用為好。

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

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

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

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

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