请问对于海量数据的查询 mysql 有什么好的解决方案？

[cc959798]

现在互联网业务单表过亿是很正常的，再优化索引还是性能不够理想，比如说某个股票交易软件的评论区域，这 A 股 3 千多只，每天产生 100 条，一年就过亿了，这种情况下计算时分片查找的话也是性能不够理想，当然很多数据都是老的，不使用的，可以做冷热分离，但是这样维护起来就太麻烦了。 使用数据库中间件的话比如 mycat 联表又不方便而且单个分片卡会造成性能问题。 现在个大公司类似的场景都使用什么解决方案呢？多谢诸位

[batter]

海量数据还用 mysql，应该不会吧，mysql 作为数据的最后备份，而不是查询主体吧

[jswh]

MySQL 分库分表都不能适应的时候，业务的有不愿改变，可以考虑换数据库。评论这种可以考虑稳定数据库，或者 tidb 这种分布式数据库。
不过，在那之前，确保缓存用好了。个人对数据理解，一个是数据落地的地方，还有就是事务处理中心，其他查询的问题，大部分情况可以用加机器和加缓存解决。

[jswh]

稳定数据库-〉文档数据库

[ihavecat]

es、hbase 都可以阿

[gstqc]

搜索评论里的内容？
可以把评论内容放 Elasticsearch 上做全文索引，搜索评论文本时调用 ES

[wsc449]

建议 mysql 数据 同步到 Elasticsearch

[cc959798]

@jswh tidb 还是比较新的，在这类数据库出现之前是怎么解决的？

[cc959798]

@gstqc 不是搜索就是纯粹的查询呀，把评论展示到页面，如果上亿了，就算查 10 条也是很慢的，何况还得连表

[jswh]

@cc959798 基本就是分库分表，查询缓存所有这些东西吧。

[fireapp]

@cc959798 只是展示评论，3000 支股票分 3000 张表啊，简单粗暴🤭，数据一下缩小 3000 倍

[cc959798]

@jswh 分库有用中间件的比如 mycat，或者冷热分离，这些性能都先放一边，连表查很困难呀

[cc959798]

@fireapp 这个方法有道理，也比较暴利，但是这样会数据不均匀，比如腾讯 阿里 的股票很热门，单表过亿很轻松呀

[summerwar]

再多的数据也没有 Google 索引的数据多，到时候参考 Google 使用的方法就是了

[realpg]

@cc959798 #12
基于查询历史统计的优化分库分表

因为你之前没提出这些问题，黑箱基于外面大家掌握的信息给你的按照股票分表

如果你掌握更多的查询细节 那就可以按照生产环境的实际情况自定义更符合你环境的分表分库方法

[privil]

TiDB 了解一下

[Leigg]

hbase 了该一哈，如果你是负责人，你应该走在身边所有人的前面，如果你不是，告诉你，你也是懂个概念。

[likuku]

充分利用缓存，每日统计热点，可以空闲时，主动对涉及热点的评论“预热”，主动让它们进驻缓存。

或者，最近一周／一个月 发出的评论／"新帖" 优先主动推进缓存里。

[akira]

当数据量去到亿级别的时候，就别嫌麻烦了。 单台数据库的负荷终归是有上限的，该拆表拆，改分库分