数据库优化一二

一般如果出现系统缓慢的时候，我首先想到的就是索引问题，哪些sql造成的系统缓慢，响应超时，把sql拎出来，单独执行看执行时间和执行计划，确定是否走了对应的索引，对应的表如果设计了索引，很多时候，开发和索引设计者因为没有沟通，造成很多表存在索引，但是sql写的跟索引不搭导致不走索引也是很可惜的，系统初期或开发环境下，本身数据库数据量小，索不索引都看不出什么问题，一旦线上用户指数增长，数据库查询的压力就越来越大，百万数据量甚至千万数据量的时候，索引就非常重要了，索引优化也是成本最低的数据库优化方案，至于索引创建的一些准则我们一般遵循一个规则，叫三星索引规则，这个是《数据库索引设计与优化》一书中提出的，我也是现学现买，里面有很多索引创建的规则和启示，接下来我简单总结下，不敢说理解深刻，纯当交流。
所谓的三星索引，可以从几个方面去理解，一星是查询范围，二星是查询顺序，还有三星就是包含查询的所有列，其中第三星是最容易满足的，一星规则其实就是主要对where条件的设计，where条件通常可以缩小查询范围，针对等值条件，范围条件添加索引，可以不用全表查询来提升查询性能，全表随机读的查询是最慢的，一旦创建的索引能把索引片范围确定的足够小，那查询性能也是很高的，主键索引就是一个很好例子。二星规则优化的是数据库查询顺序，其实也很好理解，我就用我一些不成熟的理解描述下，数据库查询数据时，机械硬盘需要转N圈才能把存储在硬盘上的数据全部读取完成，但，一旦执行顺序确定，那数据库查询就不再是随机读取，而是顺序读取，所以一般order by后的字段是应该放到索引中的。
需要注意的是一星和二星有的时候是无法同时满足的，当一星中的where条件存在范围查询的时候，如between，二星和一星就必须选其一了，因为他们无法同时达成。
这就是我的一些索引简单的理解，只是拾了《数据库索引设计与优化》的一些牙慧而已，如果说的哪里不对，可能是我理解上还有些偏差，见笑。
造成数据库性能缓慢的还有一个比较常见的问题那就是单库数据表过多或单表数据量增长过快导致的数据量过大，互联网项目一般面向的是成千上万的用户，如果不是可伸缩的数据库集群设计，只靠单机性能很容易出现瓶颈，即使初始设计的时候是集群设计没有考虑可伸缩的话，问题也会出现，只是时间或早或晚的问题，现在网上也有一些解决方案，但是都存在这样那样的瑕疵，我也只是稍作浏览和看过一些书，个人理解的一些方案，无非就是分库分表，表多垂直分，将表按业务需求拆分出去，这个一般没什么难度。
但单表数据过大做水平拆分的话，方案就比较复杂，需要考虑的因素也很多，而且存在一些本身还无法有效解决只能做规避的问题。既然拆表，首先考虑的就是按什么规则做拆分，怎样拆分之后的数据能较合理平均的落地到多个库中，这个是最主要的问题，因为，之后代码查询都会通过这个规则去对应的库中查询，规则不够好的话，直接影响整个库操作性能，现在常见的拆分规则是按某一字段取模，具体怎么取，其中又有很多算法，各个算法的长处短处都不一样，还要考虑可扩展性，下次瓶颈再分库的可操作性，第二个就是主键问题，一旦表拆分之后，之前如果用的是自增主键，那就无法使用，必须重新定义全局主键，还有就是拆分之后代码层面也肯定是需要做变更的，数据源变更，sql变更等，如果是运用一些中间件处理的话，哪一些sql支持不支持也需要注意。
然后说下这些方案一些无法有效解决的共性问题，分页和排序，这是一般这些拆分方案无法有效解决的，举个例子简单描述下这个问题，因为大数据表拆分之后，每次分页取数，都需要往多个库里查询数据，比如取第一页，一页取10条，分两库，那就是首先得去两个库里排序，每个库取顶上10条，这就合计取了20条，再20条排序，取10条做一页，然后第二页，每个库排序取顶上的20条，合计40条，排序之后取作为第二页的10条数据，依次类推，页数越大，取数越大，查询压力越大，排序一样的意思，所以，如果大数据表水平拆分，最好规避分页以及排序，如果确实无法规避，可以考虑，只取少数几页，不做深度分页。