1、查詢出的資料量過大（可以採用多次查詢，其他的方法降低資料量），盡量採取分頁查詢資料
2、鎖或者死鎖(這也是查詢慢最常見的問題，是程式設計的缺陷)
3、返回了不必要的行和列
用or的字句可以分解成多個查詢，並且通過union鏈結多個查詢。它們的速度只與是否使用索引有關，如果查詢需要用到聯合索引，用union all執行的效率更高。
4、如果是使用like進行查詢的話，簡單的使用index是不行的，但是全文索引，耗空間。 like 'a%' 使用索引 like '%a' 不使用索引用 like '%a%' 查詢時，查詢耗時和字段值總長度成正比,所以不能用char型別，而是varchar。對於欄位的值很長的建全文索引。
5、盡量將資料的處理工作放在伺服器上，減少網路的開銷，如使用儲存過程。儲存過程是編譯、優化過，並且被組織到乙個執行規劃裡，且儲存在資料庫中的sql語句（儲存過程是資料庫伺服器端的一段程式），是控制流語言的集合，速度當然快。
6、將需要查詢的結果預先計算好放在表中，查詢的時候再select。這在sql7.0以前是最重要的手段。例如計算商品購買小計計算。
7、沒有必要時不要用distinct和order by，這些動作可以改在客戶端執行。它們增加了額外的開銷。這同union和union all一樣的道理。
8、一次更新多條記錄比分多次更新每次一條快,就是說批處理好
9、用臨時表，盡量用結果集和table類性的變數來代替它,table 型別的變數比臨時表好
10、資料庫設計：資料庫內所有表結構均新增索引
調整原因：
近日資料庫壓力很大，經查有些大資料量表的查詢速度很慢，導致資料庫伺服器cpu一直持續90%-100%，將這些表新增索引後，cpu很快變正常。
根據查詢條件,建立索引,優化索引、優化訪問方式，限制結果集的資料量。注意填充因子要適當（最好是使用預設值0）。索引應該盡量小，使用位元組數小的列建索引好（參照索引的建立）,不要對有限的幾個值的字段建單一索引如性別字段
11、 將大資料表做分庫、分割槽處理:
具體操作如下：
1）、將大資料表與主資料庫分離，單獨新建乙個資料庫，然後將這些表做分割槽；
2）、將資料插入到訊息佇列內，後台利用windows計畫任務執行（5分鐘執行一次）c#控制台程式將訊息佇列內的資料批量（訊息佇列內有50000條記錄，一次性插入到資料表內）插入到相應的資料表內；
調整原因：
例如：使用者訪問日誌，每次使用者訪問乙個頁面的時候我們之前的操作是直接將資料插入資料庫，這樣做對資料庫的訪問及操作太大，嚴重影響其他資料插入、查詢的效率，利用分庫、分割槽、訊息佇列完成此操作的好處是使用者訪問頁面的時候不直接對資料庫操作，而是在訊息佇列內積累一定數量的資料後批量插入資料庫，只執行一次資料庫操作，而且因為資料庫分離的原因，對其他的查詢及插入不會有影響；
web開發效能優化 安全篇
1 許可權管理 從模組 表單 資料審核 功能按鈕全面資料安全驗證及管理。2 ip驗證 資料介面訪問進行ip校驗 3 登入 操作日誌 程式安全日誌 系統所有使用者登入 操作全部日誌記錄。程式安全日誌操作可檢視我之前寫過 loghelper 日誌記錄幫助類 4 sql注入校驗過濾 a 表單控制項js前端...
Android開發效能優化
1 盡量不適用靜態引用，以避免記憶體溢位 2 對進行壓縮 3 listview的優化 4 自定義view中減少measure layout draw 中的耗時操作即它們執行次數 5 不在ui執行緒總做耗時操作，網路請求 資料庫操作 複雜計算等放在子執行緒 6 webview退出時手動銷毀 方法未知 ...
web開發效能優化 專案架構篇
專案技術架構層級規劃和介紹 簡稱四橫兩縱 四橫即四大層次，分別為 1 使用者渠道層 使用者渠道層是直接面向終端使用者。通過 的形式向使用者提供產品展示 企業市場宣傳 對產品的訂購 互動分享 客戶關懷以及使用者中心入口等功能，並提供後期擴充套件移動終端接入 2 應用 業務層 該層面向的是系統管理人員。...