3

2.000.000 を超えるレコードを含むテーブルの SQL クエリの応答時間を最適化するための最適なソリューションを知りたい

解決策として、SQL ビューを作成して仮想テーブルを作成することを考えました (実際、このアプリケーションのデータは季節に基づいているため、今年作成された行の早い段階で mysql を検索する方が好きです)。

より良い解決策または推奨事項はありますか?

例: 家賃 12 のすべての家賃ラインを検索するには

before => select * fromrent_lines 場所rent_id = 12

今=>ビューを作成しました

CREATE VIEW v_rent_lines
AS SELECT rent_id, category_id, customer_id, amount ..
Where rent_lines FROM created_at > = (select starts_on from seasons where current = true)

select * from v_rent_lines Where rent_id = 12

ノート：

  • データベース エンジンが使用されている InnoDB

  • インデックス テーブルを追加しました (index_rent_lines_on_rent_id、index_rent_lines_on_category_id、index_rent_lines_on_customer_id)

  • 家賃には多くのrent_linesがあります

4

1 に答える 1

1

この場合、ビューは実際には何の役にも立ちません。ビューは主に、開発者として、詳細を常に繰り返すのではなく、名前でより複雑なクエリを参照できるようにすることで役立ちます。それらは、mysqlをそれほど助けません。

あなたにはたくさんの選択肢があります。

  1. まだ行っていない場合は、rent_idがインデックス内の唯一のフィールド、またはインデックス内の最初のフィールドのいずれかであるインデックスがあることを確認してください。例えば：

    create index rent_id_idx on rent_lines (rent_id)

  2. mysqlのパーティショニングシステムとrent_idでのパーティショニングの使用を検討できます

  3. 次のような操作を行うことで、カーディナリティが低くなるインデックスを作成できます。

    alter table rent_lines add rent_id_bucket smallint unsigned not null after rent_id;
update rent_lines set rent_id_bucket = rent_id>>16;
alter table rent_lines add key rent_id_bucket_idx(rent_id_bucket);

    これにより、次のようなクエリを実行できます。

    select * from rent_lines where rent_id_bucket = 16>>16 and rent_id=16
于 2012-09-07T13:47:43.300 に答える