timestampdiff(year, birth_date, now()) 返回的是年份差而非周岁，因不考虑月日会导致虚岁误判；正确做法是先算年份差，再用date_format(now(), '%m%d')与date_format(birth_date, '%m%d')比较是否已过生日并校正。
用 TIMESTAMPDIFF 计算年龄：注意年份“虚岁”陷阱
TIMESTAMPDIFF(YEAR, birth_date, NOW()) 看似直接，但实际返回的是两个日期之间**完整的年份差**，不考虑月份和日。比如 2000-12-31 出生的人，在 2024-01-01 就会返回 24，哪怕只过了 1 天——这其实是“虚岁”逻辑。
真正按生日算的周岁，得先判断是否已过生日：
SELECT TIMESTAMPDIFF(YEAR, birth_date, NOW()) - (CASE WHEN DATE_FORMAT(NOW(), '%m%d')
-
DATE_FORMAT(NOW(), '%m%d')提取当前月日（如 0315），和出生月日比大小 - 别用
DAYOFYEAR，闰年会导致 12 月 31 日和 1 月 1 日跨年错判 - 如果业务接受虚岁（如部分 HR 系统），直接用
TIMESTAMPDIFF(YEAR, ...)即可，但必须明确告知下游
计算工龄时，TIMESTAMPDIFF 的单位选 YEAR 还是 MONTH？
选 YEAR 会丢失精度：2022-07-15 入职到 2024-06-30，TIMESTAMPDIFF(YEAR, '2022-07-15', '2024-06-30') 返回 1，但实际接近 2 年。
更稳妥的做法是先算总月数，再拆解：
SELECT FLOOR(TIMESTAMPDIFF(MONTH, hire_date, NOW()) / 12) AS years, TIMESTAMPDIFF(MONTH, hire_date, NOW()) % 12 AS months FROM employees;
-
TIMESTAMPDIFF(MONTH, ...)按日历月计算，不依赖天数折算，结果稳定 - 避免用
DAY单位再除以 365：不同年份天数不同，且忽略闰日会导致累计误差 - 如果只要整年工龄（如晋升门槛），用
YEAR单位没问题；若需展示“X 年 Y 个月”，必须走MONTH路径
TIMESTAMPDIFF 在不同 MySQL 版本里的行为差异
MySQL 5.7+ 和 8.0 对边界日期的处理一致，但低版本（如 5.6）在 LEAP YEAR 边界可能有偏差。例如 TIMESTAMPDIFF(YEAR, '2020-02-29', '2021-02-28')：
- MySQL 8.0 返回 0（未满一年）
- 某些 5.6 补丁版本可能返回 1（错误地将 2 月 28 日视为 2 月 29 日的“次日”）
- 一律用
DATE_ADD(hire_date, INTERVAL 1 YEAR)做校验更可靠，尤其涉及法定权益计算时
遇到 NULL 或非法日期时，TIMESTAMPDIFF 怎么不报错还返回奇怪值？
TIMESTAMPDIFF 遇到 NULL 参数直接返回 NULL，看似安全；但若传入非法字符串（如 '2023-13-01'），在 sql_mode 不严格时会静默转成 '0000-00-00'，导致结果为极大负数（如 -1970）。
- 务必在查询前加过滤：
WHERE hire_date IS NOT NULL AND hire_date != '0000-00-00' - 建表时对日期字段加
CHECK(hire_date >= '1900-01-01')（MySQL 8.0.16+ 支持） - 应用层写入前做基础校验，比在 SQL 里补救更高效
年龄和工龄这类字段，往往牵扯薪酬、合同、退休等关键逻辑，函数本身简单，但输入质量、边界定义和版本兼容性才是真正的坑。
