0

このクエリに問題があります。このクエリの複雑さは良くありません。このクエリを長い間使用しており、現在、このデータベースにはこの方法で選択する行が多数あります。すべてのインデックスが適切に追加されます。これがこのソリューションのボトルネックであるため、日付比較によってこのクエリを最適化する他の方法を検索します。

SELECT (...) FROM table 
WHERE (YEAR(row_add_date) * 10000 + 
       MONTH(row_add_date) * 100 + 
       DAYOFMONTH(row_add_date)) >= (var_0 * 10000 + var_1 * 100 + var_2) and
      (YEAR(row_add_date) * 10000 + 
       MONTH(row_add_date) * 100 + 
       DAYOFMONTH(row_add_date)) <= (var_3 * 10000 + var_4 * 100 + var_5)

誰でも私を助けることができますか？ご挨拶

4

3 に答える 3

2

なんでそんなにデートをバラバラにするの？行ごとの関数はうまくスケーリングしません。最後の日付セクション全体を次のように置き換えることができるように思えます。

where row_add_date = '2010-10-27'

範囲が必要な場合でも、日付をそのまま使用する方が適切です。

変数を使用していることを示す編集に基づいて、条件の右側で計算を行う必要があります。これは、クエリの開始前に1 回実行されるためです。あなたが持っているものでは、左側の計算は行ごとに1回行われ、明らかにパフォーマンスキラーです.

于 2010-10-27T14:50:14.803 に答える
2

組み込みの mysql 日付比較を使用することをお勧めします。

row_add_date <= '20101027' and row_add_date >= '20101027'

ただし、これはそもそも奇妙なテストであることに注意してください。次のように、日付が 10 月 27 日に等しいことをテストしているだけではありません。

row_add_date = '20101027'
于 2010-10-27T14:51:04.147 に答える
0

row_add_date は type であると推測しdatetimeます。その場合は、20101027 を に変換しdatetime、列をそれと比較する必要があります。

言い換えると：

row_add_date >= firstDateTime and row_add_date <= secondDateTime
于 2010-10-27T14:58:30.347 に答える