数据库相关优化方案

数据库优化方案很多，主要分为两大类：软件层面、硬件层面。

1.软件层面包括：SQL 调优、表结构优化、读写分离、数据库集群、分库分表等；

1.1SQL 调优

SQL 调优往往是解决数据库问题的第一步，往往投入少部分精力就能获得较大的收益。

SQL 调优主要目的是尽可能的让那些慢 SQL 变快，手段其实也很简单就是让 SQL 执行尽量命中索引。

1.1.1开启慢 SQL 记录

如果你使用的是 MySQL，需要在 MySQL 配置文件中配置几个参数即可。

slow_query_log=on
long_query_time=1
slow_query_log_file=/path/to/log

1.1.2 调优的工具

常常会用到 explain 这个命令来查看 SQL 语句的执行计划，通过观察执行结果很容易就知道该 SQL 语句是不是全表扫描、有没有命中索引。

select id, age, gender from  user where name = '转载';

返回查询结果中有一列叫“type”，常见取值有：

ALL、index、range、 ref、eq_ref、const、system、NULL（从左到右，性能从差到好）

ALL 代表这条 SQL 语句全表扫描了，需要优化。从index开始表示已经使用索引，一般来说需要达到 range 级别及以上。

1.2表结构优化

以一个场景举例说明：

“user”表中有 user_id、nickname 等字段，“order”表中有order_id、user_id等字段，如果想拿到用户昵称怎么办？一般情况是通过 join 关联表操作，在查询订单表时关联查询用户表，从而获取用户昵称。

但是随着业务量增加，订单表和用户表肯定也是暴增，这时候通过两个表关联数据就比较费力了，为了取一个昵称字段而不得不关联查询几十上百万的用户表，其速度可想而知。

这个时候可以尝试将 nickname 这个字段加到 order 表中（order_id、user_id、nickname），这种做法通常叫做数据库表冗余字段。这样做的好处展示订单列表时不需要再关联查询用户表了。

冗余字段的做法也有一个弊端，如果这个字段更新会同时涉及到多个表的更新，因此在选择冗余字段时要尽量选择不经常更新的字段。

1.3架构优化（读写分离、数据库集群、分库分表等）

当单台数据库实例扛不住，我们可以增加实例组成集群对外服务。

当发现读请求明显多于写请求时，我们可以让主实例负责写，从实例对外提供读的能力；如果读实例压力依然很大，可以在数据库前面加入缓存如 redis，让请求优先从缓存取数据减少数据库访问。

缓存分担了部分压力后，数据库依然是瓶颈，这个时候就可以考虑分库分表的方案了，后面会详细介绍。

2.硬件层面主要是增加机器性能。

2.1硬件优化

硬件成本非常高，一般来说不可能遇到数据库性能瓶颈就去升级硬件。

在前期业务量比较小的时候，升级硬件数据库性能可以得到较大提升；但是在后期，升级硬件得到的收益就不那么明显了。