标签: sql-server-2008

是否可以将表值参数用作存储过程的输出参数？

这是，我想在代码中做什么

/*First I create MY type */
CREATE TYPE typ_test AS TABLE 
(
     id int not null
    ,name varchar(50) not null
    ,value varchar(50) not null
    PRIMARY KEY (id)
)
GO


--Now I want to create stored procedu whic is going to send output type I created, 
--But it looks like it is inpossible, at least in SQL2008
create  PROCEDURE [dbo].sp_test
         @od datetime 
        ,@do datetime 
        ,@poruka varchar(Max) output
        ,@iznos money output 
        ,@racun_stavke  dbo.typ_test   READONLY --Can I Change READONLY with OUTPUT …

背景

我有一个针对 SQL Server 2008 R2 运行的查询，该查询连接和/或左连接大约 12 个不同的“表”。该数据库相当大，有超过 5000 万行的许多表和大约 300 个不同的表。这是一家在全国拥有 10 个仓库的大型公司。所有的仓库都对数据库进行读写。所以它很大而且很忙。

我遇到问题的查询如下所示：

select t1.something, t2.something, etc.
from Table1 t1
    inner join Table2 t2 on t1.id = t2.t1id
    left outer join (select * from table 3) t3 on t3.t1id = t1.t1id
    [etc]...
where t1.something = 123

请注意，其中一个连接位于不相关的子查询上。

问题是从今天早上开始，没有对系统进行任何更改（我或我团队中的任何人都知道），通常需要大约 2 分钟才能运行的查询，开始需要一个半小时才能运行——当它跑了。数据库的其余部分运行良好。我已经从它通常运行的 sproc 中取出了这个查询，并且我已经在 SSMS 中以相同的速度在带有硬编码参数变量的情况下运行它。

奇怪的是，当我将不相关的子查询放入临时表中，然后使用它而不是子查询时，查询运行良好。另外（这对我来说是最奇怪的）如果我将这段代码添加到查询的末尾，查询运行得很好：

and t.name like '%'

我从这些小实验中得出结论（可能是错误的），速度变慢的原因是 SQL 的缓存执行计划是如何设置的——当查询有点不同时，它必须创建一个新的执行计划。

我的问题是：当一个曾经运行得很快的查询在半夜突然开始运行缓慢并且除了这个查询之外没有其他任何影响时，我该如何解决它以及如何防止它在未来发生? 我怎么知道 SQL 在内部做了什么使其如此缓慢（如果错误的查询运行，我可以获得它的执行计划但它不会运行——也许预期的执行计划会给我一些东西？）？如果这个问题与执行计划有关，我如何让 SQL 不认为真正糟糕的执行计划是个好主意？

此外，这不是参数嗅探的问题。我以前见过，但事实并非如此，因为即使我在 SSMS 中对变量进行硬编码，我的性能仍然很慢。

下面是一个简单的例子，它返回奇怪的结果，这是不可预测的，我们无法在我们的团队中解释。我们做错了什么还是 SQL Server 错误？

经过一番调查，我们将搜索区域缩小到子查询中的 union 子句，从“men”表中选择一条记录

它在 SQL Server 2000 中按预期工作（返回 12 行），但在 2008 和 2012 年它只返回一行。

create table dual (dummy int)

insert into dual values (0)

create table men (
man_id int,
wife_id int )

-- there are 12 men, 6 married 
insert into men values (1, 1)
insert into men values (2, 2)
insert into men values (3, null)
insert into men values (4, null)
insert into men values (5, null)
insert into men values …

让我们检查这两个语句：

IF (CONDITION 1) OR (CONDITION 2)
...

IF (CONDITION 3) AND (CONDITION 4)
...

如果CONDITION 1是TRUE，会CONDITION 2被检查吗？
如果CONDITION 3是FALSE，会CONDITION 4被检查吗？

条件如何WHERE：SQL Server 引擎是否优化WHERE子句中的所有条件？程序员是否应该以正确的顺序放置条件以确保 SQL Server 优化器以正确的方式解析它？

添加：

感谢 Jack 提供链接，来自 t-sql 代码的惊喜：

IF  1/0 = 1 OR 1 = 1
      SELECT 'True' AS result
ELSE
      SELECT 'False' AS result


IF  1/0 = 1 AND 1 = 0
      SELECT 'True' …

是否有任何硬性规则来决定应该将哪些列以及应该以何种顺序放置在 Included in non-clustered index 中。我刚刚读了这篇文章/sf/ask/91559331/ 我发现以下查询：

SELECT EmployeeID, DepartmentID, LastName
FROM Employee
WHERE DepartmentID = 5

海报建议制作这样的索引：

CREATE NONCLUSTERED INDEX NC_EmpDep 
  ON Employee(EmployeeID, DepartmentID)
  INCLUDE (Lastname)

我的问题来了，为什么我们不能像这样制作索引

CREATE NONCLUSTERED INDEX NC_EmpDep 
      ON Employee( EmployeeID, DepartmentID, LastName)

或者

    CREATE NONCLUSTERED INDEX NC_EmpDep 
          ON Employee( EmployeeID, LastName)
INCLUDE (DepartmentID)

以及是什么导致发布者决定保留姓氏列。为什么不是其他列？以及如何决定我们应该以什么顺序保留列？

定义表时，按目的对逻辑组中的列和组本身进行排序会很有帮助。表中列的逻辑顺序向开发人员传达了意义，是良好风格的元素。

这是清楚的。

然而，不清楚的是，表中列的逻辑顺序是否对其在存储层的物理顺序有任何影响，或者是否有任何其他人可能关心的影响。

除了对样式的影响之外，列顺序是否重要？

Stack Overflow 上有一个关于这个的问题，但它缺乏权威的答案。

我们每天通过 WAN 运送我们的 SQL Server 备份。我们需要最小化这些备份的大小，这样它就不会花很长时间。

我们不介意我们的备份过程是否需要更长的时间；目前，我们需要在 WAN 上移动 30gigs 的压缩备份，这需要 10 多个小时。

我们有两种选择来获得较小的每日备份。

1. 日志传送，这意味着我们必须重构 DR 流程。
2. 从数据库中剥离信息并在另一侧重建（删除非聚集索引，100% 打包聚集索引 - 在另一侧重建）

两者都涉及我们的大量工作。我们使用的是 SQL Server 2008 pro，所有备份都是压缩的。

是否有任何商业产品可以为我们提供与选项 (2) 类似的备份大小？

是否有一个全面的脚本可以让我们完成（2）？（处理索引视图、过滤索引、外键等）

这个问题是关于 SQL Server 索引技术的有效性。我认为它被称为“索引交集”。

我正在使用一个现有的 SQL Server (2008) 应用程序，该应用程序存在许多性能和稳定性问题。开发人员在索引方面做了一些奇怪的事情。我无法获得关于这些问题的结论性基准，也无法在互联网上找到任何真正好的文档。

表上有许多可搜索的列。开发人员在每个可搜索列上创建了一个单列索引。理论上，SQL Server 将能够组合（交叉）这些索引中的每一个，以在大多数情况下有效地访问表。这是一个简化示例（真实表有更多字段）：

CREATE TABLE [dbo].[FatTable](
    [id] [bigint] IDENTITY(1,1) NOT NULL,
    [col1] [nchar](12) NOT NULL,
    [col2] [int] NOT NULL,
    [col3] [varchar](2000) NOT NULL, ...

CREATE NONCLUSTERED INDEX [IndexCol1] ON [dbo].[FatTable]  ( [col1] ASC )
CREATE NONCLUSTERED INDEX [IndexCol2] ON [dbo].[FatTable] ( [col2] ASC )

select * from fattable where col1 = '2004IN' 
select * from fattable where col1 = '2004IN' and col2 = 4

我认为针对搜索条件的多列索引要好得多，但我可能错了。我看到查询计划显示 SQL Server 在两个索引查找上执行哈希匹配。当您不知道如何搜索表时，这也许有意义？谢谢。

我的许多数据库都有定义为 varchars 的字段。自从我在美国生活和工作以来，这并不是什么大问题（那里唯一存在的语言是“美国”。咳咳）

在使用数据库大约 5 年后，我发现我最终遇到了 varchar 字段的有限性质的问题，我必须修改我的字段以将数据存储为 nvarchars。在不得不对表进行另一次更新，将 varchar 字段转换为 nvarchar 之后，我有了一个想法——为什么我们仍然这样做？我早就决定将所有新的文本字段定义为 nvarchar，而不是 varchar，这是我 10 年前在学校时从教科书中学到的。

现在是 2011 年，去年发布了新版本的 SQL Server。当我们可以/应该使用 nvarchar 时，为什么我们继续支持 varchar 数据类型？

我知道经常有人争论 nvarchars 是 varchars 的“两倍大”，因此存储空间的使用可能是维护 varcars 的一个争论点。

但是，今天的用户如果想节省存储空间，可以定义他们的 nvarchars 以将数据存储为 UTF-8 而不是默认的 UTF-16。如果主要需要，这将允许 8 位编码，同时保证插入到他们的数据库中的稀有 2-8 字节字符不会破坏任何东西。

我错过了什么吗？在过去的 15 到 20 年里，这是否有充分的理由没有改变？

给定某种等待，您如何在生产 SQL 2008 R2 服务器上安全地找到导致这些等待的查询？

在这种特殊情况下，我想知道async_network_io.