小编孔夫子*_*孔夫子的帖子

这与计算符合特定条件的记录数有关，例如invoice amount > $100。

我倾向于更喜欢

COUNT(CASE WHEN invoice_amount > 100 THEN 1 END)

然而，这同样有效

SUM(CASE WHEN invoice_amount > 100 THEN 1 ELSE 0 END)

我认为 COUNT 更可取有两个原因：

1. 传达意图，即 COUNT
2. COUNT 可能在i += 1某处涉及一个简单的操作，而 SUM 不能指望它的表达式是一个简单的整数值。

有没有人有关于特定 RDBMS 差异的具体事实？

最后是一个测试脚本，用于比较@table 变量和#temp 表之间的性能。我想我已经正确设置了 - 性能计时是在 DELETE/TRUNCATE 命令之外进行的。我得到的结果如下（以毫秒为单位）。

@Table Variable  #Temp (delete)  #Temp (truncate)
---------------  --------------  ----------------
5723             5180            5506
15636            14746           7800
14506            14300           5583
14030            15460           5386
16706            16186           5360

只是为了确保我是理智的，这表明 CURRENT_TIMESTAMP (aka GetDate()) 是在语句时使用的，而不是批处理时，因此 TRUNCATE/DELETE 与SET @StartTime = CURRENT_TIMESTAMP语句之间不应有交互。

select current_timestamp
waitfor delay '00:00:04'
select current_timestamp

-----------------------
2012-10-21 11:29:20.290

-----------------------
2012-10-21 11:29:24.290

当使用 DELETE 清除表时，第一次运行和后续运行之间的跳转非常一致。我对DELETE 的理解缺少什么？我已经重复了很多次，交换了顺序，调整了 tempdb 的大小以使其不需要增长等。

CREATE TABLE #values (
  id int identity primary key, -- will be clustered …

我通常通过首先构造一个使用正确计划的查询，然后将其复制到类似的查询中来创建计划指南。但是，这有时很棘手，尤其是在查询不完全相同的情况下。从头开始创建计划指南的正确方法是什么？

SQLKiwi 已经提到在 SSIS 中制定计划，有没有一种方法或有用的工具来帮助为 SQL Server 制定一个好的计划？

有问题的具体实例是这个 CTE：SQLFiddle

with cte(guid,other) as (
  select newid(),1 union all
  select newid(),2 union all
  select newid(),3)
select a.guid, a.other, b.guid guidb, b.other otherb
from cte a
cross join cte b
order by a.other, b.other;

有没有任何方法来使结果拿出正好3个不同的guidS和没有更多？我希望将来能够通过包含多次引用的 CTE 类型查询的计划指南来更好地回答问题，以克服一些 SQL Server CTE 怪癖。

这适用于最有可能出现在 StackOverflow/dba.stackexchange 上的主要关系数据库管理系统，包括SQL Server、MySQL、PostgreSQL 和 SQLite (WebSQL)。

select 'abc' abc, 1 def;

它不适用于 Oracle。为什么我们需要在Oracle中选择DUAL？SQL 的 ISO/ANSI 标准是否要求SELECT语句的 FROM 子句？

根据Bacon Bit的回答，它似乎是 SQL 标准所要求的。

所以实际上，因为名称 DUAL 用词不当，如果我要创建一个表并将其命名为 ATOM 或 ONE，例如create table one (atom int);.. select 'abc' abc, 1 def FROM one;- 与 相比是否有性能损失SELECT .. FROM DUAL？

我们有这个打算“缩小”的大型数据库（> 1TB）。数据库围绕一个主要实体，我们称之为“访问”。为了讨论，假设它是一个医疗实践的数据库。

共有30个访问“类型”，例如程序、年度、随访、免疫等，每个访问“类型”都是“访问”的子表，例如“visit_immuno”。

该数据库自 2000 年以来已经积累了大约 12 年的数据。有人建议我们将大约 3 年的数据保留在“实时”版本中，而将其余的数据保留在“旧数据”数据库中。日期仅存储在“访问”表中，因为它是标准化的。Visit 表还包含一个ROWVERSION列和一个BIGINT伪标识（集群）列。出于所有意图和目的，假设集群键由 SEQUENCE (SQL Server 2012 Enterprise) 填充 - 我们将其命名为cid。

在visit.date当医生的推移延长探视，并与他的数据的“公文包”的回报并不总是以相同的顺序作为聚集键，例如，它被合并到主表。“访问”表也有一些更新，这将导致ROWVERSION列与cid和date列不同步- 简单地说，由于这个原因，ROWVERSION也cid不会制作合适的分区键。

从“实时”中删除数据的业务规则是visit.date必须大于 36 个月并且visit_payment必须存在子记录。此外，“old_data”数据库不包含任何基表，除了visit%.

所以我们最终得到：

直播DB（日常使用） -所有表老数据DB -对于较旧的数据visit%表

该提案要求一个组合数据库，它是一个外壳，其中包含（除外）中所有基表的同义词以及跨两个数据库中的表联合所有的视图。Live DBvisit%visit%