標籤：

在 LAMP 或 LNMP 架構中，MySQL 的定位到底是怎樣的？

01-15

當前對於MySQL在LAMP或者LNMP架構中的定位到底應該是什麼？與同事聊天的過程中，很多人都是認為MySQL就是應該作為一個數據容器，僅僅利用其最基本的數據儲存的過程，至多加加索引。至於MySQL的存儲過程之類，完全不用。

他們的理由很簡單「為了日後的遷移」，以免發生遷移上額外造成的成本。

另外也有部分同時認為，將業務邏輯加在資料庫上不是一個明智的選擇，如果修改業務邏輯，還需要修改資料庫相關內容，而不是在程序中進行修正。

所以，在這裡，想請問一下，你們怎麼認為MySQL的定位問題。到底是僅僅作為一個放數據的地方，還是應該更大可能性的使用MySQL提供的功能，包括存儲過程、事務等內容。

另外，如果這個問題與其他內容相關聯，也可以同時說明。

謝謝。

挺有意思的，要是你去認真看下，會發現很多互聯網企業中，oracle也僅僅類似你說的容器，首先必須承認其真是一個存放和管理數據的容器；

其次，對於附加的功能，比如存儲過程，觸發器、事務調度器等，要在適當地場景中適度地用。

比如一個複雜非常大的系統，你使用存儲過程去處理業務邏輯就不合適，因為資料庫伺服器本身就會因無力I/O的原因，而成為一個瓶頸。

但是像一些WebGame遊戲中，因為採用分區分服，遊戲本身等原因，每個服上人數不多，那麼就可以用存儲過程了

還不如遊戲的充值系統，就真用存儲過程寫業務邏輯了，因為不可能那麼大壓力，除非是遊戲平台型公司.....

還有一些企業內部系統，就可以考慮了.....

業務邏輯放資料庫上最大的問題就是更新帶來的問題。

  • 業務繁忙時資料庫中存儲過程或者函數的更新很容易造成系統出現異常造成故障
  • 程序員很多時候只關注自己程序中的代碼而忽略資料庫中的業務代碼，經常會發生業務邏輯變化後程序代碼更新了但是資料庫中的代碼沒有更新造成業務異常
  • 資料庫中的存儲過程和函數之類的東西並不是資料庫的核心功能，只是一些輔助功能，更多用在非業務場景的數據處理中，而不是與業務綁定
  • 程序的發布可以一個節點一個節點的輪換髮布而完全不影響業務，資料庫的發布更容易影響在線業務

我不反對存儲過程,但門檻相對較高.

比較傳統的說法,參考:

http://dev.mysql.com/tech-resources/articles/mysql-storedprocedures.html

If you have a repetitive task that requires checking, looping, multiple statements, and no user interaction, do it with a single call to a procedure that"s stored on the server. Then there won"t be messages going back and forth between server and client, for every step of the task.

存儲過程在傳統公司是經常用到的,因為有複雜的業務邏輯,有大量的計算,也涉及到數據保護,許可權管理.但互聯網公司不一樣,互聯網公司一般業務邏輯簡單多了,相對來說資料庫資源(包括人)比較緊缺,應用伺服器更容易擴展,網路資源也一般不成為問題.

之前也一直有類似的疑問，用過Mysql的函數、存儲過程和觸發器，以及innodb的事物，也不是想像的那樣垃圾，可以滿足一些應用了。感覺Mysql很少用這類「高級」方法主要還是出於：

  1. 大部分的mysql用戶都是www，相對oracle的企業用戶來說業務邏輯不算複雜，沒有大批量的事物數據需要聯動。www的少量數據，大量並發的環境要求數據結構盡量簡單，而且多交由相對成本較低的程序端處理。
  2. mysql的鎖機制始終是個問題，這就要求對資料庫的操作儘可能的簡短，類似的使用會增加表鎖概率。
  3. 將業務邏輯放置在資料庫中是為了解決客戶端運算不足的狀況，比如ERP系統的業務報表。C/S系統中C的運算能力和通訊狀況一般都小於S，顯然不適合在客戶端生成數據。但B/S系統中瀏覽器僅僅作為交互展示，不需要進行大量的運算且通訊數據相對不多，如LAMP環境中數據處理就交由伺服器的PHP進行，事實上還是屬於S端計算。

總之，函數、存儲過程和觸發器適用於大量數據匯總，而mysql在lamp中的地位是數據記錄大量引用。

上面很多朋友所說的，關於 MySQL 不應該處理業務邏輯的原因，我覺得挺有道理的。

那我來補充一個用 MySQL 處理業務邏輯的優點吧。

數據一般都是由 server 端寫入資料庫的。如果公司是面向企業級用戶的話（乙方賣產品給甲方），公司開發的業務系統可能會分 Windows 和 Linux 兩種（具體實施哪個由客戶的 OS 來定），如果業務系統 server 端的開發不是採用 Java 之類的跨平台的語言的話（eg. C/C++），那後端程序員就要實現兩套完全相同的業務邏輯。

如果這部分業務邏輯不是很複雜，可以放在 MySQL 資料庫層面實現（函數、存儲過程、觸發器、事件調度等），兩邊的後端程序員就不用處理了。

上面的情形，是工作中真實遇到並且採用的。當然，這種情形並不常見。

如果想要以後有充分的擴展性 一定要在資料庫設計時就不要耦合太強

而且查詢邏輯盡量的簡單 不然以後要加cache或者上nosql存儲會很難遷移

MySQL定位沒有一杆子打死的說法，作為資料庫，MySQL本身的基本作用就是存儲數據的容器，存儲過程、觸發器之類的功能是這容器提供給你的附加增強功能，如何給資料庫定位，取決於你的應用程序和業務邏輯的需求，基於lamp、lnmp的應用不一定只有互聯網應用程序，也有其他複雜的基於B/S架構應用程序。

我所在的公司主營業務是ERP系統，沒有使用LAMP架構或者Mysql。

大部分非常複雜的業務邏輯都是在資料庫中實現的，一方面是有很多的業務流程、業務邏輯需要維護，另一方面對於大數據量的操作也可以減少網路傳輸與交互。

還有一個比較重要的是客戶方的維護人員可以根據自己特殊的業務方式通過修改存儲過程實現相應的需要，特別是報表等功能。

盡量的減小程序的分支。

場景1：存業務數據，並發不高但易於統計

場景2：高並發，簡邏輯，做持久備份

場景3：讀cache於4/7層、各邏輯前端，SSD於主庫，分表互為主從硬扛

存儲過程適用於統計或大量數據的定時更改，比如之前股票每天信息更新。

中小型企業站的最愛。但是不適合把項目做大，很難解決大並發，大流量的問題。這也是關係型資料庫的通病。

業務邏輯是否放在資料庫上我覺得應該根據業務需求來決定。一般來說開發人員和資料庫能力都比較差，而且目前的開發的一下方法能便於大型項目的維護，所以更多的情況是不會把業務放在資料庫中去。但有些軟體在業務處理的效率上要求非常高，而且有很大的數據計算的話會選擇把業務邏輯放到存儲過程里去以提高效率。比如：工程建築的計算業務邏輯就必須放到資料庫中才能達到要求的效率。

mysql是一種數據倉庫 必然就是一種容器。但是這個容器也需要變的跟完善，mysql如果是一個水壺

，最基本的功能就是盛水，但是現在也可以用來泡茶，茶泡的好不好，和水壺有關係，但是更和泡茶的人有關。

所以存儲過程、事務『、觸發器 不是不能用而是 謹慎使用，用的好也很穩定

從來沒有用過存儲過程之類的，互聯網應用應該很少用到

一般這些東西在進銷存或ERP之類的內部系統用得比較多

我的選擇是盡量不用. 感覺修改程序比修改資料庫那端要方便很多. 而且資料庫的修改影響範圍有時候可能很大. 其實這個定位也得看項目,產品的定位. 一,你是否打算一直使用mysql? 二,產品是什麼樣的產品. 查詢 輸入的比例大約會是多少? 你選擇什麼引擎?

一般不要用，維護是個問題。沒有用的理由。弊大於利。

將業務邏輯加在資料庫上不是一個明智的選擇，如果修改業務邏輯，還需要修改資料庫相關內容，而不是在程序中進行修正。

推薦閱讀：

TAG:資料庫 | MySQL | LAMP |