大家應該都遇到過web應用資料庫訪問慢的問題，如果只是少量的頁面訪問有問題（效能問題）時，優化是非常簡單的。但是如果是「所有的都慢」，需要如何做呢？
看那些來自於資料庫並且在頁面上顯示的資訊。這是重要的，因為這些資訊是需要用這樣或那樣的方法從資料庫中讀取出來的，如果確實是打算這樣顯示的話。任務就是要使用最高效的方法，從資料庫中得到這些資訊。
考查這些資訊的動態性。如果很少改變，或者乾脆就是靜態的，那麼比較好的方法是預先建立（pre-create）或者快取它。只是要記住，優化資料庫訪問的最好的方法，就是避免訪問資料庫。這對於其他的類似事情也適用----如果可以完全避免動態頁面的產生，並且使用伺服器的快取來解決，就更好了。
檢查從資料庫讀出的資料與需要顯示的資訊是否相符。從資料庫出讀取的資訊，往往比生成頁面所需要的資訊要多。輕一點的像是selectfromtbl，而不是只列出那些真正需要的列；嚴重的可以是用selectfromtbl來計算表中有多少行記錄（不是開玩笑）。有時候會看到查詢了100個stories，其中任乙個會被選擇顯示出來，由應用程式層做過濾。有時候在應用程式層這樣做是高效的，但是通常應該使查詢只返回需要的資訊。
檢查結果集的記錄數。這是非常重要、而且經常被遺忘的步驟。如果乙個查詢返回很少的行數，有些人就認為它是簡單的，而真正重要的是這個查詢分析了多少行資料。比如selectcount(*)fromlinkswheredomain=「mysql.com」;只返回一行，但卻掃瞄了成千上萬的記錄（或者索引節點）。其他通常的殺手查詢是groupby查詢和sort查詢----selectname,descrfromtitlesorderbyrankdesclimit10----如果沒有適當的索引，就會使用「filesort」，會有些問題。此外就是join（關聯）----關聯是高代價的（當然是相對的），並且確實增加了為了產生結果集而使用的資料量----如果不得不關聯10個表來組合出想要的結果，那麼會比從乙個表中得到同樣的資料要慢很多。
檢查結果集的生成實際需要的記錄數。有時查詢需要使用大量資料來產生結果集，是因為沒有適當的索引----這是容易發生的。比如我們的orderbyrank查詢就是這樣----為rank列增加索引，會使這個查詢僅使用10行資料來返回10行----恰恰是我們想要的。然而我們的count(*)查詢是不同的----即使在domain列上有索引，它仍然需要掃瞄很多行資料來得到結果集。這樣的查詢需要重新設計，而不是簡單地調整----比如彙總表（summarytable）儲存了每個域的link數量，就可以解決。
檢查查詢的次數。如果可以使用乙個查詢得到所需要的資料，那麼就好於用多個查詢得到同樣的資料，前提是這乙個查詢不會因為與那些查詢優化方式不同而需要分析更多行的資料。這裡乙個典型的例子是select*fromtblwhereid=5執行了很多次，每次使用不同的常量----用類似in(5,7,4,56)來替換是非常有效的。但也不要被這樣的方法迷住。我曾經看到有人嘗試用union（需要適當填充以使不同的字段數目及型別能夠匹配）連線所有的查詢----這不是個好主意。然而，如果可以減小查詢的次數，而又不會增加應用程式架構的複雜性，那麼是值得做的。
資料庫應用優化
基本語句優化的10個原則 1 盡量避免在列上進行運算，這樣會導致索引失敗 2 使用join時，應該用小結果集驅動大結果集。同時把複雜的join查詢拆分成多個query。因為join多個表時，可能導致更多的鎖定和堵塞 3 注意like模糊查詢的使用，避免 4 僅列出需要查詢的字段，這對速度不會有明顯的...
資料庫訪問優化法則
從圖上可以看到基本上每種裝置都有兩個指標 延時 響應時間 表示硬體的突發處理能力 頻寬 吞吐量 代表硬體持續處理能力。從上圖可以看出，計算機系統硬體效能從高到代依次為 cpu cache l1 l2 l3 記憶體 ssd硬碟 網路 硬碟 根據資料庫知識，我們可以列出每種硬體主要的工作內容 cpu及記...
訪問資料庫優化法則
減少資料訪問 減少磁碟訪問 建立並正確使用索引 只通過索引訪問資料 優化sql執行計畫 返回更少的資料 減少網路傳輸 資料分頁處理 a 應用程式分頁 客戶端或瀏覽器 a 應用伺服器分頁 客戶端或瀏覽器 a 資料庫sql分頁 客戶端或瀏覽器 只返回需要的字段 減少互動次數 減少網路傳輸 使用儲存過程 ...