數據庫性能問題

我遇到了非常基本的查詢中查詢時間過長的問題。這是我第一次使用更大的表格（12.5 mil的行），我只是想弄清楚什麼可能是瓶頸，或者我可以做些什麼來提高性能。所有數據都在1個表格中。數據庫性能問題

服務器規格：

的Windows Server 2008 R2標準英特爾至強X3430 @ 2.40GHz的 4GB內存1TB 7200RPM硬盤

表信息

ID INT（10 ）聯合國PK AI
商店 INT（2）聯合國
日期日期時間
註冊 INT（2）聯合國
出納 INT（3）聯合國
部 INT（4）聯合國
總十進制（7 ，2）
客戶 int（5）UN
項目 INT（5）UN
時間 INT（5）UN

例查詢和時報

SELECT Store, sum(Total) 
FROM sales 
GROUP BY Store

19.56sec

SELECT Date, Register, Customers, Items, Total 
FROM sales 
WHERE Date(Date) = Date('2013-10-22') 
AND Store = 1

9.59sec

我當然可以提供更多的信息，但有什麼明顯的跡象顯示爲什麼這些運行速度如此之慢？

來源

2013-10-24 Justin Mathieu

你有什麼指標？使用'explain'並告訴我們你選擇的語句的結果。 – kmas

它可能會慢，因爲索引，那麼my.ini配置文件也可能是問題。 – kmas

而不是你有的表信息，添加'SHOW CREATE TABLE sales;'輸出。對於其他人來說，瞭解表結構和索引的詳細信息會更有幫助。 –

是的，有2個明顯的問題。在第一個查詢中，您沒有任何標準 - 因此您要求對整個銷售表進行讀取，分組和彙總。分組也將創建一個臨時表。因此，您將進行表掃描，並且這將僅限於硬件可以提供的io性能，這可能是您的瓶頸。

在第二個查詢中，您正在日期列Date（Date）上執行一個函數，這意味着即使您在Date上有一個索引，也不能使用該索引，因此再一次您將要表掃描表。這樣說的話，你應該在每個查詢上運行explain擴展的SELECT ....來獲得這個評估的信心。

來源

2013-10-24 20:51:35 gview

感謝您的建議！我將不得不考慮是否有替代日期（日期），我肯定會檢查解釋擴展。 –

將解釋的結果粘貼到您的問題中：這將有助於@ypercube和我自己更好地理解您的問題。你也可以調整你的mysql實例的參數，所以這些可能會有所幫助。你的表是innodb引擎嗎？我強烈建議。 – gview

-1

您可以嘗試第二個查詢的兩件事：（1）爲datetime列創建索引。（2）使用整數代替日期時間，2013年10月22日=> 20131022

來源

2013-10-24 20:53:46 Danyu

查詢1：

SELECT Store, sum(Total) 
FROM sales 
GROUP BY Store ;

上(Store, Total)添加的索引：

ALTER TABLE sales 
    ADD INDEX store_total_IX    -- pick a name for the index 
    (store, total) ;

查詢2 ：

SELECT Date, Register, Customers, Items, Total 
FROM sales 
WHERE Date(Date) = Date('2013-10-22') 
AND Store = 1 ;

上(Store, Date)添加一個索引：

ALTER TABLE sales 
    ADD INDEX store_date_IX    -- pick a name for the index 
    (store, date) ;

，並重新編寫查詢 - 因此可以利用索引 - 爲：

SELECT Date, Register, Customers, Items, Total 
FROM sales 
WHERE Date >= '2013-10-22' 
    AND Date < '2013-10-22' + INTERVAL 1 DAY 
    AND Store = 1 ;

來源

2013-10-24 20:54:08

感謝您的迴應！將索引添加到第一個查詢後，時間減少到約9秒。在第二個查詢中刪除Date（Date）並將其替換爲您的建議將查詢截斷爲1.6秒。 –

這聽起來仍然非常低效。我建議你檢查你的mysql配置。設置。 –

數據庫性能問題

回答

相關問題