好多年不做服務器項目了，最近幾個項目均和服務器有關，出現很多性能相關問題，其中一個項目涉及到這麼一個業務，拿出來和大家分享下。
一.背景
產品業務流程大致爲：刷身份證過檢，設備端生成一個過檢記錄id,需要把身份證文字信息和身份證圖片信息分別上傳到服務器S1和圖片服務器S2，其中服務器數據庫中身份證圖片信息保存的是身份證照片在圖片服務S2上的url。
如果強制必須文本信息在服務器S1上傳成功後，再上傳身份證圖片，勢必會影響圖片上傳時間。如果不做這個強制限制，上傳圖片url和文字信息入庫時間先後就不能確定，url數據和文字信息在服務器數據庫中是執行insert還是update就無法確定了，此時就必須處理insert失敗返再重新進行update操作，這個時候可以考慮使用存儲過程了。
在使用存儲過程的問題上，和服務器端研發進行討論決定是否使用存儲過程，所以使用與否我們需要了解下存儲過程的優缺點。
二.優點
1. 運行速度：對於很簡單的sql，存儲過程沒有什麼優勢。對於複雜的業務邏輯，因爲在存儲過程創建的時候，數據庫已經對其進行了一次解析和優化。存儲過程一旦執行，在內存中就會保留一份這個存儲過程，這樣下次再執行同樣的存儲過程時，可以從內存中直接調用，所以執行速度會比普通sql快。
2. 減少網絡傳輸：存儲過程直接就在數據庫服務器上跑，所有的數據訪問都在數據庫服務器內部進行，不需要傳輸數據到其它服務器，所以會減少一定的網絡傳輸。
3. 可維護性：存儲過程有些時候比程序更容易維護，這是因爲可以實時更新DB端的存儲過程。 有些bug，直接改存儲過程裏的業務邏輯，而不用修改程序端代碼。
4. 增強安全性：提高代碼安全，防止 SQL注入。這一點sql語句也可以做到。
5. 可擴展性：應用程序和數據庫操作分開，獨立進行，而不是相互在一起。方便以後的擴展和DBA維護優化。
三.缺點
1. SQL本身是一種結構化查詢語言，但不是面向對象的的，本質上還是過程化的語言，面對複雜的業務邏輯，過程化的處理會很喫力。同時SQL擅長的是數據查詢而非業務邏輯的處理，如果如果把業務邏輯全放在存儲過程裏面，違背了這一原則。
2. 如果需要對輸入存儲過程的參數進行更改，或者要更改由其返回的數據，則您仍需要更新程序集中的代碼以添加參數、更新調用，等等，這時候估計會比較繁瑣了。
3. 開發調試複雜，由於IDE的問題，存儲過程的開發調試要比一般程序困難，不過這個對於有數據庫功底的研發來說調試不是問題。 4.. 沒辦法應用緩存。雖然有全局臨時表之類的方法可以做緩存，但同樣加重了數據庫的負擔。如果緩存併發嚴重，經常要加鎖，那效率實在堪憂。
5. 不支持羣集，數據庫服務器無法水平擴展，或者數據庫的切割（水平或垂直切割）。數據庫切割之後，存儲過程並不清楚數據存儲在哪個數據庫中。
四.小結
1. 適當的使用存儲過程，能夠提高服務器性能。
2. 存儲過程不應該大規模使用，DBA應該在設計與維護數據庫時需要均衡考慮。
3. 隨着衆多ORM 的出現，存儲過程很多優勢已經不明顯。
4. 結合項目業務實際，從業務邏輯簡單的數據庫操作不建議使用存儲過程，複雜對數據實時性要求比較高，可以考慮從存儲過程觸發器上進行設計優化。
最後，回到我們的這個項目業務上看。使用與否也需要結合客戶是否對身份證圖片信息實時性是否要求很高。最後與項目產品經理確認，身份證圖片信息可延遲離線上傳，那麼完全可以不使用存儲過程了。