たくさんの行（100億以上）があると予想されるテーブルのテーブルデザインを実験しています。すぐに頭に浮かぶいくつかのこと：

• 私が「トール」テーブルアプローチと呼んでいるものでは、各行には、このタイプに対応する値とともに、約25の「タイプ」の1つがあります。これを、各タイプの値のNULL可能列を含む単一の行を持つ「ワイドアプローチ」に変換する必要がありますか？これは、保守性の観点からは優れたアプローチではありませんが（「タイプ」を追加する必要がある場合はどうなりますか）、サイズを二次的に考慮して、パフォーマンスに関心があります。
• 行には日付のタイムスタンプがあります（分だけで十分なので、おそらくsmalldatetimeです）。表では、日時自体ではなく、日時に整数表現を使用する方がよいと聞いています。この日時は、クエリで頻繁に使用されることを期待しています（おそらく、クラスター化インデックスの一部である場合でも）。

私の主な関心事は、クエリのパフォーマンス、次にサイズの順です。大量のデータがテーブルにダンプされますが、変更または大きくなることはありません（おそらく、毎日または毎月の更新ですが、多くの更新ではなく、トランザクションと見なすものもありません）。

複数のフィールドを持つDBがあります

..そして〜15万行。

'search_string%'これは辞書なので、 LIKE を使用してマスク付きの単語を検索しています。以前は問題なく動作し、一致する行を見つけるのに 15 ミリ秒かかりました。テーブルにはフィールドのインデックスがあります'word'。最近、テーブル (スコープ外のテーブルのいくつかのフィールド) を変更しましたが、何かが発生しました。クエリの実行に 400 ミリ秒かかっているため、現在はインデックスを使用できないことを理解しています。like の代わりに = を使用した単純なクエリは、10ms の結果を示します。誰かがここで何が起こっているのか知っていますか?

Solr 3.4を実行しており、90,000ドキュメント程度の比較的小さなインデックスがあります。これらのドキュメントは複数の論理ソースに分割されているため、各検索には特定のソースに適用されるフィルタークエリがあります。例：

ここsourceで、は古典的な文字列フィールドです。edismaxを使用しており、デフォルトの検索フィールドテキストがあります。

現在q=*、実行にかかる時間は。よりも平均20倍長くなっていますq=*:*。違いは非常に顕著で、 100ミリ秒*:*と*最大3500ミリ秒かかります。ドキュメントセット内の一般的な単語（すべてのドキュメントのほぼ50％に一致）を検索すると、200ミリ秒未満の結果が返されます。

debugQueryがオンになっているクエリを見ると、*がに解析され、がに解析されているDisjunctionMaxQuery((text:*))こと*:*がわかりMatchAllDocsQuery(*:*)ます。これは理にかなっていますが、それでもこの規模の減速（ドキュメントの50％に一致するものよりも2000％の減速）を説明しているとは思えません。

これを引き起こしている可能性がありますか？微調整できるものはありますか？

に最適化

クエリの応答時間が30秒から13秒に改善されました。

• SQLユニオン=30秒
• sql left join=13秒

ただし、クエリプランを確認すると、SQLユニオンのI/Oコストは低くなります。以下を参照してください。

• sql union =ステートメント1（1行目）の推定I / Oコストの合計：6277566。
• sql left join =ステートメント1（1行目）の推定I / Oコストの合計：10481124。

私はSybase12.5ASEを使用しており、クエリプランはDBArtisan8.5からのものでした。クエリプラン全体をアップロードする必要がある場合はお知らせください。私はまだクエリプランに精通していませんが、あちこちでSQLの最適化を行っています。通常は、時間の改善に基づいています。また、結果セットが両方のクエリで同じであることを確認しました（27949行）。また、テーブル名をマスクして簡略化しました。

私の質問は、SQLの左結合はより高速ですが、より多くのリソースを消費することを意味しますか？もしそうなら、私はまだより速い選択肢を選ぶべきですか？

私は次のデータベーススキーマを持っています：

すべてのカテゴリ、そのコースのチューター、およびそのコースのサブスクライバーの数を含むコースを取得するには、1つのSQLを作成する必要があります。これは1つのクエリで実行できますか？これは、ストアドプロシージャを使用して実行する必要がありますか？

したがって、特定のエンティティのインスタンスを ID ごとに取得しています。

これにより、ID ごとに SQL クエリが生成されるため、これを 1 回で実行する必要があると思いましたが、クエリを実行する以外に、1 回の呼び出しで複数のエンティティを取得する方法が見つかりませんでした。だから私はクエリを書きました

ただし、第 2 レベルのキャッシュを有効にしても、古いメソッドが第 2 レベルのキャッシュからオブジェクトを返すことができるというわけではありません (以前に要求されていた場合) が、クエリは常にデータベースに送信されます。

これを行う正しい方法は何ですか？

PRIMARY KEY（a、b）を持つテーブルから複合インデックスで複数のレコードを取得しようとしています

問題は、I FORCE INDEX（）を使用しても、MySQLがインデックスを使用していないことPRIMARYです。
EXPLAIN SELECTは、nullのpossible_keysを示します。

なぜpossible_keysがないのですか？

複合キーで複数の行を取得するための最良の方法は何ですか。

• ORを使用
• UNIONALLを使用する
• WHERE（）IN（（）、（））を使用する

PSクエリは結果によって次のようになります

ありがとう

アップデート

これを聞くのは時期尚早だったと思います。さらにいくつかのテストを行った後、パフォーマンスが向上していないことがわかりました。さらにいくつかのテストを実行し、ここに更新を投稿します。それまでは、わざわざこれに答えないでください。

こんなお問い合わせがありました…

このクエリは、かなりのデータ セットに対して実行するのに非常に時間がかかります。また、一時テーブルの Id 列に CLUSTERED インデックスを追加しました。これにより、パフォーマンスがいくらか向上しましたが、それでも完了しませんでした。

このクエリをこれに置き換えました...

これは数秒で完了しました。誰かがここで何が起こったのか説明できますか?

更新: 両方のクエリは同じだと思いました。これが必要です。

BusinessObject_Table has following Ids: 1, 2, 3

#BusinessObject_Table has: 3, 4, 5

TempTable has rows whose Field_A values are: 1, 2, 3, 4, 6

クエリの結果は次のようになります: 6 (上記のクエリの変更に注意してください)

クエリプランを取得して、ここに投稿しようとします。

特定のVARCHAR列に数値（数値に変換可能）がある行の数を取得したいMySqlテーブルがあります。現在、このフィールドで簡単なREGEXPチェックを行っています。このテーブルは非常に大きいため、REGEXPへの一連のインデックスをできるだけ少ない行で使用しています。

ただし、このVARCHAR列にもインデックスが付けられます。さらに少ない行をスキャンするために利用できるMySqlインデックス作成アルゴリズムの巧妙なハックはありますか？：-/これはInnoDBテーブルです。