本文总结 LiteOrm 在不同数据库上的常见差异点，帮助你在选型、排障和扩展方言时更快定位问题。接入新数据库、排查方言行为或评估是否需要扩展 SqlBuilder 时，都可以先从这里开始。
当前文档和 README 中明确提到的主要数据库包括：
分页通常是最容易暴露方言差异的部分。
OFFSET ... FETCHROW_NUMBER() 或嵌套分页LIMIT/OFFSET如果目标数据库的分页规则比较特殊，优先参考：
同一个业务意图，在不同数据库上的函数名和参数形式可能不同，常见差异包括：
如果你注册了自定义 Lambda 翻译，一定要确认最终生成的 SQL 是否适配目标数据库方言。
建议参考：
LiteOrm.Demo\Demos\DateFormatDemo.cs批量写入通常最依赖数据库驱动和 provider 的实现方式。
SqlBulkCopyMySqlBulkCopy 或等效高效导入能力IBulkProvider因此，BatchInsertAsync 的最终性能不仅取决于 LiteOrm，也取决于你是否接入了合适的 IBulkProvider。
不同数据库和驱动对单条 SQL 参数数量的容忍度不同，因此配置中的 ParamCountLimit 很重要。
需要特别留意的场景包括：
IN (...)常见处理方式：
ParamCountLimit参考文档：
| 能力 | 兼容性敏感点 | 建议 |
|---|---|---|
| 分页 | SQL 方言差异最大 | 优先验证分页 SQL，必要时自定义 SqlBuilder |
| 窗口函数 | 老版本数据库可能不支持 | 先确认数据库版本，再决定是否启用 |
| 自定义函数 | 函数名和参数形式差异大 | 用表达式扩展做数据库定制 |
| 批量导入 | 依赖驱动和 provider | 尽量使用数据库原生批量能力 |
| 分表 | 主要取决于表名规则 | 尽早统一 TableArgs 约定 |
这五类基本能覆盖大部分早期暴露出来的方言差异。
如果目标环境是老版本 Oracle，或其他分页语法较特殊的数据库，建议优先验证“排序 + 分页”的组合查询。
排查兼容性问题时，推荐按这个顺序进行：
SqlBuilderSqlBuilder出现以下情况时，通常应考虑自定义 SqlBuilder：
参考入口：
如果你需要在多个数据库之间迁移，或同时支持多种数据库，推荐采用以下策略：
SqlBuilder 和表达式扩展层这样可以让业务层代码长期保持更稳定。