1

こんにちは。私が抱えている MYSQL の最適化の問題について、何らかの方向性を示していただけることを願って、私はあなたのところに来ています。まず、いくつかのシステム仕様。

  • MYSQL バージョン: 5.2.47 CE
  • ワンプサーバー v 2.2

コンピューター：

  • サムスン QX410 (ラップトップ)
  • ウィンドウズ7
  • インテル i5 (2.67 GHz)
  • 4GBのRAM

私は2つのテーブルを持っています:

  1. 「Delta_Shares」には株式取引データが含まれており、注目すべき 2 つの列が含まれています。「ティッカー」は Varchar(45)、「Date_Filed」は日付です。このテーブルには約 300 万行 (すべて一意) があります。このテーブルには、(Ticker, Date_Filed) の「DeltaSharesTickerDateFiled」というインデックスがあります。

  2. 「Stock_Data」には注目すべき 2 つの列が含まれています。「Ticker」は Varchar(45)、「Value_Date」は日付です。このテーブルには約 1,900 万行 (すべて一意) があります。このテーブルには、(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
4

2 に答える 2

1

ボトルネックがどこにあるかを確認するために作成できるベンチマークがいくつかあります。たとえば、フィールドを定数値に更新してみて、どれくらい時間がかかるかを確認してください (当然、これを行うにはデータベースのコピーを作成する必要があります)。次に、更新しない選択クエリを試しますが、更新する値と更新する値を選択するだけです。

このようなベンチマークは通常、最適化のために時間を無駄にしているかどうか、または改善の余地がたくさんあるかどうかを教えてくれます。

メモリに関しては、ここにあなたが見ているものの大まかな考えがあります：

varchar フィールドは 2 バイトに実際の長さを加えたもので、datetime フィールドは 8 バイトです。それでは、Stock_Data テーブルの varchar フィールドが平均で約 42 バイトであることを非常に大雑把に推測してみましょう。行ごとに最大 50 バイトを追加する datetime フィールドを使用します。

50 バイト x 2000 万行 = 0.93 ギガバイト

したがって、このプロセスがマシンで行われている唯一のことである場合、クエリが一度にメモリ内で処理している両方のテーブルのすべてのデータを簡単に収めることができるため、メモリが問題になるとは思いません。しかし、他のことが起こっている場合は、それが要因である可能性があります.

于 2013-07-23T02:45:43.560 に答える
-1

analyse両方のテーブルで試してstraight join、暗黙的な結合の代わりに使用してください。単なる推測ですが、混乱したオプティマイザーのように聞こえます。

于 2013-12-09T09:37:56.387 に答える