Mysql 如何实现分库分表？

[Anlim]

PS：看了一下网上的资料，使用垂直切分或者水平切分感觉都不太理解，目前的数据表外键依赖比较泛滥。。。 感觉无从下手……

解决方案： 1、读写分离 2、分库分表

读写分离问题应该不大，需要注意读写分离数据同步的问题。注意问题就是如何实现分库分表……

希望大牛们指导一下。往后肯定需要分库分表！！！感谢

[nullcc]

互联网项目不建议使用外键，最好由业务逻辑保证数据关联性和一致性。

读写分离你需要设置主-从关系，主库写从库读，不过可能会出现不一致窗口，这个问题可以用一些一致性方案去解决。

垂直切分出现在不同业务之间，比如用户服务（用户库）和订单服务（订单库）。

水平切分主流方案是设设置 db_0、db_1、db_2...然后有个 db_proxy 去根据某个 id （此时你需要有一个保证全局唯一趋势递增的 id ），去选择要把查询路由到哪个 db。

[LYEHIZRF]

楼主可以参考一下阿里的 cobar

[microhz]

互联网公司一般都不用外键了（不要问我为啥不用）。还有我就是想问下你们单表数据能达到多少

[littleylv]

不用外键路过

[iyaozhen]

实际经验来看，不太好做。

你还有外键，一看业务就比较复杂

[sampeng]

外键如果不能去掉。只能人肉分表。就是按整个逻辑来分表，甚至有大量冗余表。相当大工作量的感觉

[backing]

分表分库对业务来说是有损的，数据量没有特别大（或者 qps 特别高）时，无论从维护还是效率上都是单库最优。
@nullcc

[backing]

我擦，没填完，我是想说 @nullcc 的答案已经比较完整了。读从库会有一定的主从延迟，一般读流量比较大的情况前面要加一层 cache 来抗。可以通过 mq 来更新 cache 解决延迟问题。

[zhx1991]

先把外键去掉然后人肉分

[Anlim]

感谢大家的帮助🙏 ！！
刚开始搭建数据库的时候本人并没有参与（声明不是想甩锅），滥用外键比较严重。也理解当初设计使用外键（ Django ORM 外键查询比较方便）。往后先把外键的问题先解决吧，目前的数据量才十几万。查询就比较慢了。优化的路还很长。。。

[nullcc]

@backing 是的，需不需要分库分表需要看实际情况，在未来业务量增长不大，单库能承受的话，没必要进行这么复杂的架构变化。

[Anlim]

@microhz 目前单表数据在 10W，这数据量不算大，但是已经有点影响查询的速度了

[Anlim]

@sampeng 之前有想过这种方式，但是往后维护的成本太高了。。

[EricCartman]

https://www.citusdata.com/blog/2017/08/09/principles-of-sharding-for-relational-databases/?utm_source=wanqu.co&utm_campaign=Wanqu+Daily&utm_medium=website
今天刚看到的文章

[ylcc]

@Anlim #12 10w 的数据量分库分表对你的慢查询基本没啥帮助啊

[we3613040]

还是优化你的 sql 吧，10 来 w 数据根本用不到分库分表

[Anlim]

@ylcc 只能说往后的数据表需要重新整理一份了。因为历史记录很少查询。确保新的订单查询效率：）

[sagaxu]

@Anlim 才几十万就分表，预期会爆炸性增长么？单表超过千万以前，分库或者分表没什么意义。

[sampeng]

才十几万就要分表了。。。你这摆明了是数据库设计不对啊。。看看索引，查询语句。巴拉巴拉的。
你这是打算 1 万条 1 张表么。。尴尬

[sampeng]

换成是我，才这么点数据。老老实实把外键去了。重建一个干净的数据库。到时候要分表再说。
才几十万数据库，脚本也就几分钟的事。