不能。MySQL标量函数无法直接判断法定节假日，因其无内置节假日日历，需依赖外部维护的节假日表（如cn_holidays）并通过READS SQL DATA、DETERMINISTIC声明的自定义函数查询实现。
MySQL标量函数能直接判断法定节假日吗
不能。MySQL原生不提供节假日计算能力，也没有内置中国法定节假日日历。所谓“判断”，本质是查表匹配或硬编码规则——而标量函数（CREATE FUNCTION）只适合做轻量、确定性逻辑，比如查内存表、匹配固定日期列表、或实现调休规则的简单推导。复杂动态规则（如国务院每年发布的放假通知）必须靠外部同步更新数据表，函数本身无法自动感知政策变更。
用CREATE FUNCTION查节假日表是最可靠的做法
前提是已有一张维护好的节假日基础表，例如：CREATE TABLE cn_holidays (
dt DATE PRIMARY KEY,
is_official TINYINT(1) NOT NULL COMMENT '1=法定假日, 0=调休上班',
name VARCHAR(32) COMMENT '节日名称，如"春节", "国庆节"'
);
然后编写标量函数查询它：DELIMITER $$
CREATE FUNCTION is_cn_holiday(d DATE) RETURNS TINYINT(1)
READS SQL DATA
DETERMINISTIC
BEGIN
DECLARE result TINYINT(1) DEFAULT 0;
SELECT IFNULL(is_official, 0) INTO result
FROM cn_holidays
WHERE dt = d;
RETURN result;
END$$
DELIMITER ;
注意三点：
- 必须声明
READS SQL DATA，否则无法读表
- 务必加
DETERMINISTIC（虽然实际依赖外部数据，但MySQL要求标量函数声明确定性；否则在某些SQL模式下会报错）
-
IFNULL 防止查不到时返回 NULL，确保始终返回 0 或 1
硬编码几个关键日期虽快但极易出错
有人倾向在函数里写死 IF d IN ('2025-01-28', '2025-01-29', ...)，这仅适用于测试或极短期场景。问题在于：
- 春节日期每年浮动（农历正月初一），硬编码必然漏年份
- 调休日每年不同（如2025年春节前的2月1日可能上班），硬编码无法覆盖
- 函数体超过几KB后，MySQL解析和缓存效率明显下降
- 修改需重定义函数，比UPDATE表更难灰度和回滚
若真要硬编码，只建议用于单年验证，且必须配合注释说明适用年份，例如：-- 注意：以下仅覆盖2025年国务院通知（国办发明电〔2024〕XX号）
性能和权限坑点必须提前确认is_cn_holiday() 在 WHERE 子句中被频繁调用时，容易成为瓶颈：
- 该函数无法利用
cn_holidays.dt 上的索引加速（MySQL对函数参数中的列不优化）
- 若表无主键或未建索引，全表扫描会拖慢整个查询
- 执行函数的用户必须有
SELECT 权限 on cn_holidays，否则运行时报 ERROR 1370 (42000): execute command denied to user
- 函数默认以定义者权限（DEFINER）执行，若定义者账号后续被删，函数将失效
真正上线前，务必用 EXPLAIN FORMAT=TREE 看执行计划，并在高并发场景下压测函数调用开销。
CREATE FUNCTION查节假日表是最可靠的做法
前提是已有一张维护好的节假日基础表，例如：CREATE TABLE cn_holidays ( dt DATE PRIMARY KEY, is_official TINYINT(1) NOT NULL COMMENT '1=法定假日, 0=调休上班', name VARCHAR(32) COMMENT '节日名称，如"春节", "国庆节"' );然后编写标量函数查询它：
DELIMITER $$ CREATE FUNCTION is_cn_holiday(d DATE) RETURNS TINYINT(1) READS SQL DATA DETERMINISTIC BEGIN DECLARE result TINYINT(1) DEFAULT 0; SELECT IFNULL(is_official, 0) INTO result FROM cn_holidays WHERE dt = d; RETURN result; END$$ DELIMITER ;注意三点：
- 必须声明
READS SQL DATA，否则无法读表 - 务必加
DETERMINISTIC（虽然实际依赖外部数据，但MySQL要求标量函数声明确定性；否则在某些SQL模式下会报错） -
IFNULL防止查不到时返回NULL，确保始终返回0或1
硬编码几个关键日期虽快但极易出错
有人倾向在函数里写死 IF d IN ('2025-01-28', '2025-01-29', ...)，这仅适用于测试或极短期场景。问题在于：
- 春节日期每年浮动（农历正月初一），硬编码必然漏年份
- 调休日每年不同（如2025年春节前的2月1日可能上班），硬编码无法覆盖
- 函数体超过几KB后，MySQL解析和缓存效率明显下降
- 修改需重定义函数，比UPDATE表更难灰度和回滚
若真要硬编码，只建议用于单年验证，且必须配合注释说明适用年份，例如：-- 注意：以下仅覆盖2025年国务院通知（国办发明电〔2024〕XX号）
性能和权限坑点必须提前确认is_cn_holiday() 在 WHERE 子句中被频繁调用时，容易成为瓶颈：
- 该函数无法利用
cn_holidays.dt 上的索引加速（MySQL对函数参数中的列不优化）
- 若表无主键或未建索引，全表扫描会拖慢整个查询
- 执行函数的用户必须有
SELECT 权限 on cn_holidays，否则运行时报 ERROR 1370 (42000): execute command denied to user
- 函数默认以定义者权限（DEFINER）执行，若定义者账号后续被删，函数将失效
真正上线前，务必用 EXPLAIN FORMAT=TREE 看执行计划，并在高并发场景下压测函数调用开销。
is_cn_holiday() 在 WHERE 子句中被频繁调用时，容易成为瓶颈：- 该函数无法利用
cn_holidays.dt上的索引加速（MySQL对函数参数中的列不优化） - 若表无主键或未建索引，全表扫描会拖慢整个查询
- 执行函数的用户必须有
SELECT权限 oncn_holidays，否则运行时报ERROR 1370 (42000): execute command denied to user - 函数默认以定义者权限（DEFINER）执行，若定义者账号后续被删，函数将失效
EXPLAIN FORMAT=TREE 看执行计划，并在高并发场景下压测函数调用开销。
函数本身不是魔法，它只是把「查表」这个动作封装得更顺手一点。最常被忽略的是：节假日数据源是否及时、准确、可审计。别让一个方便的函数，掩盖了数据同步流程的缺失。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
