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软件编程IT技术

.NET技术面试题系列(2) -sql server数据库优化规范的更多相关文章

  1. C#面试题(转载) SQL Server 数据库基础笔记分享(下) SQL Server 数据库基础笔记分享(上) Asp.Net MVC4中的全局过滤器 C#语法——泛型的多种应用

    C#面试题(转载) 原文地址:100道C#面试题(.net开发人员必备)  https://blog.csdn.net/u013519551/article/details/51220841 1. . ...

  2. 人人都是 DBA(V)SQL Server 数据库文件

    SQL Server 数据库安装后会包含 4 个默认系统数据库:master, model, msdb, tempdb. SELECT [name] ,database_id ,suser_sname ...

  3. SQL Server数据库空间管理 (1)

    数据库经常遇到的问题: 1).数据库文件空间用尽  2).日志文件不停增长 3).数据库文件无法收缩  4).自动增长和自动收缩 本系列就以上面的4个问题入手分析并总结数据库空间的管理方法.   1. ...

  4. Microsoft SQL Server 数据库 错误号大全

    panchzh :Microsoft SQL Server 数据库 错误号大全0 操作成功完成. 1 功能错误. 2 系统找不到指定的文件. 3 系统找不到指定的路径. 4 系统无法打开文件. 5 拒 ...

  5. 极限挑战—C#100万条数据导入SQL SERVER数据库仅用4秒 (附源码)

    原文:极限挑战-C#100万条数据导入SQL SERVER数据库仅用4秒 (附源码) 实际工作中有时候需要把大量数据导入数据库,然后用于各种程序计算,本实验将使用5中方法完成这个过程,并详细记录各种方 ...

  6. Red Gate系列之三 SQL Server 开发利器 SQL Prompt 5.3.4.1 Edition T-SQL智能感知分析器 完全破解+使用教程

    原文:Red Gate系列之三 SQL Server 开发利器 SQL Prompt 5.3.4.1 Edition T-SQL智能感知分析器 完全破解+使用教程 Red Gate系列之三 SQL S ...

  7. .NET技术面试题系列(1) 基础概念

    这是.NET技术面试题系列第一篇,今天主要分享基础概念. 1.简述 private. protected. public.internal 修饰符的访问权限 private : 私有成员, 在类的内部 ...

  8. .NET跨平台之旅:升级至ASP.NET 5 RC1,Linux上访问SQL Server数据库

    今天微软正式发布了ASP.NET 5 RC1(详见Announcing ASP.NET 5 Release Candidate 1),.NET跨平台迈出了关键一步. 紧跟这次RC1的发布,我们成功地将 ...

  9. SQL Server数据库定时自动备份

    SQL Server 数据库定时自动备份[转]   在SQL Server中出于数据安全的考虑,所以需要定期的备份数据库.而备份数据库一般又是在凌晨时间基本没有数据库操作的时候进行,所以我们不可能要求 ...

  10. C#操作access和SQL server数据库代码实例

    在C#的学习中,操作数据库是比较常用的技术,而access和sql server 数据库的操作却有着不同.那么,有哪些不同呢? 首先,需要引用不同的类.因为有着不同的数据引擎. access:usin ...

随机推荐

  1. Jenkins 系列:Jenkins 安装(Windows、Mac、Centos)和简介

    目录 简介 发展历史 应用场景 Jenkins 安装部署 先决条件 硬件要求 软件包下载 war 包部署 linux 系统部署 mac 系统部署 windows 系统部署 安装后基本配置 解锁 自定义 ...

  2. 新版的Django中的path不能使用正则表达式

    新版的path 虽然 取代了 之前的url,但是在写路由的时候不能在路由中直接写正则表达式,不然会找不到页面. 解决方法使用 re_path from django.urls import re_pa ...

  3. 5分钟搞定vue3函数式弹窗

    前言 最近接到一个需求,需要在一些敏感操作进行前要求输入账号和密码,然后将输入的账号和密码加到接口请求的header里面.如果每个页面都去手动导入弹窗组件,在点击按钮后弹出弹窗.再拿到弹窗返回的账号密 ...

  4. Spring系列:基于Spring-Jdbc实现事务

    目录 一.事务基本概念 二.编程式事务 三.声明式事务 前期准备 四.基于注解的声明式事务 @Transactional注解标识的位置 事务属性:只读 事务属性:超时 事务属性:回滚策略 事务属性:隔 ...

  5. 常见的6种MySQL约束

    摘要:一篇文章带你彻底了解MySQL各种约束 MySQL约束 <1> 概念 是一种限制,它是对表的行和列的数据做出约束,确保表中数据的完整性和唯一性. <2> 使用场景 创建表 ...

  6. 支持60+数据传输链路,华为云DRS链路商用大盘点

    如今,业务上云已是时代潮流,技术的迅猛发展也使得上云变得愈发轻松起来.但在实际迁移过程中,客户仍会担心以下问题:不同数据库之间能迁吗?迁移前后数据不一致怎么办?可以不停机迁移吗-- 迁移毕竟是项大工程 ...

  7. 论文解读丨无参数的注意力模块SimAm

    摘要:本文提出了一个概念简单但对卷积神经网络非常有效的注意力模块. 本文分享自华为云社区<论文解读系列三十:无参数的注意力模块SimAm论文解读>,作者:谷雨润一麦. 摘要 本文提出了一个 ...

  8. 火山引擎DataLeap如何解决SLA治理难题(一):应用场景与核心概念介绍

    更多技术交流.求职机会,欢迎关注字节跳动数据平台微信公众号,回复[1]进入官方交流群 基于火山引擎分布式治理的理念,数据平台数据治理团队自研了火山引擎DataLeap SLA保障平台,目前已在字节内部 ...

  9. 基于jdk自带httpserver开发的最小完整MVC框架

    基于jdk自带httpserver开发的最小完整MVC框架 410kb级的完整MVC:solon(83k) + jdkhttp(27k) + enjoy(227k) + snack3(73k) DEM ...

  10. 利用 Solon-web 框架写一个 Hello World

    Solon 项目的开源地址: https://gitee.com/noear/solon 最近看了不少别人写的各种框架的 Hello world 示例,有些看起来,真的很复杂. 今天,我们用号称简单到 ...