從知乎瞭解到，為什麼Mysql禁用儲存過程、外來鍵和級聯？

開啟帖子直接一張醒目的圖，是阿里巴巴的Java開發手冊對Mysql相關的要求。

看看下面的回覆

靈劍

儲存過程沒有版本控制，版本迭代的時候要更新很麻煩。儲存過程如果和外部程式結合起來用，更新的時候很難無感升級，可能需要停服。儲存過程不利於將來分庫分表。儲存過程的功能不一定夠強大，業務擴充套件之後可能會發現無法繼續用儲存過程實現了。儲存過程可能無法和許多中介軟體、ORM庫一起使用。某些特殊的相容MySQL的實現可能根本就不支援儲存過程，那就更不用說了。
這也不絕對，在微軟的時候就有專案是反過來的，所有業務都需要用儲存過程寫在SQL Server裡面，查詢全寫成檢視，業務程式碼只允許使用檢視和儲存過程，只要SELECT和EXECUTE許可權就夠了；修改業務只需要登伺服器改儲存過程。這屬於思路不同。

 

吳啊

任何技術都要分使用場景，阿里這種網際網路高併發的場景，很多資料都是分庫分表的，而且要求高度可擴充套件，原則是對db的保護做到最大化，能減少db壓力的就減少db壓力，儘量把運算邏輯拉到程式碼裡面。儲存過程的優點在於封裝性好，直接讓db進行運算，但是缺點在於難以維護，而且大大增大db壓力。所以開發過程中禁止使用儲存過程也是阿里多年經驗積累出來的。

 

孤盡[《阿里巴巴JAVA開發手冊》主要作者]

解釋一下這個事情：曾經寫過近1200行的儲存過程，沒有辦法斷點，下層資料結構只是稍微變動，根本無法找到出錯點，只是提示一下說：ERROR:1064啥的。在資料庫遷移的時候，由於資料庫版本變更，居然儲存過程無法執行。另外，業務上需要擴充套件一下，那就是災難性的啊。沒想到，我覺得毫無爭議的這一條，反而成了一個最大的爭議點。儲存過程只是單機時代的產物，並不適合網際網路時代。

 

陳曦

小公司還好，大公司對db把控很嚴格。分別說下：除錯：線上除錯一般就是打日誌，在應用層，日誌可以在任何一步打，但是儲存過程的話，日誌沒法跟蹤詳細的執行過程。擴充套件：譬如你的 產品購買流程 要增加一個動作，這時候就要修改儲存過程到db裡，你這時候要直接操作db，而在大公司，直接操作db只能有dba來進行，其他都要審批後使用公司自己開發的工作來進行，且只能是簡單的crud。移植：你用mysql寫的儲存過程，到了sqlserver不一定能直接用。但是在應用層的話，程式裡的crud的基礎sql基本上通用的，修改下連線串一般就ok了。

 

........

原貼地址：知乎地址