前言

数据库相关的面试题早已成为了一线互联网大厂面试的家常菜，如果你对数据库不太熟悉，我劝你不要轻易面试大厂。那么，为什么数据库成了大厂面试的家常菜呢？主要原因当然还是海量数据。

无论对于刚入行的小白还是有几年Java开发经验的从业而言，面试不仅是你必须要面对的事情，更是你升职加薪的一个途径。许多朋友面试了几家公司也没拿到一个满意的薪资，究其根还是在于自己的知识不够系统化，太凌乱。针对性的温故知新往往能达到事半功倍的效果。

在这里我总结一线互联网大厂java面试中常问的“数据库”问题，由于过多答案文字仅以图片展示，所有内容已总结成文档在文末有领取方式！

为什么要分库分表？

首先回答一下为什么要分库分表，答案很简单：数据库出现性能瓶颈。用大白话来说就是数据库快扛不住了。

数据库出现性能瓶颈，对外表现有几个方面：

大量请求阻塞在高并发场景下，大量请求都需要操作数据库，导致连接数不够了，请求处于阻塞状态。
SQL 操作变慢如果数据库中存在一张上亿数据量的表，一条 SQL 没有命中索引会全表扫描，这个查询耗时会非常久。
存储出现问题业务量剧增，单库数据量越来越大，给存储造成巨大压力。

从机器的角度看，性能瓶颈无非就是CPU、内存、磁盘、网络这些，要解决性能瓶颈最简单粗暴的办法就是提升机器性能，但是通过这种方法成本和收益投入比往往又太高了，不划算，所以重点还是要从软件角度入手。

数据库相关优化方案

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

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

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

SQL 调优

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

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

开启慢 SQL 记录

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

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

调优的工具

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

select id, age, gender from  user where name = '爱笑的架构师';

返回有一列叫“type”，常见取值有：

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

ALL 代表这条 SQL 语句全表扫描了，需要优化。一般来说需要达到range 级别及以上。

表结构优化

以一个场景举例说明：

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

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

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

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

架构优化

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

当发现读请求明显多于写请求时，我们可以让主实例负责写，从实例对外提供读的能力；

如果读实例压力依然很大，可以在数据库前面加入缓存如 redis，让请求优先从缓存取数据减少数据库访问。

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

硬件优化

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

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

分库分表详解

下面我们以一个商城系统为例逐步讲解数据库是如何一步步演进。

单应用单数据库

在早期创业阶段想做一个商城系统，基本就是一个系统包含多个基础功能模块，最后打包成一个 war 包部署，这就是典型的单体架构应用。

如上图，商城系统包括主页 Portal 模板、用户模块、订单模块、库存模块等，所有的模块都共有一个数据库，通常数据库中有非常多的表。

因为用户量不大，这样的架构在早期完全适用，开发者可以拿着 demo到处找（骗）投资人。

一旦拿到投资人的钱，业务就要开始大规模推广，同时系统架构也要匹配业务的快速发展。

多应用单数据库

在前期为了抢占市场，这一套系统不停地迭代更新，代码量越来越大，架构也变得越来越臃肿，现在随着系统访问压力逐渐增加，系统拆分就势在必行了。

为了保证业务平滑，系统架构重构也是分了几个阶段进行。

第一个阶段将商城系统单体架构按照功能模块拆分为子服务，比如：Portal 服务、用户服务、订单服务、库存服务等。

如上图，多个服务共享一个数据库，这样做的目的是底层数据库访问逻辑可以不用动，将影响降到最低。

多应用多数据库

随着业务推广力度加大，数据库终于成为了瓶颈，这个时候多个服务共享一个数据库基本不可行了。我们需要将每个服务相关的表拆出来单独建立一个数据库，这其实就是“分库”了。

单数据库的能够支撑的并发量是有限的，拆成多个库可以使服务间不用竞争，提升服务的性能。

如上图，从一个大的数据中分出多个小的数据库，每个服务都对应一个数据库，这就是系统发展到一定阶段必要要做的“分库”操作。

现在非常火的微服务架构也是一样的，如果只拆分应用不拆分数据库，不能解决根本问题，整个系统也很容易达到瓶颈。

分表

说完了分库，那什么时候分表呢？

如果系统处于高速发展阶段，拿商城系统来说，一天下单量可能几十万，那数据库中的订单表增长就特别快，增长到一定阶段数据库查询效率就会出现明显下降。

因此，当单表数据增量过快，业界流传是超过500万的数据量就要考虑分表了。当然500万只是一个经验值，大家可以根据实际情况做出决策。

那如何分表呢？

分表有几个维度，一是水平切分和垂直切分，二是单库内分表和多库内分表。

水平拆分和垂直拆分

就拿用户表（user）来说，表中有7个字段：id,name,age,sex,nickname,description，如果 nickname 和 description 不常用，我们可以将其拆分为另外一张表：用户详细信息表，这样就由一张用户表拆分为了用户基本信息表+用户详细信息表，两张表结构不一样相互独立。但是从这个角度来看垂直拆分并没有从根本上解决单表数据量过大的问题，因此我们还是需要做一次水平拆分。