有很多方法可以優化數據庫和查詢。我的方法如下。
看那DB模式,看看它是否有意義
大多數情況下,數據庫有壞的設計和不歸。這可能會極大地影響數據庫的速度。作爲一般情況,請學習3種標準格式並隨時應用。第三範式以上的常規形式通常稱爲反規範化形式,但這實際上意味着它們違反了一些規則以使數據庫更快。
我的建議是堅持第三範式,除非你是DBA(這意味着你知道後續表單並知道你在做什麼)。第三次NF之後的標準化通常在以後進行,而不是在設計期間進行。
只能查詢你真正需要的
過濾儘可能
你的where子句優化最重要的部分。
只選擇字段,你需要
不要使用 「SELECT *」 - 指定只有你所需要的領域;它會更快,並將使用更少的帶寬。
小心加入
加入是在時間方面昂貴。確保您使用將兩個表格關聯在一起的所有關鍵字,並且不加入未使用的表格 - 始終嘗試加入索引字段。連接類型也很重要(INNER,OUTER,...)。
優化查詢和存儲過程(大部分程序已經運行)
查詢的速度非常快。一般來說,即使使用連接,排序和計算,您也可以在不到一秒的時間內檢索多條記錄。作爲一個經驗法則,如果您的查詢超過一秒鐘,您可以優化它。
從最常用的查詢開始,以及花費最多時間執行的查詢。
添加,刪除或修改索引
如果您的查詢做全表掃描,索引和適當的過濾可以解決什麼通常是一個非常耗時的過程。所有主鍵都需要索引,因爲它們使聯接更快。這也意味着所有的表都需要一個主鍵。您還可以在「Where子句」中經常用於過濾的字段上添加索引。
你特別想使用整數,布爾值和數字索引。另一方面,你可能不想在Blob,VarChars和Long Strings上使用索引。
小心添加索引,因爲它們需要由數據庫維護。如果您在該字段上執行了許多更新,則維護索引可能需要比節省更多的時間。
在互聯網世界中,只讀表是非常普遍的。當表是隻讀時,您可以添加索引,因爲索引不需要維護(或者很少需要維護),因此索引負面影響較小。
移動查詢到存儲過程(SP)
存儲過程通常比查詢,原因如下更好更快:
Stored Procedures are compiled (SQL Code is not), making them faster than SQL code.
SPs don't use as much bandwidth because you can do many queries in one SP. SPs also stay on the server until the final results are returned.
Stored Procedures are run on the server, which is typically faster.
Calculations in code (VB, Java, C++, ...) are not as fast as SP in most cases.
It keeps your DB access code separate from your presentation layer, which makes it easier to maintain (3 tiers model).
刪除不需要的意見
視圖是特殊類型的查詢 - 它們不是表格。它們是合乎邏輯的,而不是物理的,所以每次從MyView運行select *時,都會運行使視圖和查詢生效的查詢。
如果您始終需要相同的信息,則視圖可能會很好。
如果您必須過濾查看,就像在查詢上運行查詢 - 速度較慢。
調庫設定
您可以調整DB在很多方面。更新優化器使用的統計信息,運行優化選項,使數據庫只讀等等。這需要更廣泛的關於您使用的數據庫的知識,並且主要由DBA完成。
****>使用查詢分析器****
在許多數據庫中,有用於運行和優化查詢的工具。 SQL Server有一個稱爲查詢分析器的工具,對於優化非常有用。您可以編寫查詢,執行它們,更重要的是查看執行計劃。您使用該執行來了解SQL Server如何處理您的查詢。
另外,正如其他人所暗示的,您的表現會因您網站的流量而異。如果您在非高峯時段在phpMyAdmin中運行查詢,您顯然會獲得比在峯值流量時間內(或訪客)運行查詢時更好的性能。 – 2010-12-20 06:05:39