BETWEEN日期范围结果少一天，因数据库将'2024-01-01'默认补为'2024-01-01 00:00:00'，而'2024-01-31'被补为'2024-01-31 00:00:00'，漏掉当日23:59:59前数据；应改用>=与<组合。
WHERE子句里用BETWEEN写日期范围，为什么结果总少一天？
因为 BETWEEN 是闭区间，但如果你传入的是 '2024-01-01' 这样的纯日期字符串，多数数据库（如 PostgreSQL、SQL Server）会默认补成 '2024-01-01 00:00:00'，而你实际想查的可能是“1月1日全天”，即从 00:00:00 到 23:59:59。直接写 BETWEEN '2024-01-01' AND '2024-01-31' 在 MySQL 中可能隐式转成 '2024-01-31 00:00:00'，漏掉当天下午的数据。
更稳妥的做法是用 >= 和 组合：
WHERE order_date >= '2024-01-01' AND order_date < '2024-02-01'
这样既避免时区/隐式类型转换干扰，又天然覆盖整个月所有时间点。
- 永远优先考虑
>=+替代 <code>BETWEEN处理带时间的字段 - 如果字段类型是
DATE（不含时间），BETWEEN '2024-01-01' AND '2024-01-31'是安全的 - Oracle 对
DATE类型默认包含时间部分，即使你只插了日期，也得按带时间处理
在视图定义里写日期过滤，会不会让视图变“死”？
会。如果你在 CREATE VIEW 语句里硬编码了具体日期（比如 WHERE created_at BETWEEN '2024-01-01' AND '2024-12-31'），那这个视图就只能查这一年，后续必须 DROP + RECREATE 才能更新范围——这不是视图该干的事。
视图应该保持通用性。真正需要动态过滤时，靠查询时加 WHERE 来实现：
CREATE VIEW recent_orders AS SELECT id, amount, created_at FROM orders WHERE created_at >= '2024-01-01'; -- 可留一个基础兜底，但别锁死上限
然后使用时再叠加条件：
SELECT * FROM recent_orders WHERE created_at < '2024-07-01';
- 视图里尽量不写具体日期范围，除非业务上绝对固定（如“历史冻结数据”）
- 若必须参数化，PostgreSQL 可用
CREATE FUNCTION返回TABLE，MySQL 8.0+ 可用内联表值函数（但支持有限） - 别指望标准 SQL 视图支持运行时传参
用BETWEEN和AND组合多个条件时，括号到底要不要加？
要。当混合使用 AND、OR 和日期范围时，不加括号极易出错。例如：
WHERE status = 'shipped' AND order_date BETWEEN '2024-01-01' AND '2024-01-31' OR user_id = 123
这条语句实际等价于：
WHERE (status = 'shipped' AND order_date BETWEEN '2024-01-01' AND '2024-01-31') OR user_id = 123
也就是“所有 user_id=123 的记录都会被查出来，不管 status 或日期”。正确写法必须显式分组：
WHERE status = 'shipped' AND (order_date BETWEEN '2024-01-01' AND '2024-01-31')
-
BETWEEN a AND b本身是一个原子表达式，但和外部逻辑运算符连用时，优先级不总是符合直觉 - 只要出现
OR，或同时有多个AND涉及不同业务维度，就用括号明确意图 - 很多 ORM 生成的 SQL 默认加括号，不是为了好看，是防错
日期范围过滤最麻烦的从来不是语法，而是对字段真实精度、数据库隐式行为、以及视图定位的理解。硬编码范围、忽略时间部分、省略括号——这三个动作加起来，比写错一个逗号更容易让查询结果悄悄偏离预期。
