PostgreSQL 15 的存储过程虽然支持事务相关能力，但过程体里并不能直接写 `BEGIN`、`COMMIT`、`ROLLBACK`。真正可用的做法，是把事务边界交给调用方，在过程内部借助 `SAVEPOINT` 与 `ROLLBACK TO SAVEPOINT` 做局部回退。 很多人把 PostgreSQL 15 的 CREATE PROCEDURE 理解成“终于能在存储过程里自己提交事务”，但真正动手时，最先遇到的往往是语法错误，或者提交时机和预期完全不一致。
看 SQL JOIN 的执行计划，先别被一堆字段吓住，真正决定性能排查效率的通常只有几项：`type`、`key`、`possible_keys`、`rows`、`filtered` 和 `Extra`。这篇文章按排查顺序拆开讲，帮助你快速判断是索引没用上、统计信息失真，还是排序与连接阶段出了问题。
MyBatis-Plus 查询结果“条数正确但每项都是 null”，通常不是 SQL 没查到，而是结果映射阶段出了问题。最常见的原因是下划线字段与默认驼峰映射冲突，其次还要检查 Bean 的 setter、Lombok 生效情况，以及是否需要关闭 `map-underscore-to-camel-case`。
在 SQL Server 2019 里做 UPDATE 审计，难点不在 `CREATE TRIGGER` 语法，而在能否稳定记录“谁改了什么、改前改后各是什么”。这篇文章把触发器类型、`inserted/deleted` 联结、`NULL` 比较、日志表结构和递归风险拆开说明。 很多人第一次写 SQL Server 审计触发器，重点都放在语法能不能跑通，结果上线后才发现日志缺字段、漏记录，甚至一批量更新就失真。
这篇文章整理了在 CentOS 上用 Golang 连接 MySQL 和 PostgreSQL 的最小可行流程，包括 Go 安装、驱动获取、连接代码示例和运行验证方法。文中保留了原始命令与示例代码，并补充了连接串字段、端口和常见排查点，方便直接照着落地。
触发器能否调用存储过程，关键不在“能不能调”，而在过程内部是否触碰了事务、引擎和参数传递限制。本文分别梳理 MySQL 与 SQL Server 的常见写法、ERROR 1422 的真正原因，以及触发器调用后数据未更新、BEFORE 触发器改写 NEW 字段失效的排查方法。
SQL 里把字符串直接 `CAST` 成日期，看起来简单，实际最容易踩到数据库默认解析规则、非法日期静默失败和索引失效这三类坑。本文按常见查询场景拆开说明 SQL Server、PostgreSQL、MySQL 的差异，并给出更稳妥的写法。
批量更新本身不可怕，真正拖垮业务的往往是事务过大、条件不走索引，以及分页策略选错。本文按“分批推进、索引命中、事务收口”三条主线，整理出更稳的存储过程写法，并点出 SQL Server、MySQL、PostgreSQL 各自容易踩的坑。
物化视图并不是通用加速开关，而是用空间换时间的定向手段。适合反复执行、计算成本高且能接受分钟到小时级延迟的查询；若刷新策略、唯一索引和口径稳定性没配好，性能收益很容易被抵消。
在 PostgreSQL 14 里，SQL 触发器函数有几条不能踩的硬规则：返回类型必须是 `TRIGGER`，结尾必须返回 `NEW`、`OLD` 或 `NULL`；动态 SQL 里表名、列名要用 `format('%I', ...)`；`NEW` 和 `OLD` 只能按 `TG_OP` 对应场景访问。再加上行级触发器在批量更新时的性能成本，这些细节决定了触发器是稳定运行还是一上生产就报错。
这篇文章用 Spring Boot + Testcontainers 演示真实集成测试的基本做法，覆盖 MySQL、Redis 以及共享容器三类场景。重点保留依赖版本、注解用法和动态注入配置，帮助你判断什么时候该单独起容器，什么时候该用基类复用。
MyBatis 里的 `${}` 之所以危险，不在于语法本身少见，而在于它会把变量原样拼进 SQL，直接绕开 JDBC 预编译。本文从执行机制、典型注入方式和高危使用场景三部分说明问题，并给出项目里可落地的排查与约束思路。
