Manager.raw()与connection.cursor()查询的核心差异、性能及适用场景对比

这俩都是Django里执行原生SQL的方式，但封装层级和使用场景差得挺多，给你拆解清楚：

核心区别 #

1. 封装层级与返回值 #

• Manager.raw()是ORM层的封装，返回RawQuerySet，里面是对应的Model实例——查询到的字段会自动映射到模型的属性，你还能像用普通QuerySet那样调用部分方法（比如order_by()、切片操作）。
• connection.cursor()直接操作数据库底层游标，返回的是原始行数据（默认是元组，也可配置为字典），完全脱离ORM体系，所有字段映射、类型转换都得自己手动处理。

2. ORM集成度 #

• raw()能无缝融入Django ORM的上下文：比如自动参与当前事务，修改实例后调用save()会触发模型的验证、信号等机制。
• cursor()完全独立，不会触发任何ORM钩子，也需要自己处理游标和连接的关闭（推荐用with connection.cursor() as cursor:的上下文管理器自动处理）。

3. 参数安全处理 #

两者都支持安全的参数传递（避免SQL注入），但用法略有不同：

• raw()直接在SQL字符串里用%s占位，参数作为第二个参数传入：

  User.objects.raw("SELECT * FROM auth_user WHERE id = %s", [1])
  

• cursor()需要在execute()方法中传递参数：

  from django.db import connection
  with connection.cursor() as cursor:
      cursor.execute("SELECT * FROM auth_user WHERE id = %s", [1])
  

⚠️ 注意：不管用哪种方式，都绝对不要手动拼接SQL字符串传参数，否则会有注入风险。

性能对比：connection.cursor()更优 #

原因很直白：raw()需要把每一行查询结果实例化成Model对象——这个过程包含字段类型转换、对象初始化、甚至关联模型的懒加载处理，会产生额外的CPU和内存开销。而cursor()直接返回原始数据库行数据，跳过了所有ORM实例化步骤，在处理大数据量或性能敏感场景时，差距会非常明显。

适用场景 #

选Manager.raw()的情况 #

• 你需要执行原生SQL，但后续还要用Model实例的方法/属性：比如把结果传给模板渲染，或者调用save()、delete()修改数据。
• 查询结果的字段和你的Model结构完全匹配，不想写手动映射逻辑。
• 想省心利用ORM的事务管理、连接池机制，不想自己处理连接和游标。

选connection.cursor()的情况 #

• 追求极致性能：比如处理上万条以上的查询结果，只需要原始数据做统计或批量处理。
• 执行DDL语句（如CREATE TABLE、ALTER TABLE）或调用存储过程，这类操作本来就和Model无关。
• 查询结果是跨表聚合、统计数据，不需要映射到任何Model：比如只需要返回一个统计数值或一组键值对。
• 需要更细粒度的数据库控制：比如自定义事务隔离级别、批量插入更新时手动控制提交时机。

内容的提问来源于stack exchange，提问作者Usama Alzomor