主页 / dba / 问题 / 164808
Accepted
eckes
Asked: 2017-02-19 14:11:19 +0800 CST

为什么 BIGINT col 上的此搜索具有额外的常量扫描、计算标量和嵌套循环运算符？

  • 772

当我查看一些查询的实际执行计划时，我注意到 WHERE 子句中使用的文字常量显示为计算标量和常量扫描的嵌套链。

sql工作室截图

为了重现这一点，我使用下表

CREATE TABLE Table1 (
    [col1] [bigint] NOT NULL,
    [col2] [varchar](50) NULL,
    [col3] [char](200) NULL
)
CREATE NONCLUSTERED INDEX IX_Table1 ON Table1 (col1 ASC)

其中有一些数据：

INSERT INTO Table1(col1) VALUES (1),(2),(3),
                               (-9223372036854775808),
                               (9223372036854775807),
                               (2147483647),(-2147483648)

当我运行以下（无意义的）查询时：

SELECT a.col1, a.col2
  FROM Table1 a, Table1 b
  WHERE b.col1 > 2147483648

我看到它将在索引查找和标量计算（来自常量）的结果中进行嵌套循环绘图。

请注意，文字大于 maxint。它确实有助于写作CAST(2147483648 as BIGINT)。知道为什么 MSSQL 将其推迟到执行计划并且有没有比使用强制转换更短的方法来避免它？它是否也会影响到准备好的语句（来自 jtds JDBC）的绑定参数？

标量计算并不总是完成（似乎是特定于索引查找的）。有时查询分析器不会以图形方式显示它，而是col1 < scalar(expr1000)在谓词属性中显示。

我已经在 Windows 7 上使用 MS SSMS 2016 (13.0.16100.1) 和 SQL Server 2014 Expres Edition 64 位看到过这种情况，但我想这是一种普遍行为。

sql-server sql-server-2014

2 个回答

  1. Best Answer
    SELECT thing, 
       sql_variant_property(thing,'basetype') AS basetype,
       sql_variant_property(thing,'precision') AS precision, 
       sql_variant_property(thing,'scale') AS scale
FROM (VALUES (2147483648)) V(thing)

    向您展示文字2147483648被解释为numeric(10,0). 此行为早bigint于 SQL Server (2000) 中的引入。

    没有语法表明应将文字视为bigint- 添加显式CAST是最佳解决方案。文章Dynamic Seeks and Hidden Implicit Conversions讨论了计划中的其他工具。

    该计划本身表明嵌套循环有一个搜索谓词

    Seek Keys[1]: Start: [tempdb].[dbo].[Table1].col1 > Scalar Operator([Expr1005]), 
                End: [tempdb].[dbo].[Table1].col1 < Scalar Operator([Expr1006])

    您可以使用扩展事件会话query_trace_column_values来查看这些内容，如下所示。

    在此处输入图像描述

    计划中的 XML 也显示了这一点

      <DefinedValue>
    <ValueVector>
      <ColumnReference Column="Expr1005" />
      <ColumnReference Column="Expr1006" />
      <ColumnReference Column="Expr1004" />
    </ValueVector>
    <ScalarOperator ScalarString="GetRangeWithMismatchedTypes((2147483648.),NULL,(6))">
      <Intrinsic FunctionName="GetRangeWithMismatchedTypes">
        <ScalarOperator>
          <Const ConstValue="(2147483648.)" />
        </ScalarOperator>
        <ScalarOperator>
          <Const ConstValue="NULL" />
        </ScalarOperator>
        <ScalarOperator>
          <Const ConstValue="(6)" />
        </ScalarOperator>
      </Intrinsic>
    </ScalarOperator>
  </DefinedValue>

    这并不意味着它实际上是在进行比较< null，而是

    范围边界表达式使用 NULL 来表示两端的“无界”。（来源）

    所以最终的结果是你的查询谓词b.col1 > CAST(2147483648 AS NUMERIC(10, 0))仍然以查找结束b.col1 > CAST(2147483648 AS BIGINT)

    它是否也会影响到准备好的语句（来自 jtds JDBC）的绑定参数？

    我没有使用过 jtds JDBC，但我认为它允许您定义参数数据类型？如果是这样，只需确保参数是与列 ( bigint) 匹配的正确数据类型，这样 SQL Server 就不需要处理不匹配的数据类型。

    • 9

  2. 关于我关于 JDBC 准备语句的问题。jTDS使用sp_prepare/ sp_execute（在默认prepareSQL=3模式下）。

    使用以下查询（来源）：

    use database
select
    cp.objtype, st.text
from sys.dm_exec_cached_plans cp
cross apply sys.dm_exec_sql_text(cp.plan_handle) st
where cp.objtype = 'prepared' and st.text like '%TABLE%'

    我可以看到 JTDS 发出的准备好的语句，它确实(@P0 bigint)...按预期声明了变量。

    所以这一切都很好，我需要记住，在尝试执行计划时，最好实际定义本地类型变量而不是用文字替换它们（和/或使用sp_execute缓存的执行计划）。

    • 3

相关问题