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

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

rockyou12

2019 年 4 月 11 日

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

ggicci

2019 年 4 月 11 日

## 自己扛

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

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

## 云服务扛

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

linxb

2019 年 4 月 11 日

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

jusalun

2019 年 4 月 11 日

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

love

2019 年 4 月 11 日

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

goodleixiao

2019 年 4 月 11 日

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

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

wedoub

2019 年 4 月 11 日

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

luozic

2019 年 4 月 11 日

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

alamaya

2019 年 4 月 11 日

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

qiyuey

2019 年 4 月 11 日

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

rb6221

2019 年 4 月 11 日

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

simapple

2019 年 4 月 11 日

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

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

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

2019 年 4 月 11 日

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

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.