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