C# EF 4.1 SQL压缩字节

我的查询中存在一些性能瓶颈。当我在实体中以字节形式引入属性时，EF4.1会在使用它之前将其强制转换为int。给定的代码将解释：

var segmentQuery = workUnit.SegmentRepository.GetQuery()
                                             .Where(x => x.FileId == file.Id)
                                             .Where(x => x.StateValue == (byte)SegmentState.Unhandeled)
                                             .OrderBy(x => x.Index);

很好地解释为：

SELECT 
....
FROM ( SELECT 
    [Extent1].[Id] AS [Id], 
    ...
    [Extent1].[StateValue] AS [StateValue]
    FROM [Segments] AS [Extent1]
    WHERE ([Extent1].[FileId] = @p__linq__0) AND (0 = [Extent1].[StateValue])
)  AS [Project1]
ORDER BY [Project1].[Index] ASC

然而，在上面的例子中：StateValue实际上是一个整数，这对于我的需求（4种不同的状态）来说非常重要，但是当将其更改为一个字节时，我得到：

SELECT ...
FROM ( SELECT 
    [Extent1].[Id] AS [Id], 
      ...
    [Extent1].[StateValue] AS [StateValue]
    FROM [Segments] AS [Extent1]
    WHERE ([Extent1].[FileId] = @p__linq__0) AND (0 = ( CAST( [Extent1].[StateValue] AS int)))
)  AS [Project1]
ORDER BY [Project1].[Index] ASC

因为这个表一天可能包含超过100000行，所以它的状态字段只占用1字节是节省空间的（尽管幸运的是不是必要的），但是，更改为字节会杀死我的查询

我做错什么了吗？有什么我能做的吗？这个“问题”是已知的吗

谢谢

**更新**

[Flags]
public enum SegmentState : byte
{
    Unhandeled,
    Downloaded,
    Invalid,
    Assembled
}

在我的实体中：

/// <summary>
/// Dont use this, use SegmentState instead
/// </summary>
[Required]
public byte StateValue
{
    get { return _stateValue; }
    set { _stateValue = value; }
}

public SegmentState State
{
    get { return (SegmentState)StateValue; }
    set 
    {
        if (State != value)
        {
            StateValue = (byte)value;
            RaisePropertyChanged(StatePropertyName);
        }
    }
}

//
///不要使用此选项，请使用SegmentState
/// 
[必需]
公共字节状态值
{
获取{return\u stateValue；}
设置{u stateValue=value；}
}
公营国
{
获取{return（SegmentState）StateValue；}
设置
{
如果（状态！=值）
{
StateValue=（字节）值；
RaisePropertyChanged（StatePropertyName）；
}
}
}

严肃地说，不要使用EF-这将是你一生中最大的痛苦。

---

看看C#中的质量和动力学-它将为你的生活打开眼睛；-）

啊哈，回答我不喜欢听；）我刚刚用一个简洁的EF4.1层替换了一个普通的Sql DB层。虽然有一些问题（比如这一个），但它在很多方面都很奇妙。幸运的是，我总是可以回到EF中的普通SQL查询（但不是）。Massive也很好，但它有缺点，我不喜欢在我真的不需要的时候使用dynamics。我选择.NET和C#是有原因的，我想坚持使用它，只要你不以性能为目标，EF可能是一个选项；-）我们不应该在这里开始讨论，但是。。。。你的观点部分错误。EF并没有优化到适合高性能的程度，但它做得相当好（特别是有了智能SQL CE查询规划器）。我已经看到大量linq语句变成了高度优化的SQL查询，我不会再编写任何优化的SQL查询了。EF绝对是一种选择。（我知道客户端的性能问题，但即使是这样也可以解决，虽然速度仍然慢于大规模，我同意，但这只是一小部分）看看dapper，看看EF流血致死。你能发布

StateValue和
SegmentState`的类型吗？如果您正在处理大数据量，那么我认为SQL CE无法处理它们