别再问“分库分表”了，再问就瓦解了！

①全局表：全局表，也可看做是"数据字典表"，就是体系中全部模块都也许依靠的一些表，为了停止跨库 join 查询，可以将这类表在每个数据库中都生涯一份。这些数据凡是很少会举办修改，以是也不担忧同等性的题目。

②字段冗余：一种典范的反范式计划，操作空间换时刻，为了机能而停止 join 查询。

譬喻：订单表生涯 userId 时辰，也将 userName 冗余生涯一份，这样查询订单详情时就不必要再去查询"买家 user 表"了。

但这种要领合用场景也有限，较量合用于依靠字段较量少的环境。而冗余字段的数据同等性也较难担保，就像上面订单表的例子，买家修改了 userName 后，是否必要在汗青订单中同步更新呢?这也要团结现实营业场景举办思量。

③数据组装：在体系层面，分两次查询，第一次查询的功效齐集找出关联数据 id，然后按照 id 提倡第二次哀求获得关联数据。最后将获获得的数据举办字段拼装。

④ER 分片：相关型数据库中，假如可以先确定表之间的关联相关，并将那些存在关联相关的表记录存放在统一个分片上，那么就能较好的停止跨分片 join 题目。在 1:1 或 1:n 的环境下，凡是凭证主表的 ID 主键切分。

如下图所示：

这样一来，Data Node1 上面的 order 订单表与 orderdetail 订单详情表就可以通过 orderId 举办局部的关联查询了，Data Node2 上也一样。

跨节点分页、排序、函数题目

跨节点多库举办查询时，会呈现 limit 分页、order by 排序等题目。分页必要凭证指定字段举办排序，当排序字段就是分片字段时，通过度片法则就较量轻易定位到指定的分片;当排序字段非分片字段时，就变得较量伟大了。

必要先在差异的分片节点中将数据举办排序并返回，然后将差异分片返回的功效集举办汇总和再次排序，最终返回给用户。

如图所示：

上图中只是取第一页的数据，对机能影响还不是很大。可是假如取得页数很大，环境则变得伟大许多。

由于各分片节点中的数据也许是随机的，为了排序的精确性，必要将全部节点的前 N 页数据都排序好做归并，最后再举办整体的排序，这样的操纵是很淹灭 CPU 和内存资源的，以是页数越大，体系的机能也会越差。

在行使 Max、Min、Sum、Count 之类的函数举办计较的时辰，也必要先在每个分片上执行响应的函数，然后将各个分片的功效集举办汇总和再次计较，最终将功效返回。

如图所示：

全局主键避重题目

在分库分神色况中，因为表中数据同时存在差异数据库中，主键值平常行使的自增添将无用武之地，某个分区数据库自天生的 ID 无法担保全局独一。

因此必要单独计划全局主键，以停止跨库主键一再题目。有一些常见的主键天生存策：

①UUID

UUID 尺度情势包括 32 个 16 进制数字，分为 5 段，情势为 8-4-4-4-12 的 36 个字符，譬喻：550e8400-e29b-41d4-a716-446655440000。

UUID 是主键是最简朴的方案，当地天生，机能高，没有收集耗时。但弱点也很明明，因为 UUID 很是长，会占用大量的存储空间。

其它，作为主键成立索引和基于索引举办查询时城市存在机能题目，在 InnoDB 下，UUID 的无序性会引起数据位置频仍变换，导致分页。

②团结数据库维护主键 ID 表

在数据库中成立 sequence 表：

CREATE TABLE `sequence` (   

  `id` bigint(20) unsigned NOT NULL auto_increment,   

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!