在SQLServer处理中的一些问题及解决方法-白红宇

一、DBLINK性能问题

select * from dbsource.dbname.dbo.table where guid in (

select guid from tablechangelog

where tablename='table ' and id<110000)

这个运行居然要40秒以上。

后来分析了一下

1、table和tablechangelog是在不同的服务器上

2、在tablechangelog有230万记录，ID是聚集索引

在table上guid是主键，大概有30万条记录

解决步骤

首先执行select guid from tablechangelog where tablename='table ' and id<110000，发现时间忽略不计

再次还原到同一台服务器上测试运行，发现只要1秒

select * from table where guid in (

select guid from tablechangelog

where tablename='table ' and id<110000)

也就是说该SQL语句性能瓶颈在于网络，而不是SQL本身。

既然问题在于网络，那应该可以通过减少数据网络传递来解决部分

登陆到目标服务器上执行

select * from table where guid in (

select guid from dbdest.dbname.dbo. tablechangelog

where tablename='table ' and id<110000)

发现只需要1~3秒即可

本来想GUID应该是造成该SQL执行的最大问题，没想到居然是网络问题

既然优化已到达效果，就暂且不用去管GUID了

后话：

对于sqlserver的执行计划以及I/O、CPU之类的指标看起来实在费劲，与其研究这些，不如靠实证来解决，呵呵

问题二

关于GUID和递增性ID带来的问题

出于唯一性和系统维护的要求，在各个表中都存在以下两个字段GUID和ID，ID一般为聚集索引+主键

[GUID] [varchar] (38) COLLATE Chinese_PRC_CI_AS NOT NULL CONSTRAINT [DF_GUID] DEFAULT ('{' + convert(char(36),newid()) + '}'),

ID [int] IDENTITY (1, 1) NOT NULL ,

出于系统维护的要求，一般都会这样查询

select * from tableA where guid not in (select guid) from tableB)

但是GUID是不做唯一索引的，且即使加了唯一索引，考虑到GUID是无序且过于分散的，如果有几千上万的guid的话，仍是不会走索引的

关于ID，ID一般是递增的，是不要进行维护即可从数据库中获得的，同时由ado直接返回给前端程序，以便定位和显示、

INSERT INTO jobs (job_desc,min_lvl,max_lvl)

VALUES ('Accountant',12,125)

SELECT @@IDENTITY AS 'Identity'

但是再由sqlserver2000升级到sqlserver2008后，发现返回的@@identtiy明显是错误的

后来查了一下SQLServer2000联机帮助

在一条 INSERT、SELECT INTO 或大容量复制语句完成后，@@IDENTITY 中包含此语句产生的最后的标识值。若此语句没有影响任何有标识列的表，则 @@IDENTITY 返回 NULL。若插入了多个行，则会产生多个标识值，@@IDENTITY 返回最后产生的标识值。如果此语句激发一个或多个执行产生标识值的插入操作的触发器，则语句执行后立即调用 @@IDENTITY 将返回由触发器产生的最后的标识值。若 INSERT 或 SELECT INTO 语句失败或大容量复制失败，或事务被回滚，则 @@IDENTITY 值不会还原为以前的设置。

发现通过

SELECT IDENT_CURRENT('tablename')能够返回正确的递增值

但是否能获取这个值，不得而知

从sqlserver2005以后系统提供了NEWSEQUENTIALID ()，这个新的guid

Creates a GUID that is greater than any GUID previously generated by this function on a specified computer since Windows was started. After restarting Windows, the GUID can start again from a lower range, but is still globally unique. When a GUID column is used as a row identifier, using NEWSEQUENTIALID can be faster than using the NEWID function. This is because the NEWID function causes random activity and uses fewer cached data pages. Using NEWSEQUENTIALID also helps to completely fill the data and index pages.

这个guid是由操作系统产生的，但是每个guid都会比前一个guid要大，这即解决了唯一性问题，又解决了排序问题

目前开发人员正准备按这个思路进行修改

本文转自baoqiangwang51CTO博客，原文链接：http://blog.51cto.com/baoqiangwang/353171

，如需转载请自行联系原作者