mysql 的一张表超过 1000w 后，如何优化

[ginux]

现状： 1.超过 1000w 的表较多； 2.每个表之间会有较多的联表查； 3.一个 select 的 sql 可能需要查处几万条数据； 大伙有啥好方法么？

[ginux]

@alamaya 性能问题很大，因为都是大表

[ginux]

@ggicci 索引、分库、分表都做了，例如经常会在表里面执行 count （）或者 in(几千个参数)操作，性能低

[9684xtpa]

@ginux #22 count in?

[houshengzi]

我们也有这样的表，有七八个字段都是 0/1/2 这些值，但是业务需求基本上都用到这几个字段做条件

对于这种优化也在头疼着。

[kiddult]

@ginux 几千个参数。。。。。还是先拿板砖把开发拍死再说吧

[ducklyl]

千万级索引优化好，也还行。
接着分表，拆成 N 张子表，再不行的话，再分库，分成多个库。

[opengps]

大表做运算真的很麻烦，这个方面没经验，只能提示下分表或者分段 sum 试下

[vmskipper]

推到重来 做个容量规划 重新设计

[Antihank]

@qiyuey 大佬，我的习惯就是这样，但是问题是这样会很容易内存溢出，而且如果项目有 dubbo 或类似的 Service 层分布式架构，然后从各个服务去拉取数据，数据量变大，往往需要通过中间件来传递。。。到现在我都没有很好的解决办法。。。

[Raymon111111]

查几万的数据单纯用一个表没有什么办法

建议换存储引擎, 比如 ES

[tomczhen]

抛开一些低级错误，在 OLTP 数据库上做 OLAP 业务怎么优化都会难受。

对于时效要求不高的分析就没必要每次都在数据库统计实时数据，定时执行保存结果就好。实效性要求高的高读写数据（热点）只能用缓存解决，业务代码需要处理一致性问题。

还有就是一些需求本身不适合在关系数据库上做，可以利用 CDC 之类的把数据同步到其他类型数据库。

[redsonic]

库表是防在 SSD 上面吗? 不是的话先迁移到 SSD 再说,如果不是频繁写表的话.

[jbiao520]

in 几千个参数是什么鬼

[0xABCD]

@ginux 看出来了，问题出在 SQL 写得太渣，架构再牛也没用

[leonme]

@tomczhen 看了一圈，这个回答比较靠谱，也是大厂通用的解决方式

[lsongiu]

tidb?

[daodao116]

如果是事实性要求较高的需求
1、索引（尽量保证 join 是索引字段，当然这些字段本身是否建索引还值得商榷）
2、分区

如果是统计形需求，就像楼上 @tomczhen 说的，定时统计好了，慢一点没事，单线程不会拖垮数据库。

再复杂一点就是设计和代码层面的改动了，要看具体业务需求和表结构设计了，可能就不是一句两句能说清楚的了。

[HarryQu]

@tomczhen 实效性要求高的高读写数据（热点）只能用缓存解决，业务代码需要处理一致性问题。

在这句话中, 缓存是在哪里做 ? 直接使用 Mysql 数据库缓存,还是在业务层做缓存, 如 Redis。

[HarryQu]

@tomczhen
在实时性要求高的情况下, 如果数据库数据频繁更新,是否意味着缓存时常 miss ? 这样的话缓存也不能起到很好的效果。
那么如何处理时效性要求高且数据庞大且数据频繁更新的问题 ?

[90928yao]

clickhouse 强烈推荐