2017-05-14 16 views
0

queue_name,priorityおよびmessage_timestampの表を考慮してください。 SELECTのためにEXPLAINMySQL ORDER BY:SELECTおよびUPDATEの異なる説明

CREATE INDEX STATE_QUEUENAME_PRIORITY_TIMESTAMP ON 
     `queue_messages` (queue_name, state, priority, message_timestamp); 

:ここ

は、そのための化合物の指標である(!同じ WHEREORDER BY付き)UPDATE用のEXPLAIN Using where; Using index

EXPLAIN SELECT message_timestamp 
     from queue_messages 
     WHERE queue_name = 'folder' 
      AND state = 0 
     ORDER BY priority DESC, message_timestamp DESC 
       LIMIT 1; 

戻り値:

EXPLAIN UPDATE queue_messages 
     SET  state = 1 
     WHERE queue_name = 'folder' 
      AND state = 0 
     ORDER BY priority DESC, message_timestamp DESC 
       LIMIT 1; 
それは重大なパフォーマンスへの影響(50K行の90msののUPDATE対SELECTが20ms)を引き起こす

から

戻りUsing where; Using filesort

MariaDB(MySQL)がUPDATE文でfilesortを取り除くには、どうすればよいですか? updateについては

+0

インデックスのヒントを教えてください。https://dev.mysql.com/doc/refman/5.7/en/index-hints.html – RiggsFolly

+0

私は確かに分かりませんが、あなたは状態の一部を更新しています鍵はそうではないかもしれません。 –

+0

これは唯一のインデックスですか? –

答えて

0

、あなたは、2番目のインデックスが必要になります。

CREATE INDEX STATE_QUEUENAME_TIMESTAMP_2 ON `queue_messages` (queue_name, state, priority, message_timestamp); 

既存のインデックスがpriorityが含まれていないので、order byのために使用することはできません。

+0

大変申し訳ありませんが、間違ったインデックス宣言をコピーして貼り付けてしまいます。あなたは正しいです、私はすでに4つのフィールドすべてでインデックスを使用しています。 'STATE_QUEUENAME_PRIORITY_TIMESTAMP' –

+0

実際にそれが私が疑問に思っている理由です。SELECTクエリは完全にインデックスに一致しますが、絶対に同じWHERE/ORDER句でUPDATEします。 –

関連する問題