数据库之优化

#数据库之优化

1. SQL以及索引的优化
   首先要根据需求写出结构良好的SQL，然后根据SQL在表中建立有效的索引。但是如果索引太多，不但会影响写入的效率，对查询也有一定的影响。

2. 合理的数据库是设计
   根据数据库三范式来进行表结构的设计。设计表结构时，就需要考虑如何设计才能更有效的查询。

数据库三范式：
第一范式：数据表中每个字段都必须是不可拆分的最小单元，也就是确保每一列的原子性；
第二范式：满足一范式后，表中每一列必须有唯一性，都必须依赖于主键；
第三范式：满足二范式后，表中的每一列只与主键直接相关而不是间接相关(外键也是直接相关)，字段没有冗余。

注意：没有最好的设计，只有最合适的设计，所以不要过分注重理论。三范式可以作为一个基本依据，不要生搬硬套。

有时候可以根据场景合理地反规范化：
A：分割表。
B：保留冗余字段。当两个或多个表在查询中经常需要连接时，可以在其中一个表上增加若干冗余的字段，以 避免表之间的连接过于频繁，一般在冗余列的数据不经常变动的情况下使用。
C：增加派生列。派生列是由表中的其它多个列的计算所得，增加派生列可以减少统计运算，在数据汇总时可以大大缩短运算时间。

数据库五大约束：
A：PRIMARY key:设置主键约束；
B：UNIQUE：设置唯一性约束，不能有重复值；
C：DEFAULT 默认值约束
D：NOT NULL：设置非空约束，该字段不能为空；
E：FOREIGN key :设置外键约束。

字段类型选择：
A：尽量使用TINYINT、SMALLINT、MEDIUM_INT作为整数类型而非INT，如果非负则加上UNSIGNED
B：VARCHAR的长度只分配真正需要的空间
C：使用枚举或整数代替字符串类型
D：尽量使用TIMESTAMP而非DATETIME
E：单表不要有太多字段，建议在20以内
F：避免使用NULL字段，很难查询优化且占用额外索引空间

3. 系统配置的优化
   例如：MySQL数据库my.cnf

4. 硬件优化
   更快的IO、更多的内存。一般来说内存越大，对于数据库的操作越好。但是CPU多就不一定了，因为他并不会用到太多的CPU数量，有很多的查询都是单CPU。另外使用高的IO（SSD、RAID），但是IO并不能减少数据库锁的机制。所以说如果查询缓慢是因为数据库内部的一些锁引起的，那么硬件优化就没有什么意义。
   代码优化
   之所以把代码放到第一位，是因为这一点最容易引起技术人员的忽视。很多技术人员拿到一个性能优化的需求以后，言必称缓存、异步、JVM等。实际上，第一步就应该是分析相关的代码，找出相应的瓶颈，再来考虑具体的优化策略。有一些性能问题，完全是由于代码写的不合理，通过直接修改一下代码就能解决问题的，比如for循环次数过多、作了很多无谓的条件判断、相同逻辑重复多次等。

举个栗子：
一个update操作，先查询出entity，再执行update，这样无疑多了一次数据库交互。还有一个问题，update语句可能会操作一些无需更新的字段。
​
我们可以将表单中涉及到的属性，以及updateTime，updateUser等赋值到entity，直接通过pdateByPrimaryKeySelective，去update特定字段。

​​

定位慢SQL，并优化
这是最常用、每一个技术人员都应该掌握基本的SQL调优手段（包括方法、工具、辅助系统等）。这里以MySQL为例，最常见的方式是，由自带的慢查询日志或者开源的慢查询系统定位到具体的出问题的SQL，然后使用explain、profile等工具来逐步调优，最后经过测试达到效果后上线。

SqlServer执行计划：
通过执行计划，我们能得到哪些信息：
A：哪些步骤花费的成本比较高
B：哪些步骤产生的数据量多，数据量的多少用线条的粗细表示，很直观
C：每一步执行了什么动作

具体优化手段：
A：尽量少用（或者不用）sqlserver 自带的函数
select id from t where substring(name,1,3) = ’abc’
select id from t where datediff(day,createdate,’2005-11-30′) = 0
可以这样查询：
select id from t where name like ‘abc%’
select id from t where createdate >= ‘2005-11-30’ and createdate < ‘2005-12-1’

B：连续数值条件，用BETWEEN不用IN：SELECT id FROM t WHERE num BETWEEN 1 AND 5
C：Update 语句，如果只更改1、2个字段，不要Update全部字段，否则频繁调用会引起明显的性能消耗
D：尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型
E：不建议使用 select * from t ，用具体的字段列表代替“”，不要返回用不到的任何字段。尽量避免向客户 端返回大数据量，若数据量过大，应该考虑相应需求是否合理
F：表与表之间通过一个冗余字段来关联，要比直接使用JOIN有更好的性能
G：select count() from table；这样不带任何条件的count会引起全表扫描
连接池调优
我们的应用为了实现数据库连接的高效获取、对数据库连接的限流等目的，通常会采用连接池类的方案，即每一个应用节点都管理了一个到各个数据库的连接池。随着业务访问量或者数据量的增长，原有的连接池参数可能不能很好地满足需求，这个时候就需要结合当前使用连接池的原理、具体的连接池监控数据和当前的业务量作一个综合的判断，通过反复的几次调试得到最终的调优参数。

​​

合理使用索引
索引一般情况下都是高效的。但是由于索引是以空间换时间的一种策略，索引本身在提高查询效率的同时会影响插入、更新、删除的效率，频繁写的表不宜建索引。

选择合适的索引列，选择在where，group by，order by，on从句中出现的列作为索引项，对于离散度不大的列没有必要创建索引。
主键已经是索引了，所以primay key 的主键不用再设置unique唯一索引

索引类型
主键索引 （PRIMARY KEY）
唯一索引 （UNIQUE）
普通索引 （INDEX）
组合索引 （INDEX）
全文索引 （FULLTEXT）

可以应用索引的操作符
大于等于
Between
IN
LIKE 不以 % 开头

不能应用索引的操作符
NOT IN
LIKE %_ 开头

如何选择索引字段
A：字段出现在查询条件中，并且查询条件可以使用索引
B：通常对数字的索引和检索要比对字符串的索引和检索效率更高
C：语句执行频率高，一天会有几千次以上
D：通过字段条件可筛选的记录集很小
​​

无效索引
A：尽量不要在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描
B：应尽量避免在 where 子句中使用 != 或 <> 操作符，否则将引擎放弃使用索引而进行全表扫描。
C：应尽量避免在 where 子句中使用 or 来连接条件，如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描
select id from t where num=10 or Name = ‘admin’
可以这样查询：
select id from t where num = 10
union
select id from t where Name = ‘admin’
union all 返回所有数据，不管是不是重复。 union会自动压缩，去除重复数据。

D：不做列运算
where age + 1 = 10，任何对列的操作都将导致表扫描，它包括数据库教程函数、计算表达式等
E：查询like，如果是 ‘%aaa’ 不会使用到索引

分表
分表方式
水平分割（按行）、垂直分割(按列)

分表场景
A： 根据经验，mysql表数据一般达到百万级别，查询效率就会很低。
B： 一张表的某些字段值比较大并且很少使用。可以将这些字段隔离成单独一张表，通过外键关联，例如考试成绩，我们通常关注分数，不关注考试详情。

水平分表策略
按时间分表：当数据有很强的实效性，例如微博的数据，可以按月分割。
按区间分表：例如用户表 1到一百万用一张表，一百万到两百万用一张表。
hash分表：通过一个原始目标id或者是名称按照一定的hash算法计算出数据存储的表名。

读写分离
当一台服务器不能满足需求时，采用读写分离【写: update/delete/add】的方式进行集群。
一台数据库支持最大连接数是有限的，如果用户的并发访问很多，一台服务器无法满足需求，可以集群处理。mysql集群处理技术最常用的就是读写分离。

主从同步：数据库最终会把数据持久化到磁盘，集群必须确保每个数据库服务器的数据是一致的。从库读主库写，从库从主库上同步数据。
读写分离：使用负载均衡实现，写操作都往主库上写，读操作往从服务器上读。