5

220,000 行の比較的大きな mysql (myisam) テーブルを最適化しようとしています。テーブル自体はそれほど大きくなく、サイズは約 23.5MB です。それで、本当の問題は何ですか？- 次のようなクエリを取得しました:

SELECT * FROM table WHERE DATE_FORMAT(date_field, '%m%d') = '1128' LIMIT 10

date_field にインデックスを設定しようとしましたが、 EXPLAIN はインデックスがまったく使用されていないことを示しています... DATE_FORMAT() のため、これはそれほど奇妙ではないと思います。そのため、日付を「%m%d」として保持する別の列を追加し、それにインデックスを付ける予定です。これをしたくない唯一の理由は、データの重複のためです。
ところで、私は date_field を生年月日フィールドとして使用していますが、date_field は常に %Y-%m-%d または単に %m%d として必要であると確信しています。

上記のクエリを最適化する方法について、より良い提案はありますか? 前もって感謝します ！！！

いくつかの情報:

MySQL バージョン: 5.0.51b-log
OS: slackware 12.1
CPU: Pentium III (Coppermine) at 996.783Mhz
RAM: 512MB DDR
HDD: 80GB SATA

PS日付を %m%d として保持する別の列を追加しようとしました。結果は非常に良いですが、私はまだこのアプローチが好きではありません. 私はより多くの提案を待っています！

4

1 に答える 1

2

そこでのクエリのように、常に年にワイルドカードが必要な場合、mysqlが日付/日時フィールドでインデックスを使用できるかどうかはわかりません

これらが日付のみの場合は、time_dimension テーブルを作成して、次の数年間のカレンダーを事前に入力することができます。必要な場合に備えて、それを行うためのストアド プロシージャがあります。

create table time_dimension (
 dbdate date primary key,
 year int NOT NULL,
 month int  NOT NULL , 
 day int NOT NULL,
 KEY(year),
 KEY(month);
 KEY(day);
);

ビッグ データ テーブルをこの比較的小さなテーブルに結合し、そのフィールドでフィルター処理します。例えば

SELECT * FROM data_table d 
  inner join time_dimension t 
    on d.date_field=t.dbdate 
where t.day=28 and t.month=11 LIMIT 10

これは、小さな time_dimension でのフィルタリングを活用し、date_field = dbdate での結合は通常、インデックスを使用します。

于 2009-08-19T18:58:31.363 に答える