效能問題應該從系統設計時期開始考慮，並延續到系統的生命期終止之時。
具有可伸縮性的系統是指當系統的負載增加一倍，系統需要的資源也同樣增加一倍。說起來簡單，但在現實環境中確難以做到。由於管理併發使用者的開銷的增長、鎖事務的增長、一致性讀負載的增加、作業系統負載的增加、
低效的sql或索引設計導致的過高的i/o等等因素，會導致系統資源的消耗的增長遠大於一倍。
破壞可伸縮性的因素：
1.低效的應用程式設計、實施和配置
2.硬體部分的規模不合適
3.軟體部分的限制
4.硬體部分的限制
系統的結構可分為硬體和軟體兩部分：
硬體部分包括：
cpu、記憶體、i/o子系統和網路模組。
軟體部分包括：管理使用者介面、實現商業邏輯、管理使用者請求和資源分配、管理資料和事務。
在設計系統時，應該考慮以下幾個問題：
系統將支援多少使用者？
使用者的互動方式是什麼？
使用者所處的位置？
網路的速度怎樣？
使用者將訪問多少資料？有多少資料是唯讀訪問？
使用者對響應時間的要求？
使用者是否需要
24小時服務？
是否所有的修改需要實時完成？
應用程式設計原則：
設計簡單性原則：
1.如果表的設計複雜到沒有人能夠完全的理解，那麼表的設計可能是比較差的。
2.如果sql語句過長以致於優化程式無法優化該語句，那麼sql語句的設計、事務和表的設計一定存在問題。
3.如果表的相同列上被重複索引，那麼索引的設計可能是有問題的。
5.如果資料庫的呼叫被許多層軟體從應用邏輯中抽象出來，那麼，軟體開發的方法可能存在問題。
資料建模：應當注意，不要在非核心資料單元上花費過多的時間。
表和索引的設計：選擇合適的列進行索引、選擇索引型別、注意索引的代價、關注索引中列的順序。
乙個表上如果有
3個索引，那麼當進行insert/update/delete操作時，會比不帶索引的表慢大約10倍。
組合索引中，選擇性高的列在前查詢時需要的
i/o更少。選擇性低的列在前，有助於代排序操作的查詢。
sql執行效率：
資料庫連線管理：應避免沒有必要的過多連線。
資料庫游標管理：使用
cursor和繫結變數，盡量避免硬分析，較少軟分析。
硬分析：
sql語句第一次提交，並在共享池中無法找到。
軟分析：
sql語句第一次提交，但是可以在共享池中找到相同的語句。
實施新的應用程式：
切換方式包括兩種：
效能清單列表：
1.設定maxinstances, maxdatafiles，maxlogfiles，maxlogmembers和 maxloghistory的值高於預期值。避免系統的增長導致必須重建控制檔案。
2.設定block size和優化模式與開發環境中相同。如果測試環境中的所有sql語句的執行計畫都是正確的，可以測試環境中的統計資訊匯入到正式庫中。
3.盡量少修改初始化引數。除了sga的組成部分和歸檔目錄的設定，其他初始化引數盡量保持預設值，可以為以後效能優化留下一定的餘地。
4.通過設定資料庫物件的儲存引數來管理block的爭用。
5.所有的sql語句應該被優化。
6.驗證中間層軟體和程式採用高效的方式連線資料庫。
7.驗證sql語句有效的利用游標。
8.確認所有方案的物件從開發環境移植到了產品資料庫中。
9.一旦完成系統的切換，建立資料庫和作業系統統計資訊的基線。
10.發現最先出現的瓶頸。
Android開發效能優化
1 盡量不適用靜態引用，以避免記憶體溢位 2 對進行壓縮 3 listview的優化 4 自定義view中減少measure layout draw 中的耗時操作即它們執行次數 5 不在ui執行緒總做耗時操作，網路請求 資料庫操作 複雜計算等放在子執行緒 6 webview退出時手動銷毀 方法未知 ...
web開發效能優化
1 查詢出的資料量過大 可以採用多次查詢，其他的方法降低資料量 盡量採取分頁查詢資料 2 鎖或者死鎖 這也是查詢慢最常見的問題，是程式設計的缺陷 3 返回了不必要的行和列 用or的字句可以分解成多個查詢，並且通過union鏈結多個查詢。它們的速度只與是否使用索引有關，如果查詢需要用到聯合索引，用un...
《軟體開發效能優化系列》之表設計
樹狀表都是使用id和idparent兩個欄位來表示樹關係。對樹進行查詢只能使用自關聯方式，不光寫法麻煩而且記錄多的時候查詢效能會非常差。建議在設計樹表的時候可以考慮加入treepath欄位，記載到該節點記錄需要經歷的樹路徑。雖然會增加insert和update的成本。但是對查詢樹關係非常有幫助。可以...