标签: optimization

哪个更快

SELECT * FROM X INNER JOIN Y ON x.Record_ID = y.ForignKey_NotIndexed_NotUnique

或者

SELECT * FROM X INNER JOIN Y ON y.ForignKey_NotIndexed_NotUnique = x.Record_ID

我刚刚开始在 SQL Server 2008 中编写存储过程，并且有 30 多个参数。我从来没有写过一个参数超过 10 个的，这让我开始思考……什么时候参数太多了？

对于背景...这个程序基本上将INSERT单列成一个单一的表。也会有一个非常相似的；虽然有点小；在同一个表上执行UPDATE 的版本。大多数列相对较小，混合了 int 和 string (varchar(200) )。

有哪些问题；是好是坏; 有一个包含大量参数的程序，我应该开始考虑其他模式的阈值是多少？

我在文档中看到了count(*)和之间的区别count(pk)。我一直在使用count(pk)（哪里pk是SERIAL PRIMARY KEY）不知道count(*).

我的问题是关于 Postgres 的内部优化。是否足够聪明地发现 aSERIAL PRIMARY KEY将存在于每一行中并且永远不会为假并且只计算行数，或者它是否会对每一行进行冗余谓词检查？我同意这可能是一个毫无意义的优化，但我只是好奇。

我看了看输出EXPLAIN和EXPLAIN VERBOSE为count(*)，count(id)并count(id > 50)看看是否EXPLAIN提到检查其输出的断言。它没有。

添加NOT NULL带有DEFAULT值的列时- PostgreSQL 是否优化此操作？

如果表有 n 行，未优化的 alter-table-add-column 将产生 n 次写入默认值 - 显然，这可能非常痛苦。通过优化，数据库将立即创建新列，仅存储默认值的一个副本，当在合适的索引数据结构中找不到该列的非默认值时，该副本将返回。

例如Oracle 11g 就有这样的优化。

此连接项中的示例代码

显示一个错误

SELECT COUNT(*)
FROM   dbo.my_splitter_1('2') L1
       INNER JOIN dbo.my_splitter_1('') L2
         ON L1.csv_item = L2.csv_item

返回正确的结果。但以下返回不正确的结果（2014 年使用新的 Cardinality Estimator）

SELECT
    (SELECT COUNT(*)
    FROM dbo.my_splitter_1('2') L1
     INNER JOIN dbo.my_splitter_1('') L2
        ON L1.csv_item = L2.csv_item)

因为它错误地将 L2 的结果加载到公共子表达式假脱机中，然后重播 L1 结果的结果。

我很好奇为什么两个查询之间的行为不同。Trace Flag 8675 显示工作的进入search(0) - transaction processing，失败的进入search(1) - quick plan。

所以我假设额外转换规则的可用性是行为差异背后的原因（例如，禁用 BuildGbApply 或GenGbApplySimple似乎可以修复它）。

但是为什么对于这些​​非常相似的查询的两个计划会遇到不同的优化阶段？从我读过的内容来看search (0)，至少需要三个表，而第一个示例中肯定不满足该条件。

概要：如果逻辑树中较早存在未消除的外连接，则可以逻辑消除的内连接将被保留。为什么？

示例在 AdventureWorks2008R2 及更高版本中运行。我添加了跟踪标志来提供连续树和规则的整体上下文。

第一个例子，对于上下文：

• Product在简化过程中消除了左连接（连接表中不需要数据并且引用的值是唯一的）。
• SalesOrderDetail然后在连接崩溃期间消除内部连接，即启发式连接重新排序（连接表中不需要数据，引用者不可为空，并且强制执行 FK）

SELECT sod.SalesOrderDetailID
FROM Sales.SalesOrderDetail AS sod
    LEFT JOIN Production.Product AS p -- Eliminated during simplification (Rule: RedundantLOJN)
        ON p.ProductID = sod.ProductID
    JOIN Sales.SalesOrderHeader AS soh -- Eliminated during join collapse. (Annotated by TF 8619)
        ON soh.SalesOrderID = sod.SalesOrderID
OPTION (RECOMPILE, QUERYTRACEON 8619, QUERYTRACEON 8621, QUERYTRACEON 8606, QUERYTRACEON 3604);

然而，在第二个示例中，可以从逻辑上消除与 SalesOrderHeader 的连接，但事实并非如此。

• 保留左连接，因为需要来自 的数据Product。在逻辑树中，此连接被定义为在不消除的连接之前。
• 后续的加入SalesOrderHeader可以在逻辑上被消除，因为先前的加入不能使消除要求无效：非空引用 + FK 完整性。

SELECT p.Name
FROM …

当第一个表中的连接列定义为 NOT NULL 并且对第二个表中的相应列具有受信任的外键约束时，SQL Server 查询优化器似乎不会将 OUTER JOIN 转换为 INNER JOIN。

在这种情况下，似乎可以将 OUTER JOIN 转换为等效的 INNER JOIN，因为第一个表中的每一行是：

1. 保证在列中有一个值（NOT NULL 约束），和
2. 保证在第二个表中有匹配的行（可信外键约束）。

例如，请考虑以下表格：

 CREATE TABLE dbo.tbl_fk
 (
    fk_val CHAR(1) NOT NULL PRIMARY KEY CLUSTERED,
    junk VARCHAR(100) NOT NULL
 );
 
 CREATE TABLE dbo.tbl_main
 (
    id INT NOT NULL PRIMARY KEY CLUSTERED IDENTITY(1,1),
    fk_val CHAR(1) NOT NULL FOREIGN KEY REFERENCES dbo.tbl_fk(fk_val)
 );

在以下查询中，为什么优化器没有将执行计划中的 LEFT OUTER JOIN 转换为 INNER JOIN？

SELECT m.fk_val, f.junk
FROM dbo.tbl_main AS m
LEFT OUTER JOIN dbo.tbl_fk AS f
    ON …

根据克雷格·林格的说法：

虽然在（或包括）引用端外键列上创建索引通常是个好主意，但这不是必需的。您添加的每个索引都会稍微减慢 DML 操作的速度，因此您需要为每个INSERT,UPDATE或支付性能成本DELETE。如果索引很少使用，它可能不值得拥有。

您如何确定添加索引的收益是否超过其成本？

您是否在添加索引之前/之后分析单元测试并检查整体性能提升？或者，还有更好的方法？

我在 SQL Server 数据库中有一个表，主键上有一个聚集索引。该表有 100 万行。如果我从表中删除 10K 行，在执行删除操作期间索引会被重组吗？

删除操作是存储过程的一部分。一次，可以有多个客户端执行存储过程，但是每次运行都会删除它自己的一组行（由主键唯一标识）。当多个客户端执行该过程时，我会阻塞键锁（U 型）。阻塞锁属于同一个表中的一行，它不属于任何并发运行的事务。不应该有任何阻塞，因为每次运行都试图删除它自己的一组行。锁定升级不会发生，因为它已关闭。

我怀疑，删除操作一定会导致索引重新平衡，因此在重组过程中，它可以对表的任何行进行键锁定。

我真的很感激对此的任何意见。

如果实例MAXDOP设置为 1 并且查询提示用于允许特定查询并行执行，SQL 是否仍使用并行成本阈值值来决定是否实际并行执行？

我一直无法挖掘出这些特定信息，尽管此链接表明如果MAXDOP为 1 ，则 CTFP 将被忽略。这在没有查询提示的情况下是有意义的，因为没有请求，无论成本如何，当MAXDOP为 1时都会并行。

谁能让我知道这两个请求的预期行为是什么？

示例 1：

Instance Maxdop: 1 
CTFP: 50 
Query hint: Maxdop=2 
Query cost: 30

示例 2：

Instance Maxdop: 1
CTFP: 50
Query hint: Maxdop=2
Query cost: 70