在日常开发中，我们经常会碰到数据库的分库分表问题，有分库的，有分表的，还有既分库又分表的。在分布式技术的面试里，这也是面试官重点考察的内容。今天就来和大家聊聊为啥要进行数据库的分库分表，以及其中的底层逻辑。
在项目早期或者用户量、访问量不大，业务规模较小时，根本不用考虑分库分表。但随着业务发展，库中的表越来越多，表中的数据也日益庞大，相应的数据库操作，像增删改查的开销就会不断增大。原本很快的 SQL 查询语句，会逐渐变慢，这可能就意味着到了要分库分表的时候了。
通常来说，当单表数据达到 1000 万时就得小心了。因为达到这个量级的数据库，不管是查询还是写入，效率都会很低。查询慢很好理解，因为要遍历大的数据表。那写入操作为啥也会慢呢？比如说熟悉的用户信息表，假如有 1500 万的用户数据，为了查询快速，肯定建立了很多索引，比如用户名、姓名、手机号等。这时如果要在表中插入一条新数据，插入本身没问题，就是个追加动作，但插入完成后，数据库会针对用户表重新建立对应的索引。要知道，MySQL 为了保证查询效率，索引采用的是 B+树结构。1500 万行的数据重新构建索引，系统开销不容忽视，会严重影响数据库性能。
像这种情况，如果做了分表操作，比如分成 5 个表，每个表 300 万数据。那么在 300 万行的表中插入数据时，建立索引的时间会大幅下降，从而提高数据库的运行效率，进而提升系统的并发量。分表的好处不止在索引方面，还能减少写操作时的锁范围。写数据时会对数据加锁，如果数据表的数据很多，显然会增加锁的范围，加锁越多，效率自然就越低。总之，分表就是把数据分片拆分，又叫水平拆分，减少单表的数据量，就能提升系统性能。
再来说说分库，分库其实是为了提高架构的可用性，减少单点故障，有效分担一个库的压力。只分库不分表，常用于读请求分类的场景，比如一主多从，主库负责写，从库负责读，并从主库同步数据以保证数据一致。
好了，今天关于数据库分库分表的内容就讲到这里，要是您对本期内容有任何疑问，欢迎在评论区留言。
