标签: join

我将尝试从我的 SQL 服务器数据库中的数据制作一个图表。即使计数为零，我也会拥有所有街道以及居住在这条街道上的用户的计数。

为此，我试过这个查询：

Create table Streets(
  ID int IDENTITY  primary key,
  Name varchar(100)
);

create table users(
  ID int IDENTITY  primary key,
  Username varchar(100),
  StreetID int references Streets(id)
);

insert into streets values ('1st street'), ('2nd street'), ('3rd street'), 
                           ('4th street'), ('5th street');
insert into users values ('Pol', 1), ('Doortje', 1), ('Marc', 2), ('Bieke', 2), 
                         ('Paulien', 2), ('Fernand', 2), ('Pascal', 2), ('Boma', 3), 
                         ('Goedele', 3), ('Xavier', 4);

select s.name as street, count(s.name) as count 
from users u inner join …

当涉及到列命名时，我想要一些关于最佳实践的专家意见。

背景是，根据维基百科，以下语法，

SELECT ... FROM Employees JOIN Timesheets USING (EmployeeID);

比

SELECT ... FROM Employees JOIN Timesheets ON (Employees.EmployeeID = Timesheets.EmployeeID);

但是，该JOIN ... USING语法仅适用于所有具有全局唯一名称的主键列。因此，我想知道这是否被认为是正确的做法。

就个人而言，我总是使用 PK columnid和外键 column来创建表othertable_id。但那样就不可能使用USINGor 了NATURAL JOIN。

任何指向设计风格或表格设计最佳实践指南的链接也将不胜感激！

我们需要每晚在我们的 SQL Server 2008 R2 上做一些报告。计算报告需要几个小时。为了缩短时间，我们预先计算了一个表格。该表是基于 JOINining 12 个相当大（数千万行）的表创建的。

直到几天前，这个聚合表的计算才用了大约 4 个小时。我们的 DBA 将这个大连接拆分为 3 个较小的连接（每个连接 4 个表）。临时结果每次都保存到一个临时表中，供下次join使用。

DBA 增强的结果是，聚合表在 15 分钟内计算完成。我想知道这怎么可能。DBA 告诉我，这是因为服务器必须处理的数据数量较少。换句话说，在大的原始连接中，服务器必须处理比在总和较小的连接中更多的数据。但是，我认为优化器会使用原始大连接有效地执行此操作，自行拆分连接并仅发送下一个连接所需的列数。

他所做的另一件事是在其中一个临时表上创建了索引。但是，我再次认为优化器会在需要时创建适当的哈希表，并更好地优化计算。

我和我们的 DBA 讨论过这个问题，但他自己不确定是什么导致了处理时间的改善。他刚刚提到，他不会责怪服务器，因为计算如此大的数据可能会让人不知所措，而且优化器可能很难预测最佳执行计划...... 我明白这一点，但我想对确切原因有更多明确的答案。

所以，问题是：

1. 什么可能导致大的改善？

2. 将大连接拆分为小连接是标准程序吗？

3. 在多个较小连接的情况下，服务器必须处理的数据量真的更小吗？

这是原始查询：

    Insert Into FinalResult_Base
SELECT       
    TC.TestCampaignContainerId,
    TC.CategoryId As TestCampaignCategoryId,
    TC.Grade,
    TC.TestCampaignId,    
    T.TestSetId
    ,TL.TestId
    ,TSK.CategoryId
    ,TT.[TestletId]
    ,TL.SectionNo
    ,TL.Difficulty
    ,TestletName = Char(65+TL.SectionNo) + CONVERT(varchar(4),6 - TL.Difficulty) 
    ,TQ.[QuestionId]
    ,TS.StudentId
    ,TS.ClassId
    ,RA.SubjectId
    ,TQ.[QuestionPoints] 
    ,GoodAnswer  = Case When TQ.[QuestionPoints] Is null Then 0
                      When TQ.[QuestionPoints] > 0 Then 1 
                      Else 0 End
    ,WrongAnswer …

鉴于当前 Postgres 9.4 中的此设置（来自此相关问题）：

CREATE TABLE foo (ts, foo) AS 
VALUES (1, 'A')  -- int, text
     , (7, 'B');

CREATE TABLE bar (ts, bar) AS
VALUES (3, 'C')
     , (5, 'D')
     , (9, 'E');

db<> fiddle here（也来自上一个问题）。

我SELECT用 a写了一个FULL JOIN来实现引用问题的目标。简化：

SELECT ts, f.foo, b.bar
FROM   foo f
FULL   JOIN bar b USING (ts);

As per specifications, the correct way to address the column ts is without table qualification. Either of the …

我正在解开一些遗留代码，而且我多年来从未见过这个：

Select * 

FROM GLAccounts
INNER JOIN GLCharts
    ON glaGLChartID = glcGLChartID
LEFT JOIN GLCategories
    ON glcGLCategoryID = gltGLCategoryID
INNER JOIN GLDepartments
    ON glaGLDepartmentID = gldGLDepartmentID
INNER JOIN GLDivisions
    ON glaGLDivisionID = glvGLDivisionID
        ,GLFiscalYearPeriods                --<this comma>
INNER JOIN GLFiscalYears
    ON glfGLFiscalYearID = glzGLFiscalYearID


ORDER BY glcGLCategoryID
    ,glcParentGLChartID
    ,glaGLChartID

连接有效，但我没有在 ON 子句的任何 T-SQL 语法参考中找到逗号的这种用法。

这里发生了什么事？TIA

我有以下表格和索引定义：

CREATE TABLE munkalap (
    munkalap_id serial PRIMARY KEY,
    ...
);

CREATE TABLE munkalap_lepes (
    munkalap_lepes_id serial PRIMARY KEY,
    munkalap_id integer REFERENCES munkalap (munkalap_id),
    ...
);

CREATE INDEX idx_munkalap_lepes_munkalap_id ON munkalap_lepes (munkalap_id);

为什么在以下查询中没有使用 munkalap_id 上的任何索引？

EXPLAIN ANALYZE SELECT ml.* FROM munkalap m JOIN munkalap_lepes ml USING (munkalap_id);

QUERY PLAN
Hash Join  (cost=119.17..2050.88 rows=38046 width=214) (actual time=0.824..18.011 rows=38046 loops=1)
  Hash Cond: (ml.munkalap_id = m.munkalap_id)
  ->  Seq Scan on munkalap_lepes ml  (cost=0.00..1313.46 rows=38046 width=214) (actual time=0.005..4.574 rows=38046 loops=1)
  ->  Hash  (cost=78.52..78.52 rows=3252 …

我在 PostgreSQL 9.6 查询计划方面遇到了麻烦。我的查询如下所示：

SET role plain_user;

SELECT properties.*
FROM properties
JOIN entries_properties
  ON properties.id = entries_properties.property_id
JOIN structures
  ON structures.id = entries_properties.entry_id 
WHERE structures."STRUKTURBERICHT" != ''
  AND properties."COMPOSITION" LIKE 'Mo%'
  AND (
    properties."NAME" LIKE '%VASP-ase-preopt%'
    OR properties."CALCULATOR_ID" IN (7,22,25)
  )
AND properties."TYPE_ID" IN (6)

我为上面使用的表启用了行级安全性。

• 用set enable_nestloop = True，查询规划运行嵌套循环用约37秒的总运行时间加入：https://explain.depesz.com/s/59BR

• with set enable_nestloop = False，采用Hash Join方式，查询时间约0.3秒：https : //explain.depesz.com/s/PG8E

我VACUUM ANALYZE在运行查询之前做过，但没有帮助。

我知道这不是一个好的做法set enable_nestloop = False，对于计划者来说，还有任何其他类似的选择。但是我怎样才能“说服”规划器在不禁用嵌套循环的情况下使用散列连接？

重写查询是一种选择。

如果我在绕过 RLS 的角色下运行相同的查询，那么它的执行速度非常快。行级安全策略如下所示：

CREATE POLICY properties_select …

我在应该从 Oracle 外连接语法移植到 SQL 标准外连接语法的查询中看到了以下内容：

SELECT ...
FROM A, B, C, D, E
WHERE A.A_ID = B.A_ID
AND B.B_ID = C.A_ID(+)
AND B.B_KEY = C.B_KEY(+)
AND C.C_ID = D.C_ID(+)
AND B.A_ID = E.A_ID(+)
AND B.B_KEY = E.B_KEY(+)
AND 'CONSTANT' = C.X_ID(+)

现在翻译外连接语法通常是一个非常机械的过程，但最后一行让我感到困惑。这是什么意思？它有什么作用？

我有一张comments表，可以简化为：

comments
=======
id
user_id
text
parent_id

where 可以parent_id为空，但可能是其父注释的键。

现在，我如何才能select对特定评论的所有后代？
评论可能低了好几层……