小编Rao*_*bin的帖子

这个问题是关于 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 在两个索引查找上执行哈希匹配。当您不知道如何搜索表时，这也许有意义？谢谢。

我正在对大型SQL server 2008 数据库做一些性能调优，IT 组不愿意给SHOWPLAN 权限。过去，“显示执行计划”是了解单个查询和过程性能的最有效方法。

授予此权限有哪些固有风险？对数据库的开发副本进行这种限制是否有正当理由？

注意：该 SQL IT 组在单个 SQL Server 实例下拥有 200 多个数据库。谢谢。

答：我认为没有回应意味着除了下面提到的风险之外没有重大的安全风险。基本上，将其限制在开发数据库上会适得其反。

如果有人提出更好的答案，我会更新。感谢您的意见！

这个问题是关于 SQL Server 索引性能，a varchar(2000)as an INCLUDEin a coverage index。

我正在尝试提高缓慢且不稳定的数据库应用程序的性能。在某些情况下，数据是通过大VARCHAR字符串来访问的，与查询包括像multple字符串操作SUBSTRING()，SPACE()和DATALENGTH()。这是访问的简化示例；

update fattable set col3 =  
   SUBSTRING(col3,1,10) + '*' + 
   SUBSTRING(col3,12,DATALENGTH(col3)-12)
from fattable where substring(col3,10,1) = 'A' and col2 = 2

架构如下所示：

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 [IndexCol2Col3] ON [dbo].[FatTable]  ( [col2] ASC ) 
    INCLUDE( [col3] )

从我读过的内容来看，将大数据字段放在索引中是很糟糕的。我一直在阅读几篇文章，包括http://msdn.microsoft.com/en-us/library/ms190806.aspx，其中讨论了分页和磁盘大小对索引性能的影响。话虽如此，查询计划肯定会使用覆盖索引。我没有足够的信息来确定这在系统负载方面实际上给我带来了多少成本。我确实知道总体而言，系统性能不佳，我担心这是问题之一。问题：

• 将此varchar(2000) …