标签: parameter

在 pgAdminIII 中，我创建了一个函数，该函数使用 RETURN TABLE 在名为 identifier 的单列中返回多行：

CREATE OR REPLACE FUNCTION test(
    IN parm1 date,
    IN parm2 interval)
  RETURNS TABLE(identifier INT) 
AS
$BODY$
BEGIN
    RETURN QUERY
    SELECT 1;

END;
$BODY$
  LANGUAGE plpgsql;

创建函数后，pgAdminIII 显示该函数具有以下定义：

CREATE OR REPLACE FUNCTION test(IN parm1 date, IN parm2 interval)
  RETURNS SETOF integer AS
$BODY$
BEGIN
    RETURN QUERY
    SELECT 1;

END;
$BODY$
  LANGUAGE plpgsql VOLATILE
  COST 100

执行函数时，它遵循RETURNS TABLE. 但是，在编辑该函数时，它将拾取RETURNS SETOF. 这提供了与我指定的函数不同的功能（例如，返回的列的名称不再存在）。

那么，如何强制 pgAdminIII 保留返回的列名identifier？我并不特别关心我是否将其定义为 aTABLE或SETOF …

我才发现， 通过纯粹的光彩意外的是，SQL Server 允许您创建没有任何名称的变量、参数、表变量、临时表（本地和全局）和临时存储过程（本地和全局）！好吧，至少不是我认为的名字。意思是，您可以指定DECLARE @ INT = 5;并且这是有效的 T-SQL：它执行时没有错误，甚至没有在 SSMS 中用红色波浪线下划线标记（本问题末尾显示了完整示例列表的代码）。

鉴于数据库标识符的 MSDN 页面指出（强调我的）：

有两类标识符：
常规标识符
...
分隔标识符
... 常规标识符和分隔标识符都必须包含1 到128 个字符。对于本地临时表，标识符最多可以有 116 个字符。

这当然看起来不像预期的行为，我最初认为这是一个缺陷（不会导致任何错误，但似乎不是“正确”的行为）并提交了一个连接错误：参数、变量和临时表和过程名称/标识符可以为空。

然而，同一个 MSDN 页面还指出：

常规标识符规则

变量、函数和存储过程的名称必须符合以下 Transact-SQL 标识符规则。

1. 第一个字符必须是以下字符之一：

   • Unicode 标准 3.2 定义的字母。字母的 Unicode 定义包括从 a 到 z、从 A 到 Z 的拉丁字符，以及来自其他语言的字母字符。

   • 下划线 (_)、at 符号 (@) 或数字符号 (#)。

     标识符开头的某些符号在 SQL Server 中具有特殊含义。以 at 符号开头的常规标识符始终表示局部变量或参数，不能用作任何其他类型对象的名称。以数字符号开头的标识符表示临时表或过程。以双数字符号 (##) 开头的标识符表示全局临时对象。尽管可以使用数字符号或双数字符号字符作为其他类型对象的名称的开头，但我们不推荐这种做法。

因此，可以解释为，名称的 1 个字符的最低要求（从显示“1 到 128 …

我一直在使用 EventClass RPC:Completed 跟踪一些存储过程，这些过程是从 .Net SqlClient 数据提供程序间歇性调用的，没有必需的参数 - 只是“exec SprocName”。

如果我在它们出现在跟踪的 TextData 中时手动调用它们，它们会生成一个异常 - 但在原始跟踪中不会生成任何异常。这些“无参数”调用的“错误”列确实显示“1 - 错误”，但我不明白该调用如何不生成异常。

起初我怀疑这是分析器的故障，“1 - 错误”导致参数从 TextData 被截断，但我在扩展事件会话中看到了相同的结果。

有没有人在他们的分析器跟踪或事件会话中看到过这样的东西？该应用程序几乎可以肯定将这些调用作为某些边缘情况错误的一部分，但为什么 sql server 没有抛出异常？

我发现每天运行的大而讨厌的数据提取查询需要更新统计信息，以避免根据不正确的行数估计制定可怕的查询计划（让我们不必担心我的统计信息是否应该自动更新）。

如标题中所述，我的问题是：如果在更新给定的统计数据集之前准备好查询计划，而在优化器做出的决定结果出来的时候，我是否应该担心不正确的查询计划仍然存在？是错的？

或者统计更新自动导致依赖查询计划被刷新？

如果计划仍然存在，是否有办法确定哪些计划取决于给定索引的统计数据？（我知道，我可以去挖掘 DMV 文档，只是希望有人已经有了答案）

我们开始使用 SQL Server 2008 R2 构建数据仓库系统。一位资深 DBA 告诉我们考虑对 SQL Server 服务使用启动参数 -E。我从在线书籍中读到：

-E：增加为文件组中的每个文件分配的区数。此选项可能对运行索引或数据扫描的用户数量有限的数据仓库应用程序很有帮助。不应在其他应用程序中使用它，因为它可能会对性能产生不利影响。32 位版本的 SQL Server 不支持此选项。

我的问题是这个参数如何帮助索引和数据扫描？如果同一实例中可能存在其他数据库（可能处于操作角色），我们是否应该使用此参数？

如何在升级前从 Oracle 数据库中删除所有隐藏参数？我正在使用下面的 SQL 查询。那你推荐什么？

SELECT name,description from SYS.V$PARAMETER WHERE name LIKE '\_%' ESCAPE '\'

以下是参数：

_fast_full_scan_enabled
_gby_hash_aggregation_enabled
_like_with_bind_as_equality
_optimizer_push_pred_cost_based
_sort_elimination_cost_ratio
_sqlexec_progression_cost
_trace_files_public
_b_tree_bitmap_plans

问候，

我有一些查询需要获取 64 个以上的特定行，例如这个带有 65 个 ID 的示例。TableID 为主键，类型为 BigInt。

SELECT * FROM TableA 
        WHERE TableID IN (260905384, 260915601, 260929877, 260939625, 260939946, 261096977, 261147037, 261152934, 261163936, 261357728, 261369122, 261376714, 261454472, 261488500, 261527284, 261584786, 261619749, 261679560, 261777653, 261786639, 261795246, 261795810, 261803724, 261821199, 261824173, 261827397, 261840197, 261848595, 261874545, 261889122, 261889355, 261929793, 261953069, 262106609, 262134069, 262134088, 262339745, 262354363, 262360015, 262571936, 262586920, 262591486, 262663776, 262703601, 262746674, 262792439, 262801544, 262826561, 262933229, 262933270, 262947539, 262958110, 263021588, 263032875, 263037208, 263039292, 263045038, 263085369, 263089147, 263091427, 263097644, 263100021, 263103339, 263104396, …

下面的查询使用 StackOverflow2010 示例数据库：

DECLARE @Id INT = 18471

SELECT c.UserId FROM dbo.Comments AS c
INNER HASH JOIN dbo.Users AS u
ON c.UserId = u.Id
AND c.UserId = @Id

使用散列连接提示，它返回以下错误：

由于此查询中定义的提示，查询处理器无法生成查询计划。在不指定任何提示且不使用 SET FORCEPLAN 的情况下重新提交查询

当我添加时它有效 OPTION(RECOMPILE)用字符串文字或替换变量。

什么可能导致这个问题？

我们的系统大约有 500 个“客户”，它们的记录数量存在极大差异。这是一个（非常简化的）示例查询，它可以根据传递的参数返回 0 - 100000 行。这个查询运行 find 但我相当肯定它会受到参数嗅探的影响，具体取决于哪个参数被缓存。

exec sp_executesql N'
               SELECT *
                 FROM Widgets
                WHERE CustomerId=@0
',N'@0 nvarchar(40)',@0=N'bda43162-2d98-4e79-8e81-7056f6df5e51'

如果我修改查询以包含参数作为选择，它似乎会为每个客户缓存查询。

exec sp_executesql N'
               SELECT ''bda43162-2d98-4e79-8e81-7056f6df5e51'', *
                 FROM Widgets
                WHERE CustomerId=@0
',N'@0 nvarchar(40)',@0=N'bda43162-2d98-4e79-8e81-7056f6df5e51'

由于每个客户都缓存了自己的查询版本，因此性能得到了极大的提高。这种方法有任何副作用吗？

假设：

• 系统的这部分必须是动态 SQL
• 此查询经常运行
• 客户数量不会快速增长

编辑：我考虑过使用 OPTION (RECOMPILE) 但如果我可以通过这种方法获得编译查询的好处，我不想每次都重新编译。

最近我注意到我公司的应用程序使用AddWithValue将参数值传递给动态的参数化查询。例子：

cmd.Parameters.AddWithValue("@VehicleId", Vehicles.VehicleId);

在数据库中，该数据类型VehicleID是INT。

据我了解，由于 AddWithValue（已弃用）未指定数据类型/长度，因此此“@VehicleID”被转换并可能被错误转换。在“INT”的情况下，该转换是否会影响 SQL Server 性能？

这会导致计划缓存污染之外的问题吗？转换是否会导致性能下降？