タグ付けされた質問 「query-optimization」

このようなクエリを実行するより良い方法はありますか？ SELECT COUNT(*) FROM (SELECT DISTINCT DocumentId, DocumentSessionId FROM DocumentOutputItems) AS internalQuery この表の個別のアイテムの数を数える必要がありますが、個別のアイテムは2列以上です。 私のクエリは正常に機能しますが、1つのクエリのみを使用して（サブクエリを使用せずに）最終結果を取得できるかどうか疑問に思いました

212 sql  sql-server  performance  tsql  query-optimization 

私はMySQLデータベースでしばらくインデックスを使用していますが、それらについて適切に学習したことはありません。一般に、WHERE句を使用して検索または選択するフィールドにインデックスを付けますが、白黒のように見えない場合があります。 MySQLインデックスのベストプラクティスは何ですか？ 状況/ジレンマの例： テーブルに6つの列があり、それらのすべてが検索可能である場合、それらのすべてにインデックスを付けるか、どれにもインデックスを付けないか？ インデックス作成のパフォーマンスへの悪影響は何ですか？ サイトの一部から検索できるVARCHAR 2500列がある場合、それをインデックスに登録する必要がありますか？

208 mysql  indexing  query-optimization 

SQLチューニング関連のドキュメントを読んでいると、次のことがわかりました。 SELECT COUNT(*) ： 行数をカウントします。 多くの場合、レコードの存在を確認するために不適切に使用されます。 あるSELECT COUNT(*)本当に悪いですか？ レコードの存在を確認する適切な方法は何ですか？

207 sql  optimization  query-optimization 

JOINクエリは、いくつかのクエリよりも高速ですか？（メインクエリを実行してから、メインクエリの結果に基づいて他の多くのSELECTを実行します） それらを結合するとアプリケーションの設計が非常に複雑になるので、私は尋ねています より速い場合、だれがどれだけ大まかに概算できますか？1.5倍の場合は気にしませんが、10倍の場合はそうだと思います。

180 mysql  database  join  query-optimization 

ドキュメントを引用するには： インデックスを作成するとき、キーに関連付けられた番号はインデックスの方向を指定するため、常に1（昇順）または-1（降順）である必要があります。方向は、単一のキーインデックスやランダムアクセス検索では重要ではありませんが、複合インデックスで並べ替えや範囲クエリを実行する場合は重要です。 ただし、複合インデックスでインデックスの方向が重要である理由はわかりません。誰かがさらに説明（または例）を提供できますか？

114 mongodb  performance  sorting  indexing  query-optimization 

LIKEデータベース内の特定のテーブルに対するクエリに関して、応答時間にかなり大きな変動が見られます。200〜400ミリ秒以内に結果が得られる場合がありますが（非常に許容範囲内）、結果が返されるまでに30秒ほどかかる場合もあります。 LIKEクエリは非常に多くのリソースを必要とすることを理解していますが、応答時間にこのような大きな違いが生じる理由を理解していません。owner1フィールドにbtreeインデックスを作成しましたが、LIKEクエリに役立つとは思いません。誰かアイデアはありますか？ サンプルSQL： SELECT gid, owner1 FORM parcels WHERE owner1 ILIKE '%someones name%' LIMIT 10 私も試しました： SELECT gid, owner1 FROM parcels WHERE lower(owner1) LIKE lower('%someones name%') LIMIT 10 そして： SELECT gid, owner1 FROM parcels WHERE lower(owner1) LIKE lower('someones name%') LIMIT 10 同様の結果。 テーブルの行数：約95,000。

112 postgresql  indexing  pattern-matching  query-optimization  sql-like 

私は、time_stamp、usr_id、transaction_id、およびlives_remainingの列を持つレコードを含むPostgresテーブル（ "lives"と呼ばれます）を処理しています。各usr_idの最新のlives_remaining合計を取得するクエリが必要です 複数のユーザーがいる（個別のusr_id） time_stampは一意の識別子ではありません。ユーザーのイベント（テーブルの行ごとに1つ）が同じtime_stampで発生することがあります。 trans_idは、非常に狭い時間範囲でのみ一意です。時間の経過とともに繰り返します。 remaining_lives（特定のユーザーの場合）は、時間の経過とともに増加および減少する可能性があります 例： time_stamp | lives_remaining | usr_id | trans_id ----------------------------------------- 07:00 | 1 | 1 | 1 09:00 | 4 | 2 | 2 10:00 2 | 3 | ３ 10:00 1 | 2 | 4 11:00 | 4 | 1 | 5 11:00 | …

96 sql  postgresql  query-optimization  cbo  cost-based-optimizer