09 | 数据库优化方案（二）：写入数据量增加时，如何实现分库分表？

Oct 7, 2019

09 | 数据库优化方案（二）：写入数据量增加时，如何实现分库分表？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

09 | 数据库优化方案（二）：写入数据量增加时，如何实现分库分表？

2019-10-07 唐扬来自北京

《高并发系统设计40问》

课程介绍



讲述：唐扬

时长13:45大小12.59M



你好，我是唐扬。
前一节课，我们学习了在高并发下数据库的一种优化方案：读写分离，它就是依靠主从复制的技术使得数据库实现了数据复制为多份，增强了抵抗大量并发读请求的能力，提升了数据库的查询性能的同时，也提升了数据的安全性。当某一个数据库节点，无论是主库还是从库发生故障时，我们还有其他的节点中存储着全量的数据，保证数据不会丢失。此时，你的电商系统的架构图变成了下面这样：
这时，公司 CEO 突然传来一个好消息，运营推广持续带来了流量，你所设计的电商系统的订单量突破了五千万。订单数据都是单表存储的，你的压力倍增，因为无论是数据库的查询还是写入性能都在下降，数据库的磁盘空间也在报警。所以，你主动分析现阶段自己需要考虑的问题，并寻求高效的解决方式，以便系统能正常运转下去。你考虑的问题主要有以下几点：
1. 系统正在持续不断地发展，注册的用户越来越多，产生的订单越来越多，数据库中存储的数据也越来越多，单个表的数据量超过了千万甚至到了亿级别。这时即使你使用了索引，索引占用的空间也随着数据量的增长而增大，数据库就无法缓存全量的索引信息，那么就需要从磁盘上读取索引数据，就会影响到查询的性能了。那么这时你要如何提升查询性能呢？
2. 数据量的增加也占据了磁盘的空间，数据库在备份和恢复的时间变长，你如何让数据库系统支持如此大的数据量呢？
3. 不同模块的数据，比如用户数据和用户关系数据，全都存储在一个主库中，一旦主库发生故障，所有的模块都会受到影响，那么如何做到不同模块的故障隔离呢？
4. 你已经知道了，在 4 核 8G 的云服务器上对 MySQL 5.7 做 Benchmark，大概可以支撑 500TPS 和 10000QPS，你可以看到数据库对于写入性能要弱于数据查询的能力，那么随着系统写入请求量的增长，数据库系统如何来处理更高的并发写入请求呢？
这些问题你可以归纳成，数据库的写入请求量大造成的性能和可用性方面的问题，要解决这些问题，你所采取的措施就是对数据进行分片。这样可以很好地分摊数据库的读写压力，也可以突破单机的存储瓶颈，而常见的一种方式是对数据库做“分库分表”。
分库分表是一个很常见的技术方案，你应该有所了解。那你会说了：“既然这个技术很普遍，而我又有所了解，那你为什么还要提及这个话题呢？”因为以我过往的经验来看，不少人会在“分库分表”这里踩坑，主要体现在：
1. 对如何使用正确的分库分表方式一知半解，没有明白使用场景和方法。比如，一些同学会在查询时不使用分区键；
2. 分库分表引入了一些问题后，没有找到合适的解决方案。比如，会在查询时使用大量连表查询等等。
本节课，我就带你解决这两个问题，从常人容易踩坑的地方，跳出来。
如何对数据库做垂直拆分分库分表是一种常见的将数据分片的方式，它的基本思想是依照某一种策略将数据尽量平均地分配到多个数据库节点或者多个表中。
不同于主从复制时数据是全量地被拷贝到多个节点，分库分表后，每个节点只保存部分的数据，这样可以有效地减少单个数据库节点和单个数据表中存储的数据量，在解决了数据存储瓶颈的同时也能有效地提升数据查询的性能。同时，因为数据被分配到多个数据库节点上，那么数据的写入请求也从请求单一主库变成了请求多个数据分片节点，在一定程度上也会提升并发写入的性能。
比如，我之前做过一个直播项目，在这个项目中，需要存储用户在直播间中发的消息以及直播间中的系统消息，你知道这些消息量极大，有些比较火的直播间有上万条留言是很常见的事儿，日积月累下来就积攒了几亿的数据，查询的性能和存储空间都扛不住了。没办法，就只能加班加点重构，启动多个数据库来分摊写入压力和容量的压力，也需要将原来单库的数据迁移到新启动的数据库节点上，好在最后成功完成分库分表和数据迁移校验工作，不过也着实花费了不少的时间和精力。
数据库分库分表的方式有两种：一种是垂直拆分，另一种是水平拆分。这两种方式，在我看来，掌握拆分方式是关键，理解拆分原理是内核。所以你在学习时，最好可以结合自身业务来思考。
垂直拆分，顾名思义就是对数据库竖着拆分，也就是将数据库的表拆分到多个不同的数据库中。
垂直拆分的原则一般是按照业务类型来拆分，核心思想是专库专用，将业务耦合度比较高的表拆分到单独的库中。举个形象的例子，就是在整理衣服的时候，将羽绒服、毛衣、T 恤分别放在不同的格子里。这样可以解决我在开篇提到的第三个问题：把不同的业务的数据分拆到不同的数据库节点上，这样一旦数据库发生故障时只会影响到某一个模块的功能，不会影响到整体功能，从而实现了数据层面的故障隔离。
我还是以微博系统为例来给你说明一下。
在微博系统中有和用户相关的表，有和内容相关的表，有和关系相关的表，这些表都存储在主库中。在拆分后，我们期望用户相关的表分拆到用户库中，内容相关的表分拆到内容库中，关系相关的表分拆到关系库中。
对数据库进行垂直拆分是一种偏常规的方式，这种方式其实你会比较常用，不过拆分之后，虽然可以暂时缓解存储容量的瓶颈，但并不是万事大吉，因为数据库垂直拆分后依然不能解决某一个业务模块的数据大量膨胀的问题，一旦你的系统遭遇某一个业务库的数据量暴增，在这个情况下，你还需要继续寻找可以弥补的方式。
比如微博关系量早已经过了千亿，单一的数据库或者数据表已经远远不能满足存储和查询的需求了，这个时候，你需要将数据拆分到多个数据库和数据表中，也就是对数据库和数据表做水平拆分了。
如何对数据库做水平拆分和垂直拆分的关注点不同，垂直拆分的关注点在于业务相关性，而水平拆分指的是将单一数据表按照某一种规则拆分到多个数据库和多个数据表中，关注点在数据的特点。
拆分的规则有下面这两种：
1. 按照某一个字段的哈希值做拆分，这种拆分规则比较适用于实体表，比如说用户表，内容表，我们一般按照这些实体表的 ID 字段来拆分。比如说我们想把用户表拆分成 16 个库，每个库是 64 张表，那么可以先对用户 ID 做哈希，哈希的目的是将 ID 尽量打散，然后再对 16 取余，这样就得到了分库后的索引值；对 64 取余，就得到了分表后的索引值。
2. 另一种比较常用的是按照某一个字段的区间来拆分，比较常用的是时间字段。你知道在内容表里面有“创建时间”的字段，而我们也是按照时间来查看一个人发布的内容。我们可能会要看昨天的内容，也可能会看一个月前发布的内容，这时就可以按照创建时间的区间来分库分表，比如说可以把一个月的数据放入一张表中，这样在查询时就可以根据创建时间先定位数据存储在哪个表里面，再按照查询条件来查询。
一般来说，列表数据可以使用这种拆分方式，比如一个人一段时间的订单，一段时间发布的内容。但是这种方式可能会存在明显的热点，这很好理解嘛，你当然会更关注最近我买了什么，发了什么，所以查询的 QPS 也会更多一些，对性能有一定的影响。另外，使用这种拆分规则后，数据表要提前建立好，否则如果时间到了 2020 年元旦，DBA（Database Administrator，数据库管理员）却忘记了建表，那么 2020 年的数据就没有库表可写了，就会发生故障了。
数据库在分库分表之后，数据的访问方式也有了极大的改变，原先只需要根据查询条件到从库中查询数据即可，现在则需要先确认数据在哪一个库表中，再到那个库表中查询数据。这种复杂度也可以通过数据库中间件来解决，我们在08 讲中已经有所讲解，这里就不再赘述了，不过，我想再次强调的是，你需要对所使用数据库中间件的原理有足够的了解，和足够强的运维上的把控能力。
不过，你要知道的是，分库分表虽然能够解决数据库扩展性的问题，但是它也给我们的使用带来了一些问题。
解决分库分表引入的问题分库分表引入的一个最大的问题就是引入了分库分表键，也叫做分区键，也就是我们对数据库做分库分表所依据的字段。
从分库分表规则中你可以看到，无论是哈希拆分还是区间段的拆分，我们首先都需要选取一个数据库字段，这带来一个问题是：我们之后所有的查询都需要带上这个字段，才能找到数据所在的库和表，否则就只能向所有的数据库和数据表发送查询命令。如果像上面说的要拆分成 16 个库和 64 张表，那么一次数据的查询会变成 16*64=1024 次查询，查询的性能肯定是极差的。
当然，方法总比问题多，针对这个问题，我们也会有一些相应的解决思路。比如，在用户库中我们使用 ID 作为分区键，这时如果需要按照昵称来查询用户时，你可以按照昵称作为分区键再做一次拆分，但是这样会极大地增加存储成本，如果以后我们还需要按照注册时间来查询时要怎么办呢，再做一次拆分吗？
所以最合适的思路是你要建立一个昵称和 ID 的映射表，在查询的时候要先通过昵称查询到 ID，再通过 ID 查询完整的数据，这个表也可以是分库分表的，也需要占用一定的存储空间，但是因为表中只有两个字段，所以相比重新做一次拆分还是会节省不少的空间的。
分库分表引入的另外一个问题是一些数据库的特性在实现时可能变得很困难。比如说多表的 JOIN 在单库时是可以通过一个 SQL 语句完成的，但是拆分到多个数据库之后就无法跨库执行 SQL 了，不过好在我们对于 JOIN 的需求不高，即使有也一般是把两个表的数据取出后在业务代码里面做筛选，复杂是有一些，不过是可以实现的。再比如说在未分库分表之前查询数据总数时只需要在 SQL 中执行 count() 即可，现在数据被分散到多个库表中，我们可能要考虑其他的方案，比方说将计数的数据单独存储在一张表中或者记录在 Redis 里面。
当然，虽然分库分表会对我们使用数据库带来一些不便，但是相比它所带来的扩展性和性能方面的提升，我们还是需要做的，因为，经历过分库分表后的系统，才能够突破单机的容量和请求量的瓶颈，就比如说，我在开篇提到的我们的电商系统，它正是经历了分库分表，才会解决订单表数据量过大带来的性能衰减和容量瓶颈。
课程小结总的来说，在面对数据库容量瓶颈和写并发量大的问题时，你可以采用垂直拆分和水平拆分来解决，不过你要注意，这两种方式虽然能够解决问题，但是也会引入诸如查询数据必须带上分区键，列表总数需要单独冗余存储等问题。
而且，你需要了解的是在实现分库分表过程中，数据从单库单表迁移多库多表是一件既繁杂又容易出错的事情，而且如果我们初期没有规划得当，后面要继续增加数据库数或者表数时，我们还要经历这个迁移的过程。所以，从我的经验出发，对于分库分表的原则主要有以下几点：
1. 如果在性能上没有瓶颈点那么就尽量不做分库分表；
2. 如果要做，就尽量一次到位，比如说 16 库，每个库 64 表就基本能够满足几年内你的业务的需求。
3. 很多的 NoSQL 数据库，例如 Hbase，MongoDB 都提供 auto sharding 的特性，如果你的团队内部对于这些组件比较熟悉，有较强的运维能力，那么也可以考虑使用这些 NoSQL 数据库替代传统的关系型数据库。
其实，在我看来，有很多人并没有真正从根本上搞懂为什么要拆分，拆分后会带来哪些问题，只是一味地学习大厂现有的拆分方法，从而导致问题频出。所以，你在使用一个方案解决一个问题的时候一定要弄清楚原理，搞清楚这个方案会带来什么问题，要如何来解决，要知其然也知其所以然，这样才能在解决问题的同时避免踩坑。
一课一思分库分表实际上是分布式存储中一种数据分片的解决方案，那么你还了解哪些分布式存储组件也使用了类似的技术呢？它的实现方式你了解吗？欢迎在留言区与我分享你的经验。
最后，感谢你的阅读，如果这篇文章让你有所收获，也欢迎你将它分享给更多的朋友。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 32

提建议

08 | 数据库优化方案（一）：查询请求增加时，如何做主从分离？

10 | 发号器：如何保证分库分表后ID的全局唯一性？

 写留言

精选留言(86)

每天晒白牙
2019-10-07
主要内容梳理写入请求量大会造成性能和可用性的问题，如何应对呢？采取对数据进行"分片"，这是一种思想，在数据库中就是分库分表，Kafka中是分区，ES中是分片分库分表的思想是根据某种分配策略把数据尽量均匀的分到多个数据库节点或多个表中，这样每个数据库节点和表都只存储部分数据，这样对数据的存储、读和写都有意义存储:因为分库分表后每个节点和表只存储部分数据，这样就能解决数据存储的瓶颈读:因为每个节点和表存储部分数据，数据量变小，可以提升查询性能写:数据写入被分摊到多个节点和表，写入性能提高分库分表有两种方式:垂直拆分和水平拆分垂直拆分的关注点在业务相关性，原则是按照业务拆分，核心思想是专库专用，将业务耦合度高的拆分到单独库中水平拆分是把单一数据库按照某种规则拆分到多个数据库和多个数据表中，关注点在数据的特点水平拆分的两种方法 1.根据某个字段的hash值拆分比如想把用户表拆成16库64表，方案如下先对id进行hash操作hash(id)，这样有助于打散数据然后对16取余 hash(id)%16，这样就得到了分库后的索引最后对64取余 hash(id)%16%64，这样就得到了分表后的索引值 2.根据某个字段的区间或范围拆分可以根据时间拆分引入分库分表确实有很多优点，但也会引入新的问题 1.引入了分区分表键，也叫分区键因为我们需要对分区键进行hash进行索引，这样就导致我们查询都要带上该分区键，比较好的解决办法是用id做分区键，但是如果有根据用户昵称查询的需求怎么办呢？解决办法就是建立一个昵称和id的映射表 2.一些数据库的特性的实现变得困难 (1)夸库join不可用解决办法是在业务代码中做处理 (2)求count 采取第三方组件例如redis实现课后思考题大数据的存储组件一般都涉及数据分片技术例如Kafka的分区，ES的分片等等拿Kafka的分区来举例 Kafka会对消息的key进行hash然后对分区数量取模，这样就得到了topic对应的分区索引疑问点 1.老师我想请教下就是多库join的问题，如果采用在业务代码中进行处理不太妥吧，数据量太大了，如果有分页或排序的需求，这是要把各个库的数据都查出来，在内存中进行操作，这样会想当耗费内存，且性能低，老师有啥好办法吗？ 2.如果一个订单库采用了买家id做为分区键，这样查询买家的订单非常容易，那要查询卖家的订单是不是和文中根据昵称查询一样，建立一个卖家和买家的映射表解决？ 3.文中老师说如果要做分库分表留言一次性做到位，但这样在开始会很浪费空间，所以一般公司还是会采取慢慢扩容的方式，这样就引入了不停机迁移数据的问题，针对这种情况，老师是怎么做的呢？谢谢老师
展开
作者回复: 1.多表join一般不会是全量数据，是分页数据，所以只有一少部分 2.建议是订单ID分库分表，然后建立买家ID和卖家ID和订单ID的映射 3. 一般是先双写两个库，然后校验数据，然后灰度切读，最后全量切读
共 8 条评论
86
Xiang
2020-02-22
介绍一个 range+hash 分库分表的方案吧，分库分表？如何做到永不迁移数据和避免热点？ https://mp.weixin.qq.com/s/QFlUPS8X0errMwpxdBMHvg
作者回复: 👍
共 8 条评论
34
撒旦的堕落
2019-10-09
老师说的道理我都明白只是如果现在有一张上亿的表并且存在特定属性更新那么如何不停机进行分库分表有木有具体的实践
作者回复: 可以搭建新的库之后，先在业务上双写，然后校验两边的数据，再灰度切读，再全量切读
共 6 条评论
27
逍遥飞鹤
2020-03-25
如果是因读性能引起的分库分表，可考虑ES或MongoDB、HBase的数据重构方式，避免在MySQL做文章如果是写性能引起的分库分表，可按老师上面的这些原则进行实践和改造
作者回复: 是的
共 4 条评论
16
leesir
2019-11-20
分库分表如何做： 1、对实体表，路由规则可以是id取模，计算得到数据真正存放的表。可以降低单表的规模，平均每个表的数据量。 2、对时间倒排的列表，比如微博内容或者订单，可以根据时间字段水平分表，将近期少部热点数据集中到一起。分库分表所引发的问题的解决方案： 1、由于分区规则的原因，查询无论如何都必须拿到分区键。可以对某些高频非分区键字段建立二级映射，模拟mysql主键和二级索引的解决方式（二级索引的叶子数据存放的是主键索引）。比如根据name查询用户，可以建立name和uid的映射，查询时先根据name拿到uid，再用uid做后续查询。 2、数据库拆分后，针对联表查询，要么少做联表，要么做数据冗余（表字段冗余，或者其他nosql数据冗余）。 3、分布式事务 a) 数据库中间件 b) mq事务消息 c) 将分布式大事务转化成多个本地小事务，通过异步通知+定时补偿+幂等实现最终一致性
展开
11
枫叶11
2019-10-07
公司小业务少时，不可能一开始就规划很多库和表(如16*64)，就像很多项目开始都只有一个库，但是我们做架构时可以预先考虑到后面可能会分库分表。请问老师，能不能讲一下最开始设计数据库时需要为今后分库分表考虑哪些因素，和一旦扩容后数据迁移的方案和注意点。谢谢。
作者回复: 主要考虑数据的增长情况，数据迁移一般是先双写旧库和新库，然后校验数据，然后灰度切读，最后全量切读，注意点就是数据校验过程，会比较繁琐
共 5 条评论
11
正在减肥的胖籽。
2019-10-09
分库分表之后,对于app端查询的问题还比较好解决。但是后端运营系统查询就麻烦，比如订单分库分表后，运营系统查询订单的时候可能根据多维度查询，这种方案您在工作中是怎么去解决的？我现在的做法就是同步到es里面。用ES去查。
作者回复: 可以的，也可以同步到一个大库中，不过性能有点儿差
共 2 条评论
9
Chocolate
2019-10-07
老师，请问下昵称和 ID 的映射表怎么建立，是按照昵称进行分库分表吗，即先查询这个昵称在哪个库哪个表，然后找到 ID，根据 ID 所在的库和表进行查询吗？
作者回复: 是的，没错
共 5 条评论
8
深深的人
2019-10-15
老师查询conut怎么做冗余，那种有where条件的
作者回复: 可以考虑用es
6
jc9090kkk
2019-10-08
感谢老师分享，对于分表有点疑问： 1.如果是用户信息表需要分表，数据量大的前提下，需要准备一个映射表来存储昵称+uid的对应关系，文中提到了映射表也可以做分库分表，基本的思路是什么？用户在做登录相关操作的时候，都不知道昵称+uid的映射关系在哪张表中，难道是通过昵称算出hash值来确定分区键？ 2.如果hash分表的策略又达到了瓶颈，需要更多的容量呢？基于对业务影响最小的方案是采用数据冗余+新的分区表还是重建分表规则做数据迁移？这一部分没有讲到哦，后面能否专门讲解下，一般应该是前者吧，因为后者在数据量大的情况下做一次数据迁移成本太高了？ 3.对于文中提到的，16个库每个库中64张表，1024个张表，这个分表策略的理由是什么？个人感觉这个分表规则显得有些太浮夸了，因为有些业务压根用不到这么多表，甚至有时候分表操作是分表策略（局部分表）+当前模式（局部不分表）公用的方式来协调的，一步一步迭代过来的？不是很理解文中提到的这个策略的容量是如何计算出来的？如果数据量压根用不到这么多表，数据过于分散，对于管理和维护成本来讲有点小题大做了吧？另外有一点，文中提到的总计数的问题，用redis存储的前提是当前的业务逻辑不是敏感的，用redis可以提升性能，如果是敏感业务的话，在更新数据库后还没有写入redis中的这个时间差，请求并发没办法估量和控制，所以最后的数据总量仅仅是最终的数据是一致的，但是逻辑是不一致的，核心原因是redis和mysql是属于不同的存储系统，无法做到两个系统公共支持一个分布式事物，无法拿到精确一致的视图，当然如果是非敏感业务，在保证性能的前提下，逻辑不一致可以容忍的话是可以考虑这种方案的。
展开
作者回复: 1. 是对昵称做hash，登陆的时候不需要知道昵称呀，可以针对手机号做hash，昵称是用来判断昵称是否存在 2. 不太清楚数据冗余 + 新的分区表的意思，是增加新的分区表吗？那么就要改分库分表的规则，那这样原先的数据就读不到了？是要做数据迁移？ 3. 是需要一步步迭代，这里是说这些库表是足够了，如果业务没有那么大数据量，可以按照业务来 4. 计数是最终一致就好了
共 2 条评论
6
Sam_Deep_Thinking
2020-05-28
我觉得分库和分表要单独分开来讲。要分库，是因为并发写压力太大，不得不分，这个时候分表是没任何作用的，单个数据库实例瓶颈就在那。而分表，在数据量大，而并发写压力不高时，就很合适，也没必要分库。另外比较赞同的是，尽量不分库分表，实在没办法才做这一步，部分情况下，做数据归档也是可以的。
展开
共 1 条评论
6
小喵喵
2019-10-10
老师能详细介绍一下分区和分片技术吗？
共 1 条评论
5
黑暗浪子
2019-10-10
这个东西能不用就不用。毕竟很多老系统还有超多join操作，你一开始分库分表，所有代码都要重写。我倒觉得换es，mongodb是个好思路
作者回复: 如果有运维能力也可
共 2 条评论
6
Corner
2019-10-07
请教老师，为什么id要先做hash再做取余计算分库位置呢？直接用id取余不可以吗？
作者回复: 直接取余也好，只是怕ID会不均匀
共 6 条评论
5
Josey
2020-03-24
老师，我们现在面临一个问题，如果我们在使用某个业务字段哈希之后分了64张表之后，后面又发现分表后性能瓶颈，要把64张表分成128张表，这种操作就需要把原来的哈希规则重制，有什么好的办法解决吗？
作者回复: 要么一次分足够多的表，要么可以采用类似时间范围这样不需要hash得分表方式
共 3 条评论
3
张珂
2020-01-21
老师好，我这辈子做过的最大系统，不仅仅用上分库分表和读写分离了。很简单就是在100个MySQL，每个MySQL有100个表，这样根据id后四位就可以定位到它应该放在哪个MySQL和哪个表。但是因为每天可能有20亿的事务量，长此以往的数据积累，单表超过2000万时增改查性能都急剧下降，而且还有大数据团队要从这里导数据出去，低峰时还要删数据。那么我们就在时间纬度上也做了“分库分表”的思想：这一套分库分表乘以31，每天一套表来做日切，于是避免了单表过大，线上导数据风险大的问题，但业务上只能实时查询的31天内的数据，就是成本好大运维压力挺大。
展开
作者回复: 👍能解决问题就好
共 2 条评论
3
xu晓晨
2019-10-08
如果分库分表后又增加了一个库来存储。那么原来的数据岂不是都不能用了？所有的数据再需要重新的分一遍吗？据说一致性hash能解决这问题？老师可以具体说说吗
作者回复: 一致性hash解决不了这个问题，如果要增加库的话，只能重新分配，所以会比较麻烦
共 3 条评论
3
红鲤鱼与绿鲤鱼与驴ba...
2020-05-21
老师关于分表的问题，比如您文章中说的用户分表根据uid 进行hash运算，分了一共16个库（0-15）我要获取某个用户的信息，可以根据uid 进行hash运算找到对应的用户表，这个能理解，但是在添加的时候呢？分了16个库，来一个注册用户，这时候这个用户的注册数据应该怎么进行hash计算，让用户数据写入到对应的分库中？
作者回复: uid可以用发号器生成，然后就可以根据uid知道写哪一个库了
2
null
2020-04-29
老师，你好！订单表分库分表之后，像后台 OA 系统，带查询条件订单分页列表，带查询条件count 订单数量，这些需求该如何实现吖？
作者回复: 一般会同步到一个非分库分表的存储中，比如elasticsearch，或者单个mysql，因为后台的请求量不大，所以还好
共 2 条评论
3
M
2019-12-04
麻烦请教下老师，项目中单表百万级的多表联查怎么做优化呢？
作者回复: 额，尽量不做连表，互联网业务比较简单，一般可以查出数据后，在内存中关联
共 2 条评论
2

