› 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
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
这是一个创建于 2681 天前的主题，其中的信息可能已经有所发展或是发生改变。
PS：看了一下网上的资料，使用垂直切分或者水平切分感觉都不太理解，目前的数据表外键依赖比较泛滥。。。 感觉无从下手……
解决方案： 1、读写分离 2、分库分表
读写分离问题应该不大，需要注意读写分离数据同步的问题。注意问题就是如何实现分库分表……
希望大牛们指导一下。往后肯定需要分库分表！！！感谢
第 1 条附言 · 2017-08-10 22:49:52 +08:00
感谢大家的帮助🙏 ！！
刚开始搭建数据库的时候本人并没有参与（声明不是想甩锅），滥用外键比较严重。也理解当初设计使用外键（ Django ORM 外键查询比较方便）。往后先把外键的问题先解决吧，目前的数据量才十几万。查询就比较慢了。优化的路还很长。。。
刚开始搭建数据库的时候本人并没有参与（声明不是想甩锅），滥用外键比较严重。也理解当初设计使用外键（ Django ORM 外键查询比较方便）。往后先把外键的问题先解决吧，目前的数据量才十几万。查询就比较慢了。优化的路还很长。。。
 |
1
nullcc 2017-08-10 16:44:46 +08:00  1
互联网项目不建议使用外键，最好由业务逻辑保证数据关联性和一致性。
读写分离你需要设置主-从关系，主库写从库读，不过可能会出现不一致窗口，这个问题可以用一些一致性方案去解决。 垂直切分出现在不同业务之间，比如用户服务（用户库）和订单服务（订单库）。 水平切分主流方案是设设置 db_0、db_1、db_2...然后有个 db_proxy 去根据某个 id （此时你需要有一个保证全局唯一趋势递增的 id ），去选择要把查询路由到哪个 db。 |
 |
2
LYEHIZRF 2017-08-10 17:27:06 +08:00
楼主可以参考一下阿里的 cobar
|
 |
3
microhz 2017-08-10 17:33:09 +08:00
互联网公司一般都不用外键了（不要问我为啥不用）。还有我就是想问下你们单表数据能达到多少
|
 |
4
littleylv 2017-08-10 17:43:55 +08:00
不用外键路过
|
 |
5
iyaozhen 2017-08-10 17:45:32 +08:00 via Android
实际经验来看，不太好做。
你还有外键，一看业务就比较复杂 |
 |
6
sampeng 2017-08-10 17:48:41 +08:00
外键如果不能去掉。只能人肉分表。就是按整个逻辑来分表，甚至有大量冗余表。相当大工作量的感觉
|
 |
8
backing 2017-08-10 18:41:52 +08:00
我擦，没填完，我是想说 @nullcc 的答案已经比较完整了。读从库会有一定的主从延迟，一般读流量比较大的情况前面要加一层 cache 来抗。可以通过 mq 来更新 cache 解决延迟问题。
|
 |
9
zhx1991 2017-08-10 19:04:55 +08:00
先把外键去掉然后人肉分
|
 |
10
Anlim OP 感谢大家的帮助🙏 ！！
刚开始搭建数据库的时候本人并没有参与（声明不是想甩锅），滥用外键比较严重。也理解当初设计使用外键（ Django ORM 外键查询比较方便）。往后先把外键的问题先解决吧，目前的数据量才十几万。查询就比较慢了。优化的路还很长。。。 |
 |
14
EricCartman 2017-08-10 23:48:50 +08:00 via Android
|
 |
16
we3613040 2017-08-11 11:22:16 +08:00
还是优化你的 sql 吧，10 来 w 数据根本用不到分库分表
|
|
19
sampeng 2017-08-11 12:02:26 +08:00
才十几万就要分表了。。。你这摆明了是数据库设计不对啊。。看看索引，查询语句。巴拉巴拉的。
你这是打算 1 万条 1 张表么。。尴尬 |
|
20
sampeng 2017-08-11 12:03:15 +08:00
换成是我，才这么点数据。老老实实把外键去了。重建一个干净的数据库。到时候要分表再说。
才几十万数据库，脚本也就几分钟的事。 |
 |
21
andreby 2017-08-11 12:28:46 +08:00
用 mycat
|
|
23
sampeng 2017-08-11 12:43:27 +08:00
@Anlim 你现在改，没什么影响。就是多点工作量。以后想改都没人允许你改。当你上千万数据量的时候，想改数据表结构？没人敢承担这样的风险
|
 |
24
linpf 2017-08-11 16:27:56 +08:00
绝对是数据库表设计的不合理，或者 SQL 语句没有用到合适的索引。
我前段时间也对平台做了分表，因为两个百万级别的表 join 经常会带来慢查询。但是分表就意味着要重写好多 sql 语句。然后我重写了 sql 语句，然后重新安排了表字段，做了适当冗余取消掉 join 以后，再来几百万数据也用不到分表。 |
Select Language