标签: sql-server-2014

在下面的查询计划片段中，很明显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）可能会产生影响。

我正在尝试将查询从 Oracle 迁移到 SQL Server 2014。

这是我在 Oracle 中运行良好的查询：

select
count(distinct A) over (partition by B) / count(*) over() as A_B
from MyTable 

这是我尝试在 SQL Server 2014 中运行此查询后遇到的错误。

Use of DISTINCT is not allowed with the OVER clause

有谁知道是什么问题？在 SQL Server 中可以进行这种查询吗？请指教。

在我之前的一个问题中，在向表中添加新的计算列时禁用锁升级是个好主意吗？，我正在创建一个计算列：

ALTER TABLE dbo.tblBGiftVoucherItem
ADD isUsGift AS CAST
(
    ISNULL(
        CASE WHEN sintMarketID = 2 
            AND strType = 'CARD'
            AND strTier1 LIKE 'GG%' 
        THEN 1 
        ELSE 0 
        END
    , 0) 
    AS BIT
) PERSISTED;

计算列是PERSISTED，并且根据计算列定义(Transact-SQL)：

坚持

指定数据库引擎将计算值物理存储在表中，并在计算列所依赖的任何其他列更新时更新值。将计算列标记为 PERSISTED 允许在确定性但不精确的计算列上创建索引。有关更多信息，请参阅计算列上的索引。任何用作分区表的分区列的计算列都必须显式标记为 PERSISTED。当指定 PERSISTED 时，computed_column_expression 必须是确定性的。

但是当我尝试在我的列上创建索引时，我收到以下错误：

CREATE INDEX FIX_tblBGiftVoucherItem_incl
ON dbo.tblBGiftVoucherItem (strItemNo) 
INCLUDE (strTier3)
WHERE isUsGift = 1;

无法在表 'dbo.tblBGiftVoucherItem' 上创建过滤索引 'FIX_tblBGiftVoucherItem_incl'，因为过滤器表达式中的列 'isUsGift' 是计算列。重写过滤器表达式，使其不包含此列。

如何在计算列上创建过滤索引？

或者

有替代的解决方案吗？

我有一张这样的表：

CREATE TABLE Updates
(
    UpdateId INT NOT NULL IDENTITY(1,1) PRIMARY KEY,
    ObjectId INT NOT NULL
)

本质上是跟踪 ID 增加的对象的更新。

该表的使用者将选择一个由 100 个不同对象 ID 组成的块，按UpdateId特定的UpdateId. 本质上，跟踪它停止的位置，然后查询任何更新。

我发现这是一个有趣的优化问题，因为我只能通过编写由于索引而碰巧做我想要的查询来生成最大优化的查询计划，但不保证我想要什么：

SELECT DISTINCT TOP 100 ObjectId
FROM Updates
WHERE UpdateId > @fromUpdateId

@fromUpdateId存储过程参数在哪里。

有以下计划：

SELECT <- TOP <- Hash match (flow distinct, 100 rows touched) <- Index seek

由于UpdateId正在使用索引上的搜索，结果已经很好，并且按照我想要的从最低到最高的更新 ID 排序。这会生成一个流程不同的计划，这就是我想要的。但是排序显然不能保证行为，所以我不想使用它。

这个技巧也会产生相同的查询计划（尽管有一个冗余的 TOP）：

WITH ids AS
(
    SELECT ObjectId
    FROM Updates …

我正在研究从 MS SQL 2012 升级到 2014 的好处。SQL 2014 的一大卖点是内存优化表，这显然使查询速度超快。

我发现内存优化表有一些限制，例如：

• 没有(max)大小的字段
• 每行最大 ~1KB
• 无timestamp字段
• 没有计算列
• 没有UNIQUE限制

这些都属于麻烦事，但如果我真的想解决这些问题以获得性能优势，我可以制定计划。

真正的问题是您无法运行ALTER TABLE语句，并且每次向索引列表添加字段时都必须经历这些繁琐INCLUDE的过程。此外，您似乎必须将用户拒之门外，才能对实时数据库上的 MO 表进行任何架构更改。

我觉得这简直太离谱了，以至于我实际上无法相信 Microsoft 会在此功能上投入如此多的开发资金，却让其维护起来如此不切实际。这使我得出结论，我一定是拿错了棍子的一端；我一定误解了内存优化表的某些内容，这让我相信维护它们比实际困难得多。

那么，我误解了什么？你用过MO表吗？是否有某种秘密开关或过程使它们易于使用和维护？

右键单击表格并选择“选择前 1000 行”时，出现此错误：

除了明显升级到 SQL Server 2014 之外，还有其他解决方法吗？

我的一位同事给我发了一个有趣的问题，我无法完全解释。

他运行了一些代码（包括在下面）并从中得到了一些意想不到的结果。

本质上，当将 a UniqueIdentifier（Guid从这里开始我将称之为）转换为 a binary(or varbinary) 类型时，结果的前半部分的顺序是倒序的，但后半部分不是。

我的第一个想法是系统的字节序是原因，并且Guid保留了显示，但binary不能保证形式。

显然这是一个实现细节，但我想知道是否有一个很好的解释。

代码：

declare @guid uniqueidentifier = '8A737954-CBEC-40CE-A534-2AFFB5A0E207';
declare @binary binary(16) = (select convert(binary(16), @guid));
select @guid as [GUID], @binary as [Binary];

结果：

GUID                                 Binary
8A737954-CBEC-40CE-A534-2AFFB5A0E207 0x5479738AECCBCE40A5342AFFB5A0E207

如您所见，每个部分的前半部分Guid（一直到40CE）是向后存储的。也就是说，the的第一部分是向后的，然后是第二部分，然后是第三部分，但是这些部分的顺序是保留的。之后，最后两个部分按照它们在.GuidGuid

declare @guid_to_binary table
(
    [id] int identity(1,1),
    [guid] uniqueidentifier,
    [binary_conversion] binary(16)
);
declare @i int = 1;
while @i <= 100
begin
    insert into …