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

[ginux]

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

[90928yao]

没看题 太多关联 clickhouse 可能性能不太好

[whp1473]

1.分表、分库。横向、纵向切分。
纵向：将数据分为易变更、高热度数据和不易变更、低热度数据，把 N 列，切分成 M 个表，关联。降低单表的数据储量
横向：可以考虑用数据库中间件 mycat 之类的，将原有的数据按照 ID 分片到不同库。查询时数据库中间件会自动聚合返回。但要考虑事务问题、使用 join 困难问题。
2.数据异构
mysql 数据库对于以 T 为单位的数据本身就存在瓶颈，可以考虑通过 binlog 或者消息的方式同步数据到其他存储引擎(例如：es、hbase)，通过实时计算或定时计算将要查询、join 的数据的结果回流到 mysql、es，然后通过该存储进行查询。
3.热点数据缓存
对于敏感的数据，需要考虑缓存问题，可以使用 Redis+本地缓存+ZK 的方式做多级缓存。

异构数据同步快慢，依赖于消息的消费速度，速度慢可以扩容 mq 机器、消费者机器，基本可以保障基本同步。

[whp1473]

或者换 Oracle ？单表几亿数据应该没问题吧，写存储过程、优化 Sql、索引，应该能撑很长时间

[whp1473]

一次性查几万数据，这个还好吧。一次实时取几万数据，那就只能打产品了。

[ggicci]

@ginux 把这些你认为是瓶颈的查询往死里优化，实在优化到头了就得考虑其它可替代的解决方案了。你可以看看是否有其它数据库系统能更好地来处理你的瓶颈部分，想想把这部分数据外挂给这些系统处理能否解决你的需求。

[wind3110991]

（ 1 ）订单信息、运营报表数据，建议分表分库，或者更换成 ES 搜索引擎；
（ 2 ）时序数据换成 Hbase、openTSDB ；
（ 3 ）建议检查优化索引，重建表然后瘦身、迁移；
（ 4 ）实时性不强的数据一定要加缓存；
太多大表联表，说明你的业务逻辑需要优化了，尽量用空间换时间，把业务逻辑尽量放在代码端而不是 mysql，
mysql 就是个最傻瓜的东西来用就对了，不要 XJB 用，尽量不要在大表间做 join ；

[Ja1]

千万级别数据库优化，按照从简到繁：
1.sql 语句以及索引优化
2.加缓存
3.主从复制，主主复制，读写分离
4.分区
5.垂直切分
6.水平切分，（迫不得已才使用，会增加难度）

[lolizeppelin]

介绍你个东西 maxwell

可以读取 mysql 的 binglog 以 json 形式发到卡夫卡 /redia/rabiitmq....
这样你可以在不改业务代码的情况下,把数据转发到其他的位置做 olap 啦

把要做分析的数据丢 pg 里比 mysql 里分析快多了...

不过 maxwell 的代码好像有点简单..有资源可以考虑 debezium