2

to_days(created_at) の範囲でパーティション分割されたデータベースがあります。

パーティションは毎月 (p1 - p50) で、末尾に pmax キャッチオールがあります。以下の例では、パーティション p45 のみがヒットすると予想しています。

Explain partitions select * from units where created_at > "2013-01-01 00:00:00" and NOW() を実行するとき

パーティション列の下に p1,p45 が表示されます

これは 5.1 と 5.5 の両方で発生します。

オプティマイザーが不等式チェックのために最初のパーティションを含めるのはなぜですか?

4

1 に答える 1

4

あなたはずっと前にこれを尋ねましたが、私もこの問題に遭遇し、ここで回避策を見つけました:

http://datacharmer.blogspot.com/2010/05/two-quick-performance-tips-with-mysql.html

... 基本的に、(0) より小さい値を含む最初のパーティションを作成する必要があります。これは常に空になります。MySQL クエリ オプティマイザはこの最初のパーティションを引き続き含めますが、少なくともリソースを集中的に使用するスキャンを実行するべきではありません。

更新: 元の回答にリンクされている URL の短い要約を次に示します。

公式の MySQL バグトラッカーは、この動作を機能として認めています。

バグの説明:

BETWEEN 句の範囲に関係なく、TO_DAYS 関数を使用して RANGE でパーティション化されたテーブルには、プルーニング時にテーブルの最初のパーティションが常に含まれます。

応答：

TO_DAYS() は無効な日付に対して NULL を返すため、これはバグではありません。最初のパーティションも (すべて NULL 値を保持しているため) 範囲をスキャンする必要があります。

...

パフォーマンスの回避策は、特定のパーティションを作成してすべての NULL 値 (「... LESS THAN (0)」など) を保持することです。これにより、すべての不正な日付も検出されます。

于 2014-09-17T22:42:05.350 に答える