1、数据库优化规范
a.索引
每个表格都要求建立主键，主键上不一定需要强制建立聚集索引。
聚集索引，表中存储的数据按照索引的顺序存储，即逻辑顺序决定了表中相应行的物理顺序，因此聚集索引的字段值应是不会改变的值，并且是顺序增长的，否则对数据新增/修改/删除的影响比较大。
非聚集索引，一般考虑在下列情形下使用非聚集索引：使用JOIN的条件字段、使用GROUP BY的字段、完全匹配的WHERE条件字段、外键字段等等。
索引是有900字节大小限制的，因此不要在超长字段上建索引，索引字段的总字节数不要超过900字节，否则插入的数据达到900字节时会报错。
合理建立索引，合理建立索引，合理建立索引。
b.使用SET NOCOUNT ON 选项
缺省地，每次执行SQL语句时，一个消息会从服务端发给客户端以显示SQL语句影响的行数。这些信息对客户端来说很少有用，甚至有些客户端会把这些信息当成错误信息处理。通过关闭这个缺省值，你能减少在服务端和客户端的网络流量，帮助全面提升服务器和应用程序的性能。为了关闭存储过程级的这个特点，在每个存储过程的开头包含“SET NOCOUNT ON”语句。同样，为减少在服务端和客户端的网络流量，生产环境中应该去掉存储过程中那些在调试过程中使用的SELECT和PRINT语句。
c.正确使用UNION和UNION ALL
许多人没完全理解UNION和UNION ALL是怎样工作的，因此，结果浪费了大量不必要的SQL Server资源。当使用UNION时，它相当于在结果集上执行SELECT DISTINCT。换句话说，UNION将联合两个相类似的记录集，然后搜索重复的记录并排除。如果这是你的目的，那么使用UNION是正确的。但如果你使用UNION联合的两个记录集本身就没有重复记录，那么使用UNION会浪费资源，因为它要寻找重复记录，即使你确定它们不存在。
所以如果你知道你要联合的记录集里没有重复，那么你要使用UNION ALL，而不是UNION。UNION ALL联合记录集，但不搜索重复记录，这样减少SQL Server资源的使用，从而提升性能。
d.只返回需要的数据，尽量不用SELECT *
绝大多数情况下，不要用 * 来代替查询返回的字段列表，用 * 的好处是代码量少、就算是表结构或视图的列发生变化，编写的查询SQL语句也不用变，都返回所有的字段。但数据库服务器在解析时，如果碰到 *，则会先分析表的结构，然后把表的所有字段名再罗列出来，这就增加了分析的时间。
另一个问题是，SELECT * 可能包含了不需要的列，增加了网络流量。如果在视图创建中使用了SELECT *，在后期如果有对视图基表的表结构进行了更改，当查询视图时，可能会生成意外结果，除非重建视图或利用sp_refreshview更新视图的元数据。
e.慎用SELECT DISTINCT
DISTINCT子句仅在特定功能的时候使用，即从记录集中排除重复记录的时候。这是因为DISTINCT子句先获取结果集然后去重，这样增加了SQL Server资源的消耗。当然，如果你需要去做，那就只有去做了。
如果你知道SELECT语句将从不返回重复记录，那么使用DISTINCT语句是对SQL Server资源不必要的浪费。
f.少用游标
任何一种游标都会降低SQLServer性能。有些情况不能避免，但大多数情况可以避免，所以如果你的应用程序目前正在使用TSQL游标，看看这些代码是否能够重写以避免它们。如果你需要一行一行的执行操作，考虑使用批处理来代替游标的使用。
g.字段前加指定的别名
当在SQL语句中连接多个表时，请将表名或别名加到每个Column前面，这样可以减少解析的时间并减少那些由Column歧义引起的语法错误。
h.SARG你的WHERE条件
ARGE来源于"Search Argument"（搜索参数）的首字母拼成的"SARG"，它是指WHERE子句里，列和常量的比较。如果WHERE子句是sargable（可SARG的），这意味着它能利用索引加速查询的完成。如果WHERE子句不是可SARG的，这意味着WHERE子句不能利用索引（或至少部分不能利用），执行的是全表或索引扫描，这会引起查询的性能下降。
在WHERE子句里不可SARG的搜索条件如"IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT IKE"和"LIKE ‘%500‘"，通常（但不总是）会阻止查询优化器使用索引执行搜索。另外在列上使用包括函数的表达式、两边都使用相同列的表达式、或和一个列（不是常量）比较的表达式，都是不可SARG的。
并不是每一个不可SARG的WHERE子句都注定要全表扫描。如果WHERE子句包括两个可SARG和一个不可SARG的子句，那么至少可SARG的子句能使用索引（如果存在的话）帮助快速访问数据。
大多数情况下，如果表上有包括查询里所有SELECT、JOIN、WHERE子句用到的列的覆盖索引，那么覆盖索引能够代替全表扫描去返回查询的数据，即使它有不可SARG的WHERE子句。但记住覆盖索引尤其自身的缺陷，如此经常产生宽索引会增加读磁盘I/O。某些情况下，可以把不可SARG的WHERE子句重写成可SARG的子句。例如：
WHERE SUBSTRING(firstname,1,1) = ‘m‘ 可以写成：WHERE firstname like ‘m%‘
这两个WHERE子句有相同的结果，但第一个是不可SARG的（因为使用了函数）将运行得慢些，而第二个是可SARG的，将运行得快些。
如果你不知道特定的WHERE子句是不是可SARG的，在查询分析器里检查查询执行计划。这样做，你能很快的知道查询是使用了索引还是全表扫描来返回的数据。仔细分析，许多不可SARG的查询能写成可SARG的查询。
i.避免或简化排序
应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤。以下是一些影响因素：
索引中不包括一个或几个待排序的列；
group by或order by子句中列的次序与索引的次序不一样；
排序的列来自不同的表。
为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提高是值得的）。如果排序不可避免，那么应当试图简化它，如缩小排序的列的范围等。
j.注意事务和锁
事务是数据库应用中和重要的工具，它有原子性、一致性、隔离性、持久性这四个属性，很多操作我们都需要利用事务来保证数据的正确性。在使用事务中我们需要做到尽量避免死锁、尽量减少阻塞。具体以下方面需要特别注意：
1)事务操作过程要尽量小，能拆分的事务要拆分开来。
2)事务操作过程不应该有交互，因为交互等待的时候，事务并未结束，可能锁定了很多资源。
3)事务操作过程要按同一顺序访问对象，比如在一事务中要按顺序更新A、B两表，那么在别的事务中就不要按B、A的顺序去更新这两个表。
4)提高事务中每个语句的效率，利用索引和其他方法提高每个语句的效率可以有效地减少整个事务的执行时间。
5)尽量不要指定锁类型和索引，SQL SERVER允许我们自己指定语句使用的锁类型和索引，但是一般情况下，SQL Server优化器选择的锁类型和索引是在当前数据量和查询条件下是最优的，我们指定的可能只是在目前情况下更优，但是数据量和数据分布在将来是会变化的。
k.用存储过程代替直接写查询语句
存储过程为开发人员提供了很多好处，包括：
减少网络流量和响应时间，提升应用程序性能。例如，通过网络发送一个存储过程调用，而不是发送500行的TSQL将更快，资源使用更少。当每次执行SQL时，都会执行解析SQL语句、估算索引的利用率、绑定变量、读数据块等等工作。
存储过程执行计划能够重用，驻留在SQL Server内存的缓存里，减少服务器开销。
客户端执行请求更有效率。例如，如果应用程序需要插入大量的二进制值到一个image数据列而不使用存储过程，它必须转化二进制为字符串（大小会增加一倍），然后发送给SQL Server。当SQL Server接收到后，它必须把字符串值转回二进制格式。大量的浪费开销。存储过程能消除这个问题通过将应用程序传给SQL Server的二进制格式作为参数，从而减少开销提升性能。
存储过程帮助提供代码重用。虽然这些不直接提升应用程序的性能，通过减少代码量和减少调试时间来提升开发人员的效率。
存储过程能封装逻辑。你能够改变存储过程代码而不影响客户端（假定你保持参数相同也不移除任何结果集的列）。这节约开发人员的时间。
存储过程为你的数据提供更好的安全性。如果你仅使用存储过程，你可以移除直接对表的SELECT、INSERT、UPDATE和DELETE权限从而强迫开发人员使用存储过程访问数据。这会节约DBA的时间。
l.不要在子查询中使用count()求和执行存在性检查
不要使用这样的语句：
SELECT column_list FROM tablename WHERE 0 < (SELECT count(*) FROM table2 WHERE ..)
应使用这样的语句代替：
SELECT column_list FROM tablename WHERE EXISTS(SELECT * FROM table2 WHERE ...)
当你使用count()时，SQL Server不知道你要做的是存在性检查，它会计算所有匹配的值，要么会执行全表扫描，要么会扫描最小的非聚集索引。当你使用EXISTS时，SQL Server知道你要执行存在性检查，当它发现第一个匹配的值时，就会返回TRUE，并停止查询。
m.临时表和表变量的用法
在复杂系统中，临时表和表变量很难避免，关于临时表和表变量的用法，需要注意：
1)如果语句很复杂，连接太多，可以考虑用临时表和表变量分步完成。
2)如果需要多次用到一个大表的同一部分数据，考虑用临时表和表变量暂存这部分数据。
3)如果需要综合多个表的数据，形成一个结果，可以考虑用临时表和表变量分步汇总这多个表的数据。
4)其他情况下，应该控制临时表和表变量的使用。
5)关于临时表和表变量的选择，很多说法是表变量在内存，速度快，应该首选表变量，但是在实际使用中发现，这个选择主要考虑需要放在临时表的数据量，在数据量较多的情况下，临时表的速度反而更快。
6)关于临时表产生使用SELECT INTO和CREATE TABLE + INSERT INTO的选择，我们做过测试，一般情况下，SELECT INTO会比CREATE TABLE + INSERT INTO的方法快很多，但是SELECT INTO会锁定TEMPDB的系统表SYSOBJECTS、SYSINDEXES、SYSCOLUMNS，在多用户并发环境下，容易阻塞其他进程，所以我的建议是，在并发系统中，尽量使用CREATE TABLE + INSERT INTO，而大数据量的单个语句使用中，使用SELECT INTO。
注意排序规则，用CREATE TABLE建立的临时表，如果不指定字段的排序规则，会选择TEMPDB的默认排序规则，而不是当前数据库的排序规则。如果当前数据库的排序规则和TEMPDB的排序规则不同，连接的时候可能会出现排序规则的冲突错误。一般可以在CREATE TABLE建立临时表时指定字段的排序规则为DATABASE_DEFAULT来避免上述问题。
ps：SQL数据库中临时表、临时变量和WITH AS关键词创建“临时表”的区别
1).with tempTableName as方法（05之后出现）：
with temptable as 其实并没有建立临时表，只是子查询部分（subquery factoring），定义一个SQL片断，该SQL片断会被整个SQL语句所用到。有的时候，是为了让SQL语句的可读性更高些，也有可能是在UNION ALL的不同部分，作为提供数据的部分。特别对于UNION ALL比较有用。因为UNION ALL的每个部分可能相同，但是如果每个部分都去执行一遍的话，则成本太高，所以可以使用WITH AS短语，则只要执行一遍即可。
2).临时表方法
临时表与永久表相似，只是它的创建是在Tempdb中，它只有在一个数据库连接结束后或者由SQL命令DROP掉，才会消失，否则就会一直存在（临时表一般被创建后，如果在执行的时候，没有通过DROP Table的操作，第二次就不能再被创建）。临时表在创建的时候都会产生SQL Server的系统日志，虽它们在Tempdb中体现，是分配在内存中的，它们也支持物理的磁盘，但用户在指定的磁盘里看不到文件。
临时表分为本地和全局两种，本地临时表的名称都是以“#”为前缀，只有在本地当前的用户连接中才是可见的，当用户从实例断开连接时被删除。全局临时表的名称都是以“##”为前缀，创建后对任何用户都是可见的，当所有引用该表的用户断开连接时被删除。
3).表变量方法
表变量创建的语法类似于临时表，区别就在于创建的时候，必须要为之命名。表变量是变量的一种，表变量也分为本地及全局的两种，本地表变量的名称都是以“@”为前缀，只有在本地当前的用户连接中才可以访问。全局的表变量的名称都是以“@@”为前缀，一般都是系统的全局变量，像我们常用到的，如@@Error代表错误的号，@@RowCount代表影响的行数。
临时表和表变量的区别：
1)表变量是存储在内存中的，当用户在访问表变量的时候，SQL Server是不产生日志的，而在临时表中是产生日志的;
2)在表变量中，是不允许有非聚集索引的;
3)表变量是不允许有DEFAULT默认值，也不允许有约束;
4)临时表上的统计信息是健全而可靠的，但是表变量上的统计信息是不可靠的;
5)临时表中是有锁的机制，而表变量中就没有锁的机制。
临时表和表变量的选择：
1)使用表变量主要需要考虑的就是应用程序对内存的压力，如果代码的运行实例很多，就要特别注意内存变量对内存的消耗。我们对于较小的数据或者是通过计算出来的推荐使用表变量。如果数据的结果比较大，在代码中用于临时计算，在选取的时候没有什么分组的聚合，就可以考虑使用表变量。
2)一般对于大的数据结果，或者因为统计出来的数据为了便于更好的优化，我们就推荐使用临时表，同时还可以创建索引，由于临时表是存放在Tempdb中，一般默认分配的空间很少，需要对tempdb进行调优，增大其存储的空间。
欢迎大家关注微信号，微信公众号名称：DotNet修炼宝典。 扫下面的二维码或者收藏下面的二维码关注吧（长按下面的二维码图片、并选择识别图中的二维码）
原文地址：https://www.cnblogs.com/MaxInfo/p/8289033.html