再最后一次问这个问题,但愿这次能解惑

[kuangtu007]

现象： select a.sc#,b.parentcomp# from YSBMEORD a,View_ysbcp0101_unitarea b WHERE a.keyindate>='2008/01/01'
a.keyindate<='2008/07/03' and a.comp# =b.parentcomp# ------查询用时为1秒

select a.sc#,b.parentcomp# from YSBMEORD a,View_ysbcp0101_unitarea b WHERE a.keyindate>='2008/07/01'
a.keyindate<='2008/07/03' and a.comp# =b.parentcomp#----------查询用时 30秒

目前处理办法： 在对 YSBMEORD 进行 DBCC DBREINDEX(YSBMEORD ,SC#,100)操作后， 查询用时会在1秒。但是，当到下个月的时候，又会恢复到原来样子，如果每个月都要做DBCC DBREINDEX(YSBMEORD ,SC#,100) 的话太烦。

问题： 为什么会出这样的情况，如何能有一个彻底的解决办法？

[hery2002]

DBCC DBREINDEX(YSBMEORD ,SC#,100)
----------------
你的填充因子设置为100?

在对 YSBMEORD 进行 DBCC DBREINDEX(YSBMEORD ,SC#,100)操作后， 查询用时会在1秒。
但是，当到下个月的时候，又会恢复到原来样子
----------------
那就证明你的索引碎片在使用一个月以后有很多,
需要重建来提高速度,
检查一下是否需要重建索引.

[sdxiong]

两个语句的where中都缺少了and
索引sc#中有些什么字段？？如果只有sc#一个字段似乎对查询时间没什么影响
另外索引sc#的填充因子不应该用100。

如果DBCC DBREINDEX(YSBMEORD ,SC#,100)在这个查询语句中没什么影响，
那为何两个时间会有那么大的差距？我想可能是因为重建索引时把表装入了内存中，所以加快了速度。

[中国风]

在日期建聚集索引,定期重建一下索引或整理一下索引
填充因子设置为100?
如果對表做update\delete\inesrt時，會造成頁的分拆，和索引重建..不可這樣設置

[kuangtu007]

多谢关注, 再注明一点: dbcc dbreindex 后在本月内查询速度是很快,但是从下个月第一天开始就很慢,不过只要我把起始日期放到前任意一个月(dbcc dbreindex 过),结束日期放到本月(尚未做dbcc dbreindex 整理的时候)查询速度也是很快的.

填充因子 100的问题,我再了解一下

还请各位再帮忙分析一下

[kuangtu007]

另外: 只要是到了新月份第一天就开始变慢, 比女人的yj还准时! 为什么会这样呢? 和month有什么关系呢

[playwarcraft]

應該是和你建的索引有很大關係，建立貼出table schema ，索引

[kuangtu007]

在对 YSBMEORD 进行 DBCC DBREINDEX(YSBMEORD ,SC#,100)操作后， 查询用时会在1秒。
但是，当到下个月的时候，又会恢复到原来样子
----------------
那就证明你的索引碎片在使用一个月以后有很多,
需要重建来提高速度,
检查一下是否需要重建索引.
--------------------------------------------------------

那怕是我在7/31号执行DBCC DBREINDEX(YSBMEORD ,SC#,100), 等到8/1号也同样会很慢. 不可能在一天的时间内产生那么多碎片吧

[kuangtu007]

[SC#] [varchar](11) NOT NULL,
	[CustID] [varchar](5) NULL,
	[Comp#] [varchar](6) NULL,
	[P/O#] [varchar](50) NULL,
	[LOT#] [varchar](50) NULL,
	[Description] [char](50) NULL,
	[PO_Category] [varchar](3) NULL,
	[PO_Qty] [decimal](10, 0) NULL,
	[Part_code] [char](50) NULL,
	[UnitPrice] [decimal](10, 3) NULL,
	[AskToDelBalance] [decimal](10, 0) NULL,
	[AskToProdBalance] [decimal](10, 0) NULL,
	[NewOrder] [varchar](1) NULL,
	[ParentSC#] [varchar](50) NULL,
	[KeyInDate] [datetime] NULL,
	[KeyInTime] [datetime] NULL,
	[KeyInBy] [varchar](6) NULL,
	[ForceComplete] [bit] NULL,
	[SCStatus] [varchar](8) NULL,
	[SpecialApproval#] [varchar](100) NULL,
	[CommissionTheir] [real] NULL,
	[CommissionOur] [real] NULL,
	[SeparatePrintings] [real] NULL,
	[ProfitMargin] [real] NULL,
	[PriceLevel] [varchar](2) NULL,
	[SessionID] [int] NULL,
	[DeliveryPresent] [varchar](3) NULL,
	[DeliveryPresentQty] [int] NULL,
	[AddrNo] [char](10) NULL,
	[DelAddress] [varchar](500) NULL,
	[SampleOrder] [varchar](1) NULL,
	[DelDate] [datetime] NULL,
	[AdditionalAllowance] [real] NULL,
	[NotToProduce] [char](1) NULL,
	[NotToStore] [char](1) NULL,
	[OnHoldSC#] [varchar](9) NULL,
	[SampleForPrinting] [smallint] NULL,
	[SampleForDieCut] [smallint] NULL,
	[sampleBox] [smallint] NULL CONSTRAINT [DF_YSBMEORD_sampleBox]  DEFAULT ((0)),
	[Salesman] [varchar](6) NULL,
	[TotalCost] [real] NULL,
	[NoOfPalletForSS] [int] NULL,
	[ratio] [int] NULL,
	[belongto] [char](2) NULL,
	[status] [varchar](10) NULL,
	[model#] [varchar](100) NULL,
	[NotTrim] [int] NULL,
	[PorWorking] [varchar](1) NULL,
	[Plantid] [char](2) NULL,
	[txtbank] [smallint] NULL,
	[DCMould] [smallint] NULL,
	[musr] [char](5) NULL,
	[mdtm] [datetime] NULL,
	[DM] [char](3) NULL,
	[Sellout] [smallint] NULL CONSTRAINT [DF_YSBMEORD_Sellout]  DEFAULT (NULL),
 CONSTRAINT [PK_ysbmeord] PRIMARY KEY CLUSTERED 
(
	[SC#] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 100) ON [PRIMARY]
) ON [PRIMARY]

表信息如上, 只有sc#索引而已

[flairsky]

如果表YSBMEORD有很多增删减操作，索引会产生大量碎片

你的查询条件利用索引将是非聚集索引+有序查询。

碎片严重影响有序查询

所以1个月后你的查询又慢了，可以订制一个作业，每天闲时做索引整理

[jasonren]

整理索引碎片.

[comszsoft]

索引碎片引起，去帮助里看看 索引，dbcc indexdefrag,dbcc dbreindex ,填充因子，微软的建议是保持默认的填充因子；
如果你的数据更新频繁，是每个一段时间都要做碎片整理的，这可以通过数据库维护计划来做，也可以通过自己写作业来做。

[水族杰纶]

学习~~

[Garnett_KG]

我的建议:

去掉YSBMEORD上面的聚集索引！

[hyde100]

学习

[flairsky]

产生碎片的原因并不决定于你是否是1天还是10天，而看你插入多少需要分页的索引

[locket]

create index on keyindate

[Garnett_KG]

对於新删修操作极其频繁的表，最好的解决方案就是去掉聚集索引.