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

クレイグ・フリードマンのブログ「ネストされたループ結合」では、ネストされたループ結合が右外部結合をサポートできない理由を説明しています。 問題は、内部テーブルを複数回（外部結合の行ごとに1回）スキャンすることです。これらの複数のスキャン中に、同じ内部行に複数回遭遇する可能性があります。特定の内側の行が結合していない、または結合しないと結論できるのはどの時点ですか？ 誰かがこれを本当にシンプルで教育的な方法で説明してくれませんか？ それは、ループが外側のテーブル（R1）で始まり、内側のテーブル（）をスキャンすることを意味しR2ますか？ とR1結合しない値については、結果セットが（）になるようにR2aに置き換える必要があることを理解しています。参加しない場合に値を返すことは、私にとって不可能であるように思われます。理由は、返す値がわからないためです。しかし、それはそれが説明される方法ではありません。またはそれは？NULLNULL, R2R2R1R2 SQL Serverは、実際の最適化でない（そして多くの場合、置き換え）RIGHT JOINでLEFT JOIN、しかし問題は、それはだ理由を説明することで、技術的には不可能NESTED LOOPS JOINに使用する/サポートRIGHT JOINロジック。

11 sql-server  join  database-internals 

2つのテーブルがあります。最初のテーブルには、CMS内のすべての記事/ブログ投稿が含まれています。これらの記事の一部は雑誌にも掲載される場合があります。その場合、それらは雑誌固有の情報を含む別のテーブルと外部キーの関係を持っています。 以下は、これらの2つのテーブルの作成テーブル構文の簡略化されたバージョンで、いくつかの重要でない行が削除されています。 CREATE TABLE `base_article` ( `id` int(11) NOT NULL AUTO_INCREMENT, `date_published` datetime DEFAULT NULL, `title` varchar(255) NOT NULL, `description` text, `content` longtext, `is_published` int(11) NOT NULL DEFAULT '0', PRIMARY KEY (`id`), KEY `base_article_date_published` (`date_published`), KEY `base_article_is_published` (`is_published`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; CREATE TABLE `mag_article` ( `basearticle_ptr_id` int(11) NOT NULL, …

11 mysql  performance  index  join  order-by 

tempdbイベントへの流出（遅いクエリの原因）が発生すると、特定の結合で行の見積もりがずれることがよくあります。マージイベントとハッシュ結合で流出イベントが発生し、ランタイムが3倍から10倍に増えることがよくあります。この質問は、流出事故の可能性を減らすことを前提として、行の見積もりを改善する方法に関係しています。 行の実際の数40k。 このクエリの場合、プランは不適切な行の見積もり（11.3行）を示しています。 select Value from Oav.ValueArray where ObjectId = (select convert(bigint, Value) NodeId from Oav.ValueArray where PropertyId = 3331 and ObjectId = 3540233 and Sequence = 2) and PropertyId = 2840 option (recompile); このクエリの場合、プランは適切な行推定（56k行）を示しています。 declare @a bigint = (select convert(bigint, Value) NodeId from Oav.ValueArray where PropertyId = 3331 and …

11 sql-server  optimization  join 

私には2つのスタッフリストがあります。 List A: StaffID Supervisor ==================== 0001234 NULL 0001235 0001234 0001237 0001234 0001239 0001237 そして List B: StaffID Supervisor ==================== 0001234 NULL 0001235 0001234 0001238 0001235 0001239 0001235 そして、私は次の出力が必要です： StaffID SupervisorA SupervisorB =================================== 0001234 NULL NULL 0001235 0001234 0001234 0001237 0001234 NULL 0001238 NULL 0001235 0001239 0001237 0001235 リストAとリストBのスタッフIDが1つの繰り返しのないリストにマージされ、2つのリスト間で一致しない可能性がある2つの監督者の詳細がマージされていることに注意してください。 クエリは優れている必要はありません。各リストに最大8000件のレコードがあり、うまく実行できます。その後、必要に応じてExcelのマイナーな操作を行ってよかったです。 …

11 query  join  ms-access 

外部キーを定義したときに、エンジンがこの情報を使用して正しいJOIN式を自動的に把握できず、代わりに同じ句を再入力する必要があるのは不思議に思えます。既存の外部キーを検査するデータベース、ある種の研究プロジェクトはありますか？

11 database-recommendation  feature-comparison  join  foreign-key 

複雑な問題に取り組んでいますが、この問題を簡単に説明します。 2つのテーブルがあります A [ID, column1, column2, column3] B [ID, column1, column2, column3, column4] そして、私は3番目を更新したいです： C [ID, column1, column2,column3] このクエリを使用して別の3番目のテーブルを更新しています。 UPDATE C set column1=t.firstTab, column2=t.secondTab, column3=t.thirdTab from (select A.column1 as firstTab, B.column2 as secTab, (A.column1 + B.column2) thirdTab from A, B limit 1; ) as t ; 私は得ました： UPDATE 0 このクエリを実行すると： …

11 postgresql  join  update 

私は20Mの行のテーブルを有し、各行は3つの列を有している：time、id、およびvalue。それぞれについてidとtime、そこにあるvalue状態のため。time特定の特定の特定のリードとラグの値を知りたいid。 これを達成するために2つの方法を使用しました。1つの方法は結合を使用し、もう1つの方法は、クラスター化インデックスがオンtimeおよびのウィンドウ関数lead / lagを使用することidです。 これら2つの方法のパフォーマンスを実行時間で比較しました。結合メソッドは16.3秒かかり、ウィンドウ関数メソッドは20秒かかります（インデックスの作成時間は含まれません）。結合メソッドがブルートフォースであるときにウィンドウ関数が進んでいるように見えるので、これは私を驚かせました。 2つのメソッドのコードは次のとおりです。 インデックスを作成 create clustered index id_time on tab1 (id,time) 結合方法 select a1.id,a1.time a1.value as value, b1.value as value_lag, c1.value as value_lead into tab2 from tab1 a1 left join tab1 b1 on a1.id = b1.id and a1.time-1= b1.time left join tab1 c1 on a1.id = c1.id …

11 sql-server  query-performance  join  sql-server-2016  window-functions 

以下について理解したい。 合計と順序付けによるグループと5つのテーブルの結合を例に挙げると、複雑なクエリがあるとします。 余談せるなど、クエリ自体例えばインデックスに任意の最適化を 使用して、任意の大幅なパフォーマンス上の利点はありますかLIMIT？LIMITを適用する前にすべてのクエリ（および結果）を処理する必要があると思います。そのため、LIMITを使用して結果のサブセットを取得すると、大幅に改善されますか？

11 mysql  performance  join 

以下は、クエリストアで発生するパフォーマンスの問題の簡略化です。 CREATE TABLE #tears ( plan_id bigint NOT NULL ); INSERT #tears (plan_id) VALUES (1); SELECT T.plan_id FROM #tears AS T LEFT JOIN sys.query_store_plan AS QSP ON QSP.plan_id = T.plan_id; plan_id列は、主キーとして文書化されているsys.query_store_planが、実行計画は使用されません撤廃への参加が期待されるように： DMVから投影される属性はありません。 DMV主キーplan_idは一時テーブルの行を複製できません A LEFT JOINが使用されているため、から行をT削除できません。 実行計画 これはなぜですか、ここで参加の削除を取得するにはどうすればよいですか？

10 sql-server  query-performance  join  execution-plan  query-store 

それらすべてが同じ結果を提供する場合、どの結合がより良いパフォーマンスを発揮しますか？たとえば、2つのテーブルemployees(emp_id,name, address, designation, age, sex)とがありwork_log(emp_id,date,hours_wored)ます。いくつかの具体的な結果を得るために、両方のinner joinとleft join同じ結果になります。しかし、私はまだこの疑問だけに限定されない疑問をいくつか抱えています。 同じ結合の場合、同じ結果値の場合にどちらが優先されるのでしょうか。 結合を適用するときに考慮しなければならない他の要素は何ですか？ 内部結合とクロス結合の間に関係はありますか？

10 mysql  performance  query-performance  join 

以前は完全外部結合を使用して希望の結果を得ていましたが、単純な結合を実現できないため、概念を完全に理解できていない可能性があります。 それぞれ2つのフィールドを持つ2つのテーブル（t1とt2と呼びます）があります。 t1 Policy_Number Premium 101 15 102 7 103 10 108 25 111 3 t2 Policy_Number Loss 101 5 103 9 107 20 私がやろうとしていることは、両方のテーブルとPolicy_NumberからPremiumとSum of Lossesの合計を取得することです。私が使用しているコードは： select sum(premium) Prem_Sum, sum(Loss) Loss_Sum, t1.policynumber from t1 full outer join t2 on t1.policynumber = t2.policynumber group by t1.policynumber 上記のコードは正しい合計を返しますが、一致するpolicy_numberがないすべてのレコードを「NULL」policy_numberでグループ化します。 結果がこのように見えるようにしたい Policy_Number Prem_Sum …

10 sql-server  sql-server-2008  join 

CREATE TABLE "ATABLE1" ( "COLUMN1" VARCHAR2(20 BYTE), "COLUMN2" VARCHAR2(20 BYTE) ); CREATE TABLE "ATABLE2" ( "COLUMN1" VARCHAR2(20 BYTE), "COLUMN2" VARCHAR2(20 BYTE) ); Insert into ATABLE1 (COLUMN1,COLUMN2) values ('A','1'); Insert into ATABLE1 (COLUMN1,COLUMN2) values ('B','2'); Insert into ATABLE2 (COLUMN1,COLUMN2) values ('A',null); Insert into ATABLE2 (COLUMN1,COLUMN2) values ('A','1'); Insert into ATABLE2 (COLUMN1,COLUMN2) …

10 oracle  join 

TLDR; 2つの実行プランを見ると、どちらが良いのか簡単な答えはありますか？意図的にインデックスを作成しなかったので、何が起こっているのかを簡単に確認できます。 異なる結合スタイル（つまり、ネストされたものと従来のもの）の間のクエリパフォーマンスの違いを発見した私の以前の質問をフォローアップして、ネストされた構文もクエリの動作を変更することに気付きました。次の2つのクエリについて考えます。 SELECT a.*, m.*, n.* FROM dbo.Autos a LEFT JOIN dbo.Models m JOIN dbo.Manufacturers n -- <-- Nested INNER JOIN ON n.ManufacturerID = m.ManufacturerID ON m.ModelID = a.ModelID これは、Modelsテーブルにない ModelIDを持つ自動行を含めるために、製造元を結合する必要はありません。 従来の構文を使用して、結合をManufacturesから外部結合に変更する必要があります。ただし、これによりクエリプランが変更されます。 SELECT a.*, m.*, n.* FROM dbo.Autos a LEFT JOIN dbo.Models m ON m.ModelID = a.ModelID LEFT JOIN …

10 sql-server  sql-server-2012  join  syntax 

スキーマ： CREATE TABLE "items" ( "id" SERIAL NOT NULL PRIMARY KEY, "country" VARCHAR(2) NOT NULL, "created" TIMESTAMP WITH TIME ZONE NOT NULL, "price" NUMERIC(11, 2) NOT NULL ); CREATE TABLE "payments" ( "id" SERIAL NOT NULL PRIMARY KEY, "created" TIMESTAMP WITH TIME ZONE NOT NULL, "amount" NUMERIC(11, 2) NOT NULL, …

10 postgresql  join  aggregate 

この答え「データベースは、Googleの使用を何？」へ ： Bigtableはリレーショナルデータベースではありません。結合はサポートされず、SQLに似た豊富なクエリもサポートされません。 これは明らかですか？私はなぜなのか理解していない。

9 join  nosql  bigtable  distributed-databases