对于中文版的SQL SERVER,默认安装后使用的默认排序规则为Chinese_PRC_CI_AS,在此排序规则下,使用varchar类型来可以“正常存取”存放中文字符以及一些东南亚国家的字符,同时varchar类型在存放英文字符和数字时比nvarchar节省一半的存储空间,因此很多DBA都习惯使用varchar类型来存放字符数据,但这样便存在一些乱码隐患! 首先是特殊字符如上下标或版权字符,测试Code如下: --准备测试表 DROP TABLE TB1 GO CREATE TABLE TB1…

原文:曲演杂坛--一条DELETE引发的思考 场景介绍: 我们有一张表,专门用来生成自增ID供业务使用,表结构如下: CREATE TABLE TB001 ( ID ,) PRIMARY KEY, DT DATETIME ) 每次业务想要获取一个新ID,就执行以下SQL: INSERT INTO TB001(DT) SELECT GETDATE(); SELECT @@IDENTITY 由于这些数据只需保留最近一天的数据,因此建立一个SQL作业来定期删除数据,删除脚本很简单: DELETE TO…

对于中文版的SQL SERVER,默认安装后使用的默认排序规则为Chinese_PRC_CI_AS,在此排序规则下,使用varchar类型来可以“正常存取”存放中文字符以及一些东南亚国家的字符,同时varchar类型在存放英文字符和数字时比nvarchar节省一半的存储空间,因此很多DBA都习惯使用varchar类型来存放字符数据,但这样便存在一些乱码隐患! 首先是特殊字符如上下标或版权字符,测试Code如下: --准备测试表 DROP TABLE TB1 GO CREATE TABLE TB1…

使用ROW_NUMBER来分页几乎是家喻户晓的东东了,而且这东西简单易用,简直就是程序员居家必备之杀器,然而ROW_NUMBER也不是一招吃遍天下鲜的无敌BUG般存在,最近就遇到几个小问题,拿出来供大家娱乐下. ---====================================================== 问题1:为什么加WHERE条件就慢,不加反而快? 查询SQL: WITH Temp AS( SELECT * , ROW_NUMBER()OVER(ORDER BY T2.…

值班期间研发同事打来电话,说应用有超时,上服务器上检查发现有SQL大批量地执行,该SQL消耗IO资源较多,导致服务器存在IO瓶颈,细看SQL,发现自己都被整蒙了,不知道这SQL是要干啥,处理完问题赶紧研究下. SQL类似于: WITH T1 AS ( ) ID , ROW_NUMBER() OVER ( ORDER BY C1 ) AS RID FROM [dbo].[TB002] ) SELECT * FROM T1 ) 第一赶脚是写这代码的研发同事想分页,但是这每页的数据量有点吓人啊(是我太…

在一次系统优化中,意外发现一个比较“坑”的SQL,拿出来供大家分享. 生成演示数据: --====================================== --检查测试表是否存在 IF(OBJECT_ID('TB2002') IS NOT NULL) BEGIN DROP TABLE TB2002 END GO --============================ --生成测试数据并创建索引 SELECT ,) AS ID, * INTO TB2002 FROM sys.co…

很多刚入门的DBA在捕获阻塞得时候,会问这么一个问题“为什么这个SELECT语句被那个SELECT语句阻塞了,难道不是共享锁么?” 让我们来做个小测试,首先准备一些测试数据: --====================================== --准备测试数据 SELECT ROW_NUMBER()OVER(ORDER BY object_id) AS RID, name AS C1 INTO TB003 FROM sys.all_columns GO CREATE UNIQUE…

通常在我写EXISTS语句时,我会写成IF EXISTS(SELECT TOP(1) 1 FROM XXX),也没细细考究过为什么要这么写,只是隐约认为这样写没有啥问题,那今天就深究下吧! 首先准备测试测试数据 USE [TestDB1] GO CREATE TABLE TB1001 ( ID ,), C1 ), CONSTRAINT PK_TB1001_ID PRIMARY KEY(ID) ) GO CREATE INDEX IDX_ID ON TB1001(ID) GO INSERT INT…

今天使用SQLCMD导入到SQL SERVER数据库中,看着数据文件都成功执行,但是意外发现有一个文件数据没有成功导入,但执行不报错,很容易导致问题被忽略. 使用存在问题的文件做下测试,从界面上看几行脚本没有任何问题: 4条INSERT语句“几乎”一样,区别在于最上面三行的部分文字是我从问题语句中粘贴出来,而最后一行是我手动敲打的. 使用SQLCMD来执行上面4条SQL来执行,执行效果为: 看上去没有任何错误提示,似乎顺利执行完成,但数据没有成功插入到表中,且在没有设置“SET NOCOUNT…

今天偶然想起一个UPDATE相关的小问题,正常情况下,如果我们将UPDATE改写成与之对应的SELECT语句,其SELECT查询结果应与UPDATE的目标表存在一对一的关系,例如: 对于UPDATE语句: UPDATE TB1 SET C2=TB2.C2 FROM TB1 INNER JOIN TB2 ON TB1.C1=TB2.C1 假设TB1中C1为主键,那么改写成对应的SELECT SQL SELECT TB1.C1, TB1.C2 AS C2_OLD, TB2.C2 AS C2_NEW…