Entity Framework结合LINQ查询无主键Log表的重复记录问题

这个重复结果和你写的LINQ查询逻辑、排序语句没有关系，完全是因为Log表没有配置主键，触发了EF6的实体身份追踪机制缺陷：

• EF6 在将数据库返回的结果集转换为内存实体对象时，会依赖主键做身份映射（Identity Map）：只要是主键值相同的行，就会被判定为同一个实体对象，后续读到的同主键行不会新建实例，直接复用第一行生成的实体值。
• 通过实体数据模型向导映射无主键表时，EF会自动选取所有非可空值类型的字段拼凑出伪主键。你的Log表中timestamp是不可空的datetime类型，会被EF直接当作唯一的伪主键字段。
• 此时所有timestamp值相同的行，不管实际存储的内容差异有多大，都会被EF判定为同一个实体：结果集中三个timestamp为06-11-2020 10:32:49的行，EF在读完第一行的message-1后，剩下两行因为伪主键匹配，直接复用已经生成的实体值，根本不会读取这两行实际存储的message-2、message-3内容，最终读出来的三个同时间戳行的message值全是message-1。
• SSMS中查询结果完全正确，是因为它仅返回纯原始结果集，没有实体物化、身份追踪的逻辑，每一行数据都是独立呈现的，自然不会出现合并重复的问题。

按照推荐优先级从高到低排列：

• 根源修复：给Log表补充合法物理主键
  日志表本身没有天然唯一标识，直接新增一个自增整型的Id列作为表主键即可。这种方式完全匹配EF的设计要求，从根源上避免伪主键识别的问题，后续的跟踪查询、数据增删改操作都不会出现逻辑异常。
• 兼容适配：手动修正EDM模型的主键映射
  如果因为业务历史约束无法修改数据库表结构，可以在Visual Studio的EDM设计器中手动调整Log实体的主键配置，把所有能唯一区分一行数据的字段（比如timestamp、owner、message、docid）全部设置为联合主键，确保每个数据行都有唯一的主键值组合，避免跨行的实体误判。
• 临时绕过：关闭查询的对象追踪
  如果仅做只读查询、不需要实体变更跟踪，可以在LINQ查询结尾追加.AsNoTracking()。此时EF不会启动身份映射逻辑，会为结果集的每一行都创建独立的实体对象，直接读取行内存储的真实值。但这种方式没有解决本质的模型配置问题，后续如果执行更新、删除操作依然会触发逻辑异常，不适合作为长期方案。

代码冗余说明：你在循环中每次输出后清空message变量的写法没有实际作用，直接在循环内部定义局部变量读取entry.message输出即可，这部分写法不是导致结果重复的原因。

内容的提问来源于stack exchange，提问作者Suresh Kaushik