Mysql 如何实现分库分表？

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

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

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

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

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

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

不用外键路过

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

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

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

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

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

先把外键去掉然后人肉分

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

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

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

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

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
今天刚看到的文章

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

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

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

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

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

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

用 mycat

@sampeng 外键拆除，但是应用层的所有查询就需要重新写。。现在主要是为了后面数据量大的情况考量

@Anlim 你现在改，没什么影响。就是多点工作量。以后想改都没人允许你改。当你上千万数据量的时候，想改数据表结构？没人敢承担这样的风险

绝对是数据库表设计的不合理，或者 SQL 语句没有用到合适的索引。
我前段时间也对平台做了分表，因为两个百万级别的表 join 经常会带来慢查询。但是分表就意味着要重写好多 sql 语句。然后我重写了 sql 语句，然后重新安排了表字段，做了适当冗余取消掉 join 以后，再来几百万数据也用不到分表。