4G内存的电脑，如何读取8G的日志文件进行分析，汇总数据成报表。
先说思想解决，不说实际代码实现；
1. 内存1G，所以大文件首先要分割；如分割为20个文件，那么每个可以做到接近250M左右
2. 拿前面的3个文件做案例：
A B C 3个文件，每个250M；首先做到加载没有问题
1.A 文件读取到SetA中，此时集合中A的URL不重复
2.B文件读取到SetB中；
3.SetA 和SetB比较，将集合A和B中相同项都剔除；
4.清空SetB；
5.加载C文件；SetA 和SetC比较,将集合A和C中相同项都剔除；
6.前三个文件A比较完成，生成和B,C文件完全不重复的A1文件
依次类推：
总拿前面的一个文件内容和后面文件对比，对比一轮完成的那个文件；
就绝对是完全不重复的内容了
数据库索引的坏处：
索引是完全独立于基础数据之外的一部分数据。假 设在Table ta 中的Column ca 创建了索引 idx_ta_ca，那么任何更新 Column ca 的操作，MySQL在更新表中 Column ca的同时，都须要更新Column ca 的索引数据，调整因为更新带来键值变化的索引信息。而如果没有对 Column ca 进行索引，MySQL要做的仅仅是更新表中 Column ca 的信息。这样，最明显的资源消耗就是增加了更新所带来的 IO 量和调整索引所致的计算量。此外，Column ca 的索引idx_ta_ca须要占用存储空间，而且随着 Table ta 数据量的增加，idx_ta_ca 所占用的空间也会不断增加，所以索引还会带来存储空间资源消耗的增加。
较频繁的作为查询条件的字段应该创建索引
唯一性太差的字段不适合单独创建索引，即使频繁作为查询条件
唯一性太差的字段主要是指哪些呢？如状态字段、类型字段等这些字段中存放的数据可能总共就是那么几个或几十个值重复使用，每个值都会存在于成千上万 或更多的记录中。对于这类字段，完全没有必要创建单独的索引。因为即使创建了索引，MySQL Query Optimizer 大多数时候也不会去选择使用，如果什么时候 MySQL Query Optimizer选择了这种索引，那么非常遗憾地告诉你，这可能会带来极大的性能问题。由于索引字段中每个值都含有大量的记录，那么存储引擎在根据索引 访问数据的时候会带来大量的随机IO，甚至有些时候还会出现大量的重复IO。
原文地址：https://www.cnblogs.com/jimsu/p/11185090.html