一篇很棒的 MySQL 觸發器學習教程
阿新 • • 發佈：2019-01-22
下面簡單參考知乎和CSDN論壇，簡單講解幾個內容：
問題一：
大型系統必須得要儲存過程和觸發器嗎？ - 知乎
回答1：
我們先要弄清楚二個問題：
1.什麼是大型系統？
2.你討論的是什麼領域的應用，可以大致分為二種：網際網路、企業內部
接下來給你舉一些例子：
1.SAP、peopleSoft、ERP等企業級別應用
一般情況下，會使用儲存過程和觸發器，減少開發成本，畢竟其業務邏輯修改頻繁，而且為通用，很多時候會把一些業務邏輯編寫成儲存過程，像Oracle會寫成包，比儲存過程更強大。
另外一個原因是伺服器的負載是可控，也即系統的訪問人數首先是可控的，沒有那麼大，而且這些資料又非常關鍵，為此往往使用的裝置也比較好，多用儲存櫃子支撐資料庫。
2.另外一類網際網路行業的
比如淘寶、知呼、微博等，資料庫的壓力是非常大的，也往往會最容易成為瓶頸，而且多用PC伺服器支撐，使用者量的增速是不可控的，同時線上訪問的使用者量也是不可控的，為此肯定會把業務邏輯放到其他語言的程式碼層，而且可以藉助一些LVS等型別軟硬體做負載均衡，以及平滑增減Web層的伺服器，從而達到線性的增減而支援大規模的訪問。
所以不管你的這個系統是否龐大，首先要分業務支援的物件，系統最可能容易出現瓶頸的地方在那？
當然也不是說網際網路行業的應用就絕對不用儲存過程，這個也不對，曾在阿里做的Oracle遷移MySQL系統確實用了，因為歷史的原因，另外還有一些新系統也有用，比如晚上進行定期的資料統計的一些操作，不過有量上的控制。儲存過程是好東西，要分場景，分業務型別來用就可以把握好。
回答2：
肯定不能一刀切的說能用或者不能用，不同型別的系統、不同的規模、不同的歷史原因都會有不同的解決方案。
一般情況下，Web應用的瓶頸常在DB上，所以會盡可能的減少DB做的事情，把耗時的服務做成Scale Out，這種情況下，肯定不會使用儲存過程；而如果只是一般的應用，DB沒有效能上的問題，在適當的場景下，也可以使用儲存過程。
至於觸發器，我是知道有這東西但從來沒用過。我希望風險可控，遇到問題能夠快速的找到原因，儘可能不會去使用觸發器。
回答3：
1.PLSQL可以大大降低parse/exec 百分比；
2.儲存過程可以自動完成靜態SQL variable bind；
3.儲存過程大大減少了JDBC網路傳輸與互動，速度快；
4.oracle 中儲存過程內部commit為非同步寫，一定程度上減少了等redo日誌落地時間；
5.儲存過程最大問題就是給資料庫開發工作壓力太大，另外架構升級時候會比較難解耦；
6.觸發器不推薦使用，觸發操作能在業務層解決就在業務層解決，否則很難維護，而且容易產生死鎖。
問題2：
為什麼大家都不推薦使用MySQL觸發器而用儲存過程？- segmentfault
回答1：
1.儲存過程和觸發器二者是有很大的聯絡的，我的一般理解就是觸發器是一個隱藏的儲存過程，因為它不需要引數，不需要顯示呼叫，往往在你不知情的情況下已經做了很多操作。從這個角度來說，由於是隱藏的，無形中增加了系統的複雜性，非DBA人員理解起來資料庫就會有困難，因為它不執行根本感覺不到它的存在。
2.再有，涉及到複雜的邏輯的時候，觸發器的巢狀是避免不了的，如果再涉及幾個儲存過程，再加上事務等等，很容易出現死鎖現象，再除錯的時候也會經常性的從一個觸發器轉到另外一個，級聯關係的不斷追溯，很容易使人頭大。其實，從效能上，觸發器並沒有提升多少效能，只是從程式碼上來說，可能在coding的時候很容易實現業務，所以我的觀點是：摒棄觸發器！觸發器的功能基本都可以用儲存過程來實現。
3.在編碼中儲存過程顯示呼叫很容易閱讀程式碼，觸發器隱式呼叫容易被忽略。
4.儲存過程的致命傷在於移植性，儲存過程不能跨庫移植，比如事先是在mysql資料庫的儲存過程，考慮效能要移植到oracle上面那麼所有的儲存過程都需要被重寫一遍。
回答2：
這種東西只有在併發不高的專案，管理系統中用。如果是面向使用者的高併發應用，都不要使用。
觸發器和儲存過程本身難以開發和維護，不能高效移植。觸發器完全可以用事務替代。儲存過程可以用後端指令碼替代。
回答3：
我覺得來自兩方面的因素：
1.儲存過程需要顯式呼叫，意思是閱讀原始碼的時候你能知道儲存過程的存在，而觸發器必須在資料庫端才能看到，容易被忽略。
2.Mysql的觸發器本身不是很好，比如after delete無法鏈式反應的問題。
我認為效能上其實還是觸發器佔優勢的，但是基於以上原因不受青睞。
問題一：
大型系統必須得要儲存過程和觸發器嗎？ - 知乎
回答1：
我們先要弄清楚二個問題：
1.什麼是大型系統？
2.你討論的是什麼領域的應用，可以大致分為二種：網際網路、企業內部
接下來給你舉一些例子：
1.SAP、peopleSoft、ERP等企業級別應用
一般情況下，會使用儲存過程和觸發器，減少開發成本，畢竟其業務邏輯修改頻繁，而且為通用，很多時候會把一些業務邏輯編寫成儲存過程，像Oracle會寫成包，比儲存過程更強大。
另外一個原因是伺服器的負載是可控，也即系統的訪問人數首先是可控的，沒有那麼大，而且這些資料又非常關鍵，為此往往使用的裝置也比較好，多用儲存櫃子支撐資料庫。
2.另外一類網際網路行業的
比如淘寶、知呼、微博等，資料庫的壓力是非常大的，也往往會最容易成為瓶頸，而且多用PC伺服器支撐，使用者量的增速是不可控的，同時線上訪問的使用者量也是不可控的，為此肯定會把業務邏輯放到其他語言的程式碼層，而且可以藉助一些LVS等型別軟硬體做負載均衡，以及平滑增減Web層的伺服器，從而達到線性的增減而支援大規模的訪問。
所以不管你的這個系統是否龐大，首先要分業務支援的物件，系統最可能容易出現瓶頸的地方在那？
當然也不是說網際網路行業的應用就絕對不用儲存過程，這個也不對，曾在阿里做的Oracle遷移MySQL系統確實用了，因為歷史的原因，另外還有一些新系統也有用，比如晚上進行定期的資料統計的一些操作，不過有量上的控制。儲存過程是好東西，要分場景，分業務型別來用就可以把握好。
回答2：
肯定不能一刀切的說能用或者不能用，不同型別的系統、不同的規模、不同的歷史原因都會有不同的解決方案。
一般情況下，Web應用的瓶頸常在DB上，所以會盡可能的減少DB做的事情，把耗時的服務做成Scale Out，這種情況下，肯定不會使用儲存過程；而如果只是一般的應用，DB沒有效能上的問題，在適當的場景下，也可以使用儲存過程。
至於觸發器，我是知道有這東西但從來沒用過。我希望風險可控，遇到問題能夠快速的找到原因，儘可能不會去使用觸發器。
回答3：
1.PLSQL可以大大降低parse/exec 百分比；
2.儲存過程可以自動完成靜態SQL variable bind；
3.儲存過程大大減少了JDBC網路傳輸與互動，速度快；
4.oracle 中儲存過程內部commit為非同步寫，一定程度上減少了等redo日誌落地時間；
5.儲存過程最大問題就是給資料庫開發工作壓力太大，另外架構升級時候會比較難解耦；
6.觸發器不推薦使用，觸發操作能在業務層解決就在業務層解決，否則很難維護，而且容易產生死鎖。
問題2：
為什麼大家都不推薦使用MySQL觸發器而用儲存過程？- segmentfault
回答1：
1.儲存過程和觸發器二者是有很大的聯絡的，我的一般理解就是觸發器是一個隱藏的儲存過程，因為它不需要引數，不需要顯示呼叫，往往在你不知情的情況下已經做了很多操作。從這個角度來說，由於是隱藏的，無形中增加了系統的複雜性，非DBA人員理解起來資料庫就會有困難，因為它不執行根本感覺不到它的存在。
2.再有，涉及到複雜的邏輯的時候，觸發器的巢狀是避免不了的，如果再涉及幾個儲存過程，再加上事務等等，很容易出現死鎖現象，再除錯的時候也會經常性的從一個觸發器轉到另外一個，級聯關係的不斷追溯，很容易使人頭大。其實，從效能上，觸發器並沒有提升多少效能，只是從程式碼上來說，可能在coding的時候很容易實現業務，所以我的觀點是：摒棄觸發器！觸發器的功能基本都可以用儲存過程來實現。
3.在編碼中儲存過程顯示呼叫很容易閱讀程式碼，觸發器隱式呼叫容易被忽略。
4.儲存過程的致命傷在於移植性，儲存過程不能跨庫移植，比如事先是在mysql資料庫的儲存過程，考慮效能要移植到oracle上面那麼所有的儲存過程都需要被重寫一遍。
回答2：
這種東西只有在併發不高的專案，管理系統中用。如果是面向使用者的高併發應用，都不要使用。
觸發器和儲存過程本身難以開發和維護，不能高效移植。觸發器完全可以用事務替代。儲存過程可以用後端指令碼替代。
回答3：
我覺得來自兩方面的因素：
1.儲存過程需要顯式呼叫，意思是閱讀原始碼的時候你能知道儲存過程的存在，而觸發器必須在資料庫端才能看到，容易被忽略。
2.Mysql的觸發器本身不是很好，比如after delete無法鏈式反應的問題。
我認為效能上其實還是觸發器佔優勢的，但是基於以上原因不受青睞。