mysql千万级数据查询问题

Question

日志存在mysql里面，现在的问题是，默认日志页为当天的日志信息，现在测试发现的问题是，如果日志数量达到千万级的时候，一开始的页面就非常卡，这个是开始页面的查询语句；这里面为了达到数据量很大的目的，时间才改为1410243201

另外这个页面里面有搜索功能，千万级的数据一搜索就更卡，搜索语句都会有addtime。现在问题内存使用量很大，搜索也很慢。一开始sql where里面的条件字段都已经加上了索引，为全文索引的字段使用了like

求大神告知解决方案！！！！

Answer 1

这个优化需要根据实际的日志业务需求来。 题主目前的情况，看到的页面会卡是一个问题，其实最恐怖的问题是，你的这个SQL执行下去，首先会导致服务器IO上升，IO到内存后，内存会开始爆满，爆满的结果是什么，你的应用程序的内存不够用，缓存被释放掉，会导致整个服务器内存不够，而不是仅仅看到的一个页面执行慢的问题。

第一眼就看到一个SELECT FROM，如果你的数据没有做分库分表存储，你这样的SELECT FROM 确定不会被你们CTO吊起来打。

Answer 2

这种一次性拉取千万级数据的sql根本就不应该出现在线上的业务里面，报表类的需求的话慢点也无所谓了
如果一定要在mysql层面解决慢的问题你就只能从io层面去考虑了，
磁盘io，网络io，或者干脆全部使用内存存取，都是money
其实你可以换个角度，一次性取出千万级数据展示给用户肯定不可能一次性全部展示出来，要分页的啊
这样你就可以在sql读取数据的时候直接limit或者“where id between and”分页了，每次取一小部分就很快了

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

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

Answer 11

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

Answer 12

1. between and 索引失效

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

Answer 13

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

Answer 14

分表并且分页

Answer 15

经过这么多大神的指导，我总结如下http://www.fang99.cc/index.ph...