MySQL如何实现分库分表，如何提高查询效率

作为一个对电商平台数据库运作有一定了解的小编，今天想跟大家聊聊当电商网站的业务量越来越大，数据库也跟着膨胀时，我们该如何应对这种数据洪流。
那就是——分库分表。

1 . 分库分表，怎么分？
对于数据库来说，随着数据量的增加，我们常常需要对其进行分库分表来提高性能和扩展性。
这里主要有两种方法：

垂直拆分：简单来说，就是把一张大表中的字段拆分到不同的表中。
比如说，一张用户信息表，我们可以把经常变动的字段（如用户最新订单信息）和不变动的字段（如用户基本信息）拆分成两张表。


水平拆分：这种方法主要是把表中的数据行分割到不同的数据库或表中。
比如，按照用户ID的奇偶性，把user表拆分成user1 和user2 等。

2 . 分库分表后，如何联合查询？
分库分表后，我们可能需要从多个表中查询数据，这时候就需要一些特殊的工具来帮忙了。
比如MyCat和Sharding-JDBC这样的第三方中间件。
它们的工作原理大致是这样的：
当你在客户端发了一条SQL查询，比如select from user，中间件会识别出这个表已经被分成了多个子表（比如user1 、user2 等），然后它会将原始的查询拆分成多个查询语句，比如select from user1 、select from user2 等，并且这些查询语句是并行执行的。
最后，中间件会汇总这些查询的结果，再返回给客户端。

总的来说，分库分表和利用中间件进行联合查询，都是提高大型电商网站数据库查询效率的有效手段。

mysql分库分表面试题

Hey小伙伴们，今天来聊聊MySQL分库分表那些事儿，准备动手的小伙伴们注意啦，以下是一些关键点：
1 . 分库时分，选对钥匙很重要：选partition key得讲究均衡，不能让某些库或表太累。
分库后，SQL里的聚合操作可能得在服务层重算，跨库事务能免则免，别让分布式事务来捣乱。

2 . 遇到表关联多字段检索怎么办？减少join吧，join太费资源。
如果必须，冗余数据或索引表是办法，但记得这会提高维护成本。
拆分查询也是一招，拆成小SQL，最后在应用层拼起来。

3 . 扩容策略了解一下？hash取模简单，但扩容麻烦，得迁移数据。
一致性hash分表则灵活，增减节点影响小。
实现时，得引入算法库，策略也得好好设计。

4 . 千万级用户，活跃只占1 %，怎么提速？分区和水平分表是关键，活跃和不活跃用户分开存，查询速度up up up！
5 . 分库分表后，id主键怎么搞？自增id或者设置sequence步长，确保每个库表的id不冲突。

6 . 系统未分库分表，未来要分怎么办？双写迁移，两边都写，导数工具帮忙，数据校验也不能少。

7 . 垂直拆分和水平拆分怎么做？垂直拆分是表拆，水平拆分看并发和数据量，选好partition key。

8 . 分库分表的拆分方式有几种？水平切分解决单表大问题，垂直切分解决资源争用和同步压力。

记好了这些，分库分表之路就不会那么坎坷啦！加油！

MySQL使用为什么要分库分表

好，没问题！咱们来聊聊数据库分库分表这事儿，用大白话给你捋一捋，保证让你听明白。

1 . 先说说，到底啥是分库分表？
说白了，就是“拆家”操作。
你想啊，以前所有数据都挤在一个大仓库（数据库）里，现在呢，咱们把它拆分成好多小仓库（多个数据库），或者一个仓库里分成好多小房间（多个表）。
简单说，就是把一个“大家伙”的数据，拆成几个“小家伙”分别放。

2 . 那为啥要搞这个分库分表呢？
最主要的原因就是，数据量没个谱，蹭蹭往上涨！你想想，没分之前，表越来越多，数据量越来越大，你查个信息、改个数据，是不是感觉越来越慢，越来越费劲？这主要是因为一台服务器（电脑）的能力是有限的，CPU、内存、硬盘这些都是死的，装不下、也处理不过那么多数据了。
再加上咱们不能把数据库也搞成分布式的（多个电脑一起用），所以最后数据库就卡壳了，撑不住了。

3 . 分库分表具体怎么操作呢？有啥策略？
主要就两种方法：
垂直切分： 这个就好比，你把一个超级大的超市（一个数据库），按照卖的东西种类分成了不同的区（不同的数据库），比如食品区、日用品区、服装区（workDB、payDB、userDB、logDB这些数据库就是例子），每个区只负责放特定类型的东西（用户数据、商品数据、日志数据等）。
这样做的好处是，每个区的数据量相对变小了，管理也相对简单。
水平切分： 这个呢，更像是把一个超大的仓库（一个表），按照货物编号（比如userID）分成了好多小格子（多个表），每个小格子放一部分货物。
比如，用户数据表userTable，可能就分成了userTable0、userTable1 、userTable2 ...好多张，每张表里只放一部分用户的数据。
这样做是为了解决单个表数据量太大的问题。
不过，这种方法更复杂一点，因为它把原本本来是一体的数据给拆开了，以后查询、管理都会更麻烦一些，需要考虑怎么平均分配数据、怎么让程序知道数据在哪。

那到底用哪种方法呢？
这得看你的具体情况。
如果你的问题是表特别多，数据量没控制住，而且你那项目的功能模块分得比较清楚，互不干扰（低耦合），那垂直切分是个好选择，简单好实现。
但如果你的表不多，但每个表的数据量都吓人，或者某些数据特别热门，访问特别频繁，那可能就得用水平切分了。
实际项目中，往往是这两种情况都有点，那就得权衡一下，甚至两种方法都用上。
我们之前做的游戏项目，就是这两种方法都用了，先垂直切分，再对一些特别大的表（比如用户数据表）进行水平切分。

4 . 分库分表会不会带来新问题？
当然有，而且还挺不少的：
事务问题： 你想做个操作，得同时改好几处地方的数据，而这些数据可能被分开放到了不同的仓库里。
这就像你要同时签两个合同的章，但一个合同在一个城市，一个在另一个城市，怎么办？找数据库帮你搞分布式事务吧，性能会差很多；自己写程序逻辑来控制吧，代码又复杂了。
这是个挺头疼的问题。
join查询问题： 以前你想查两个有关联的数据，直接写个SQL语句，把两个表关联起来查就行。
分库分表后，如果两个关联的数据被分到了不同的仓库，或者被分到了粒度不一样的表里，那这个关联查询就做不了了，可能得跑好几次查询才能把信息拼凑完整。
管理复杂度和计算量增加： 数据分散了，定位数据就更麻烦了，查、增、删、改都得多做一步功夫。
而且，像前面例子说的，查成绩最好的1 00名，以前一个命令搞定，现在可能得在每个小表里都查一次，然后还得把结果合并起来算，这得多费劲啊！所以，虽然分库分表解决了原始数据库的瓶颈，但也带来了新的管理负担和计算压力。

总的来说，分库分表是个技术活儿，能解决数据库扩展性问题，但也会带来新的挑战。
得根据实际情况，好好规划，权衡利弊再做决定。