开发者社区> 技术小美> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

在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,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
SQL Server里的文件和文件组
原文:SQL Server里的文件和文件组 在今天的文章里,我想谈下SQL Server里非常重要的话题:SQL Server如何处理文件的文件组。当你用CREATE DATABASE命令创建一个简单的数据库时,SQL Server为你创建2个文件: 一个数据文件(.mdf) 一个事务日志文件(.ldf) 数据文件本身在有且只有一个主文件组里创建。
1048 0
SQL点滴7—使用SQL Server的attach功能出现错误及解决方法
原文:SQL点滴7—使用SQL Server的attach功能出现错误及解决方法 今天用SQL Server 2008的attach功能附加一个数据库,出了点问题,提示的错误是: Unable to open physical file "D:\Documents\Dalt\XXXX.
867 0
SQL Server 字符串处理
DECLARE @str VARCHAR(50) SET @str='AP-FQC-2014072300004' --获取指定字符第一次出现的位置 SELECT PATINDEX('%-%',@str) --返回:3 --获取指定字符第一次出现的位置之前的字符串 SELECT S...
701 0
发现SQL Server惊天大秘密!!
原文:发现SQL Server惊天大秘密!! --set statistics xml onCREATE TABLE T_TEST(ID INT IDENTITY PRIMARY KEY,CreateTime DATE)INSERT INTO T_TEST SELECT '2011-11-04...
980 0
SQL点滴7—使用SQL Server的attach功能出现错误及解决方法
今天用SQL Server 2008的attach功能附加一个数据库,出了点问题,提示的错误是: Unable to open physical file "D:\Documents\Dalt\XXXX.
646 0
+关注
6819
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载