标签: sql-server

在 OUTER APPLY 语句中从嵌套查询中进行选择时，嵌套查询似乎在某些情况下只评估一次。

向 Azure 反馈论坛报告的错误：https : //feedback.azure.com/forums/908035-sql-server/suggestions/39428632-microsoft-sql-server-2014-incorrect-result-when-s

这是预期的行为还是我在文档中遗漏了什么，或者这是 SQL Server 中的错误？

另外，是否有可能强制对每一行的嵌套查询进行评估？

测试案例 1

评估 VALUES 中每一行的嵌套 FROM 查询（恕我直言，预期行为）

SELECT
    v,
    v2
FROM
    (VALUES (1), (2), (3), (4)) AS inner_query(v)
    OUTER APPLY (
        SELECT
            MAX(inner_v2) AS v2
        FROM (
            SELECT 
                15 AS id,
                v AS inner_v2
        ) AS outer_query
        GROUP BY id
    ) AS outer_apply

结果：

| v | v2|
|---|---|
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| …

我在 Windows Server 2012 R2 上运行 SQL Server 2017，并将内存从 256 GB 增加到 512 GB。我注意到虚拟内存的以下配置：

• C: [操作系统] = 2 GB
• G：[数据] = 无
• H：[日志] = 无
• T：[温度] = 无

有很多关于将大小设置为已安装内存大小的 1.5 或 2 倍的建议。我读得对还是我误读了这些文章并且它们适用于其他东西？

也有文章建议不要担心虚拟内存，因为SQL应该只使用RAM而不是虚拟内存，而操作系统只需要2GB的虚拟内存？

我刚刚看了Pinal Dave 的这个视频。

他有一个SELECT查询，它在 tempdb 中产生 ~370k 读取和 ~1200 读取查询所SELECT来自的表。

然后他创建了一个索引（我们称之为，Index1），它删除了 tempdb 假脱机，从而提高了查询的性能。到目前为止一切正常。

然而，他随后创建了一个进一步的索引（我们称之为Index2）并Index1保持原样。

然后他再次运行他的查询，尽管Index2没有被使用，但查询性能恢复到原来的状态，~370k tempdb spool 仍然存在。

他实际上似乎并没有描述导致这种情况的原因（除非我错过了）

要重现的代码如下（感谢 Martin Smith 提供 Pastebin）这假设 AdventureWorks 的 vanilla 版本，其标准索引位于 SalesOrderDetail

SET STATISTICS XML ON;
SET STATISTICS IO ON
GO

-- The query
DBCC FREEPROCCACHE;
SELECT SalesOrderID, ProductId,SalesOrderDetailID, OrderQty
FROM   Sales.SalesOrderDetail sod
WHERE  ProductID = (SELECT AVG(ProductID)
                    FROM   Sales.SalesOrderDetail sod1
                    WHERE  sod.SalesOrderID = sod1.SalesOrderID
                    GROUP  BY sod1.SalesOrderID);
/* …

现在，我面临着基数估计的逻辑问题，这个问题在一个看似相当简单的情况下对我来说不是很清楚。我在工作中遇到过这种情况，因此出于隐私考虑，下面仅对问题进行一般性描述，但为了更详细的分析，我在AdventureWorksDW培训基地中模拟了此问题。

有以下形式的查询：

SELECT <some columns>
FROM <some dates table>
CROSS APPLY(

    SELECT
        <some p columns>
    FROM <some table> p
    WHERE p.StartDate <= Dates.d
      AND p.EndDate >= Dates.d
) t

从上面给出的执行计划中可以看出，基数估计器估计索引查找操作中的估计行数为 17,884,200（对应于 NL 外部的每行 2,980,700），这与实际数量非常接近.

现在我将修改查询并添加到 CROSS APPLY LEFT OUTER JOIN：

SELECT <some columns t>
FROM <some dates table>
CROSS APPLY(

    SELECT
        <some p columns>
    <some columns f>
    FROM <some table> p
    LEFT JOIN <some table> f ON p.key = f.key
        AND f.date = Dates.d
    WHERE p.StartDate <= Dates.d
      AND p.EndDate …

查询优化器创建多个可能的执行计划。如何查看在选择执行的计划之前生成的所有计划？

微软说：

查询优化器必须分析可能的计划并选择估计成本最低的计划。

请注意，我不是在谈论执行计划缓存和重用，我在谈论候选执行计划，即生成但未选择执行的执行计划。

根据 Benjamin Nevarez 的文章SQL Server 查询优化器：

候选执行计划的生成在查询优化器内部使用转换规则执行，启发式的使用限制了考虑的选择数量，以保持优化时间合理。候选计划在优化期间存储在内存中，称为备忘录的组件中。

是否有可能以显示实际执行计划的方式呈现候选计划？

我最近继承了一个使用日期分区的项目，其中每日计划任务实现了过去 30 天和未来 60 天的滑动窗口方案。

实际上，插入的数据SYSUTCDATETIME()用于分区列，因此未来的 60 个分区始终为空。

这是一个需要解决的问题还是我应该让睡狗撒谎？

我们的应用程序之一报告错误消息 2628：

string or binary data would be truncated in table '******', column '******'. Truncated value: '******'

代替

String or binary data would be truncated in table 'mytable', column 'mycolumn'. Truncated value: 'myvalue'.

我用 SSMS 得到的。

我需要更改什么设置才能获得完整的消息？

我试图搜索这个，但我得到的只是我需要将 VERBOSE_TRUNCATION_WARNINGS 设置为 ON，并将 compatible_level 设置为 150。我很久以前就这样做了。

该应用程序具有以下错误处理程序：

 try
     {
         ES.isWorking = true;
         Worker worker = new Worker(new DBConnection(Settings.ConnectionString));
         worker.DoWork();
         ES.isWorking = false;
     }
 catch (Exception ex)
     {
         ES.isWorking = false;
         this.eventLog.WriteEntry("In OnTimer exception ! message: " + ex.Message.ToString());
         errorHandler.HandleException(ex, "In OnTimer exception …

我正在尝试找出提高非常慢查询性能的方法。它有更明显的问题，但我注意到的一件事是 WHERE 子句中的条件之一是 'AND t.data IS NOT NULL' 而表 t 的 'data' 列没有为 NULL 的条目并且确实有一个 NOT NULL 约束。

所以我想知道查询优化器是否能够忽略条件。我的想法是，它不能仅仅因为约束而这样做（因为不能保证它是否是用 NOVALIDATE 创建的），但可能足够“聪明”以使用有关列中 NULL 字段数量的统计信息。

我自己的测试是不确定的，我无法找到有关此主题的任何进一步信息。

我一直在使用旧提供程序 (SQLNCLI) 的链接服务器，没有任何问题，正如Microsoft推荐的那样，我计划切换到新提供程序 (MSOLEDBSQL)。安装驱动程序后，我可以使用以下 T-SQL 添加链接服务器

EXEC sp_addlinkedserver     
   @server=N'SQL02\DEV1',   
   @srvproduct=N'',  
   @provider=N'MSOLEDBSQL',   
   @datasrc=N'SQL02,1933';  

不幸的是，当我尝试查询新的链接服务器时出现以下错误：

我试过的查询：

--- example 1
select * from OPENQUERY ([SQL02\DEV1], 'select name from sys.databases');

--- example 2
select name from [SQL02\DEV1].master.sys.databases;


--- example 3 (without linked server dependency)
SELECT c.* FROM OPENROWSET(
      'MSOLEDBSQL'
    , 'Server=SQL02,1933;Database=master;Integrated Security=True;'
    , 'SELECT name FROM sys.databases;'
    ) c;

从所有示例中得到相同的错误：

不支持 OLE DB 提供程序“MSOLEDBSQL”与 SQL Server 的进程外使用。

这是否真的意味着 SQL-2016 不支持使用新的提供程序 MSOLEDBSQL，尤其是在链接服务器中，或者除了重新安装驱动程序和重新启动 SQL Server 之外，我还有什么遗漏。

这个问题带来了查询优化器在简单查询的现有谓词中选择不好的搜索谓词的情况。运行一些测试后，我得出的结论是，糟糕的决定是由于使用了本地临时表而不是全局临时表或常规表。

db fiddle：本地临时表、全局临时表、常规表。

我在临时表文档中找不到任何可以解释我们在使用本地临时表而不是全局临时表或常规表时看到的不同行为的特征。这有合乎逻辑的原因还是可能是错误？