爱站程序员基地
如果当你的数据量达到千万级，亿级的时候，我们用常规的方式去做优化那么效果可能就不是很好了。这已经不是说性能的问题了，而是数据量响应的处理问题了，所以我们需要针对根本的问题去使用对应的技术去进行彻底的解决。如果对于这块技术内容不是很熟悉的话，或者没有去真正接触到这样的一个大项目实战，那么你在面试的时候你可能就只能答出一些技术名词来了，而有一些解决方案，细节问题你可能就答不上来了，可能你就嗝屁了。
1.目前准备做数据库水平切分，需要注意什么关键问题？目前了解需要避免跨库事务。答：（1）需要注意分库patition key的选取，要保证两个均衡：数据量的均衡，请求量的均衡。（2）库后，需要注意分之前用SQL满足的需求是否还能满足，需要怎么改进满足，例如max, min, avg, sum都需要在服务层再做一次聚合。（3）夸库事务，分布式事务，在吞吐量是主要矛盾的互联网场景，目前没有能够很好解决的方案，尽量避免。
2.如果分库分表的情况下碰到要对一个表或多个表关联并且按多个字段为条件进行检索的情况下怎么办呢？答：分库后join怎么办：（1）前端用户侧业务，流量大，并发大，join真的很少，58同城用户库几亿数据，帖子库300亿数据，没有join。（2）如果真要join，分库后冗余数据、索引表、分页，for循环低效查询 -> 总能解决的，只是看性能是不是主要矛盾、一致性是不是主要矛盾了。（3）拆成小sql是互联网的玩法，互联网很少用join、子查询、视图、外键、用户自定义函数、存储过程的。当然，我指面向用户侧的高并发业务。
3.采用hash取模方式的表扩容策略及采用一致性hash分表的表扩容策略如何实现？答：数据库水平切分的方式，常用的有两种：（1）hash取模：user_id%2=0为0库，user_id%2=1为1库。（2）数据分段：user_id属于[0, 1亿]为0库，属于[1亿, 2亿]为2库。方案一 优点：简单、数据均衡、负载均衡。缺点：扩容困难，要迁移数据，%2变%3麻烦。方案二 优点：简单、数据均衡、扩容简单。缺点：负载不均衡，大号段的库往往压力更大。大部分互联网公司使用方案一。
4.设定网站用户数量在千万级，但是活跃用户数量只有1%，如何通过优化数据库提高活跃用户访问速度？答：（1）可以使用MySQL的分区，把活跃用户分在一个区，不活跃用户分在另外一个区，本身活跃用户区数据量比较少，因此可以提高活跃用户访问速度。（2）还可以水平分表，把活跃用户分在一张表，不活跃用户分在另一张表，可以提高活跃用户访问速度。
5.分库分表之后，id 主键如何处理（1）数据库自增 id这个就是说你的系统里每次得到一个 id，都是往一个库的一个表里插入一条没什么业务含义的数据，然后获取一个数据库自增的一个 id。拿到这个 id 之后再往对应的分库分表里去写入。（2）设置数据库 sequence 或者表自增字段步长可以通过设置数据库 sequence 或者表的自增字段步长来进行水平伸缩。
6.现在有一个未分库分表的系统，未来要分库分表，如何设计才可以让系统从未分库分表动态切换到分库分表上？答:双写迁移方案。同时写俩库，老库和新库。然后系统部署之后，新库数据差太远，用之前说的导数工具，跑起来读老库数据写新库，写的时候要根据gmt_modified 这类字段判断这条数据最后修改的时间，除非是读出来的数据在新库里没有，或者是比新库的数据新才会写。导完一轮之后，有可能数据还是存在不一致，那么就程序自动做一轮校验，比对新老库每个表的每条数据，接着如果有不一样的，就针对那些不一样的，从老库读数据再次写。反复循环，直到两个库每个表的数据都完全一致为止。
7.你们具体是如何对数据库如何进行垂直拆分或水平拆分的？一般来说，垂直拆分，你可以在表层面来做，对一些字段特别多的表做一下拆分；水平拆分，你可以说是并发承载不了，或者是数据量太大，容量承载不了，拆了，按什么字段来拆。分表，你如果哪怕是拆到每个库里去，并发和容量都ok了，但是每个库的表还是太大了，那么你就分表，将这个表分开，保证每个表的数据量并不是很大。
8.分库分表的拆分方式有？他们分别主要解决什么问题？（1）水平切分，主要解决单表过大造成的性能问题，单表过大造成的单服务器空间问题。（2）垂直切分，主要解决表与表之间资源争用问题，锁争用机率小，实现核心与非核心的分级存储，如UDB登陆库拆分成一级二级三级库，数据库同步压力问题。
