数据库性能优化一

这周公司组织的去惠州游玩，玩得很开心，就是坐车的时间比较长，除了睡觉基本一半时间都在车上，刚回来吃了饭，本来计划着这周搞点docker的一些知识，不过太累了，就写点我的总结吧。做为IT程序员，特别是作了几年的，三年以上的吧，若是仍是以为只要能实现功能，就万事大吉完成任务，只是着眼与功能点的实现，那可就真成搬砖的了，最基本的是实现功能的优化。一个项目都会包含应用服务器和数据服务器，若是说对项目进行优化，那优化的地方有好多，优化的方法也有好多，今天要说的对数据库的优化也有好几个方面。

1、系统框架方面

1.框架

首先是要搞清楚业务需求，在知足业务需求的状况下，合理的技术选型和系统架构不只仅是对数据库方面有帮助，对后期的开发维护都有帮助，系统框架要考虑长远，也不是说一个小的企业宣传网站就搞什么分布式、大数据这些，毕竟软件也有生命周期的，但也不能只顾眼前，能够根据自身状况以及对将来五年十年的规划，最起码先有一个目标，能知足多人用户的需求，天天访问量能达到多少、并发量能到多少，将来五年又是一个目标，不能说软件用了一两年数据量一大、人一多就不能用了，扩展性方面要有必定的考虑。

2.业务实现方面

在系统中会进行对数据库的访问，访问的多了超过数据库的承载能力了，就会影响数据库的性能。因此咱们能够从系统业务实现方面来进行数据库的一些优化，好比缓存，能减小一些访问次数，好比链接池的设计，也是更减小系统的开销，更好的利用资源，有的项目也会把一些经常使用的不宜改变的数据放在客户端，这样也能减小对数据库的访问次数。同时一些对应用服务器优化的方法其实也是对数据库的优化，好比队列，利用队列能够达到错峰的效果，这样也能够防止数据库崩溃，致使更大的灾难,增长数据库的抗压能力。还有就是能够减小返回的数据，数据量小了速度也会提高。

2、数据库自身方面

1.表结构的设计

业务需求影响表的设计，同时表的设计影响需求的实现。通常项目都会有登陆功能，并且也是比较常常访问的，我见过的大部分的系统，表的设计是将用户登陆的密码放在用户我的信息表中，一个用户信息表可能会有二三十个字段，甚至包含手机号、邮箱等一些比较隐私的信息。像这种也是能实现需求的，不过之后用户多的时候，达到百万千万级时，一条记录这么多字段，这么多的用户那一个表的数据也是蛮大的，仅仅是实现登陆功能，就可能会查询很久，可能有人会说，这不怕，能够分库分表啊，将一半的数据分到令一个数据表甚至数据库中，这确实是个办法，不过其实登陆也就仅仅是用户名和密码、验证码，何须搞那么多呢，并且将用户名密码和我的私人信息放在一块儿也不安全，万一哪天被盗，那就把我的信息透露完了，若是只把用户名、密码、验证码只与登陆有关的放在一个表，那可能自动就会少一些，我的信息泄露的风险也会下降一点。在作功能时，会有单一原则，在作表的设计时也能够考虑，可能有的会说，也不能太单一了，不是有三级范式，能够按照三级范式来进行设计，确实三级范式是一个很好的参考，平时在作表的设计时须要考虑三级范式，不过也有一些状况比较特殊，因此仍是权衡着选择。

2.字段的设计

仍是拿用户表来讲，用户头像也是比较常见的吧，可能有的是直接把头像放入数据库中，图像占的空间也是比较大的，可能全部的我的信息还没一个头像占的空间大，这也致使了数据库容量的增大，其实将头像专门放到一个文件服务器，数据库中只保存一个url也是一种对数据库的优化。

3.sql语句

这个写过sql的应该都会或多或少的了解，查询一样的数据有的sql查询很快，有的就很慢，甚至会有死锁，特别是本身苦思冥想了半天始终憋不出思路或者可憋出来了查询数据很慢，等半天还没结果，另外的小伙伴可能将本身的sql稍微改动改动就会很快查出结果，这种是比较尴尬的。sql语句的优化也有好多注意的，也有好多方法。

4.主键、索引、存储过程等

对表添加主键通常都会有，不论是逻辑主键仍是业务主键，但有一些查询可能不是经过主键查的，特别是一些条件查询，好比查询特定时间段的数据，并且使用的也特别频繁，这种可使用索引来提升速度，存储过程也是，存储过程是预编译的相比直接sql仍是好一点的。

5.锁、事务

系统中减小锁与事务的使用，或者减小锁的粒度，防止死锁的发生，对于事务，特别是分布式事务，使用它们都会下降数据库的并发量。有的使用不慎，可能致使系统愈来愈慢。

3、数据库架构方面

上面对数据库的优化是从单个数据库来讲的，也是能够知足必定的用户需求的，若是用户量比较大，访问比较多，数据量也比较大，咱们能够对数据库架构进行优化，好比读写分离、分库分表。

1.读写分离

咱们都知道二八原则，其实在互联网中也能体现二八原则，用户操做中大部分是浏览，读的操做，一小部分是写的操做，因此读比较频繁，写就相对不频繁，能够将数据库设计成一主多从或多主多从，这样就能减小对一个数据库服务器的压力，一样有利有弊，数据库增多也会带来一些新的问题，好比数据同步的问题，数据库节点变化的问题，增长一个数据库或减小一个数据库可能就会致使一部分用户映射不到。

2.分库分表

分库分表也是分而治之的思想，一个表或一个库的数据比较大，那就放在多个表多个库中，好比一个1000万数据库的表的查询确定是没有两个500万数据库的表查询快，一样也是有利有弊，可能在系统设计阶段进行分库分表还好分一点，但对数据库或表的水平扩展那就麻烦了，好比增长一个数据库或表，那怎么将原来用户的数据映射到正确的数据库或表中呢。这是均分数据，还有一种分库分表是按时间或者按其余因素来分，好比新闻类的，时效性比较强，用户可能关注的也就一周的信息，那能够将比较热点的访问频率比较高的多放几个数据库，或者用SSD来存储，这样也会快一点。抢购也是，热门的能够专门搞一个数据库或多部署几个数据库，这样也能防止访问量太高致使整个项目崩溃。

3.容灾防灾

容灾防灾也是对数据库的优化，主要是对数据冗余，可能常见的就是日志、备份，定时按期作备份，防止数据丢失，经过日志也能够防止数据库异常，防止数据丢失。咱们能够将数据和日志分开，放在不一样的磁盘上，这样也是一种方法来进行数据库优化。还有一种备份是主从备份，这种有热备份和冷备份，咱们可能听过异地多活，其实这种咱们能够把对数据库的操做增长消息，让多个地方来接收消息，这样就能够实现数据同步，达到异地多活的目的。

4、硬件方面

硬件方面也有不少，好比网络带宽、服务器内存、操做系统、CPU还有上面说的SSD固态硬盘等。

5、我的总结

上面列举的可能也不是太全面，毕竟我也不是这方面的专家，对数据库的设计经验可能也不是太多，也只设计过两三个项目并且也都是小的项目，并且上面的每一点若是要深刻研究可能又有好多东西要学，均可以单独展开学习，对数据库性能的优化也不是单个方面的，可能上面的各个方面都要用到。这是我在这两天去惠州玩的过程当中的一些思考与总结，欢迎各位指点,或者有好的观点也能够多多交流。