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

1組の列（両方int）で結合する3つの「大きな」テーブルがあります。 Table1には2億行まで Table2には約150万行あります Table3には約600万行あります 各テーブルには、上のクラスタ化インデックスを持っているKey1、Key2して、1つの以上の列。Key1カーディナリティが低く、非常にゆがんでいます。これは常にWHERE句で参照されます。条項でKey2言及されていないWHERE。各結合は多対多です。 問題は、カーディナリティの推定にあります。各結合の出力見積もりは、大きくなるのではなく小さくなります。これにより、実際の結果が数百万に相当する場合、最終的な推定値は数百になります。 CEを手掛かりにしてより良い推定を行う方法はありますか？ SELECT 1 FROM Table1 t1 JOIN Table2 t2 ON t1.Key1 = t2.Key1 AND t1.Key2 = t2.Key2 JOIN Table3 t3 ON t1.Key1 = t3.Key1 AND t1.Key2 = t3.Key2 WHERE t1.Key1 = 1; 私が試したソリューション： 上の複数列の統計情報を作成しKey1、Key2 大量のフィルターされた統計を作成するKey1（これはかなり役に立ちますが、ユーザーが作成した何千もの統計がデータベースに残ることになります。） マスクされた実行計画（悪いマスキングのため申し訳ありません） 私が見ている場合、結果には900万行があります。新しいCEは180行を推定します。従来のCEでは6100行と推定されています。 これは再現可能な例です： DROP TABLE IF EXISTS #Table1, #Table2, …

9 sql-server  join  sql-server-2016  many-to-many  cardinality-estimates 

注文表があります Column | Type | Modifiers ------------+-----------------------------+----------------------------------------------------- id | integer | not null default nextval('orders_id_seq'::regclass) client_id | integer | not null start_date | date | not null end_date | date | order_type | character varying | not null データにはclient_idの重複しない永続的な注文があり、時にはclient_idが一致する場合、start_dateの永続的な注文を上書きする一時的な注文があります。同じタイプの注文が重複しないようにするアプリケーションレベルの制約があります。 id | client_id | start_date | end_date | order_type ----+-----------+------------+------------+------------ 17 …

9 postgresql  join 

免責事項：データベースの内部に関する知識が不足していることをお許しください。ここに行く： データベースの定期的なクリーンアップジョブで大きなパフォーマンスの問題があるアプリケーション（私たちが作成したものではありません）を実行します。クエリは次のようになります。 delete from VARIABLE_SUBSTITUTION where BUILDRESULTSUMMARY_ID in ( select BUILDRESULTSUMMARY_ID from BUILDRESULTSUMMARY where BUILDRESULTSUMMARY.BUILD_KEY = "BAM-1"); わかりやすく、読みやすく、標準SQL。しかし、残念ながら非常に遅いです。クエリを説明すると、既存のインデックスVARIABLE_SUBSTITUTION.BUILDRESULTSUMMARY_IDが使用されていないことがわかります。 mysql> explain delete from VARIABLE_SUBSTITUTION where BUILDRESULTSUMMARY_ID in ( -> select BUILDRESULTSUMMARY_ID from BUILDRESULTSUMMARY -> where BUILDRESULTSUMMARY.BUILD_KEY = "BAM-1"); | id | select_type | table | type | possible_keys | key | …

9 mysql  index  join  delete  optimization 

これについてはさまざまな情報を聞きましたが、正規または専門家の意見を期待しています。 複数LEFT OUTER JOINのがあり、それぞれが最後のに依存している場合、それらをネストする方が良いですか？ 不自然な例では、JOINすることMyParentに依存JOINするMyChild： http://sqlfiddle.com/#!3/31022/5 SELECT {columns} FROM MyGrandChild AS gc LEFT OUTER JOIN MyChild AS c ON c.[Id] = gc.[ParentId] LEFT OUTER JOIN MyParent AS p ON p.[id] = c.[ParentId] http://sqlfiddle.com/#!3/31022/7と比較 SELECT {columns} FROM MyGrandChild AS gc LEFT OUTER JOIN ( MyChild AS c LEFT OUTER JOIN MyParent …

9 sql-server-2008-r2  performance  join 

「hierarchy_table」と「name_table」の2つのテーブルがあります。 階層テーブルには、複数の親と子を持つオブジェクトが含まれています。親と子はそれぞれIDで参照されます。 | object_id | parent_id_1 | parent_id_2 | child_id_1 | child_id_2 | ----------------------------------------------------------------------------- | 1234 | 9999 | 9567 | 5555 | 5556 | ----------------------------------------------------------------------------- hierarchy_tableの各オブジェクトIDは、name_tableにエントリを持っています。 | name_id | name | -------------------------- | 1234 | ABCD | -------------------------- | 9999 | ZYXW | -------------------------- | ... hierarchy_tableの各IDをname_tableに複数回結合して、すべての名前が入力された結果を得るにはどうすればよいですか？ このような： | …

9 postgresql  join 

PostgreSQL 9.2 私は違いを理解しようとしているHash Semi JoinだけにHash Join。 2つのクエリを次に示します。 私 EXPLAIN ANALYZE SELECT * FROM orders WHERE customerid IN (SELECT customerid FROM customers WHERE state='MD'); Hash Semi Join (cost=740.34..994.61 rows=249 width=30) (actual time=2.684..4.520 rows=120 loops=1) Hash Cond: (orders.customerid = customers.customerid) -> Seq Scan on orders (cost=0.00..220.00 rows=12000 width=30) (actual time=0.004..0.743 rows=12000 loops=1) …

8 postgresql  join  hashing 

table1とtable2の2つのテーブルがあります。両方のテーブルを結合して階層的な出力が必要です。 Table1には3つのカテゴリCAT1、CAT2、およびCAT3が含まれ、1つの外部キー、つまりF_IDがもう1つのテーブルtable2の主キーであり、もう1つの列、つまりVALが含まれています。 TABLE 1 ----------------- CAT1 CAT2 CAT3 F_ID A a aa 1 A a ab 2 A b ba 3 A b bb 4 B c ca 5 B c cb 6 B d da 7 TABLE 2 ------------------- F_ID VAL 1 4 2 6 3 4 4 1 …

8 oracle  join  oracle-11g 

MS Access 2013で食品購入/請求システムを使用していて、個々の食品の最新の購入価格を返すSQLクエリを作成しようとしています。 ここに私が作業しているテーブルの図があります： SQLについての私の理解は非常に基本的です。次の（正しくない）クエリを試してみました。（DISTINCT演算子のため）アイテムごとに1つのレコードのみが返され、最新の購入のみが返されることを期待しています（ORDER BY [Invoice Date] DESC） SELECT DISTINCT ([Food items].Item), [Food items].Item, [Food purchase data].[Price per unit], [Food purchase data].[Purchase unit], Invoices.[Invoice Date] FROM Invoices INNER JOIN ([Food items] INNER JOIN [Food purchase data] ON [Food items].ID = [Food purchase data].[Food item ID]) ON Invoices.ID = [Food …

8 join  ms-access  date  sorting  distinct 

SQLサーバーに次のようなテーブルがあります。 Id |Version |Name |date |fieldA |fieldB ..|fieldZ 1 |1 |Foo |20120101|23 | ..|25334123 2 |2 |Foo |20120101|23 |NULL ..|NULL 3 |2 |Bar |20120303|24 |123......|NULL 4 |2 |Bee |20120303|34 |-34......|NULL 入力データとバージョン番号を取得するdiffのストアドプロシージャに取り組んでいます。入力データには、名前からfieldZまでの列があります。ほとんどのフィールド列はNULLであることが期待されています。つまり、通常、各行には最初のいくつかのフィールドのデータのみが含まれ、残りはNULLです。名前、日付、およびバージョンは、テーブルに対する一意の制約を形成します。 特定のバージョンについて、このテーブルに関して入力されたデータを比較する必要があります。各行を比較する必要があります。行は名前、日付、バージョンで識別され、フィールドの列の値を変更すると、比較結果に表示されるようになります。 更新：すべてのフィールドが10進数である必要はありません。それらのいくつかはnvarcharである可能性があります。タイプを変換せずにdiffを実行したいのですが、diff出力はすべてをnvarcharに変換できるため、それは表示目的でのみ使用されるためです。 入力が次のようであり、要求されたバージョンが2であるとします。 Name |date |fieldA |fieldB|..|fieldZ Foo |20120101|25 |NULL |.. |NULL Foo |20120102|26 |27 |.. |NULL Bar |20120303|24 …

8 sql-server  join  union  cross-apply 

設定 データウェアハウスでは、ファクトテーブルを20ディメンションに結合しています。ファクトテーブルには、3,200万行と30列があります。これは一時的なステージングテーブルなので、他のユーザーがテーブルを読み書きする必要はありません。ベーステーブルから10列、それぞれのディメンションから20列を選択します。ディメンションテーブルは小さい（3〜15.000行）。結合されるフィールドは、整数とnvarcharの両方です。SELECT ... INTOステートメントを使用しています。テーブルにインデックスはありません。 このクエリの実行速度は遅すぎるため、役に立ちません。 試してみたソリューション クエリの処理に時間がかかりすぎるため、次の解決策を試しました。 20の結合を5つのテーブルの4つの結合に分割します。ただし、クエリのパフォーマンスは低いままです。 外部キー列にインデックスを配置します。時間の大幅な短縮はありません。 結合条件のフィールドが整数であることを確認してください。パフォーマンスが25％向上しました。私が探しているものではありません。 select intoではなく、insert intoステートメントを使用します。データベースは単純復旧モードですが、ログファイルの増大によりパフォーマンスが低下します。 これらの調査結果から、コストの89％が表の挿入にあるという実際の実行計画を含めることにしました。その他のコストは、ファクトテーブルの8％のテーブルスキャンと、内部結合のハッシュマッチングの2％です。 ご質問 遅いテーブル挿入の考えられる理由は何ですか？ 実行計画なしでこのボトルネックを特定する方法は何ですか？ テーブル挿入のコストを削減するためにどのようなアクションを実行できますか？

8 sql-server  optimization  join  insert 

世帯の詳細が記載されたテーブルと、その世帯に関連するすべての人物の詳細が記載されたテーブルがあります。世帯テーブルには、2つの列を使用して定義された主キーがあります- [tempId,n]。personテーブルには、3つの列を使用して定義された主キーがあります。[tempId,n,sporder] 主キーのクラスター化インデックスによって指示された並べ替えを使用して、各世帯[HHID]および各人の[PERID]レコードに一意のIDを生成しました（以下のスニペットはPERIDを生成するためのものです）： ALTER TABLE dbo.persons ADD PERID INT IDENTITY CONSTRAINT [UQ dbo.persons HHID] UNIQUE; 今、私の次のステップは、各人を対応する世帯に関連付けることです。マップ[PERID]には[HHID]。2つのテーブル間の横断歩道は、2つの列に基づいています[tempId,n]。このため、次の内部結合ステートメントがあります。 UPDATE t1 SET t1.HHID = t2.HHID FROM dbo.persons AS t1 INNER JOIN dbo.households AS t2 ON t1.tempId = t2.tempId AND t1.n = t2.n; 私は合計で1928783世帯の記録と5239842人の記録を持っています。現在、実行時間は非常に長くなっています。 さて、私の質問： このクエリをさらに最適化することは可能ですか？より一般的には、結合クエリを最適化するための経験則は何ですか？ より良い実行時間で私が望む結果を達成できる別のクエリ構造はありますか？ 私がしている実行計画アップロード SQLPerformance.comに全体のスクリプトは、SQL Server 2008によって生成されたが

8 sql-server  optimization  join  execution-plan 

私の仕事では、「コンピューターの処理能力のために」最初の正規形（列全体でグループを繰り返す、空/ null値を使用）に何度も違反するように依頼されました。簡単に言えば、「学生」テーブルには、私の提案ではなく、少なくとも8つの空のフィールド（たとえば、telephones：telephone1、telephone2、telephone3 ...）が必要です。電話番号（およびその他のメタデータ）を保持する「telephone」テーブル外部キーは学生ID番号です。私の上司は、リレーションを使用する代わりに、「CPUサイクルが少なく、それがWebプラットフォームで問題になる」ため、それらをそのように保存する方が良いと述べています。最悪の場合、それはごくわずかです。 その例では、リレーションの使用（テーブルが中規模のWebアプリケーションの多くのレコードで満たされていると想定）は、そのようなテーブルスキーマを使用するよりも著しく遅いですか？

8 mysql  database-recommendation  join  rdbms 

結合をしばらく使用したいと思っていましたが、出力の視覚化に問題があるため、どのように使用するかわかります。 2つのテーブルがあるとします。 CREATE TABLE Cities ( id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, city tinyblob ); CREATE TABLE Users ( id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, username TINYBLOB, city INT UNSIGNED, FOREIGN KEY (city) REFERENCES Cities (id) ); アプリケーションがSQLクエリを実行してユーザーのプロファイルデータを取得する場合、結合を使用してユーザーのレコードに関連付けられた都市を取得するにはどうすればよいですか。また、出力されたレコードはどのように表示されますか？

8 mysql  join  foreign-key 

2つLEFT JOINのie を使用する SELECT <some columns> FROM Table1 AS t1 LEFT JOIN Table2 AS t2 ON <condition1> LEFT JOIN Table2 AS t3 ON <condition2> これANDはシングルで使用するのと同じLEFT JOINですか？すなわち SELECT <some columns> FROM Table1 AS t1 LEFT JOIN Table2 AS t2 ON <condition1> AND <condition2> 両方が同じか、または一般的に異なりますか？

7 sql-server-2012  join