现状: 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 |