タグ付けされた質問 「index」

次の構造のSQLデータテーブルがあります。 CREATE TABLE Data( Id uniqueidentifier NOT NULL, Date datetime NOT NULL, Value decimal(20, 10) NULL, RV timestamp NOT NULL, CONSTRAINT PK_Data PRIMARY KEY CLUSTERED (Id, Date) ) 個別のIDの数は3000から50000の範囲です 。テーブルのサイズは10 億行を超えます。 1つのIDで、テーブルの5％までの数行をカバーできます。 このテーブルで最も実行されるクエリは次のとおりです。 SELECT Id, Date, Value, RV FROM Data WHERE Id = @Id AND Date Between @StartDate AND @StopDate …

8 sql-server  index  index-tuning 

データベースの各テーブルに最適なインデックスを作成したい。このプロセスを支援するクエリまたはSQL Serverのツールはありますか？

8 sql-server  database-design  sql-server-2008  sql-server-2008-r2  index 

過去数週間、私は古いFirebirdデータベースに対して激怒しています。このデータベースはさまざまな理由でひどいですが、私が気付いたことの1つは、すべてのテーブルのすべてのフィールドに2つのインデックスがあることです。それぞれに単一のセグメントがあり、1つはasc順番に、もう1つはdesc順番に。 同じインデックスセグメントを持つ2つのインデックスを有することに単一セグメントのインデックスのいずれかの利点があるが、1で-以外のすべてのテーブル内のすべてのフィールドのインデックスを持つのwtf'nessから、それは考えて私を得たdescと1でasc？何か得られることはありますか、または最新のDBMSは単純にascインデックスを使用し、最後から始めて、必要に応じて逆方向に動作しますか？

8 index  firebird 

私はパフォーマンスの理由でアクティブテーブルとアーカイブテーブルに分割し、直接フィールドマッピングを使用して、アーカイブプロセスを毎晩実行する大きなテーブル（数千から数億レコード）を持っています。 コード内のいくつかの場所で、アクティブテーブルとアーカイブテーブルを結合するクエリを実行する必要があります。ほぼ常に1つ以上のフィールド（両方のテーブルにインデックスを配置している）によってフィルター処理されます。便宜上、次のようなビューがあると理にかなっています。 create view vMyTable_Combined as select * from MyTable_Active union all select * from MyTable_Archive しかし、次のようなクエリを実行すると select * from vMyTable_Combined where IndexedField = @val でフィルタリングする前に、ActiveとStoreのすべてに対して結合を行う@valため、パフォーマンスが低下します。 ユニオン@valを作成する前に、ユニオンビューの2つのサブクエリを各フィルターで作成する賢い方法はありますか？ それとも、私が目指していることを達成するために提案する他のアプローチがあるかもしれません。つまり、インデックス付きフィールドによってフィルター処理されたユニオンレコードセットを取得する簡単で効率的な方法ですか。 編集：ここに実行計画があります（そして実際のテーブル名がここに表示されます）： 奇妙なことに、アクティブテーブルは実際には正しいインデックス（およびRID検索？）を使用していますが、アーカイブテーブルはテーブルスキャンを実行しています！

8 sql-server  index  view  union 

MongoDBに次の種類のデータ（実際のケースから少し簡略化）があります。 { "name":"some name", "attrs":[ {"n":"subject","v":"Some subject"}, {"n":"description","v":"Some great description"}, {"n":"comments","v":"Comments are here!"}, ] } attrs配列は動的属性のコンテナーです。つまり、どのような属性がそこに配置されるのかは、事前にわかりません。nは名前を表し、vは値を表します。 MongoDB In Actionブックでは、属性が完全に予測可能である場合に動的属性を持つためのソリューションとしてこれを説明しています。また、次のようにインデックスを作成できることも説明しています。 db.mycollection.ensureIndex({"attrs.n":1, "attrs.v":1}) クエリは次のように実行できます。 db.mycollection.find({attrs: {$elemMatch: {n: "subject", v: "Some subject"}}}) これをテストすると、パフォーマンスが非常に低下します。200万のドキュメントがあり、インデックスがないmycollectionでテストしたところ、パフォーマンスが向上したようです。 それで、問題は、このような動的属性設定にインデックスを付けて、良いパフォーマンスが得られるようにする方法があるのでしょうか？私の場合、「件名」や「説明」などのキーを用意してすべてにインデックスを付けることはできません...

8 index  mongodb 

MySQLで重複したインデックスを削除するのにはかなり時間がかかりました。そのため、私が待っていたときにそれについて検索し、MySQLがどのように処理し、インデックスを作成するかについて話している2006年のこの投稿を見つけました。ADDDROP テーブルTが4つのインデックス（ndx1、ndx2、ndx3、ndx4）を持つMySQLテーブルであり、「テーブルTをドロップインデックスndx3に変更」したい場合。ここでは、内部で何が起こるかを正確に示します。 1）MySQLはT.MYDを一時テーブル、つまりS.MYDとゼロバイトのS.MYIにコピーします。2）MySQLは「テーブルSを変更し、インデックスndx1（...）を追加します。3）MySQLは「テーブルSを変更し、インデックスndx2（...）; 4）MySQLはテーブルSを変更し、インデックスndx4（...）を追加します。5）MySQLはT.MYDを削除してT.MYIを削除します6）MySQLはS.MYDをT.MYDに名前変更し、S.MYIをT.MYIに名前変更します これはまだ本当ですか？彼のアドバイスはまだ有効ですか？ 同じMyISAMテーブルTに4つのインデックス（ndx1、ndx2、ndx3、ndx4）があり、「テーブルTドロップインデックスndx3を変更する」とします。代わりにこれを試してください： 1）TのようなテーブルT1を作成します。これにより、ndx1、ndx2、ndx3、およびndx4のインデックスを持つ空のテーブルT1が作成されます。2）テーブルT1ドロップインデックスndx3を変更します。これにより、空であるT1のインデックスndx3が削除されます。3）T1に挿入* Tから選択します。これにより、テーブルTにデータが読み込まれ、T1の3つすべてのインデックスが1つのパスで読み込まれます。4）ドロップテーブルテーブルT; 5）テーブルT1の名前をTに変更します。 大きなテーブルでのインデックスの追加と削除をどのように処理しますか？

8 mysql  performance  index  myisam 

IDENTITY型の列など、常に単調に増加する値のBツリーインデックスについて考えます。従来のBツリーの実装では、ノードがいっぱいになると常に50％/ 50％に分割され、（ほとんど）すべてのノードが50％だけいっぱいになるBツリーになります。 私は、Oracleが値が増加し続けるときを発見し、そのような場合にOracleが90％/ 10％の分割を実行することを知っています。そうすれば、（ほぼ）すべてのノードが90％満たされ、これらの非常に一般的なケースではるかに優れたページ使用率が得られます。 SQL Serverの同様の機能に関するドキュメントを見つけることができませんでした。ただし、N個のランダムな整数とN個の連続した整数をそれぞれインデックスに挿入する2つの実験を実行しました。前者のケースは後者をはるかに多くのページを使用しました。 SQL Serverは同様の機能を提供しますか？もしそうなら、あなたは私にこの機能に関するいくつかのドキュメントを教えてもらえますか？ 更新： 以下の実験では、リーフノードは分割されず、内部ノードは50％/ 50％に分割されているようです。これにより、増加するキーのBツリーは、ランダムキーよりもコンパクトになります。ただし、Oracleによる90％/ 10％アプローチはさらに優れており、実験で確認された動作を検証できる公式ドキュメントを探しています。

8 sql-server  fragmentation  index  page-splits