2010-12-20 128 views
1

我有兩個表A和表B. 表A包含100萬(1,000,000)個記錄和4個字段,而表2包含60,000和3個字段。 我正在運行一個查詢,它連接這兩個表並使用WHERE子句來查找諸如'%Bags%'之類的WHERE產品和'Bags%'e.t.c之類的產品的特定產品。優化MySQL查詢/數據庫

當我直接在phpMyAdmin中運行查詢時,它會在大約1或2秒內返回記錄。但是,當他們在網站上使用時,根據MySQL的「慢速查詢」日誌,他們有時需要9或10秒。事實上,我的網站響應速度很慢,所以經過調查,我發現這是由於我開始瞭解「慢速查詢日誌」而導致的。

慢速查詢日誌包含所有執行時間超過long_query_time秒的SQL語句,並且至少需要檢查min_examined_row_limit行。

因此,根據上述查詢的日誌「query_time」爲13秒,而在某些情況下,它們甚至具有超過50秒的「query_time」。

我的表都使用PRIMARY鍵以及INDEXES。所以我想知道如何優化它們,或者有什麼方法可以優化MySQL設置?

網站的這種緩慢並不總是發生,但有時(可能是一週一次),持續大約1或2分鐘。它獲得了不俗的流量,還有很多其他查詢,我上面發佈的僅僅是一個例子。

感謝

回答

4

對於所有的東西MySQL和性能有關,退房http://www.mysqlperformanceblog.com/

用EXPLAIN檢查查詢,看到herehere關於如何使用EXPLAIN作爲查詢診斷工具的信息。

只有索引是不夠的。你是否在WHERE子句中搜索字段?你是否也有WHERE子句中使用的字段的索引(包括你在ORDER BY,GROUP BY和HAVING子句以及JOIN中提到的字段)?如果您在單個索引中分組了字段,那麼除非您有查詢將所有這些字段一起搜索,否則該索引不會被命中。如果您將索引中的字段分組,請確保索引實際上將用於查詢(EXPLAIN是您的朋友)。也就是說,它可能還有很多其他的事情:配置不當的MySQL服務器,服務器調整不良,模式不正確。但是,您的查詢和索引是開始調查的好地方。

Here是來自MySQL的Jay Pipes的性能最佳實踐的不錯總結。

+0

另外,正如其他人所暗示的,您的表現會因您網站的流量而異。如果您在非高峯時段在phpMyAdmin中運行查詢,您顯然會獲得比在峯值流量時間內(或訪客)運行查詢時更好的性能。 – 2010-12-20 06:05:39

0

它,因爲一些其他的查詢是在當你要刷新你的網站的頁面時運行。因此,例如,如果您的網站在頁面刷新時運行8-10個查詢,那麼它將比您在phpmyadmin中運行單個查詢花費更多的時間。如果它執行1-1.5分鐘,那麼它可能不是查詢問題,但它也可能與服務器速度有關。

並且您還可以使用MATCH() AGAINST()聲明來優化此類搜索查詢。

否則,您已經在使用PRIMARY KEY, INDEXES and JOINS,因此無需擔心其他事情。

只是檢查出來。

感謝。

1

like '%Bags%'查詢無法使用索引進行優化。

提高性能的唯一方法是使用fulltext indexes或獲得sphinx進行搜索。

+0

是的我已經在此列上使用了FULLTEXT索引。 – Ali 2010-12-20 05:54:06

+1

@Ali:那你爲什麼不用'MATCH ... AGAINST'進行搜索? – zerkms 2010-12-20 05:56:31

0

有很多方法可以優化數據庫和查詢。我的方法如下。

看那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如何處理您的查詢。