MYSQL查詢需要4個小時

Question

大家下午好。 我是來找您的，希望您可以為我遇到的MYSQL優化問題提供一些指導。 首先，一些系統規格。

• MYSQL版本：CE 5.2.47
• WampServer v 2.2

電腦：

• 三星QX410（筆記本電腦）
• Windows 7的
• 英特爾i5（2.67 Ghz）
• 4GB RAM

我有兩個表：

1. “ Delta_Shares”包含股票交易數據，並包含兩列注釋。 “ Ticker”是Varchar（45），“ Date_Filed”是Date。 該表大約有300萬行（全部都是唯一的）。 我在（Ticker，Date_Filed）上的“ DeltaSharesTickerDateFiled”表上有一個索引。

2. “ Stock_Data”包含兩列注釋。 “股票代號”是Varchar（45），“ Value_Date”是日期。 該表大約有1900萬行（所有行都是唯一的）。 我在（Ticker，Value_Date）上的“ StockDataIndex”表上有一個索引。

我試圖通過從Stock_Data表中查找信息來更新“ Delta_Shares”表。 以下查詢需要4個小時以上才能運行。

update delta_shares A, stock_data B
set A.price_at_file = B.stock_close
where A.ticker = B.ticker
    and A.date_filed = B.value_Date;

過多的運行時間是否是大量行，不良索引，不良機器，不良SQL編寫或以上所有結果的自然結果？ 請讓我知道是否還有其他有用的信息（盡管我對MYSQL不太熟悉，盡管這個問題使我大大地偏離了優化的道路）。 我非常感謝任何想法或建議。

---

用“ EXPLAIN SELECT”更新

1(id)  SIMPLE(seltype)  A(table)   ALL(type)  DeltaSharesTickerDateFiled(possible_keys) ... 3038011(rows)   

1(id)  SIMPLE(seltype)  B(table)  ref(type)  StockDataIndex(possible_keys)  StockDataIndex(key)  52(key_len) 13ffeb2013.A.ticker,13ffeb2013.A.date_filed(ref) 1(rows)   Using where

---

用表描述更新。 庫存數據表：

idstock_data    int(11)         NO  PRI     auto_increment
ticker          varchar(45)     YES MUL     
value_date      date            YES         
stock_close     decimal(10,2)   YES 

Delta_Shares表：

iddelta_shares          int(11) NO  PRI     auto_increment
cik                     int(11) YES MUL     
ticker              varchar(45) YES MUL     
date_filed_identify     int(11) YES         
Price_At_File       decimal(10,2)   YES         
delta_shares        int(11) YES         
date_filed                date  YES         
marketcomparable            varchar(45)      YES            
market_comparable_price     decimal(10,2)    YES            
industrycomparable          varchar(45)      YES            
industry_comparable_price   decimal(10,2)    YES                    

來自Delta_Shares的索引：

delta_shares    0   PRIMARY 1   iddelta_shares  A   3095057             BTREE       
delta_shares    1   DeltaIndex  1   cik A   18          YES BTREE       
delta_shares    1   DeltaIndex  2   date_filed_identify A   20633           YES BTREE       
delta_shares    1   DeltaSharesAllIndex 1   cik A   18          YES BTREE       
delta_shares    1   DeltaSharesAllIndex 2   ticker  A   619011          YES BTREE       
delta_shares    1   DeltaSharesAllIndex 3   date_filed_identify A   3095057         YES BTREE       
delta_shares    1   DeltaSharesTickerDateFiled  1   ticker  A   11813           YES BTREE       
delta_shares    1   DeltaSharesTickerDateFiled  2   date_filed  A   3095057         YES BTREE       

來自Stock_Data的索引：

stock_data  0   PRIMARY 1   idstock_data    A   18683114                BTREE       
stock_data  1   StockDataIndex  1   ticker  A   14676           YES BTREE       
stock_data  1   StockDataIndex  2   value_date  A   18683114            YES BTREE       

Answer 1

您可以通過一些基准測試來了解瓶頸所在。 例如，嘗試將字段更新為恆定值，並查看需要花費多長時間（顯然，您需要創建數據庫的副本才能執行此操作）。 然后嘗試一個不更新的選擇查詢，而只是選擇要更新的值以及它們將被更新為的值。

這樣的基准通常會告訴您是在浪費時間進行優化還是有很大的改進空間。

至於記憶，這是您正在查看的大致概念：

varchar字段是2個字節，加上實際長度，而datetime字段是8個字節。 因此，讓我們做出一個非常寬松的猜測，即Stock_Data表中的varchar字段平均約為42個字節。 使用datetime字段，每行最多增加50個字節。

50字節x 2000萬行= 0.93千兆字節

因此，如果此過程是計算機中唯一發生的事情，那么我認為內存不是問題，因為您可以輕松地一次將查詢所使用的兩個表中的所有數據放入內存中。 但是，如果發生其他情況，則可能是一個因素。

Answer 2

嘗試對兩個表analyse ，並使用straight join而不是隱式聯接。 只是一個猜測，但這聽起來像是一個困惑的優化器。