这是一个创建于 2089 天前的主题，其中的信息可能已经有所发展或是发生改变。
现状： 1.超过 1000w 的表较多； 2.每个表之间会有较多的联表查； 3.一个 select 的 sql 可能需要查处几万条数据； 大伙有啥好方法么？
 |
1
kukumao 2019-04-11 14:42:07 +08:00
分表。。。。
|
 |
2
gz911122 2019-04-11 14:45:01 +08:00
索引 ,尽量别连表
分区 |
 |
3
rockyou12 2019-04-11 14:49:08 +08:00
如果是统计类型的业务还是直接用 spark 这些来做吧，反正也可以写 sql
|
 |
4
ggicci 2019-04-11 14:52:07 +08:00
## 自己扛
因为业务影响会比较大，所以都需要根据业务按顺序考虑以下思路： 1. 索引优化 2. 分区优化 3. 分库 4. SQL 查询优化，比如把某些联表查询改造成多次单表查询 ## 云服务扛 换个超屌的关系型数据库产品 |
 |
5
reus 2019-04-11 14:58:01 +08:00
换 PostgreSQL.
|
 |
6
linxb 2019-04-11 15:00:46 +08:00
增加冗余字段，减少连表操作，水平分表
|
 |
7
yangxin0 2019-04-11 15:01:37 +08:00
删库重来
|
 |
8
babedoll 2019-04-11 15:02:13 +08:00
分表
|
 |
9
jusalun 2019-04-11 15:32:06 +08:00
放 clickhouse，十几亿的量单机都能秒查
|
 |
10
love 2019-04-11 15:43:09 +08:00 via Android
啥叫一条 sql 查几万，需要一次性取出几万条记录？
|
 |
11
goodleixiao 2019-04-11 16:04:31 +08:00
先优化业务规则，在考虑怎么优化数据库。
建索引、删外键，分表分库，减少连表操作，多点冗余字段 |
 |
12
wedoub 2019-04-11 16:06:47 +08:00 via iPhone
大表拆分成小表，以空间换取时间
|
 |
13
luozic 2019-04-11 16:06:55 +08:00
錢多不多？ 錢多去買牛逼的服務器； 錢少，那就修代碼，改架構，改查詢。
|
 |
15
alamaya 2019-04-11 16:14:05 +08:00
才 1KW，我觉得 mysql 完全木问题呀
|
 |
16
qiyuey 2019-04-11 16:16:57 +08:00
不要在数据库写 join，全部放到代码侧，这样对缓存和分库分表都比较友好。
|
 |
17
janus77 2019-04-11 16:18:10 +08:00
超过 1000w 的表较多，就这一句话我觉得你们当初的架构就有问题
要么在之前预测的时候就开始做分表 要么优化业务和表结构，要知道多个 1000w 数量级的查询不是什么常见的场景。 |
 |
18
simapple 2019-04-11 16:19:40 +08:00
看具体业务
看具体瓶颈操作卡在哪里 看优化预算 所以没有一个固定的范式去解决 也许预算是第一个要先搞清楚的 |
 |
19
loading 2019-04-11 16:23:31 +08:00 via Android
一次查几万？瓶颈可能会在磁盘 io 或者网络 io 上了。
|
 |
24
houshengzi 2019-04-11 17:46:50 +08:00
我们也有这样的表，有七八个字段都是 0/1/2 这些值，但是业务需求基本上都用到这几个字段做条件
对于这种优化也在头疼着。 |
 |
26
ducklyl 2019-04-11 18:09:16 +08:00
千万级索引优化好，也还行。
接着分表，拆成 N 张子表，再不行的话，再分库，分成多个库。 |
 |
27
opengps 2019-04-11 18:14:40 +08:00
大表做运算真的很麻烦，这个方面没经验，只能提示下分表或者分段 sum 试下
|
 |
28
vmskipper 2019-04-11 18:42:46 +08:00
推到重来 做个容量规划 重新设计
|
 |
29
Antihank 2019-04-11 19:26:13 +08:00
@qiyuey 大佬，我的习惯就是这样，但是问题是这样会很容易内存溢出，而且如果项目有 dubbo 或类似的 Service 层分布式架构，然后从各个服务去拉取数据，数据量变大，往往需要通过中间件来传递。。。到现在我都没有很好的解决办法。。。
|
 |
30
Raymon111111 2019-04-11 20:21:59 +08:00
查几万的数据单纯用一个表没有什么办法
建议换存储引擎, 比如 ES |
 |
31
tomczhen 2019-04-11 23:54:25 +08:00 via Android  3
抛开一些低级错误，在 OLTP 数据库上做 OLAP 业务怎么优化都会难受。
对于时效要求不高的分析就没必要每次都在数据库统计实时数据，定时执行保存结果就好。实效性要求高的高读写数据（热点）只能用缓存解决，业务代码需要处理一致性问题。 还有就是一些需求本身不适合在关系数据库上做，可以利用 CDC 之类的把数据同步到其他类型数据库。 |
 |
32
redsonic 2019-04-12 02:47:39 +08:00
库表是防在 SSD 上面吗? 不是的话先迁移到 SSD 再说,如果不是频繁写表的话.
|
 |
33
jbiao520 2019-04-12 07:57:13 +08:00 via Android
in 几千个参数是什么鬼
|
 |
36
lsongiu 2019-04-12 09:01:50 +08:00
tidb?
|
 |
37
daodao116 2019-04-12 09:40:19 +08:00
如果是事实性要求较高的需求
1、索引（尽量保证 join 是索引字段，当然这些字段本身是否建索引还值得商榷） 2、分区 如果是统计形需求，就像楼上 @tomczhen 说的，定时统计好了，慢一点没事，单线程不会拖垮数据库。 再复杂一点就是设计和代码层面的改动了，要看具体业务需求和表结构设计了，可能就不是一句两句能说清楚的了。 |
 |
38
HarryQu 2019-04-12 10:28:10 +08:00
@tomczhen 实效性要求高的高读写数据（热点）只能用缓存解决，业务代码需要处理一致性问题。
在这句话中, 缓存是在哪里做 ? 直接使用 Mysql 数据库缓存,还是在业务层做缓存, 如 Redis。 |
|
39
HarryQu 2019-04-12 10:34:30 +08:00
|
 |
40
90928yao 2019-04-12 11:20:43 +08:00
clickhouse 强烈推荐
|
|
41
90928yao 2019-04-12 11:21:27 +08:00
没看题 太多关联 clickhouse 可能性能不太好
|
 |
42
whp1473 2019-04-12 14:57:14 +08:00
1.分表、分库。横向、纵向切分。
纵向：将数据分为易变更、高热度数据和不易变更、低热度数据，把 N 列，切分成 M 个表，关联。降低单表的数据储量 横向：可以考虑用数据库中间件 mycat 之类的，将原有的数据按照 ID 分片到不同库。查询时数据库中间件会自动聚合返回。但要考虑事务问题、使用 join 困难问题。 2.数据异构 mysql 数据库对于以 T 为单位的数据本身就存在瓶颈，可以考虑通过 binlog 或者消息的方式同步数据到其他存储引擎(例如：es、hbase)，通过实时计算或定时计算将要查询、join 的数据的结果回流到 mysql、es，然后通过该存储进行查询。 3.热点数据缓存 对于敏感的数据，需要考虑缓存问题，可以使用 Redis+本地缓存+ZK 的方式做多级缓存。 异构数据同步快慢，依赖于消息的消费速度，速度慢可以扩容 mq 机器、消费者机器，基本可以保障基本同步。 |
|
43
whp1473 2019-04-12 15:04:26 +08:00
或者换 Oracle ？单表几亿数据应该没问题吧，写存储过程、优化 Sql、索引，应该能撑很长时间
|
|
44
whp1473 2019-04-12 15:07:24 +08:00
一次性查几万数据，这个还好吧。一次实时取几万数据，那就只能打产品了。
|
|
45
ggicci 2019-04-12 15:56:59 +08:00
@ginux 把这些你认为是瓶颈的查询往死里优化，实在优化到头了就得考虑其它可替代的解决方案了。你可以看看是否有其它数据库系统能更好地来处理你的瓶颈部分，想想把这部分数据外挂给这些系统处理能否解决你的需求。
|
 |
46
wind3110991 2019-04-12 16:33:09 +08:00
（ 1 ）订单信息、运营报表数据，建议分表分库，或者更换成 ES 搜索引擎；
（ 2 ）时序数据换成 Hbase、openTSDB ； （ 3 ）建议检查优化索引，重建表然后瘦身、迁移； （ 4 ）实时性不强的数据一定要加缓存； 太多大表联表，说明你的业务逻辑需要优化了，尽量用空间换时间，把业务逻辑尽量放在代码端而不是 mysql， mysql 就是个最傻瓜的东西来用就对了，不要 XJB 用，尽量不要在大表间做 join ； |
 |
47
Ja1 2019-04-16 09:49:36 +08:00
千万级别数据库优化，按照从简到繁：
1.sql 语句以及索引优化 2.加缓存 3.主从复制，主主复制，读写分离 4.分区 5.垂直切分 6.水平切分，（迫不得已才使用，会增加难度） |
 |
48
lolizeppelin 2019-07-11 14:52:45 +08:00
介绍你个东西 maxwell
可以读取 mysql 的 binglog 以 json 形式发到卡夫卡 /redia/rabiitmq.... 这样你可以在不改业务代码的情况下,把数据转发到其他的位置做 olap 啦 把要做分析的数据丢 pg 里比 mysql 里分析快多了... 不过 maxwell 的代码好像有点简单..有资源可以考虑 debezium |
Select Language