小编Rem*_*anu的帖子

我们的一位客户将DECIMAL(18,0)其 SQL Server 2008R2 数据库中的数据类型用于某些列。由于列增长非常缓慢，他最近提议将数据类型更改为DECIMAL(5,0)以重新获得一些存储空间。

根据MSDN 库，DECIMAL(5,0)数据类型的存储空间与数据类型一样DECIMAL(9,0)，为 5 个字节。INT小 1 个字节，但可以存储 -2^31 到 2^31 范围内的所有内容，而不是DECIMAL(5,0)可以存储的 -99,999 到 99,999 。即使是最大的DECIMAL5 个字节 ( DECIMAL(9,0)) 也只能存储 -999,999,999 到 999,999,999 范围内的整数（不到INT4 个字节提供的范围的一半）。

我可以想到使用DECIMALover的两个“好处” INT：

• 能够在不使用更多存储空间的情况下增加规模
• 能够将精度扩展到 38 位，而无需更改数据类型

但在我看来，这些并不是真正的好处：

• 向整数添加比例仅在极少数情况下才有意义（在大多数情况下，比例确实会产生影响，也可以预先添加）
• SQL Server 将每个精度/小数位数组合视为不同的数据类型，因此在增加精度或小数位数时不会单独保留数据类型。

这让我想知道：DECIMAL(5,0)整数数据类型的额外好处是什么？

我有一个非常简单的查询，它在活动监视器和其他统计信息中显示为在我的整个数据库服务器上具有最多的逻辑读取。

SELECT MAX(RESULT_DATE) FROM TABLEX mm WITH (NOLOCK) 
JOIN TABLEX_RESULTS mr WITH (NOLOCK) on mr.ID = mm.ID 
WHERE DAYS IS NOT NULL AND mm.ORDER_ID = 12345

TABLEX 大约有 2800 万行

TABLEX_RESULTS 大约有 600 万行

我可以在这里做什么来减少此查询的逻辑读取次数？我对如此简单的查询如何拥有如此大量的逻辑读取感到困惑。

谢谢

索引定义（来自评论）

tableX 
IndexName                    PK     Type    Key1            Key2
IDX_MP_MEDS                  0      B AA    ORDER_ID        MEDPASS_DATE
IDX_MP_MEDS_ID_AND_ORDER_ID  0      B A     MEDPASS_DATE    
IX_MP_MEDS_ROOT_ORDER_ID     0      B DA    ROOT_ORDER_ID   MEDPASS_DATE
PK_MP_MED PK                 1      C A     MEDPASS_MEDS_ID 

tablex_resulsts

我发现一个客户数据库的大小在昨天和今天之间激增。经过调查，我在表模式中发现了一个设计问题，但在进行了一些数学运算后，我知道已将 55MB 的数据添加到表中，但表大小现在为 1GB，而表的原始大小为 70MB。

有关其他信息，通过添加 2000 多行且varchar(max)字段填充数据来添加 55MB数据。

这是之前/之后的分析：

昨天

今天

你能向我解释一下为什么一个表需要 70MB 现在在添加 55MB 数据后需要 1GB 吗？

上没有任何索引 varchar(max)

可用空间非常低，与自增长无关。并且自动增长不是用百分比配置的，而是用固定的增长大小配置的。

这是表的创建脚本：

USE [DuoClient20140003]
GO

/****** Object:  Table [dbo].[tContactHistory]    Script Date: 23/05/2016 10:53:19 ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

SET ANSI_PADDING ON
GO

CREATE TABLE [dbo].[tContactHistory](
    [KeyCH] [int] IDENTITY(1,1) NOT NULL,
    [DateCH] [datetime] NULL,
    [KeyType] [int] NULL,
    [KeyF] [int] NULL,
    [KeyI] [int] NULL,
    [KeyCA] [int] NULL,
    [Content] [varchar](max) NULL,
    [KeyCom] [int] NULL,
    [KeyMH] [bigint] …