如何解决 SQL 日期边界导致的数据遗漏?

按日期筛选数据时,`BETWEEN` 常因隐式转换把右边界变成当天 `00:00:00`,导致最后一天的数据被漏掉。本文用订单、日志等常见场景说明问题根源,并给出更稳妥的左闭右开写法、动态边界生成方式,以及字符串日期字段的处理建议。

如何解决 SQL 日期边界导致的数据遗漏?

如何避免 SQL 存储过程出现死循环?

SQL 存储过程里的死循环,往往不是语法不会写,而是退出机制、计数保护和调试手段没统一。本文结合 MySQL 与 PostgreSQL 的典型场景,梳理合法退出方式、硬性上限写法,以及排查挂起过程时更有效的检查路径。

如何避免 SQL 存储过程出现死循环?

SQL 窗口函数怎么实现游标分页?

窗口函数适合给结果集编号,却不能承担游标分页的“从上一条继续取”的职责。本文拆开常见误区、正确 SQL 写法、窗口函数在分页中的辅助用法,以及 PostgreSQL、MySQL、SQLite、SQL Server 的实现差异。 很多 SQL 教程会把“窗口函数编号”和“游标分页”混在一起,结果写出来的语句不是直接报错,就是翻页时重复、漏数。

SQL 窗口函数怎么实现游标分页?

SQL CONCAT 怎么拼接多个字段?MySQL、PostgreSQL、SQL Server、Oracle 用法对比

SQL 里用 CONCAT 拼接多个字段,看起来是基础操作,真正容易出错的却是不同数据库对 NULL 和参数数量的处理差异。本文按 MySQL、PostgreSQL、SQL Server、Oracle 分别梳理写法、版本要求和避坑点,帮助你快速判断该用 CONCAT、`||`、`+` 还是 LISTAGG。 在 SQL 里拼接多个字段,最容易被忽略的不是语法本身,而是数据库之间对 NULL 、参数数量和版本支持的不同处理。

SQL CONCAT 怎么拼接多个字段?MySQL、PostgreSQL、SQL Server、Oracle 用法对比

SQL 金额合计怎么写才不出错?从 SUM() 空值、字段类型到性能优化一次讲清

SQL 里用 `SUM()` 统计金额不难,难的是结果常被空值、字符串金额、分组错误和大表性能拖偏。本文按排查顺序梳理 `NULL` 处理、金额字段清洗与类型转换、`GROUP BY` 规范,以及 `EXPLAIN` 和汇总表优化思路。 写金额合计 SQL 时,`SUM()` 往往不是最难的部分,真正容易出错的是空值返回、字段类型、分组规则和大表性能。

SQL 金额合计怎么写才不出错?从 SUM() 空值、字段类型到性能优化一次讲清

SQL 存储过程如何返回结果集供业务系统调用

SQL Server 存储过程给业务系统回传数据时,最常见的三条通道是 `SELECT`、`OUTPUT` 和 `RETURN`,但它们适用范围完全不同。本文按调用场景拆开说明:什么时候该回结果集,什么时候只回标量,为什么 `RETURN` 不能当业务数据通道,以及多结果集场景下客户端该如何正确消费。

SQL 存储过程如何返回结果集供业务系统调用

SQL 中如何使用 ROLLUP 生成小计和总计

本文围绕 SQL 中的 ROLLUP 用法展开,说明它如何按字段顺序生成小计与总计、如何识别结果中的汇总行,以及何时该改用 CUBE 或 GROUPING SETS。文中保留关键 SQL 写法,并补充了大表场景下的使用注意点。 在报表、经营分析和分层汇总场景里,很多人知道 ROLLUP 能“顺手带出总计”,但真正写到查询里时,往往会被层级顺序、 NULL 含义和标签显示。

SQL 中如何使用 ROLLUP 生成小计和总计

SQL 触发器递归调用问题如何解决

SQL 触发器最容易踩坑的场景之一,就是在触发器内部再次改动自己监听的表。不同数据库对这类递归的处理方式完全不同:有的直接报错,有的默认允许但要求手动拦截。本文按 MySQL、SQL Server、PostgreSQL 与 SQLite 分别梳理限制、报错和可行替代方案。

SQL 触发器递归调用问题如何解决

SQL 中如何计算每组同比增长率?

SQL 里算同比,关键不是“取上一行”,而是准确对到“去年同一周期”。文章拆开说明为什么 `LAG(value, 1)` 常被误用成环比,再给出更稳妥的 `LEFT JOIN + 日期偏移` 做法,以及在何种前提下 `LAG(value, 12)` 才能成立。 同比增长率最容易写错的地方,不是公式本身,而是把“去年同周期”误写成“上一行数据”。

SQL 中如何计算每组同比增长率?

为什么 SQL `NOT EXISTS` 比 `NOT IN` 更安全

`NOT IN` 最大的问题不是慢,而是遇到 `NULL` 后可能直接把结果变成空集,造成业务逻辑误判。相比之下,`NOT EXISTS` 在空值安全、索引利用、关联表达和并发一致性上都更稳,更适合作为默认写法。 很多开发者会把 NOT IN 和 NOT EXISTS 当成语义接近、只差一点性能的两种写法,但真正容易把线上逻辑做错的,往往是 NULL 、隐式类型转换和并发下的。

为什么 SQL `NOT EXISTS` 比 `NOT IN` 更安全