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

[ginux]

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

[kukumao]

分表。。。。

[gz911122]

索引 ,尽量别连表
分区

[rockyou12]

如果是统计类型的业务还是直接用 spark 这些来做吧，反正也可以写 sql

[ggicci]

## 自己扛

因为业务影响会比较大，所以都需要根据业务按顺序考虑以下思路：

1. 索引优化
2. 分区优化
3. 分库
4. SQL 查询优化，比如把某些联表查询改造成多次单表查询

## 云服务扛

换个超屌的关系型数据库产品

[reus]

换 PostgreSQL.

[linxb]

增加冗余字段，减少连表操作，水平分表

[yangxin0]

删库重来

[babedoll]

分表

[jusalun]

放 clickhouse，十几亿的量单机都能秒查

[love]

啥叫一条 sql 查几万，需要一次性取出几万条记录？

[goodleixiao]

先优化业务规则，在考虑怎么优化数据库。

建索引、删外键，分表分库，减少连表操作，多点冗余字段

[wedoub]

大表拆分成小表，以空间换取时间

[luozic]

錢多不多？ 錢多去買牛逼的服務器； 錢少，那就修代碼，改架構，改查詢。

[14march]

@yangxin0 暴躁程序员 我喜欢

[alamaya]

才 1KW，我觉得 mysql 完全木问题呀

[qiyuey]

不要在数据库写 join，全部放到代码侧，这样对缓存和分库分表都比较友好。

[janus77]

超过 1000w 的表较多，就这一句话我觉得你们当初的架构就有问题
要么在之前预测的时候就开始做分表
要么优化业务和表结构，要知道多个 1000w 数量级的查询不是什么常见的场景。

[simapple]

看具体业务
看具体瓶颈操作卡在哪里
看优化预算

所以没有一个固定的范式去解决


也许预算是第一个要先搞清楚的

[loading]

一次查几万？瓶颈可能会在磁盘 io 或者网络 io 上了。

[ginux]

@love 是的