mysql千万级数据查询问题

Question

日志存在mysql里面，现在的问题是，默认日志页为当天的日志信息，现在测试发现的问题是，如果日志数量达到千万级的时候，一开始的页面就非常卡，这个是开始页面的查询语句；这里面为了达到数据量很大的目的，时间才改为1410243201 另外这个页面里面有搜索功能，千万级的数据一搜索就更卡，搜索语句都会有addtime。现在问题内存使用量很大，搜索也很慢。一开始sql where里面的条件字段都已经加上了索引，为全文索引的字段使用了like 求大神告知解决方案！！！！

Answer 1

日志的搜索搭es来做会好很多，like效率差不慢才怪，还有就是你这个addtime如果跨度太大的话就全表扫瞄了，不用走索引的

Answer 2

我是这样想的，日志的话肯定会越来越大的。如果你坚持使用mysql的话，日后的表会越来越大，查询的时候如果查询的跨度太大就是全表扫描，你可以把日志按照每个月分表，然后这样查询的时候加上索引还是可以的。当然我推荐文件存储日志

Answer 3

在数据库方面,我这一般除了优化好语句之外,都是使用分布式的,不过才千万级好像有点大材小用了.

Answer 4

做个分页吧，一次性查1千万的数据再怎么优化也很费时间

Answer 5

这个情况可以冗余一个addDayTime字段，只用精确到天，然后建立索引，用这个字段来进行查询会快非常多，但是后台查询条件就不能精确到时分秒了。
还有日志查询不要一次性查出来，可以分页加载，用limit获取当页的数据，毕竟一次性加载出来也没什么意义，电脑屏幕就这么大显示不了这么多。

Answer 6

可以考虑将当天日志页面静态化，然后定期更新，将最新的记录，追加上来。数据库优化参考

Answer 7

可以考虑把日志分开存储，把当天的日志单独建一个表存储，一天一个表，减少数据量

Answer 8

可以用时间区间查询，每次查询带一个时间区间，还有，该加索引的地方，加上索引。

Answer 9

Partition或者分表。前者DBA维护压力大一点。

Answer 10

分表吧，按照日期进行分表。这样查询的数据量会小一点。还有就是分页。不可能一次性取出来那么多数据给别人看吧。楼上哥们有人提议文件存储，我觉得这个也是可以的。

Answer 11

1. between and 索引失效

2、like也可以用索引,like "字段%" 该字段加了索引且是后% explain type =range
3、全文索引 考虑使用第三方 coreseek 对中文支持也好
4、考虑分区 根据range 分区

Answer 12

需讲明业务所处场景
1、统计需要或内部其他需求，建议搜索引擎
2、客户查看，建议分页（用户最多会看20来页），建议增加过滤条件

Answer 13

分表并且分页