分库分表流程梳理
2021-11-13 22:42:11 36 举报AI智能生成
登录查看完整内容
笔记
作者其他创作
大纲/内容
不用部署，运维成本低，不用代理层二次转发，性能高，但是如果jar更新，需要各个系统重新发布升级，耦合性太强；
sharding-jdbc
需要部署，运维成本高，但是如果升级新版本，只需升级中间件，各个系统透明；
mycat
分库分表中间件
垂直拆分，把访问频率高的字段集中放到一个表里，访问频率低的字段集中放到一个表里，因为数据库是有缓存的，一行数据，频率高的字段集中起来，没用的字段不往里表里放，这样缓存中就可以放更多的行；
分库分表方式：range来分，按时间范围来分；但容易产生热点数据，可能大量请求打到热点数据上；或者按hash算法分片；
水平拆分，垂直拆分
停机迁移，凌晨12点开干
双写迁移；同时写老库和新库；然后用导数的工具读老库，写新库；要根据数据modifiedtime判断，该条数据比新库的还要新，才往里写；多次反复对照，直到新老数据库数据一致；
1，设计分库分表，如何让系统从未分库分表的地方动态迁移到分库分表？
停机扩容不推荐；
开始就32库32表，1024，长期不用扩容；根据id取模32到库，再取模32到表；
如何设计可以动态扩缩容的分库分表方案？
设置数据库sequence或者表自增字段步长；比如有8个节点，每个服务器起始值为1，2，3。。。8，第二次值为9，10，11，。。。17；服务节点固定，如果增加服务器就麻烦了；
UUID：本地生成，不依赖数据库；但是；太长占空间，无序，作为主键性能太差；会导致B+树索引过多的随机IO操作；insert不能连续，导致将B+树索引全部写入磁盘性能太差；只适合做标题，编号等，
snowflake 算法：
分库分表之后，id主键如何处理？
场景？
分库分表流程梳理
0 条评论
回复 删除
下一页
