高手请进，该问题困扰小弟几个星期了。谢谢大家了

Question

把以下索引改为聚集的
CREATE NONCLUSTERED INDEX [EVENT_GUID] ON [dbo].[EVENT] 
( 
[EVENT_GUID] ASC 
)WITH (SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF) ON [PRIMARY] --〉
CREATE CLUSTERED INDEX [EVENT_GUID] ON [dbo].[EVENT] 
( 
[EVENT_GUID] ASC 
)WITH (SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF) ON [PRIMARY] 

Answer 1

[EVENT_GUID] [char](36)
为什么用[char]？

Answer 2

那个字段是作为条件的，你的语句应该改成：UPDATE Event SET CallType='1',Customer_GUID='FA9EB93A-042F-45C9-950F-3D18F1C809A9',DNIS='2138429999',ANI='013506435188',TransferFrom=NULL,TransfterTo=NULL,CallStartTime='2009-06-12 13:09:22',CallEndTime='2009-06-12 13:18:00',HangupType='1',WorkStartTime='2009-06-12 13:09:22',WorkEndTime='2009-06-12 13:19:40',CallResult_ID='CLOSE',HandleBy_ID='E8C3DD',HandleGroup_ID='campn',StringField1='CTI',CALLBEGINTIME='2009-06-12 13:09:19',CALLESTABLISHED=1,COMMENTS='订购' WHERE Event_GUID='9A3BC39F-213B-434C-8AB8-857CB9665946' 不要做没必要的修改。

Answer 3

建议:
将数据库备份.
将表中的数据删去十分之九,再执行该程序,看是否有问题.
如有,再删除现有的十分之九,再执行,看是否有问题.
如果某一次删除后,程序运行没问题了,再分析其原因.
另外,建议执行一下:
select * from  Event where Event_GUID='9A3BC39F-213B-434C-8AB8-857CB9665946'
检查一下该行是否有什么问题,或许,你的表里有两个一模一样的行!

Answer 4

首先你确实不应该更新EVENT_GUID，这个值是不变的啊。依次为例，其它更新字段是不是也存在同样的问题？另外的建议和问题：1、EVENT_GUID是不是EVENT的主键？如果是主键，是建议建立聚集索引的。2、GUID的字段类型为什么使用[char](36)？你应该使用uniqueidentifier类型。uniqueidentifier的空间占用只有16个字节。作为查询依据的字段，字节数越少，效率越高。（如果能是int就更高了）。3、sql2005 sp3是一定要打的。1399这个版本有个对执行计划误判的bug。4、除了EVENT_GUID上面的索引，其它的几个索引你确定需要吗？如果很少用，建议删掉。5、“超时已过期”这个错误是在哪里报出来的？查询分析器？还是你的程序中？
执行上述步骤看看是否有提高，同时请贴出执行计划。

Answer 5

对于14楼的我先说下我的几个观点：
1：EVENT_GUID现在不是主键。是一个不唯一，非聚集索引。
2：已经试过将该字段改成聚集索引，可效果不怎么好。
3：EVENT_GUID字段的类型是char(36)的，是固定的36位长度，是通过newid()函数获取的。
4：除了EVNET_GUID索引，其他的索引针对查询的时候是有效的。
谢谢楼上各位朋友

Answer 6

3：EVENT_GUID字段的类型是char(36)的，是固定的36位长度，是通过newid()函数获取的。 -------------------------------newid()函数返回的就是guid，可以使用uniqueidentifier类型存储。你应该把存储guid类型的数据类型都转成uniqueidentifier类型，而不是char(36)。我记得以前有个测试，使用uniqueidentifier类型会比char(36)提升20-30%的效率。

Answer 7

16楼的朋友确定吗？如果是这样的话，我的这个帖子的分数全部送给你。可问题我的这个字段存储的是36位的guid 啊。newid函数产生的啊。

Answer 8

你看见的guid是36个字符，包括“-”，但是实际存储是不需要36个字节的。所以sql server才提供了uniqueidentifier类型专门存放guid啊。newid函数就是产生guid的。你可以把你的表弄个备份，这个备份表的guid都使用uniqueidentifier类型，然后把索引补上，看看效果。

Answer 9

那如果我将EVENT_GUID 字段改成uniqueidentifier数据类型的话,这个字段应该是建立什么索引?
是做聚集索引,还是非聚集索引,我现在是将这个字段设置为不唯一,非聚集索引.
这个表需要做大量的更新，400万条数据做更新的话，要提高更新效率需要考虑哪些方面？谢谢16楼的朋友了，如果答案正确我将立刻给你全部分的。谢谢你了。

Answer 10

怎么看这个数据库服务器打了几个补丁啊？是通过select @@version吗？
现在通过这个语句查询的结果是：Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86)  Oct 14 2005 00:33:37  Copyright  1988-2005 Microsoft Corporation  Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 1) 
那说明我需要打什么补丁呢？

Answer 11

那如果我将EVENT_GUID 字段改成uniqueidentifier数据类型的话,这个字段应该是建立什么索引? 
是做聚集索引,还是非聚集索引,我现在是将这个字段设置为不唯一,非聚集索引. 
这个表需要做大量的更新，400万条数据做更新的话，要提高更新效率需要考虑哪些方面？谢谢16楼的朋友了，如果答案正确我将立刻给你全部分的。谢谢你了。-------------------保持原来的EVENT_GUID 索引不变。
分你给前面的那些朋友吧，分对我没用。

Answer 12

怎么看这个数据库服务器打了几个补丁啊？是通过select @@version吗？ 
现在通过这个语句查询的结果是：Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86)  Oct 14 2005 00:33:37  Copyright  1988-2005 Microsoft Corporation  Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 1) 
那说明我需要打什么补丁呢？---------------------------
1399是没有打补丁的sql2005。目前你可以打sql server 2005 sp3。你可以上google下 sql server 2005 sp3，就知道了。

Answer 13

朋友，你说的1399 是什么意思啊？？？
那是否意味着我的数据库服务器sp1,sp2,sp3三个补丁都没打过啊？？？
那是否我这三个补丁都需要打上呢？

Answer 14

1399是你的sql server2005的小版本号。9.00.1399.06 是完整版本号。9代表sql2005，8代表sql2000，10代表sql2008....1399是大部分sql2005安装介质初始安装时小版本号。如果安装sp3以后好像是9.00.4....，有些记不清楚了。如果安装sp3，只安装sp3即可，不需要sp1+sp2+sp3，sp3包括了前两个。

Answer 15

我的这个更新操作，报“超时已过期”按楼上26的朋友ashzs您的建议也就是：将EVENT_GUID字段的数据类型更改成uniqueidentifier，然后重建一下这个字段的
索引对嘛？？还有其他的解决问题的方案吗？

Answer 16

贴一下消息结果：SET STATISTICS IO ON
SELECT * FROM
Event WHERE Event_GUID='9A3BC39F-213B-434C-8AB8-857CB9665946'

Answer 17

表 'Worktable'。扫描计数 0，逻辑读取 0 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'EVENT'。扫描计数 1，逻辑读取 2 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

Answer 18

这里可以看到io只读取两个2个page,不应该超时硬盘什么配置？

Answer 19

运行-->perfmon 
看一下硬盘的磁盘队列是什么情况？

Answer 20

不好意思，30楼的朋友。
我提供的这个信息是我本机这个表的信息，现在我不在数据库服务器那里。
我的意思就是想知道如何去分析这个信息，比方现在我提供你的数据是：逻辑读取是2次，就说明是只读取了2个page，那如果明天我在数据库
服务器那看到是读取的是100多个或者200个page，那该如何处理呢？？？》？

Answer 21

Set statistics profile on
Set statistics time on
Set statistics io onrun your sql
Set statistics profile off
Set statistics time off
Set statistics io off
然后把结果都贴出来。^O^

Answer 22

如果确定要改新几百个page，需要io的处理能力提高.等你有实际数据再说吧.或许需要找硬件瓶颈.

Answer 23

今天在现场数据库服务器上运行这条SQL:
SET STATISTICS IO ON
UPDATE Event SET Event_GUID='C063BC64-74CD-4B48-B8E8-82AE4D36E4BE',CallType='1',Customer_GUID=NULL,TransferFrom=NULL,TransfterTo=NULL,CallStartTime='2009-06-15 13:53:03',CallEndTime='2009-06-15 13:53:03',HangupType='1',WorkStartTime='2009-06-15 13:53:03',WorkEndTime='2009-06-15 13:53:09',CallResult_ID='CANCEL',HandleBy_ID='95F2E5',HandleGroup_ID='SYSTEM',StringField1='NOCTI',StringField2='CANCEL' WHERE Event_GUID='C063BC64-74CD-4B48-B8E8-82AE4D36E4BE'表 'EVENT'。扫描计数 1，逻辑读取 2220 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。 有办法解决吗?更新速度很慢啊.....

Answer 24

你WHERE Event_GUID='C063BC64-74CD-4B48-B8E8-82AE4D36E4BE' 有多少条记录？

Answer 25

不会吧，一条记录能读2220个page ?那：
select * from Event WHERE Event_GUID='C063BC64-74CD-4B48-B8E8-82AE4D36E4BE'
逻辑读是多少？

Answer 26

这样试试：
UPDATE Event SET Event_GUID='C063BC64-74CD-4B48-B8E8-82AE4D36E4BE',CallType='1'
,Customer_GUID=NULL,TransferFrom=NULL,TransfterTo=NULL,CallStartTime='2009-06-15 13:53:03'
,CallEndTime='2009-06-15 13:53:03',HangupType='1',WorkStartTime='2009-06-15 13:53:03'
,WorkEndTime='2009-06-15 13:53:09',CallResult_ID='CANCEL',HandleBy_ID='95F2E5'
,HandleGroup_ID='SYSTEM',StringField1='NOCTI',StringField2='CANCEL' 
FROM Event with(index=Event_GUID字段索引名称)
WHERE Event_GUID='C063BC64-74CD-4B48-B8E8-82AE4D36E4BE'加上FROM Event with(index=Event_GUID字段索引名称)试试