psycopg2执行经mogrify验证的UPDATE查询未生效且游标报错如何排查

• 对非查询类SQL的游标返回逻辑认知错误
  psycopg2 中，UPDATE、INSERT、DELETE这类不返回数据集的DML语句，通过cursor.execute()执行后，游标不会生成可供fetchone()、fetchall()等方法读取的结果集。此时直接调用fetch系列接口，必然触发DatabaseError: no results to fetch报错，该报错和UPDATE语句本身是否执行成功没有关联。
• 事务未手动提交导致修改未持久化
  psycopg2 默认关闭自动提交模式，所有通过游标执行的DML操作都会被纳入临时事务范围，只有显式调用连接对象的commit()方法后，修改才会真正写入数据库。如果执行完UPDATE没有执行commit操作，无论流程是否正常结束，之前的修改都会在连接关闭时被自动回滚，表现为“语句执行了但表数据没有变化”。

• 移除无意义的fetch调用，通过游标内置属性校验更新效果
  执行完UPDATE后不需要调用fetch类方法，可直接读取cursor.rowcount属性确认本次操作实际匹配修改的行数：
  • 返回值大于0：说明SQL语法、WHERE条件匹配逻辑无问题，修改已在事务内生效
  • 返回值为0：说明WHERE条件没有命中对应数据行，需要校验cover_id的取值和表内实际存储值的匹配性（重点排查大小写、前后空格等隐形差异）
• 补充事务提交逻辑
  在cursor.execute()执行完成且无异常的前提下，调用连接对象的commit()方法完成数据持久化；如果执行流程中捕获到运行异常，需要同步调用conn.rollback()回滚未提交的事务，避免残留无效事务占用连接资源。
• 校验动态拼接SQL的参数匹配关系
  当通过分支逻辑追加可选更新字段（如comments、approver_id）时，必须保证SQL中占位符%s的总数量、顺序和传入的参数元组完全对应。例如同时开启两个可选字段时，占位符顺序为status -> previous_status -> comments -> approver_id -> cover_id，传入参数的顺序必须和占位符位置严格对齐，避免出现参数错位、数量不匹配的执行错误。

你通过mogrify调试生成的SQL本身语法合法，不存在语法层面的错误，之前遇到的未生效、报错问题均来自上述操作逻辑疏漏，和SQL字符串生成逻辑无关。

内容的提问来源于stack exchange，提问作者Ricardo Raz