必须用 connection.cursor() 而不是 raw() 的情况包括：执行 update/insert/delete；多表 join 后不映射单模型的 select；需返回字典而非模型实例；复用含 cte/窗口函数/union 的 sql。
直接用 raw() 无法执行 UPDATE/INSERT/DELETE，也不能做跨表 JOIN 后不映射到单个模型的查询；真要跑复杂 SQL，得切到原生游标（connection.cursor()）。
什么时候必须用 connection.cursor() 而不是 raw()
raw() 只能用于 SELECT，且结果必须能一一对应到某个模型字段（哪怕字段名不一致，也得靠 translations 映射）。一旦遇到下面这些情况，raw() 就失效了：
- 执行
UPDATE、DELETE、INSERT ... SELECT等非查询语句 - SELECT 多张表的字段（比如
SELECT u.name, o.total FROM auth_user u JOIN order o ON u.id = o.user_id），且不打算强行塞进一个模型里 - 需要返回字典结构（带列名）而不是模型实例
- 想复用已有 SQL 片段（含 CTE、窗口函数、
UNION ALL）而不想重写成 ORM 表达式
cursor.execute() 怎么安全传参
所有用户可控输入必须走 params 参数，绝不能字符串拼接。Django 的 %s 占位符由底层数据库驱动处理转义，不是 Python 的字符串格式化。
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 正确写法：
cursor.execute("SELECT * FROM myapp_person WHERE age > %s AND city = %s", [18, "Beijing"]) - 错误写法：
cursor.execute(f"SELECT * FROM myapp_person WHERE city = '{city}'")—— 直接触发 SQL 注入 - 百分号字面量要写两个：
"WHERE note LIKE %s"+["%urgent%%"]，或直接写"WHERE note LIKE 'urgent%'" - 字典参数用
%(key)s：cursor.execute("SELECT * FROM person WHERE first_name = %(fname)s", {"fname": "John"})
查完怎么取数据：fetchone() vs fetchall() vs fetchmany()
cursor 返回的是普通元组，没有字段名。如果需要键值对，得自己包装或用 cursor.description 构建字典。
-
row = cursor.fetchone()→ 返回单个元组，如(1, "Alice", 28) -
rows = cursor.fetchall()→ 返回元组列表，内存占用随结果集线性增长，大数据量慎用 -
rows = cursor.fetchmany(100)→ 分批拉取，适合流式处理 - 加一层字典包装：
dict(zip([col[0] for col in cursor.description], row))
事务和连接生命周期别踩坑
Django 默认开启自动提交（autocommit）模式，但 UPDATE/INSERT/DELETE 仍受事务控制。手动管理时要注意：
- 用
with connection.cursor() as cursor:自动关闭游标，但不自动 commit - 写操作后需显式调用
transaction.commit()（如果在非事务视图里）或依赖 Django 的请求级事务封装 - 不要长期持有游标或连接——它不跨请求复用，也不该被缓存
- 若在 Celery 任务或管理命令中执行，记得检查是否已处于事务中（
transaction.atomic块内行为不同）
最常被忽略的是字段名丢失问题：用游标查出来的结果默认是位置元组，没人帮你记哪个下标对应哪个字段；一旦 SQL 改了 SELECT 列顺序，代码就静默错位。要么加注释锁定顺序，要么统一用 description 动态构字典——这点比 raw() 的模型绑定更脆弱，也更真实。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
