记FreeSql查询缓慢的一种情况

前段时间另一个项目组的一个同事反馈说在使用FreeSql进行数据查询的时候非常慢，而且是一个单表，只有3千来条数据。初一听，我的第一反应是不可能，比较在.net 体系下，FreeSql已经是非常成熟的ORM了，使用度也很高，官网上也挂着各种数据库操作的测试比较记录。

只是逐步用watchstop调试之后，发现确实是在数据库查询那一步耗时特别长，这就很奇怪，代码就是一行很简单的代码，如下

这里将其他业务代码去掉了，只保留了数据库操作的一小段，和官网上的示例没有什么区别。

最开始怀疑是实体类没有配置上相应的标签所导致的，于是给每个属性都加上了相应的数据库映射标签，却发现一样没有用。

后面怀疑是数据表没有索引，或者数据查询没有命中索引导致的，但是这明显不可能是主要原因，因为几千行数据计算全表查询也不可能那么慢。但是还是试一下吧，于是就将ORM生成的脚本拿到navicate中去执行。

果然，查询脚本在数据库中执行是很快的。这时候就怀疑是不是网络传输啊，或者暂时不知道的因素导致的了，不管怎么样，先测试一下相同的脚本在代码里面执行起来怎么样吧，虽然觉得不会有什么区别，毕竟脚本本来就是有FreeSql生成的。

竟然意外的发现，在使用FreeSql 的 ado 模式直接使用脚本进行执行的情况下，查询速度是很快的，和使用Code First模式以及Respository模式完全不一样。

这下子就只能怀疑是不是FreeSql在从数据库查询到数据之后，进行实体对象转换映射的时候有问题了。这样就有点难办了，得将FreeSql的源码加进来调试一下转换过程才行。

刚好，另一位同事在FreeSql的群里，那就先在群里请教一下大佬吧，毕竟FreeSql项目的主要贡献者都在，而且人都不错，实在不行再将FreeSql的工程源码加进来调试一下转换过程呢。

大佬也觉得奇怪，远程过来帮我们调试了一下，刚开始也没有太多的头绪，但却肯定了ado模式使用脚本查询，和Code First模式查询的实体转换逻辑是不一样的，后来我们注意到，在数据查询那一行语句执行的过程中，输出一直在输出异常，而且是类型转换失败的异常

这时候就有了一个新怀疑方向，是不是数据库字段类型和实体类型不一致？后面，找另一个项目组的同事确认了一下，这个表确实是旧表，并非是Code First模式下创建的表，到这里就大致确定了问题的所在了。在仔细检查了一遍表的各个字段的数据类型，以及实体中的各个属性的数据类型后，发现了确实有两个属性两边的数据类型是不匹配的。

修改了实体中对应的数据类型之后就没有问题了。

结论：

FreeSql 的 ado 模式直接使用脚本查询，和使用Code First模式以及Respository模式进行查询，在实体对象转换映射时候的逻辑是不一样的。Code First模式以及Respository模式下，实体类属性的数据类型只要有一个与数据表字段数据类型不一致，查询性能将非常缓慢。推荐使用Code First模式创建数据表，或者使用FreeSql.Generator从数据库生成实体。