- 2018-05-31分库，分表带来的问题都知道，能不能介绍些好的方便的改进方案？ 236
2018-05-31应该是这些操作依次尝试
1.做硬件优化，例如从机械硬盘改成使用固态硬盘，当然固态硬盘不适合服务器使用，只是举个例子
2.先做数据库服务器的调优操作，例如增加索引，oracle有很多的参数调整;
3.引入缓存技术，例如Redis，减少数据库压力
4.程序与数据库表优化，重构，例如根据业务逻辑对程序逻辑做优化，减少不必要的查询;
5.在这些操作都不能大幅度优化性能的情况下，不能满足将来的发展，再考虑分库分表，也要有预估性展开作者回复: 赞，写的很完善
1 95
2018-05-31分库分表，可以理解为是一种空间换时间的思路，同时分流了存储压力与读写压力。
数据库性能不够时，首先应该想到是否可以通过改善硬件条件等垂直扩容手段；其次可引入读写分离、缓存/NoSQL、全文检索等手段；然后，单库单表的访问仍然存在性能瓶颈，可考虑分库分表，并且分库分表可以按照业务进行垂直拆分，接着进行水平拆分。
我的问题是:当线上已经进行了分库分表的系统，需要进一步水平扩容时，有什么好的设计方案？展开作者回复: 没有太好的方案，要么一开始的分表方案就是按照id范围来设计的，要么就需要数据迁移
26
2018-07-10如果使用hash进行分表的话，为什么大多方案推荐2的n次方作为表的总数，除了收缩容易还有什么好处吗？谢谢作者回复: 这个是hash函数实现的一个技巧，当计算hash值的时候，普通做法是取余操作，例如h%len，但如果len是2的N次方，通过位操作性能更高，计算方式为h & (len-1)
1 16
2018-05-31其实在同一个库里做数据拆分，无需分表吧？就例如MySQL，只需要对表做分区就可以了。分表的目的主要是为后面把表分到不同的数据库实例作准备？
还有个疑问，文中提到，用户表的description等字段内容不是经常查到，所以做垂直划分可以提高查询性能，意思是，如果表中有内容较长的字段，查询的时候不查出来（不使用select *），也会有性能问题？
最后，我觉得当单实例的访问量，已达到机器的60%承载能力，就要考虑分库，而具体如何拆分，则要分析访问量主要集中在哪些表。至于分表，主要依据还是单表的数据量和查询性能。作者回复: 关系数据库是行存储，即使不用那一列，也会从存储读取到内存
1 16- 2018-06-01老师，使用tidb方案来代替分库分表是否推荐？ 13
2018-05-31我们是在设计初就考虑进去了，预估单表数据容量，再考虑未来三年的数据增长，不过现在反观这种做法，感觉有点过度设计，如当初一张用户表，分了127张，2个库，然而实际数据容量根本没这么多，顶多千万级别，不仅带来存储资源浪费，也给编码带来不少复杂度！所以我还是觉得得遵循演化原则，业务真正发展起来再考虑分库分表作者回复: 我们也这样做过，后来受不了了又缩表😂😂😂
13
2019-03-28老师，针对mysql，发现如果字段有blob的字段，select 不写这个字段，和写这个字段，效率差异很大啊，这个是什么原因？一直没弄明白😊 ，谢谢作者回复: blob的字段是和行数据分开存储的，而且磁盘上并不是连续的，因此select blob字段会让磁盘进入随机IO模式
12
2018-06-06我们公司业务增长比较平稳，已经经历了几个过程，
1.先是最基础的主备，Oracle 扛了3年到15年，中间优化了几次硬件和数据库上的配置
2.到16年左右开始扛不住了，数据量在3千万，但是订单表列太多，导致性能开始不理想，这个时候做了一把分区，性能勉强接受，继续扛着
3.到17年之后做到18年开始做去O项目换MySQL了，顺带着分表和分区了，目前按业务，把一些非核心业务分出去其他库了，订单的库还没分，按照历史年表和热表来做的，做滚表实现的，热表数据差不多在1千万以内，现在性能还不错，历史数据用搜索聚合的，查询性能还不错！
4.到后面如果业务再持续增长的话，估计就要拆订单库了
总结一句话，分库分表要在业务需要之前一点，看数据量和业务特性！展开作者回复: 这样做没错，如果你们12年就开始分库分表，可能当时的方案也不一定适应后来的业务变化
1 11
2018-05-31分库分表的痛点大家都知道，可否介绍下解决方案…作者回复: 没有很好的，要么中间件要么代码中间层，业务代码处理总是很麻烦的
10
2018-05-31分库分表的实施前提：
1. 数据库存在性能问题，且用加索引、慢查询优化、缓存和读写分离都无法彻底解决问题的时候
2. 复杂查询对应的单表数据量级一般超过千万以上，或简单查询的单表数据量级一般超过5000万以上
3. 对一致性要求不是特别高，只要求最终一致性。
4. 用hadoop等大数据技术因为业务需求、技术成本、时间成本无法解决该问题
其他：
1. 业务对数据的操作主要集中在某些字段上，比较适合垂直分表
2. 业务对数据的操作在整个表层面较均匀分布，适合水平分表展开 10
2018-06-29数据库优化顺序:
1. 慢查询
2. 根据业务特点，对表设计进行优化
3. 业务逻辑问题
4. 多用短查询
5. 部分表加缓存
这些做完再考虑分库分表吧？展开 6
2018-05-31其实hash还有一个问题，就是当新增一张表时，怎么处理，比如说我原来是10张表，现在要增加到11张表，可以用一致性hash解决，但也会有数据迁移问题 6
2018-08-19首先并不是数据库性能不够的时候就分库分表，提升数据库性能方式很多，若有其他能在单数据库操作的方式则毫不犹豫使用，因为使用分表有固有的复杂性（join操作，事务，order by等）。
分库使用时机：
1、业务不复杂，但整体数据量已影响了数据库的性能。
2、业务复杂，需要分模块由不同开发团队负责开发，这个时候使用分库可以减少团队间交流。
分表时机：
1、单个数据表数据量太大，拖慢了SQL操作性能。展开作者回复: 分析正确
4
2018-06-15想请教老师一个设计问题，以电商平台交易系统为例，订单数据量非常大的时候也可以考虑水平分库分表。
我的思考是针对消费者端订单表按用户ID哈希规则分表，这样所有对用户订单的查询条件全都带上用户ID，达到了数据分片的效果。
但这时商家端需要对订单做管理，就很尴尬了。于是我想到，可以将订单数据做同步到另一个数据源，表结构一致只是按照商家ID进行哈希规则分表，所有商家端查询走此数据源，条件全部带上商家ID，也可以做到数据分片的效果。
接下来问题又来了，系统还有一个平台的视角，这时貌似不好沿着这个思路继续了，恳请老师提点提点。作者回复: 淘宝的单元化改造就面临你说的问题，最后他们选择了买家纬度拆分，卖家纬度不拆分，详细可以搜网上的公开资料。
4
2019-08-09按照ID来分库的话会遇到访问热点问题，请问李老师这种情况怎么解决？作者回复: 读热点加缓存，写热点加缓冲，例如用消息队列，写热点也可以合并写
3
2018-12-30您好！请教一个问题，目前线上业务遇到一个问题，就是订单表需要在单库里分100张表，使用uid%100分的表，前端用户查数据没有问题，后台需要查天、周、月、年的统计信息，这个应该怎么实现？而且要求每行统计记录点击后可以看到该汇总信息下所有的订单记录，这个该怎么做？作者回复: 后台统计库不拆分，冗余一份线上数据，既可以应对复杂的统计需求，也不担心影响线上业务
2 3
2018-08-14看了李老师的文章，真的是受益匪浅。
我也想请教一个问题，就是我们的数据库是使用阿里云的RDS，现在是单实例，没做分库。所有业务都在同一个库上跑一共有1000个表，包括分表，也是库内分表，主要是这两年都在快速迭代业务，性能上欠考虑，到现在也遇到瓶颈，一到业务高峰，RDS就会报警，前几天做了硬件升级。暂时稳住了。
我们想从数据库架构上要优化它，但一时也不好优化，不知老师有什么好的建议，让我参考作者回复: 先分表到不同数据库服务器，估计还能再撑一两年😄
3
2018-07-24老师您好，分库分表后必然会遇见运营人员实时报表查询的问题。单库时，查询实现起来比较简单。
分库之后，查询就变得复杂了，请问有没有比较好的解决思路呢？作者回复: 数据写双份，一份给线上用，采用分库分表；一份给运营，不分库分表
3
2018-06-15所以在分库分表前，一般的业务用优化sql就搞定了。不用分库分表这把牛刀。老师对sql优化有什么指导建议麽？作者回复: 高性能mysql，把explain的结果能完全看懂就很厉害了
3