很多做系統開發編碼的程式設計師會面臨這些困惑，在開發系統時只是為了趕進度先實現功能，上線前期資料量少沒有發現異常，但是上線執行一段時間後會發現系統某些功能查詢越來越慢，甚至卡死或頁面假死，更有嚴重者導致系統崩潰。最終導致整個專案黃掉或者客戶不滿意不驗收的問題。
近幾年做了一些專案，發現很多系統都面臨這類上線後系統隨著資料規模的增大導致系統卡頓問題，也踩過不少坑。
資料庫sql優化很多人認為是dba的事，上線之後動不動會摔鍋給dba。
系統資料庫sql優化原則：提前規劃，業務設計規避複雜sql，sql語句規範合理，熟悉資料庫的語言特性和語句使用侷限性。
具體可以分為幾個階段：
一、事前做好資料庫設計和規劃，系統上線前對資料量有預估或者對資料提前做資料壓力測試驗證。對關鍵性業務表設計時，最好有專案管理人員、系統開發人員、資料庫管理人員對錶的設計和關聯進行分析，表的設計是否滿足資料庫設計原則(主外來鍵設計是否合理、表字段是否符合正規化要求、核心表的字段冗餘設計等)進行評估。能從業務簡化的表設計的，盡可能提前考慮表的各種業務場景會涉及的sql複雜度，提前做分庫分表規劃，根據業務做好有效資料規模規劃處理；
二、開發編碼階段：開發前團隊強調sql語句的規範和做好**審查。另外可以灌入大規模的模擬資料進行sql效能測試，提前規避一些問題。避免不必要的多表關聯、合理使用not in、in、like、or、order by等，避免多重巢狀查詢，游標的使用也應謹慎。對儲存過程熟悉的或者sql語句盡量用變數進行編寫。合理利用檢視、臨時表、定時器預先處理資料避免集中對大規模和歷史全域性資料的操作。
三、上線後執行階段：很多人進入乙個專案或者乙個公司都是接手維護已經上線的系統，就會面臨要解決原有的問題。可以從業務場景先著手，考慮如何取所需的資料和預先處理一部分資料，減少對伺服器的開銷；如果無法從業務層面規避的，要分析sql語句是否存在不必要的巢狀查詢，使用in、not in、or、group by等是否合理。有的字段是否是必須的如果沒有用可以精簡掉。除錯的sql要進行執行效能分析，每次優化完要思考可否進一步優化。通過預先處理一部分資料或者索引、儲存過程等手段是否能進一步優化。
以上只是sql語句的優化一點不成熟的想法，希望對大家有一點啟發。
sql優化,資料庫優化
1.sql的執行順序 from 表名 where 條件 執行順序是從後往前，where條件後面的語句盡可能縮短where 資料執行的範圍。先group by 後order by select 查詢 2.避免過多的聯查，設計合理的表關係 3.遵守常見sql規範，盡可能減少 4.如果表字段過多，經常展示...
sql優化 資料庫優化
資料庫優化 資料庫優化吧我覺應該從硬碟 記憶體和網路頻寬考慮，提高硬碟的讀寫速度，增大頻寬提高吞吐量，增大伺服器記憶體，可以採用讀寫分離，降低單台資料庫的訪問壓力，查詢的時候控制資料量的大小，返回更少資料，減少互動次數，減少cpu及記憶體的開銷，sql優化 如果乙個表中資料量過大我們可以採用橫切割，...
資料庫優化 SQL優化
前面一篇文章從例項的角度進行資料庫優化，通過配置一些引數讓資料庫效能達到最優。但是一些 不好 的sql也會導致資料庫查詢變慢，影響業務流程。本文從sql角度進行資料庫優化，提公升sql執行效率。判斷sql是否有問題時可以通過兩個表象進行判斷 可以使用sar命令，top命令檢視當前系統狀態。也可以通過...