Question

下午好。我希望你能为我提供的MYSQL优化问题提供一些指导。首先，一些系统规范。

MYSQL版本：5.2.47 CE
WampServer v 2.2

电脑：

三星QX410（笔记本电脑）
Windows 7
Intel i5（2.67 Ghz）
4GB RAM

我有两张桌子：

“Delta_Shares”包含股票交易数据，并包含两列注释。 “Ticker”是Varchar（45），“Date_Filed”是Date。该表有大约300万行（都是唯一的）。我在这个表上有一个索引“DeltaSharesTickerDateFiled”（Ticker，Date_Filed）。
“Stock_Data”包含两列注释。 “Ticker”是Varchar（45），“Value_Date”是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

用表描述更新。 Stock_Data表：

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万行= .93千兆字节

因此，如果此过程是您机器中唯一发生的事情，那么我不会将内存视为一个问题，因为您可以轻松地同时满足查询在内存中使用的两个表中的所有数据。但如果还有其他事情发生，则可能是一个因素。

Answer 2

在两个表上尝试analyse并使用straight join而不是隐式连接。只是一个猜测，但它听起来像一个困惑的优化者。

MYSQL查询需要4个小时

2 个答案: