浅谈数据库优化

1.SQL语句优化

1）应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。
2）应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0
3）很多时候用 exists 代替 in 是一个好的选择
4）用Where子句替换HAVING 子句 因为HAVING 只会在检索出所有记录之后才对结果集进行过滤

5）大家都知道，like  “%str%” 不支持索引， "str%"号是支持索引的

            因此，如果业务允许，可以使用前匹配的方法是数据库快速定位到数据，在结果集中再进行like匹配，如果这个结果集不是很大，是可以大幅提升运行效率的，这个需要对业务和程序有灵活的变通

            如果业务实在不允许前匹配，那就可以采用solr或者elastisearch来进行模糊匹配，但是进行模糊匹配有个前提，原始数据是字符串的话，不要带有特殊符号，如#，&，% 等，这样会造成分词不准，最终导致查询结果不正确
 

2.索引优化

建立索引是数据库优化各种方案之中成本最低，见效最快的解决方案，一般来讲，数据库规模在几十万和几百万级别的时候见效最快，即便是有不太复杂的表关联，也能大幅度提高sql的运行效率，这个在我们以前的项目应用中，有非常深刻的体会，本来耗时50s的sql，在增加索引后可以提升到1-2s，而且不需要有代码改动，成本低廉，见效明显

         建立索引需要注意的地方

         a、索引一般加在查询条件的关键字上，如果有多个查询条件关键字，还可以添加组合索引，写sql的时候需要注意，索引字段和sql字段需要保持一致，否则索引会无效，比如

              简单粗暴一点儿，我直接使用我们主数据数据库(测试库)中的md_house_property_info表中的source_house_code_no字段，这个字段在数据库中被定义为了varchar类型，定义了多个索引，都包含了source_house_code_no字段

           大家看，source_house_code_no我写成varchar类型的时候，是可以走索引的

         当我写成数字的时候，sql能够正确执行，但是却没有命中索引

         大家再细心一点儿会发现，我这里面有个possiable_keys，这个是指的可能命中的索引，此处出现了两个，但是数据库引擎会选择最优的一个idx_source_house_code_no,这个过程我在开始有介绍了

        b、不要在查询=前面使用函数，否则会导致索引不生效，举个栗子，where str=substring(“hello world”,6,8),这样是可以走索引的，但是 where substring(str,6,8)=“hello world” 是不会命中索引的

        c、建立索引的字段要区分度比较高，比如user表中有一个性别字段，性别字段无非男女两种值，区分度不好，建立索引效果不好，要选择区分度高的字段

        d、建立组合索引，可以持续提升sql运行效率，但是也不要盲目，同样的要注意区分度，如果区分度不够高，就不要加了，多个字段，尽可能把区分度高的字段放在前面，另外，还要注意索引长度，这个索引要同时兼顾索引长度和区分度的平衡

        e、索引会大幅提升查询效率，但是也会损耗查询后修改效率，要注意兼顾平衡，使用在一次插入，多次查询的表上效果最好，同时要注意的是，组合索引会不可避免的增加索引长度，会增加索引存储空间，注意索引长度和区分度平衡

        f、后来因为工作需要，意外发现mysql居然支持全文索引，没测试过效率，正常使用全文索引都是使用 lunce，以及在其之上的solr和现在正火的elastisearch，后面可以单独来说
 

3.数据库结构优化

1）范式优化： 比如消除冗余（节省空间。。） 2）反范式优化：比如适当加冗余等（减少join） 3）拆分表： 分区将数据在物理上分隔开，不同分区的数据可以制定保存在处于不同磁盘上的数据文件里。这样，当对这个表进行查询时，只需要在表分区中进行扫描，而不必进行全表扫描，明显缩短了查询时间，另外处于不同磁盘的分区也将对这个表的数据传输分散在不同的磁盘I/O，一个精心设置的分区可以将数据传输对磁盘I/O竞争均匀地分散开。对数据量大的时时表可采取此方法。可按月自动建表分区。
4）拆分其实又分垂直拆分和水平拆分： 案例： 简单购物系统暂设涉及如下表： 1.产品表（数据量10w，稳定） 2.订单表（数据量200w，且有增长趋势） 3.用户表 （数据量100w，且有增长趋势） 以mysql为例讲述下水平拆分和垂直拆分，mysql能容忍的数量级在百万静态数据可以到千万 垂直拆分： 解决问题：表与表之间的io竞争 不解决问题：单表中数据量增长出现的压力 方案： 把产品表和用户表放到一个server上 订单表单独放到一个server上 水平拆分： 解决问题：单表中数据量增长出现的压力 不解决问题：表与表之间的io争夺
方案： 用户表通过性别拆分为男用户表和女用户表 订单表通过已完成和完成中拆分为已完成订单和未完成订单 产品表 未完成订单放一个server上 已完成订单表盒男用户表放一个server上 女用户表放一个server上(女的爱购物 哈哈)

4.服务器硬件优化

这个么多花钱咯！

5.数据库引擎

            也是偶尔听一个dba同事提到的，有一次我跟dba同事抱怨，我的数据库查询太慢，有没有好的优化方法，他一开始就问，数据量多大，有没有索引，使用的什么数据库引擎，这时我才意识到原来数据库引擎也算是一种优化方案

            mysql比较常用的数据库引擎有两种，一种是innodb、一种是myisam 

            我当时做过一个千万级数据量复杂sql测试，myisam的效率大概能够比innodb快1-2倍，虽然效率提升不是很明显，但是也有提升，后来查过一些资料，说之所以mysiam快，是因为他的数据存储结构、索引存储结构和innodb不一样的，mysiam的索引结构是在内存中存的

            当然，mysiam也有弱点，那就是他是表级锁，而innodb是行级锁，所以，mysiam适用于一次插入，多次查询的表，或者是读写分离中的读库中的表，而对于修改插入删除操作比较频繁的表，就很不合适了

6.数据库架构扩展

  随着业务量越来越大，单台数据库服务器性能已无法满足业务需求，该考虑加机器了，该做集群了~~~。主要思想是分解单台数据库负载，突破磁盘I/O性能，热数据存放缓存中，降低磁盘I/O访问频率。

  4.1 主从复制与读写分离

  因为生产环境中，数据库大多都是读操作，所以部署一主多从架构，主数据库负责写操作，并做双击热备，多台从数据库做负载均衡，负责读操作，主流的负载均衡器有LVS、HAProxy、Nginx。

  怎么来实现读写分离呢？大多数企业是在代码层面实现读写分离，效率比较高。另一个种方式通过代理程序实现读写分离，企业中应用较少，常见代理程序有MySQL Proxy、Amoeba。在这样数据库集群架构中，大大增加数据库高并发能力，解决单台性能瓶颈问题。如果从数据库一台从库能处理2000 QPS，那么5台就能处理1w QPS，数据库横向扩展性也很容易。

  有时，面对大量写操作的应用时，单台写性能达不到业务需求。如果做双主，就会遇到数据库数据不一致现象，产生这个原因是在应用程序不同的用户会有可能操作两台数据库，同时的更新操作造成两台数据库数据库数据发生冲突或者不一致。在单库时MySQL利用存储引擎机制表锁和行锁来保证数据完整性，怎样在多台主库时解决这个问题呢？有一套基于perl语言开发的主从复制管理工具，叫MySQL-MMM（Master-Master replication managerfor Mysql，Mysql主主复制管理器），这个工具最大的优点是在同一时间只提供一台数据库写操作，有效保证数据一致性。

  主从复制博文：http://lizhenliang.blog.51cto.com/7876557/1290431

  读写分离博文：http://lizhenliang.blog.51cto.com/7876557/1305083

 MySQL-MMM博文：http://lizhenliang.blog.51cto.com/7876557/1354576

  4.2 增加缓存

  给数据库增加缓存系统，把热数据缓存到内存中，如果缓存中有要请求的数据就不再去数据库中返回结果，提高读性能。缓存实现有本地缓存和分布式缓存，本地缓存是将数据缓存到本地服务器内存中或者文件中。分布式缓存可以缓存海量数据，扩展性好，主流的分布式缓存系统有memcached、redis，memcached性能稳定，数据缓存在内存中，速度很快，QPS可达8w左右。如果想数据持久化就选择用redis，性能不低于memcached。

 

  4.3 分库

  分库是根据业务不同把相关的表切分到不同的数据库中，比如web、bbs、blog等库。如果业务量很大，还可将切分后的库做主从架构，进一步避免单个库压力过大。

  4.4 分表

  数据量的日剧增加，数据库中某个表有几百万条数据，导致查询和插入耗时太长，怎么能解决单表压力呢？你就该考虑是否把这个表拆分成多个小表，来减轻单个表的压力，提高处理效率，此方式称为分表。

  分表技术比较麻烦，要修改程序代码里的SQL语句，还要手动去创建其他表，也可以用merge存储引擎实现分表，相对简单许多。分表后，程序是对一个总表进行操作，这个总表不存放数据，只有一些分表的关系，以及更新数据的方式，总表会根据不同的查询，将压力分到不同的小表上，因此提高并发能力和磁盘I/O性能。

  分表分为垂直拆分和水平拆分：

  垂直拆分：把原来的一个很多字段的表拆分多个表，解决表的宽度问题。你可以把不常用的字段单独放到一个表中，也可以把大字段独立放一个表中，或者把关联密切的字段放一个表中。

  水平拆分：把原来一个表拆分成多个表，每个表的结构都一样，解决单表数据量大的问题。

  4.5 分区

  分区就是把一张表的数据根据表结构中的字段（如range、list、hash等）分成多个区块，这些区块可以在一个磁盘上，也可以在不同的磁盘上，分区后，表面上还是一张表，但数据散列在多个位置，这样一来，多块硬盘同时处理不同的请求，从而提高磁盘I/O读写性能，实现比较简单。

注：增加缓存、分库、分表和分区主要由程序猿来实现。

数据库范式

1 第一范式（1NF）

在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。

2 第二范式（2NF）

第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。这个惟一属性列被称为主关键字或主键、主码。
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。

3 第三范式（3NF）

满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。（我的理解是消除冗余）