SQLServer性能调优指南-优快云博客

本文链接：https://blog.youkuaiyun.com/octverve/article/details/2037046

SQL Server 2000 三个表连接SQL语句
SELECT top 1 a.simNum,a.UserID,b.DeviceNum,c.DeviceVersion FROM VehicleInfo a JOIN VehicleDetailInfo b
ON b.VehID=1028 join DeviceModelInfo c ON b.DeviceNo=c.DeviceNo

-------------------------------------------------------------------------------------------------
SQL SERVER字符串前加N，什么含义？,SQL语句里nchar类型的字段我不想加N，怎么办？
问.SQL SERVER字符串前加N，什么含义？,
请教：
看到SQL SERVER自己生成的脚本，字符串前通常都加一个N字母。
请问这个N说明什么含义？加与不加在SQL编写上有何影响？

答:是Unicode编码的意思,一般来说,英文字符是一个字节组成,但是国际上的字太多了,因此就用两个字节来表示字符,满足国际化的需要.
if your database's collation is english collation, such as sql_latin1_general_ci_as, and
if you want to input chinese characters into a nvarchar column, then you have to use
N'字符' to input chinese.
Note: '字符' is wrong character string for english collation, and can not be inserted into any varchar/nvarchar column

SQL语句里nchar类型的字段我不想加N，怎么办？

try:

更改排序规则。

alter   database   数据库   collate   排序规格


使用如下命令，可以获得更多的规则：
SELECT   *
FROM   ::fn_helpcollations()

如：

简体
alter   database   数据库   COLLATE   Chinese_PRC_CI_AS

繁体
alter   database   数据库   COLLATE   Chinese_Taiwan_Bopomofo_CI_AS

加吧.不加不行.
-----------------------------------------
数据库性能调优技术-索引调优
一、概述
随着数据库在各个领域的使用不断增长，越来越多的应用提出了高性能的要求。数据库性能调优是知识密集型的学科，需要综合考虑各种复杂的因素：数据库缓冲区的大小、索引的创建、语句改写等等。总之，数据库性能调优的目的在于使系统运行得更快。

调优需要有广泛的知识，这使得它既简单又复杂。

说调优简单，是因为调优者不必纠缠于复杂的公式和规则。许多学术界和业界的研究者都在尝试将调优和查询处理建立在数学基础之上。

称调优复杂，是因为如果要完全理解常识所依赖的原理，还需要对应用、数据库管理系统、操作系统以及硬件有广泛而深刻的理解。

数据库调优技术可以在不同的数据库系统中使用。如果需要调优数据库系统，最好掌握如下知识：1）查询处理、并发控制以及数据库恢复的知识；2）一些调优的基本原则。

这里主要描述索引调优。

二、索引调优
   索引是建立在表上的一种数据组织，它能提高访问表中一条或多条记录的特定查询效率。因此，适当的索引调优是很重要的。
   对于索引调优存在如下的几个误区：
   误区1：索引创建得越多越好？
   实际上：创建的索引可能建立后从来未使用。索引的创建也是需要代价的，对于删除、某些更新、插入操作，对于每个索引都要进行相应的删除、更新、插入操作。从而导致删除、某些更新、插入操作的效率变低。

误区2：对于一个单表的查询，可以索引1进行过滤再使用索引2进行过滤？

实际上：假设查询语句如下select * from t1 where c1=1 and c2=2，c1列和c2列上分别建有索引ic1、ic2。先使用ic1(或ic2)进行过滤，产生的结果集是临时数据，不再具有索引，所以不可使用ic2(或ic1)进行再次过滤。

索引优化的基本原则：
1.将索引和数据存放到不同的文件组
没有将表数据和索引数据存储到不同的文件组，而不加区别地将它们存储到同一文件组。这样，不但会造成I/O竞争，也为数据库的维护工作带来不变。

2.组合索引的使用
假设存在组合索引it1c1c2(c1,c2)，查询语句select * from t1 where c1=1 and c2=2能够使用该索引。查询语句select * from t1 where c1=1也能够使用该索引。但是，查询语句select * from t1 where c2=2不能够使用该索引，因为没有组合索引的引导列，即，要想使用c2列进行查找，必需出现c1等于某值。
根据where条件的不同，归纳如下：
1) c1=1 and c2=2：使用索引it1c1c2进行等值查找。
2) c1=1 and c2>2：使用索引it1c1c2进行范围查找，可以有两种方法。
方法1，使用通过索引键(1,2)在B树中命中一条记录，然后向后扫描找出第一条符合条件的记录，从此记录往后的每一条记录都是符合条件的。这种方法的弊端在于：如果c1=1 and c2=2对应的记录数很多，会产生很多无效的扫描。

方法2，如果c2对应的int型数据，可以使用索引键(1,3)在B树中命中一条记录，从此记录往后的每一条记录都是符合条件的。
本文中的例子均采用方法1。

3）c1>1 and c2=2：因为索引的第一个列不是等于号的，索引即使后面出现了c2=2，也不能将c2=2应用于索引查找。这里，通过索引键(1,- ∞)在B树中命中一条记录，向后扫描找出第一条符合c1>1的记录，此后的每一条记录判断是否符合c2=2，如果符合则输出，否则过滤掉。这里我们称c2=2没有参与到索引运算中去。这种情况在实际应用中经常出现。
4）c1>1：通过索引键(1,- ∞) 在B树中命中一条记录，以此向后扫描找出第一条符合c1>1的记录，此后的每条记录都是符合条件的。

3.唯一索引与非唯一索引的差异
   假设索引int1c1(c1)是唯一索引，对于查询语句select c1 from t1 where c1=1，达梦数据库使用索引键(1)命中B树中一条记录，命中之后直接返回该记录（因为是唯一索引，所以最多只能有一条c1=1的记录）。
   假设索引it1c2(c2)是非唯一索引，对于查询语句select c2 from t2 where c2=2，达梦数据库使用索引键(2)命中B树中一条记录，返回该记录，并继续向后扫描，如果该记录是满足c=2，返回该记录，继续扫描，直到遇到第一条不符合条件c2=2的记录。
   于是，我们可以得知，对于不存在重复值的列，创建唯一索引优于创建非唯一索引。

4.非聚集索引的作用
每张表只可能一个聚集索引，聚集索引用来组织真实数据。语句“create table employee (id int cluster primary key,name varchar(20),addr varchar(20))”。表employee的数据用id来组织。如果要查找id=1000的员工记录，只要用索引键（1000）命中该聚集索引。但是，对于要查找name=’张三’的员工记录就不能使用该索引了，需要进行全表扫描，对于每一条记录判断是否满足name=’张三’，这样会导致查询效率非常低。
要使用聚集索引，必需提供id，我们只能提供name，于是需要引入一个辅助结构实现name到id的转换，这就是非聚集索引的作用。该非聚集索引的键是name，值是id。于是语句“select * from employee where name=’张三’”的执行流程是：通过键（’张三’）命中非聚集索引，得到对应的id值3（假设’张三’对应的id为3），然后用键(3)命中聚集索引，得到相应的记录。

5.是不是使用非聚集索引的查询都需要进行聚集的查询？
不是的，虽然在上一点中查询转换为聚集索引的查找，有时候可以只需要使用非聚集索引。
创建表并创建相应的索引：create table t1(c1 int,c2 int,c3 int);create index it1c2c3 on t1(c2,c3)。查询语句为：select c3 from t1 where c2=1。
因为索引it1c2c3(c2,c3)覆盖查询语句中的列(c2,c3)。所以，该查询语句的执行流程为：通过索引键(1,- ∞)命中索引it1c2c3，对于该记录直接返回c3对应的值，继续向后扫描，如果索引记录中c1还是等于1，那么输出c3，以此类推，直到出现第一条c1不等于1的索引记录,结束查询。

6.创建索引的规则
创建索引首先要考虑的是列的可选择性。比较一下列中唯一键的数量和表中记录的行数，就可以判断该列的可选择性。如果该列的“唯一键的数量/表中记录行数”的比值越接近于1，则该列的可选择行越高。在可选择性高的列上进行查询，返回的数据就较少，比较适合索引查询。相反，比如性别列上只有两个值，可选择行就很小，不适合索引查询。

-----------------------------------------------------------------------------
SQL Server 中调整自增字段的当前初始值
前几天在把一个Communtiy Server 的数据库从SQL 2000升级到SQL 2005 的时候，碰到一个怪异的问题，报如下错误：

Violation of PRIMARY KEY constraint 'PK_cs_Threads'. Cannot insert duplicate key in object 'dbo.cs_Threads'.

分析进去后，竟然发现这个表的自增字段数据库中已经达到了6144，而数据库维护的这个表的初始自增值只到6109。

解决方法很简单，利用以下SQL 语句即可搞定：

DBCC CHECKIDENT ('cs_Threads')

上述语句的意思就是：如果表'cs_Threads'的当前标识值小于列中存储的最大标识值，则使用标识列中的最大值对其进行重置。

CHECKIDENT 命令可以有以下几种写法：

1、DBCC CHECKIDENT ('table_name', NORESEED)

不重置当前标识值。DBCC CHECKIDENT 返回一个报表，它指明当前标识值和应有的标识值。

类似如下的报表：

Checking identity information: current identity value '6109', current column value '6144'.

2、DBCC CHECKIDENT ('table_name') 或DBCC CHECKIDENT ('table_name', RESEED)

如果表的当前标识值小于列中存储的最大标识值，则使用标识列中的最大值对其进行重置。

上述命令执行的时候，也会报类似上面的报表。

3、DBCC CHECKIDENT ('table_name', RESEED, new_reseed_value)

当前值设置为 new_reseed_value。

如果自创建表后没有将行插入该表，则在执行 DBCC CHECKIDENT 后插入的第一行将使用 new_reseed_value 作为标识。否则，下一个插入的行将使用 new_reseed_value + 1。

如果 new_reseed_value 的值小于标识列中的最大值，以后引用该表时将产生 2627 号错误信息。

----------------------------------------------------------------------------------------

使用时容易忽略SQL Server的21个问题
如果你正在负责一个基于SQL Server的项目，或者你刚刚接触SQL Server，你都有可能要面临一些数据库性能的问题，这篇文章会为你提供一些有用的指导（其中大多数也可以用于其它的DBMS）。
　　在这里，我不打算介绍使用SQL Server的窍门，也不能提供一个包治百病的方案，我所做的是总结一些经验----关于如何形成一个好的设计。这些经验来自我过去几年中经受的教训，一直来，我看到许多同样的设计错误被一次又一次的重复。

　　你了解工具吗？

　　不要轻视这一点，这是我在这篇文章中讲述的最关键的一条。也许你也看到有很多的SQL Server程序员没有掌握全部的T-SQL命令和SQL Server提供的那些有用的工具。

　　“什么？我要浪费一个月的时间来学习那些我永远也不会用到的SQL命令？？？”，你也许会这样说。对的，你不需要这样做。但是你应该用一个周末浏览所有的T-SQL命令。在这里，你的任务是了解，将来，当你设计一个查询时，你会记起来：“对了，这里有一个命令可以完全实现我需要的功能”，于是，到MSDN查看这个命令的确切语法。

　　不要使用光标

　　让我再重复一遍：不要使用光标。如果你想破坏整个系统的性能的话，它们倒是你最有效的首选办法。大多数的初学者都使用光标，而没有意识到它们对性能造成的影响。它们占用内存，还用它们那些不可思议的方式锁定表，另外，它们简直就像蜗牛。而最糟糕的是，它们可以使你的DBA所能做的一切性能优化等于没做。不知你是否知道每执行一次FETCH就等于执行一次SELECT命令？这意味着如果你的光标有10000条记录，它将执行10000次SELECT！如果你使用一组SELECT、UPDATE或者DELETE来完成相应的工作，那将有效率的多。

　　初学者一般认为使用光标是一种比较熟悉和舒适的编程方式，可很不幸，这会导致糟糕的性能。显然，SQL的总体目的是你要实现什么，而不是怎样实现。

　　我曾经用T-SQL重写了一个基于光标的存储过程，那个表只有100,000条记录，原来的存储过程用了40分钟才执行完毕，而新的存储过程只用了10秒钟。在这里，我想你应该可以看到一个不称职的程序员究竟在干了什么！！！

　　我们可以写一个小程序来取得和处理数据并且更新数据库，这样做有时会更有效。记住：对于循环，T-SQL无能为力。

　　我再重新提醒一下：使用光标没有好处。除了DBA的工作外，我从来没有看到过使用光标可以有效的完成任何工作。

　　规范化你的资料表

　　为什么不规范化数据库？大概有两个借口：出于性能的考虑和纯粹因为懒惰。至于第二点，你迟早得为此付出代价。而关于性能的问题，你不需要优化根本就不慢的东西。我经常看到一些程序员“反规范化”数据库，他们的理由是“原来的设计太慢了”，可结果却常常是他们让系统更慢了。DBMS被设计用来处理规范数据库的，因此，记住：按照规范化的要求设计数据库。

　　不要使用SELECT *

　　这点不太容易做到，我太了解了，因为我自己就经常这样干。可是，如果在SELECT中指定你所需要的列，那将会带来以下的好处：

　　1 减少内存耗费和网络的带宽

　　2 你可以得到更安全的设计

　　3 给查询优化器机会从索引读取所有需要的列

　　了解你将要对数据进行的操作

　　为你的数据库创建一个健壮的索引，那可是功德一件。可要做到这一点简直就是一门艺术。每当你为一个表添加一个索引，SELECT会更快了，可INSERT和DELETE却大大的变慢了，因为创建了维护索引需要许多额外的工作。显然，这里问题的关键是：你要对这张表进行什么样的操作。这个问题不太好把握，特别是涉及DELETE和UPDATE时，因为这些语句经常在WHERE部分包含SELECT命令。

　　不要给“性别”列创建索引

　　首先，我们必须了解索引是如何加速对表的访问的。你可以将索引理解为基于一定的标准上对表进行划分的一种方式。如果你给类似于“性别”这样的列创建了一个索引，你仅仅是将表划分为两部分：男和女。你在处理一个有1,000,000条记录的表，这样的划分有什么意义？记住：维护索引是比较费时的。当你设计索引时，请遵循这样的规则：根据列可能包含不同内容的数目从多到少排列，比如：姓名+省份+性别。

　　使用事务

　　请使用事务，特别是当查询比较耗时。如果系统出现问题，这样做会救你一命的。一般有些经验的程序员都有体会-----你经常会碰到一些不可预料的情况会导致存储过程崩溃。

　　小心死锁

　　按照一定的次序来访问你的表。如果你先锁住表A，再锁住表B，那么在所有的存储过程中都要按照这个顺序来锁定它们。如果你（不经意的）某个存储过程中先锁定表B，再锁定表A，这可能就会导致一个死锁。如果锁定顺序没有被预先详细的设计好，死锁是不太容易被发现的。

　　不要打开大的资料集

　　在技术论坛中，一个经常被提出的问题是：我怎样才能迅速的将100000条记录添加到ComboBox中？这是不对的，你不能也不需要这样做。很简单，你的用户要浏览100000条记录才能找到需要的记录，他一定会诅咒你的。在这里，你需要的是一个更好的UI，你需要为你的用户显示不超过100或200条记录。

　　不要使用服务器端光标

　　与服务器端光标比起来，客户端光标可以减少服务器和网络的系统开销，并且还减少锁定时间。

　　使用参数查询

　　有时，我在技术论坛看到类似这样的问题：“SELECT * FROM a WHERE a.id='A'B，因为单引号查询发生异常，我该怎么办？”，而普遍的回答是：用两个单引号代替单引号。这是错误的。这样治标不治本，因为你还会在其它一些字符上遇到这样的问题，更何况这样会导致严重的bug，除此以外，这样做还会使SQL Server的缓冲系统无法发挥应有的作用。使用参数查询，釜底抽薪，这些问题统统不存在了。

　　在程序编码时使用大数据量的数据库

　　程序员在开发中使用的测试数据库一般数据量都不大，可经常的是最终用户的数据量都很大。我们通常的做法是不对的，原因很简单：现在硬盘不是很贵，可为什么性能问题却要等到已经无可挽回的时候才被注意呢？

　　不要使用INSERT导入大批的数据

　　请不要这样做，除非那是必须的。使用UTS或者BCP，这样你可以一举而兼得灵活性和速度。

　　注意超时问题

　　查询数据库时，一般数据库的缺省都比较小，比如15秒或者30秒。而有些查询运行时间要比这长，特别是当数据库的数据量不断变大时。

　　不要忽略同时修改同一记录的问题

　　有时候，两个用户会同时修改同一记录，这样，后一个修改者修改了前一个修改者的操作，某些更新就会丢失。处理这种情况不是很难：创建一个timestamp字段，在写入前检查它，如果允许，就合并修改，如果存在冲突，提示用户。

　　在细节表中插入纪录时，不要在主表执行SELECT MAX(ID)

　　这是一个普遍的错误，当两个用户在同一时间插入数据时，这会导致错误。你可以使用SCOPE_IDENTITY，IDENT_CURRENT和@@IDENTITY。如果可能，不要使用@@IDENTITY，因为在有触发器的情况下，它会引起一些问题（详见这里的讨论）。

　　避免将列设为NULLable

　　如果可能的话，你应该避免将列设为NULLable。系统会为NULLable列的每一行分配一个额外的字节，查询时会带来更多的系统开销。另外，将列设为NULLable使编码变得复杂，因为每一次访问这些列时都必须先进行检查。