标签: performance

这是一个我似乎无法找到答案的简单问题。

在性能方面，如果我有一个WHERE条款，例如a=0 and b=0 and ... z=0，如果我用 替换该条件，我会获得任何性能a+b+...+z=0吗？

换句话说，通过替换以下内容是否有任何性能提升

Select * 
From MyTable 
Where A=0 and B=0 and C=0 and D=0...

和

Select * 
From MyTable 
Where A+B+C+D=0...

我知道它可以依赖于索引，但为此目的，我们只说不存在索引。算术运算符 (+) 的性能是否比“OR”或“AND”逻辑运算符更好？

我的印象是加法比使用 AND 或 OR 的多个条件表现得更好。

检测结果

在 420 万行的表上

返回行其中 A=0 B=0 和 C=0 -> 351748 行

添加 (A+B+C=0) 需要 5 秒，而逻辑条件 A=0 和 B=0 和 C=0 需要 11 秒。

另一方面

返回行 其中 A<>0 B<>0 或 C<>0 -> 3829750 行 58 秒

返回行 …

在下面的查询计划片段中，很明显Concatenation运算符的行估计应该是~4.3 billion rows，或者它的两个输入的行估计的总和。

但是，~238 million rows会产生的估计值，从而导致将数百 GB 数据溢出到 tempdb的次优Sort/Stream Aggregate策略。在这种情况下，逻辑上一致的估计会产生Hash Aggregate，消除溢出并显着提高查询性能。

这是 SQL Server 2014 中的错误吗？是否存在任何有效情况下低于输入值的估计是合理的？可能有哪些解决方法？

这是完整的查询计划（匿名）。我没有系统管理员访问此服务器的权限以提供来自QUERYTRACEON 2363或类似跟踪标志的输出，但如果它们有帮助，我可以从管理员那里获取这些输出。

数据库的兼容性级别为 120，因此使用新的 SQL Server 2014 Cardinality Estimator。

每次加载数据时都会手动更新统计信息。鉴于数据量，我们目前使用默认采样率。较高的采样率（或FULLSCAN）可能会产生影响。

我正在为需要快速读取查询性能的大型地理空间数据集设计一个新系统。因此，我想看看是否有人认为在以下情况下有可能或有关于合适的 DBMS、数据结构或替代方法来实现所需性能的经验/建议：

数据将从处理过的卫星雷达数据中不断产生，这些数据将覆盖全球。根据卫星分辨率和地球的陆地覆盖范围，我估计完整数据集可在全球 750 亿个离散位置产生值。在单颗卫星的整个生命周期内，输出将在每个位置产生多达 300 个值（因此总数据集超过 22 万亿个值）。这是针对一颗卫星，并且已经有第二颗在轨，未来几年计划再有两颗。所以会有很多数据！单个数据项非常简单，仅包含（经度、纬度、值），但由于项目的数量，我估计单个卫星最多可产生 100TB。

写入的数据永远不需要更新，因为它只会随着新卫星采集的处理而增长。写入性能并不重要，但读取性能至关重要。该项目的目标是能够通过一个简单的界面（例如谷歌地图上的图层）将数据可视化，其中每个点都有一个基于其平均值、梯度或某个时间随时间变化的函数的颜色值。（帖子末尾的演示）。

从这些需求来看，数据库需要具有可扩展性，我们很可能会转向云解决方案。系统需要能够处理地理空间查询，例如“附近的点（纬度，经度）”和“范围内的点（框）”，并且具有 < 1 秒的读取性能以定位单个点，以及包含多达50,000 点（尽管最好达到 200,000 点）。

到目前为止，我在 1.11 亿个位置拥有约 7.5 亿个数据项的测试数据集。我已经试用了一个 postgres/postGIS 实例，它工作正常，但没有分片的可能性，我不这样做，这将能够随着数据的增长而应付。我还试用了一个 mongoDB 实例，这似乎再次正常到目前为止，使用分片可能足以随数据量扩展。我最近了解了一些有关 elasticsearch 的知识，因此对此的任何评论都会有所帮助，因为它对我来说是新的。

这是我们想要用完整数据集实现的快速动画：

这个 gif（来自我的 postgres 试验）提供 (6x3) 预先计算的光栅图块，每个包含约 200,000 个点，生成每个点需要约 17 秒。通过单击一个点，通过在 < 1 秒内拉取最近位置的所有历史值来制作图表。

为长篇道歉，欢迎所有评论/建议。

我通常按​​照以下规则设计我的数据库：

• 除了 db_owner 和 sysadmin 之外，没有其他人可以访问数据库表。
• 用户角色在应用层控制。我通常使用一个 db 角色来授予对视图、存储过程和函数的访问权限，但在某些情况下，我添加了第二条规则来保护一些存储过程。
• 我使用 TRIGGERS 来初步验证关键信息。

CREATE TRIGGER <TriggerName>
ON <MyTable>
[BEFORE | AFTER] INSERT
AS
    IF EXISTS (SELECT 1 
               FROM   inserted
               WHERE  Field1 <> <some_initial_value>
               OR     Field2 <> <other_initial_value>)
    BEGIN
        UPDATE MyTable
        SET    Field1 = <some_initial_value>,  
               Field2 = <other_initial_value>  
        ...  
    END

• DML 使用存储过程执行：

sp_MyTable_Insert(@Field1, @Field2, @Field3, ...);
sp_MyTable_Delete(@Key1, @Key2, ...);
sp_MyTable_Update(@Key1, @Key2, @Field3, ...);

您认为，在这种情况下，使用 DEFAULT CONSTRAINT 是否值得，或者我正在向数据库服务器添加额外且不必要的工作？

更新

我知道通过使用 DEFAULT 约束，我向必须管理数据库的其他人提供了更多信息。但我最感兴趣的是性能。

我假设数据库总是检查默认值，即使我提供了正确的值，因此我做了两次相同的工作。

例如，有没有办法在触发器执行中避免 DEFAULT 约束？

在生产 SQL Server 上，我们有以下配置：

3 台 Dell PowerEdge R630 服务器，合并到可用性组中
所有 3 台都连接到作为 RAID 阵列的单个戴尔 SAN 存储单元

有时，在 PRIMARY 上，我们会看到类似于以下内容的消息：

SQL Server 在数据库 ID 8 中
的文件 [F:\Data\MyDatabase.mdf] 上遇到了 11 次 I/O 请求需要超过 15 秒才能完成。操作系统文件句柄为 0x0000000000001FBC。
最近一次 long I/O 的偏移量为：0x000004295d0000。
长 I/O 的持续时间为：37397 毫秒。

我们是性能故障排除的新手

解决此与存储相关的特定问题的最常见方法或最佳实践是什么？

必须使用哪些性能计数器、工具、监视器、应用程序等来缩小此类消息的根本原因？

可能有一个扩展事件可以提供帮助，或者某种审计/日志记录？

更新：添加了我自己的答案（见下文），解释了我们为解决问题所做的工作