sql server中sp_send_dbmail需启用database mail xps并重启sql server agent，且不可在触发器中直接调用以防事务阻塞；mysql/postgresql无内置邮件功能，应由应用层处理。

SQL Server 里用 sp_send_dbmail 发邮件必须开代理

直接在触发器里调 sp_send_dbmail 会失败，报错 The database mail xps are disabled 或 Mail not enabled for this instance。这不是权限问题，是 SQL Server 默认禁用数据库邮件扩展存储过程。

实操建议：

• 先用 EXEC sp_configure 'show advanced options', 1; RECONFIGURE; 开启高级选项
• 再执行 EXEC sp_configure 'Database Mail XPs', 1; RECONFIGURE;
• 必须重启 SQL Server Agent 服务（不是 SQL Server 本身）才能让配置生效
• 确保 msdb 数据库中已配置好邮件配置文件（Profile）和账户（Account），且当前用户有 DatabaseMailUserRole 角色

触发器里调 sp_send_dbmail 会阻塞事务

邮件发送是同步操作，如果网络延迟高、邮件服务器响应慢，整个 INSERT/UPDATE/DELETE 事务会被卡住，影响业务写入性能，甚至引发超时或死锁。

实操建议：

• 绝对不要在 AFTER 触发器里直接调 sp_send_dbmail
• 改用异步方式：触发器只往一张中间表（如 dbo.mail_queue）插入待发邮件记录
• 另起一个 SQL Server Agent 作业，每 10–30 秒轮询该表，批量调 sp_send_dbmail 并标记已发送
• 加索引：对 mail_queue.status 和 created_at 建复合索引，避免轮询全表扫描

MySQL / PostgreSQL 不支持内置邮件触发

MySQL 没有类似 sp_send_dbmail 的系统存储过程；PostgreSQL 也没有原生邮件函数。强行实现只能靠外部手段，但会破坏数据库自治性。

实操建议：

• MySQL：触发器里不能调 shell 命令，SYS_EXEC() 等插件极不安全且默认禁用，不推荐
• PostgreSQL：可配合 pg_cron + 外部脚本，但需额外部署调度器，且触发器无法可靠传递参数给脚本
• 通用解法：把「发邮件」逻辑彻底移出数据库，由应用层监听 binlog（MySQL）或逻辑复制（PostgreSQL）来驱动
• 如果非要在 DB 层做，PostgreSQL 可用 dblink 调外部 HTTP 服务，但依赖网络和 API 稳定性

邮件内容拼接容易 SQL 注入或乱码

触发器里用 CONCAT 或 + 拼 HTML 内容时，若字段含单引号、尖括号或 UTF-8 特殊字符，轻则邮件显示异常，重则触发器编译失败或注入攻击。

实操建议：

• 所有动态字段必须用 REPLACE(字段, '''', '''''') 转义单引号（SQL Server）
• HTML 内容统一用 FOR XML PATH('') 构造，避免手动拼接
• 避免在邮件正文中直接嵌入用户输入字段；优先用 ID + 链接引导到前端查看详情
• 设置 @body_format = 'HTML' 时，@body 必须是合法 UTF-16 字符串，中文字段要确认源表列是 NVARCHAR 类型

事情说清了就结束。最常被忽略的是事务阻塞和跨数据库兼容性——SQL Server 方案看似简单，但生产环境里那几秒的邮件延迟可能拖垮整个订单流程；而 MySQL/PostgreSQL 用户硬要在 DB 层发邮件，最后基本都退回应用层处理。