database - 数据库设计/使用容易忽略的细节

1、设计

 

1，数据类型尽可能使用数字型，数字型的比较比字符型的快不少

 

2，数据类型尽可能小，预测能够知足将来需求的前提

 

3，尽可能建表时字段不容许为null，除非必要，能够用NOT NULL+DEFAULT代替

当你须要查询数据的时候你每每须要在WHERE条件中多加一个判断条件IS NOT NULL,这样的一个条件不只仅增长了额外的开销，并且对查询的性能产生很大的影响，有可能就由于多了这个查询条件致使你的查询变的很是的慢；还有一个比较重要的问题就是容许为空的数据可能会致使你的查询结果出现不许确的问题，

----若是整形字段能够赋0，字符型能够赋值空（这里只是给建议）这里的空和NULL是不同的意思
--增长整形字段能够这样写
ALTER TABLE TABLE_NAME ADD  COLUMN_NAME  INT NOT NULL DEFAULT(0)

--增长字符型字段能够这样写
ALTER TABLE TABLE_NAME ADD  COLUMN_NAME  NVARCHAR(50) NOT NULL DEFAULT('')

 

4，少用TEXT和IMAGE，二进制字段的读写是比较慢的，并且，读取的方法也很少，大部分状况下最好不用

 

5,创建自增列时单独再给自增列添加惟一约束

若是要保证ID是惟一的，单单只设置自增值不行，须要给字段设置主键或者惟一约束

 

6，创建索引

能够根据功能和性能的需求进行初步的索引设计，这里须要根据预计的数据量和查询来设计索引

A、根据数据量决定哪些表须要增长索引，数据量小的能够只有主键

B、根据使用频率决定哪些字段须要创建索引，选择常常做为链接条件、筛选条件、聚合查询、排序的字段做为索引的候选字段

C、把常常一块儿出现的字段组合在一块儿，组成组合索引，组合索引的字段顺序与主键同样，也须要把最经常使用的字段放在前面，把重复率低的字段放在前面

D、一个表不要加太多索引，由于索引影响插入和更新的速度

创建索引后，并非每一个查询都会使用索引，在使用索引的状况下，索引的使用效率也会有很大的差异。只要咱们在查询语句中没有强制指定索引，索引的选择和使用方法是SQLSERVER的优化器自动做的选择，而它选择的根据是查询语句的条件以及相关表的统计信息，这就要求咱们在写SQL语句的时候尽可能使得优化器可使用索引。

 

 

2、编码

1，查询条件不要使用计算列

例：查询条件为 year(createdate)=2014

优化：createdate>='20140101' and createdate<='20141231'

缘由：使用计算列查询，是经过[索引扫描]方式查找

不使用计算列，走的是索引查找

绝大部分状况下索引查找的查询性能要高于索引扫描，特别是查询的数据库不是很是大的状况下，索引查找的消耗时间要远远少于索引扫描的时间,相关知识[汇集、非汇集、堆的索引]

　　

2，分组统计时避免使用count(*)

if OBJECT_ID('Customer') is not null drop table [Customer]
go
create table [Customer] (CId int not null,Name nvarchar(20));
go
if OBJECT_ID('Order') is not null drop table [Order]
go
create table [Order] (OId int not null, CusId int);
go
insert into Customer values(1,'小米'),(2,'大米'),(3,'mini')
insert into [Order] values(1,1),(2,2),(3,NULL),(4,1)

　　

--例如:须要统计每一个顾客的订单量
--使用count(*)
select CID,count(*) from Customer left join [order] on Customer.CId=[order].CusId group by CId

　　

实际状况CusId=3是没有订单的，数量应该是0，可是结果是1,count()里面的字段是左链接右边的表字段，若是你用的是主表字段结果页是错误的。

--正确的方法是使用count(CusId)
select CID,count(CusId) from Customer left join [order] on Customer.CId=[order].CusId group by CId

 

3，子查询的表加上表别名

4，查询时使用*

查询时必定不能使用”*”来代替字段来进行查询，不管你查询的字段有多少个，就算字段太多没法走索引也避免了解析”*”带来的额外消耗。

查询字段值列出想要的字段，避免出现多余的字段，字段越多查询开销越大并且可能会由于多列出了某个字段而引发查询不走索引。

 

5，使用存储过程的好处

1. 减小网络通讯量。调用一个行数很少的存储过程与直接调用SQL语句的网络通讯量可能不会有很大的差异，但是若是存储过程包含上百行SQL语句，那么其性能绝对比一条一条的调用SQL语句要高得多。
2. 执行速度更快。有两个缘由：首先，在存储过程建立的时候，数据库已经对其进行了一次解析和优化。其次，存储过程一旦执行，在内存中就会保留一份这个存储过程缓存计划，这样下次再执行一样的存储过程时，能够从内存中直接调用。
3. 更强的适应性：因为存储过程对数据库的访问是经过存储过程来进行的，所以数据库开发人员能够在不改动存储过程接口的状况下对数据库进行任何改动，而这些改动不会对应用程序形成影响。
4. 布式工做：应用程序和数据库的编码工做能够分别独立进行，而不会相互压制。
5. 更好的封装移植性。
6. 安全性，它们能够防止某些类型的 SQL 插入攻击。

默认状况下，存储过程将返回过程当中每一个语句影响的行数。若是不须要在应用程序中使用该信息（大多数应用程序并不须要），请在存储过程当中使用 SET NOCOUNT ON 语句以终止该行为。根据存储过程当中包含的影响行的语句的数量，这将删除客户端和服务器之间的一个或多个往返过程。尽管这不是大问题，但它能够为高流量应用程序的性能产生负面影响。

6，判断一条查询是否有值

IF NOT EXISTS/IF EXISTS 优于 COUNT(*)

 

7, 理解TRUNCATE和DELETE的区别

TRUNCATE操做没有记录删除日志操做

主要的缘由是由于TRUNCATE操做不会激活触发器,由于TRUNCATE操做不会记录各行的日志删除操做,因此当你须要删除一张表的数据时你须要考虑是否应该若有记录日志删除操做，而不是根据我的的习惯来操做。

 

8，事务的理解

XACT_ABORT

---查询是否有打开事务
SELECT XACT_STATE()

DBCC OPENTRAN
未查询到有打开事务
当 SET XACT_ABORT 为 ON 时，若是执行 Transact-SQL 语句产生运行时错误，则整个事务将终止并回滚。

当 SET XACT_ABORT 为 OFF 时，有时只回滚产生错误的 Transact-SQL 语句，而事务将继续进行处理。若是错误很严重，那么即便 SET XACT_ABORT 为 OFF，也可能回滚整个事务。OFF 是默认设置。

编译错误（如语法错误）不受 SET XACT_ABORT 的影响。

 

9,条件字段的前后顺序

对于常常用做查询的字段放在第一个位置,其它的字段根据表的实际字段顺序排列，这样每每你的查询语句走索引的几率会更大。

 

10,避免使用长字节字段排序

order by Id 优于 order by CreateTime