根本原因是表缺少primary key或unique约束；该语句仅在唯一键冲突时触发update，否则报错中断；NULL值不视为重复；需用show create table确认约束，组合去重须建unique key而非仅索引。
mysql 中 INSERT ... ON DUPLICATE KEY UPDATE 为什么没触发更新？
根本原因不是语法错，而是表里没有定义 PRIMARY KEY 或 UNIQUE 约束。这个语句只在遇到唯一键冲突时才走 UPDATE 分支，否则直接报 Duplicate entry 错误并中断执行。
实操建议：
- 用
SHOW CREATE TABLE <code>table_name确认是否存在UNIQUE或PRIMARY KEY；光有索引（INDEX）不够 - 如果业务上靠多个字段组合去重，必须显式建
UNIQUE KEY (col_a, col_b)，不能只依赖应用层逻辑 - 注意：如果冲突字段是
NULL，MySQL 认为它们不重复（标准 SQL 中NULL != NULL），会导致语句静默插入新行
postgresql 的 DO $$ ... $$ 块里怎么捕获具体错误码？
PG 不支持类似 MySQL 的 SQLSTATE 条件跳转，但可以在 EXCEPTION 块中用 GET STACKED DIAGNOSTICS 提取错误细节，比单纯写 WHEN OTHERS THEN 实用得多。
实操建议：
- 必须用
DECLARE声明变量接收诊断信息，例如：err_code TEXT;、err_msg TEXT; - 关键语句是：
GET STACKED DIAGNOSTICS err_code = RETURNED_SQLSTATE, err_msg = MESSAGE_TEXT; - 常见需要区分的错误码：
23505（唯一约束冲突）、23503（外键失败）、42703（列不存在）——这些比笼统的OTHERS更利于精准降级
SQL Server 的 TRY...catch 为什么抓不到 select 报错？
因为 SELECT 引发的大多数错误（比如列不存在、类型转换失败）属于“编译时错误”，在 TRY 块执行前就被拦截了，根本进不了运行时捕获流程。
实操建议：
- 只有运行时错误能被
CATCH捕获，比如INSERT违反约束、除零、死锁重试失败 - 想让
SELECT安全兜底，得提前用if EXISTS (SELECT 1 FROM sys.columns WHERE ...)检查列是否存在 -
SET XACT_ABORT ON必须加在TRY外层，否则某些严重错误（如连接中断）会让事务卡在未提交状态
Python + SQLAlchemy 执行原生 SQL 时，IntegrityError 怎么区分是主键冲突还是外键失败？
不能只看异常类型，得拆开 orig 属性里的数据库原生错误信息。不同后端返回格式差异大，硬匹配字符串容易漏判或误判。
实操建议：
- 先取
exc.orig.args[0]（MySQL）或exc.orig.pgcode（PostgreSQL），避免直接解析str(exc) - MySQL 常见码：
1062（主键/唯一冲突）、1452（外键约束失败）；PostgreSQL 对应23505和23503 - 别在 except 块里做耗时操作（比如发告警），异常栈可能被 GC 清掉上下文，优先记录
exc.__cause__和traceback.format_exc()
事情说清了就结束。真正麻烦的从来不是“怎么写 try-catch”，而是错误发生时，你手里的日志能不能准确定位到是哪个约束、哪条语句、哪个参数触发的——这取决于你从建表那一刻起，有没有把约束名起得让人一眼看懂。