企业官网建设流程全解析

上次对收集到的ORM作了详细的测试，并整理成了测试项目，下面针对测试结果，详细剖析

测试环境

为什么使用 BenchmarkDotNet？

1. ​专业级微基准测试​：BenchmarkDotNet 是 .NET 生态中最成熟的基准测试框架，能有效规避 JIT 预热、GC 干扰等常见陷阱，确保测试结果的准确性和可重复性。
2. ​统计严谨​：自动执行多次迭代，输出均值、标准差、置信区间等统计指标，避免偶发波动对结论的误导。
3. ​结果易读​：自动生成 Markdown/HTML/CSV 等多种格式的报告，便于横向对比和归档分析。
4. ​低侵入性​：通过 Attribute 标记即可完成测试定义，无需修改业务代码，保持测试的纯净性。

为什么使用 SQLite？

1. ​消除网络与并发干扰​：作为嵌入式单机数据库，SQLite 不存在网络 I/O、连接池争用或服务端负载波动，能更纯粹地反映 ​ORM 或数据访问层本身的性能差异​。
2. ​环境一致性强​：所有测试在同一进程内完成，数据库文件可内存化（:memory:），避免磁盘 I/O 成为瓶颈，测试结果波动极小，适合做精细化对比。
3. ​轻量快速​：无需安装、配置或启动外部服务，测试启动速度极快，便于 CI/CD 流水线中频繁执行。
4. ​SQL 兼容性好​：支持标准 SQL 和事务，能覆盖大部分 CRUD 场景，虽非生产级数据库，但作为“性能标尺”已足够客观。

和之前网上写的测试相比(使用大型数据库，使用时间相减，不预热，不多次采样)，本次更准确，更客观，更能反映真实的效率问题

测试的ORM

下面列出常见的ORM，特别是国产

<PackageReference Include="Chloe.SQLite" Version="5.55.0" />(半活跃) <PackageReference Include="Dapper" Version="2.1.66" /> <PackageReference Include="FreeSql.Provider.Sqlite" Version="3.5.305" /> <PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="8.0.0-preview.6.23329.4" /> <PackageReference Include="SqlSugarCore" Version="5.1.4.212-preview02" /> <PackageReference Include="linq2db" Version="6.2.0" /> <Reference Include="Fast.Framework">(停止维护) <Reference Include="myTest">(私有项目)

测试结果关注点

除了运行耗时，内存分配也是非常重要的方面，谁也不想系统内存暴炸吧
下面是具体的测试结果，增加了耗时和内存排名

TestCondition

对表达式进行解析测试，执行一次

query.Where(b => b.F_String == "111" && b.F_Decimal > 0 && b.F_Bool == true && b.F_String.StartsWith("abc")).Select(b => new { b.F_Float, b.F_Bool, b.F_Double, b.F_Byte, b.F_String, b.F_Decimal, b.F_Int64 }).ToSqlString();

TestResult

一次查询100条数据，主要消耗在对象映射上

query.Take(100).ToList();

TestAnonymousResult

一次查询100条数据，映射为匿名对象

query.Take(100).Select(b => new { b.Id, b.F_Float, b.F_Bool, b.F_DateTime, b.F_Decimal, b.F_Double, b.F_Int64 }).ToList();

TestQueryLoop

循环20次，查询一条记录

for (var i = 0; i < 20; i++) { var item = query.Where(b => b.Id == i).ToList(); }

为什么不测试UPDATE/INSERT

由于 SQL 的实际执行由数据库引擎负责，ORM 无法改变数据库层面的执行逻辑；不同 ORM 的差异主要体现在 SQL 拼接、表达式解析和数据映射等实现细节（例如插入操作可通过生成 SQL 或使用 BulkCopy 实现），假定实现原理一样，测试UPDATE/INSERT无非是在测试SQL拼接，上面的测试完全可以满足。

使用AI进行总结

Q:对此测试进行性能和内存使用总结,排除FastFrameworkTest

AI:BEGIN

性能与内存使用总结（排除 FastFrameworkTest）

一、整体排名概况

本次测试覆盖了 7 个 ORM 框架（排除 FastFrameworkTest 后，实际对比 7 个：ChloeTest、DapperTest、EfSqlliteTest、FreeSqlTest、LinqToDbTest、MyTest、SqlSugarTest），在 4 种不同场景下进行了性能与内存测试。

各场景综合表现

二、各场景详细分析

1. TestCondition（表达式解析）

测试表达式解析和 SQL 生成能力，不含数据读取

​关键发现​：

• MyTest 在表达式解析上具有碾压性优势，速度是第 2 名的2 倍
• SqlSugarTest 内存分配是 MyTest 的 ​7.2 倍​，性能慢9 倍

2. TestResult（实体映射 - 100 条数据）

查询 100 条数据并映射为实体对象，模拟真实业务场景

​关键发现​：

• DapperTest 以微弱优势获得​性能第 1​，MyTest 紧随其后
• MyTest 在​内存控制上遥遥领先​，仅 35.42 KB
• EfSqlliteTest 内存分配是 MyTest 的5.7 倍

3. TestAnonymousResult（匿名对象映射 - 100 条数据）

查询 100 条数据并映射为​匿名对象​，减少实体跟踪开销

​关键发现​：

• MyTest 在此场景表现出统治级优势
• LinqToDbTest 在匿名对象映射时内存表现优异（52.67 KB），但性能慢于 Dapper/Chloe
• SqlSugarTest 的 3210.79 KB 内存分配​异常惊人​，应引起重视

4. TestQueryLoop（循环 20 次单条查询）

循环 20 次单条查询，​模拟频繁单条查询场景​，测试连接管理、SQL 解析等开销

​关键发现​：

• DapperTest在循环单次查询场景中​绝对领先​，体现了其轻量级优势
• MyTest 紧随其后，性能比 Dapper 慢约 40%，但远超其他框架
• EfSqlliteTest 内存分配高达 1156.31 KB，说明 EF 在处理多次短查询时开销巨大

三、性能与内存对比矩阵

性能对比（以 MyTest 为基准）

内存对比（以 MyTest 为基准）

四、核心结论

🎯 综合性能冠军

MyTest在3/4场景中表现最优（TestCondition、TestAnonymousResult、TestResult 内存最优），在所有场景中均位列前二，综合性能最强，内存控制最佳。

💾 内存控制王者

MyTest在全部 4 个场景中内存消耗均为最低或次低，平均内存仅为其他框架的 ​**11%-35%**​，表现卓越。

⚡ 特定场景冠军

• ​DapperTest​：纯 SQL 查询（TestResult）和循环小查询（TestQueryLoop）场景速度第一
• ​MyTest​：表达式解析（TestCondition）和匿名映射（TestAnonymousResult）场景速度第一

⚠️ 严重问题警告

1. SqlSugarTest在TestAnonymousResult中性能异常：
   • 耗时 9ms（是 MyTest 的 ​19.6 倍​）
   • 内存 3.2MB（是 MyTest 的 ​95.2 倍​）
   • 建议检查是否存在 Bug 或配置错误
2. EfSqlliteTest内存消耗巨大：
   • 在所有场景中内存均为 MyTest 的3-8.6 倍
   • 不适合内存敏感场景
3. LinqToDbTest循环查询极慢：
   • 耗时 16.9ms，是 MyTest 的7.4 倍
   • 不适合高频小查询场景

AI:END

====================== 分割符 ======================================

经过分析，在国产开源项目整体效率上Chloe>FreeSql>SqlSugar，然而热度是反过来的，很有意思的情况
在此测试中，SqlSugarTest和FreeSqlTest并没有宣称的比Dapper强，为什么出现这种情况
本着实事求是的原则，找找他们官网是如何测试的

SqlSugar

https://www.donet5.com/Home/Doc?typeId=1180

下载测试代码，发现测试不标准，直接使用的DateTime，那此测试肯定比这个准确

public void Init(OrmType type) { Console.WriteLine("GetAll"); var eachCount = 1; var beginDate = DateTime.Now; for (int i = 0; i < 10; i++) { switch (type) { case OrmType.SqlSugar: SqlSugarTest(eachCount); break; case OrmType.EF: EFTest(eachCount); break; default: break; } } Console.WriteLine("总计：" + (DateTime.Now - beginDate).TotalMilliseconds / 1000.0); } _CharSource.Add(new PerformanceTestChartModel { Name = name, Time = GetTime(), CPU = GetCurrentProcessSize() }); rollBack($"总共执行时间：{GetTime()}秒"); private double GetTime() { _endTime = DateTime.Now; return (_endTime - _beginTime).TotalMilliseconds / 1000.0; }

SqlSugar除了查询匿名对象内存会爆炸，还有其它BUG,见
https://gitee.com/hubro/dbTest/blob/master/items/SqlSugarTest.cs

FreeSql

https://freesql.net/guide/performance.html

下载源代码，找到自带的测试项目FreeSql.Bechmarker，仔细检查测试，发现这个测试项目写得有点问题，作了以下修改

1. 改为SQLite数据库
2. 注释掉[IterationSetup]，以自动采样率
3. 增加表结构字段数
   重新运行测试OrmVsSelect得到结果，跟此测试的结果差不多

最后

此轮测试可以反映和ORM的效率水平，侧面反映了编码水平和整体结构设计
附上测试项目源码
https://gitee.com/hubro/dbTest.git