V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
MySQL 5.5 Community Server
MySQL 5.6 Community Server
Percona Configuration Wizard
XtraBackup 搭建主从复制
Great Sites on MySQL
Percona
MySQL Performance Blog
Severalnines
推荐管理工具
Sequel Pro
phpMyAdmin
推荐书目
MySQL Cookbook
MySQL 相关项目
MariaDB
Drizzle
参考文档
http://mysql-python.sourceforge.net/MySQLdb.html
Anlim
V2EX  ›  MySQL

Mysql 如何实现分库分表?

  •  
  •   Anlim · 2017-08-10 16:21:38 +08:00 · 10725 次点击
    这是一个创建于 2422 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

    第 1 条附言  ·  2017-08-10 22:49:52 +08:00
    感谢大家的帮助🙏 !!
    刚开始搭建数据库的时候本人并没有参与(声明不是想甩锅),滥用外键比较严重。也理解当初设计使用外键( Django ORM 外键查询比较方便)。往后先把外键的问题先解决吧,目前的数据量才十几万。查询就比较慢了。优化的路还很长。。。
    24 条回复    2017-08-11 16:27:56 +08:00
    nullcc
        1
    nullcc  
       2017-08-10 16:44:46 +08:00   ❤️ 1
    互联网项目不建议使用外键,最好由业务逻辑保证数据关联性和一致性。

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

    垂直切分出现在不同业务之间,比如用户服务(用户库)和订单服务(订单库)。

    水平切分主流方案是设设置 db_0、db_1、db_2...然后有个 db_proxy 去根据某个 id (此时你需要有一个保证全局唯一趋势递增的 id ),去选择要把查询路由到哪个 db。
    LYEHIZRF
        2
    LYEHIZRF  
       2017-08-10 17:27:06 +08:00
    楼主可以参考一下阿里的 cobar
    microhz
        3
    microhz  
       2017-08-10 17:33:09 +08:00
    互联网公司一般都不用外键了(不要问我为啥不用)。还有我就是想问下你们单表数据能达到多少
    littleylv
        4
    littleylv  
       2017-08-10 17:43:55 +08:00
    不用外键路过
    iyaozhen
        5
    iyaozhen  
       2017-08-10 17:45:32 +08:00 via Android
    实际经验来看,不太好做。

    你还有外键,一看业务就比较复杂
    sampeng
        6
    sampeng  
       2017-08-10 17:48:41 +08:00
    外键如果不能去掉。只能人肉分表。就是按整个逻辑来分表,甚至有大量冗余表。相当大工作量的感觉
    backing
        7
    backing  
       2017-08-10 18:39:28 +08:00
    分表分库对业务来说是有损的,数据量没有特别大(或者 qps 特别高)时,无论从维护还是效率上都是单库最优。
    @nullcc
    backing
        8
    backing  
       2017-08-10 18:41:52 +08:00
    我擦,没填完,我是想说 @nullcc 的答案已经比较完整了。读从库会有一定的主从延迟,一般读流量比较大的情况前面要加一层 cache 来抗。可以通过 mq 来更新 cache 解决延迟问题。
    zhx1991
        9
    zhx1991  
       2017-08-10 19:04:55 +08:00
    先把外键去掉然后人肉分
    Anlim
        10
    Anlim  
    OP
       2017-08-10 22:49:24 +08:00
    感谢大家的帮助🙏 !!
    刚开始搭建数据库的时候本人并没有参与(声明不是想甩锅),滥用外键比较严重。也理解当初设计使用外键( Django ORM 外键查询比较方便)。往后先把外键的问题先解决吧,目前的数据量才十几万。查询就比较慢了。优化的路还很长。。。
    nullcc
        11
    nullcc  
       2017-08-10 23:11:24 +08:00
    @backing 是的,需不需要分库分表需要看实际情况,在未来业务量增长不大,单库能承受的话,没必要进行这么复杂的架构变化。
    Anlim
        12
    Anlim  
    OP
       2017-08-10 23:33:12 +08:00
    @microhz 目前单表数据在 10W,这数据量不算大,但是已经有点影响查询的速度了
    Anlim
        13
    Anlim  
    OP
       2017-08-10 23:35:00 +08:00
    @sampeng 之前有想过这种方式,但是往后维护的成本太高了。。
    ylcc
        15
    ylcc  
       2017-08-11 10:35:40 +08:00
    @Anlim #12 10w 的数据量分库分表对你的慢查询基本没啥帮助啊
    we3613040
        16
    we3613040  
       2017-08-11 11:22:16 +08:00
    还是优化你的 sql 吧,10 来 w 数据根本用不到分库分表
    Anlim
        17
    Anlim  
    OP
       2017-08-11 11:22:20 +08:00
    @ylcc 只能说往后的数据表需要重新整理一份了。因为历史记录很少查询。确保新的订单查询效率:)
    sagaxu
        18
    sagaxu  
       2017-08-11 11:34:26 +08:00
    @Anlim 才几十万就分表,预期会爆炸性增长么?单表超过千万以前,分库或者分表没什么意义。
    sampeng
        19
    sampeng  
       2017-08-11 12:02:26 +08:00
    才十几万就要分表了。。。你这摆明了是数据库设计不对啊。。看看索引,查询语句。巴拉巴拉的。
    你这是打算 1 万条 1 张表么。。尴尬
    sampeng
        20
    sampeng  
       2017-08-11 12:03:15 +08:00
    换成是我,才这么点数据。老老实实把外键去了。重建一个干净的数据库。到时候要分表再说。
    才几十万数据库,脚本也就几分钟的事。
    andreby
        21
    andreby  
       2017-08-11 12:28:46 +08:00
    用 mycat
    Anlim
        22
    Anlim  
    OP
       2017-08-11 12:34:59 +08:00
    @sampeng 外键拆除,但是应用层的所有查询就需要重新写。。现在主要是为了后面数据量大的情况考量
    sampeng
        23
    sampeng  
       2017-08-11 12:43:27 +08:00
    @Anlim 你现在改,没什么影响。就是多点工作量。以后想改都没人允许你改。当你上千万数据量的时候,想改数据表结构?没人敢承担这样的风险
    linpf
        24
    linpf  
       2017-08-11 16:27:56 +08:00
    绝对是数据库表设计的不合理,或者 SQL 语句没有用到合适的索引。
    我前段时间也对平台做了分表,因为两个百万级别的表 join 经常会带来慢查询。但是分表就意味着要重写好多 sql 语句。然后我重写了 sql 语句,然后重新安排了表字段,做了适当冗余取消掉 join 以后,再来几百万数据也用不到分表。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3485 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 10:54 · PVG 18:54 · LAX 03:54 · JFK 06:54
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.