标签: query-performance

我有以下查询（针对问题进行了简化）我正在尝试加快只读数据库的速度...

SELECT 
 [sysid]
,[Date]=CONVERT(CHAR, DATEADD(D, [date], '1800-12-28'),101)   
,[From]=[from_addr]   
,[To]=[to_addr]  --I'm a very long Text or NVARCHAR(MAX) Field
,[Subject]=[subject]  
,CASE WHEN [attach] = 1 THEN 'Yes' ELSE 'No' END AS 'Att'   
,[Code]=[ccode]   
,[Staff]=[staff]  
,[MatNo]=[mat_no]  
FROM dbo.[email] 
DYNAMIC WHERE CLAUSE ON ANY OF ABOVE

我已经尝试添加一些索引，包括覆盖索引我不能包含 to_addr 的方式（作为文本或 NVARCHAR(MAX) col），并且查询优化器最终使用聚集索引，因为不包含 to_addr 字段。有什么方法可以处理这样的情况？不幸的是，我仅限于 2005 年。

编辑

尝试添加 Full_Text For to_addr 仍然进行表扫描。但是，如果我注释掉该行，它将使用索引。:(该死的文本数据！

可能的重复：
索引如何影响查询性能？
如何知道何时/是否有太多索引？

• 在语句中使用一些“where”条件说“X”报告，因此我们在表“T”上创建索引“A”。
• 在语句中使用一些“where”条件说“Y”报告，因此我们在表“T”上创建索引“B”..
• 在语句中使用一些“where”条件说“Z”报告，因此我们在表“T”上创建索引“C”。
• 在语句中使用一些“where”条件说“M”报告，因此我们在表“T”上创建索引“D”。

现在有 4 个索引，这个表有大量的记录。

1. 当我在这个表中插入或更新行时，索引会影响这些操作的性能吗？
2. 如果是这样，那么我如何调整这些查询以使其性能良好？

问完这个问题后，我开始思考为什么某个查询会出现所有问题。

简而言之，有一个查询需要 500 毫秒，我运行了一些执行计划并应用了推荐的索引，但它只截断了大约 50-60 毫秒。

再次运行后，我发现以下查询（发生在多个位置）真的很慢：

SELECT @TempCardNumber = CardNumber 
FROM Cards 
WHERE (CardNumber=@CardNumber or FullCardNumber=@CardNumber)

当我把它改成

SELECT @TempCardNumber = CardNumber 
FROM Cards 
WHERE (CardNumber=@CardNumber)

它跑得超级快，甚至删除索引也没有太大关系，让我相信这是主要的瓶颈，但我不明白..这有什么问题？

我正在开发一个记录客户付款的系统，当客户付款时，系统必须更新帐户并显示已付款和所有以前的付款，问题是哪个选项最好：

A. 记录每笔付款，这意味着客户有多个记录。

B. 每个客户只有一个记录，并且数据库中有一个属性，其中连接以前的付款，所以它是一个包含以前付款的字符串。

注意：数据库将有很多客户，这就是为什么我担心这种情况下的性能，尤其是在查看数据库上的信息时。

我从未做过这样的系统，因此不知道具有这两种配置之一和大量记录的数据库的性能会有多大影响。

如果有更好的解决方案欢迎

我有几天时间处理这个查询，但无法按我的意愿工作。这篇文章与此相关来自不同表的几个值，我在其中艰难找到了解决方案，但我完全错误并丢失了:(。所以基本上与另一篇文章的架构相同：5 个表：default_users、default_profiles、default_status、default_comment和 default_friend。这是每个的 SQL：

default_comment

CREATE TABLE `default_comment` (
  `comment_id` int(11) NOT NULL AUTO_INCREMENT,
  `friend_id` int(11) NOT NULL,
  `message` text COLLATE utf8_unicode_ci NOT NULL,
  `created_at` timestamp NULL DEFAULT NULL,
  `status_id` int(11) NOT NULL,
  `device` varchar(50) COLLATE utf8_unicode_ci NOT NULL,
  PRIMARY KEY (`comment_id`)
) ENGINE=InnoDB AUTO_INCREMENT=13007 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

默认好友

CREATE TABLE `default_friend` (
  `friend_id` int(8) NOT NULL,
  `user_id` int(8) NOT NULL,
  `is_suscriber` tinyint(1) NOT NULL DEFAULT '1',
  `privacy` tinyint(1) NOT NULL DEFAULT '0',
  `created_at` timestamp NOT …

我有一个事实表 CardTransactionFact

表结构

TABLE [dbo].[CardTransactionFact]
    [CardTransactionID] [int] IDENTITY(1,1) NOT NULL,
    [TransactionTerminalID] [int] NOT NULL,
    [SourceAccountTypeID] [int] NULL,
    [DestinationAccountTypeID] [int] NULL,
    [RimNo] [varchar](15) NULL,
    [CaptureCodeID] [int] NOT NULL,
    [RoutingCodeID] [int] NOT NULL,
    [ProcessingCodeID] [int] NOT NULL,
    [ActionCodeID] [int] NOT NULL,
    [NetworkCodeID] [int] NOT NULL,
    [ProductCodeID] [int] NOT NULL,
    [AcquiringCountryCodeID] [int] NOT NULL,
    [IssuingCountryCodeID] [int] NOT NULL,
    [TransactionCurrencyCodeID] [int] NOT NULL,
    [AmountBD] [decimal](18, 3) NOT NULL,
    [LocalCurrencyCodeID] [int] NOT NULL,
    [CardIssuerBank] [int] NOT NULL,
    [CardTypeID] [int] NOT NULL,
    [SuspectTransactionFlag] [char](1) NOT NULL, …

我继承了一个又大又慢的存储过程，它给了我一个噩梦：

我不是DBA，虽然我有一些知识，但我不知道从哪里开始识别这个瓶颈。

我的桌面上安装了 SQL Server 2008，并带有生产数据库的精确副本。我正在从 SSMS 运行所有内容，并且尝试过直接使用 SQL 和 SP。SP 与 SQL 的时间足够接近相同，不必担心 - 这是我关心的本地与服务器的时间。

本地:

• 2GHz 双核
• 4Gb 内存
• SQL Server 2008 Sp1
• Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0（英特尔 X86）
• Windows NT 6.1 上的企业版（内部版本 7601：Service Pack 1）

服务器:

• 2GHz 双核
• 4Gb 内存
• Microsoft SQL Server 2008 (SP1) - 10.0.2573.0 (X64)
• Windows NT 5.2（内部版本 3790：Service Pack 2）（VM）上的标准版（64 位）

当我“本地”运行时，大约需要10 分钟才能完成。

当我在服务器上运行时，大约需要14 个小时才能完成！！！

[总插入量约 = 14,000,000]

我已经尝试尽可能多地调整 SP 并避免参数嗅探，但不确定为什么这在几乎等效的机器上会慢得多（我知道 SQL Server 版本略有不同，但不明白为什么会这样）有那么大的不同？） …

这应该是一个非常简单的查询，但老实说，我认为它的执行时间可以改进。

select idTag,MAX(pctimestamp) AS PCTIMESTAMP,getdate() AS NOW, datediff(SECOND,MAX(pctimestamp),getdate()) AS DELAY 
from ValuesTagsOPC
group by IdTag

此查询从“ValuesTagsOPC”表返回 1386 行，该表包含大约 4000 万行，并具有以下结构，由创建脚本检索：

CREATE TABLE [dbo].[ValuesTagsOPC](
    [IdTag] [int] NOT NULL,
    [TTimeStamp] [datetime] NOT NULL,
    [PCTimeStamp] [datetime] NOT NULL,
    [Value] [nvarchar](50) NOT NULL,
    [Quality] [int] NOT NULL,
 CONSTRAINT [PK_ValuesTagsOPC] PRIMARY KEY CLUSTERED 
(
    [IdTag] ASC,
    [PCTimeStamp] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

很明显，它的主键上有一个聚集索引。SQL Server 的时间和 IO 统计信息如下（抱歉，它是西班牙语）：

(1386 …

这些查询中哪些最有利于性能？有时我想知道 SHORT 脚本是否真的是最好的关注点。这些脚本执行相同的任务。通过左连接，我只需几行就可以实现我想要的。但后来我尝试使用更长的脚本，使用联合。哪种方法最好？在这之间：

SELECT p.productID, p.product, C.color, C.colorID, S.size, S.sizeID, q.qty From quantities q
        INNER join products P ON p.productID = q.productID
        LEFT JOIN colors C ON C.colorID = q.colorID
        LEFT JOIN sizes S ON S.sizeID = q.sizeID
        --WHERE q.productID = @productID 

和这个：

SELECT p.productID, p.product, C.color, C.colorID, S.size, S.sizeID, q.qty From quantities q
        inner join products P ON p.productID = q.productID
        INNER JOIN colors C ON C.colorID = q.colorID
        INNER JOIN sizes S ON S.sizeID = q.sizeID
        --WHERE q.productID …

在发现我的 SQL Server 上几乎所有数据库的碎片都超过 40% 后，我决定使用 80 的填充因子对所有表进行索引重建。

重建所有索引后，某些查询似乎永远需要至少两个查询/表。

这是其中一个慢查询：

SELECT  a.FileID,
        a.EventID,
        MAX(b.cyNumber) AS cyNumber,
        MAX(b.skNumber) AS skNumber,
        MAX(b.cyFormat) AS cyFormat,
        MAX(b.Cost) AS Cost,
        MAX(b.PackageRef) AS PackageRef,
        MAX(CASE WHEN b.BMUpdatedON = '1900-01-01 00:00:00.000' THEN NULL ELSE b.BMUpdatedON END) AS BMUpdatedON,
        MAX(b.RunID) AS RunID   
FROM    DB.dbo.[File] a
        INNER JOIN DB.dbo.bicy b ON a.InnerFileID = b.InnerFileID
WHERE   a.FileID NOT IN (SELECT FileID FROM DB.dbo.Event_bicy)
GROUP BY a.FileID,
        a.EventID
OPTION (MAXDOP 1);

我总是OPTION (MAXDOP 1)在所有查询中使用，因为当我不使用它时，查询会运行得很慢。现在，在索引重建之后，似乎发生了相反的情况。如果我删除MAXDOP 1或删除where子句，查询运行得很快，我觉得很奇怪。 …