最近接手一个项目，里面有好多 SQL 语句，然后拿到 ORM 执行 SQL 字符串 话说，有 ORM 平时有什么场景需要手写 SQL 的

很少手写了 除非有那种框架搞不了的 手写还容易犯错

"好多 SQL 语句，然后拿到 ORM 执行 SQL 字符串 "
这啥意思, ORM 不就是为了不手动写 SQL 么 = =

比如 写个 sql= select * from AA _db.excute(sql)

经常写，稍微复杂一点的多表查询，ORM 生成出来的只能说是能运行，但效率都不太好。

除非是一些单表查询，生成出来的，一般都问题不大。

说回正题吧, 我是不用 ORM 那一派的, 我觉得小项目不需要, 大项目谨慎使用

crud 员一般都是 ORM ，写的快可读性好，交接起来也容易。
连表查询有索引都是慢查询的时候，就用 sql 替代 ORM(因为我 ORM 理解的不够透，还是写 sql 优化容易一些)

需要查一些老项目的表的时候，不是所有表设计的都是那么规范的，这时候直接写 sql 查完了再用 orm 将结果映射成对象更方便。
我觉得 orm 的核心还是映射，能将返回结果映射成结构体就够了。
可以看看 C＃的 dapper ，写一些小项目或者运维小工具挺爽的。

数据统计往往要 sql 才好写，orm 不容易实现，我们项目就是 sql 用的多

看业务，比如写个报表 所有数据放业务层处理太复杂了， 还是直接 sql 一次性查出数据好处理点。

复杂点的项目一般都是手写 sql 吧

表结构复杂、数据量大还是写 sql ，人家几十年研发的引擎肯定比查完自己拼强

写模板 SQL 然后生成代码

一直都是手写 sql ，框架或者自己写一个语法糖，能预编译就行。orm 也用，偷懒的时候用 orm 。其实最主要的是因为 orm 还要去看文档，虽然每个框架思想大差不差，也能看懂。如果你要是维护那种老的项目，或者压根是一个不了解的框架，你就知道原生 sql 的方便处了。我现在就在看用 ruby 写的一个老项目，sql 天天有慢查询。全是用 orm 写的，找位置都挺费劲的

看情况，2 着都用，都灵活使用，今天还在群里看到有人用这个 sql ，就是比用 ORM 方便

复杂的 sql 都是自己写，orm 不仅丑，效率也不好

单表 CRUD 都用，报表手写 SQL ，性能方向也是手写 SQL 。

简单的东西直接 EFCore 出来就是了. 但是复杂的 (例如报表), 必须手写 SQL. 没办法.

用 ai 写啊

crud 用 ORM ，报表手写

自己的项目 || 不强制要求 orm = 直接手搓 sql
其他的情况,orm,但是复杂的 sql 还得是 orm,即使项目大也是如此

发版上线初期先用 orm 写，然后打点测，下一版的时候全部改成 sql （ orm 直接生成），然后手动处理性能问题的 sql 和优化慢查询

我是基本上只用 ORM

＃22
前面说什么 orm 效率不好的，orm 不也是转 sql 吗
有啥效率不好，只能说用的不熟