先说说 TIMESTAMPADD 到底是什么。它是 MySQL 独有的函数，用来给一个时间值加上指定单位的偏移量，返回新的时间戳。语法很简单：TIMESTAMPADD(unit, value, datetime_expr)。其中 unit 必须是关键字，比如 DAY、MONTH，不能写成字符串或变量；而且参数顺序容易搞反——第一个是单位，第二个是数值，第三个才是基准时间。它自动处理月末、闰年等日历逻辑，保证返回有效日期。
MySQL的TIMESTAMPADD函数怎么用？
这个函数是 MySQL 专属，不能直接用在 PostgreSQL、SQL Server 或 SQLite 里。它的单位参数必须是关键字，比如 HOUR、WEEK，不能是字符串或变量。常见写法像这样：
SELECT TIMESTAMPADD(DAY, 7, '2024-03-15');
结果返回 2024-03-22。如果想加 3 个月，写成 TIMESTAMPADD(MONTH, 3, NOW()) 即可。注意：单位关键字必须大写或小写？MySQL 不区分大小写，但习惯上用大写更清晰。
为什么TIMESTAMPADD加月份有时结果出人意料？
因为 MONTH 单位是按日历逻辑进位的，不是简单加 30 天。比如 TIMESTAMPADD(MONTH, 1, '2024-01-31') 结果是 2024-02-29（闰年），而 TIMESTAMPADD(MONTH, 1, '2024-03-31') 会变成 2024-04-30——MySQL 自动“截断”到当月最后一天，不会报错也不会溢出。这种特性在实际业务中很容易踩坑，尤其是做账期计算或到期日推算时。
- 如果业务需求是严格按 30 天加，建议改用
DATE_ADD(NOW(), INTERVAL 30 DAY)。 - 跨年场景下，
TIMESTAMPADD(YEAR, 1, '2023-02-29')会返回NULL，因为 2025-02-29 不存在——注意 2024-02-29 合法，但加一年后就没这个日子了。
一句话：加月份时，逻辑比想象中复杂，不能假设是简单加法。
和DATE_ADD比，TIMESTAMPADD有什么实际差异？
功能上两者几乎重叠，但语法结构不同。DATE_ADD 把单位和数值合并成 INTERVAL 表达式，读起来更直观；TIMESTAMPADD 把单位单独作为第一个参数，适合动态拼接 SQL——比如单位来自配置表字段时，直接传关键字变量即可。下面两个语句等价：
SELECT DATE_ADD('2024-01-01', INTERVAL 5 WEEK);
SELECT TIMESTAMPADD(WEEK, 5, '2024-01-01');
不过要注意：DATE_ADD 支持 WEEK、QUARTER 等单位，TIMESTAMPADD 也支持，但部分旧版本 MySQL 对 QUARTER 处理不一致。生产环境建议统一用 DATE_ADD，除非你明确需要参数化单位。另外，TIMESTAMPADD 返回的是 DATETIME 类型，而 DATE_ADD 根据输入类型有所变化，这点在跨版本时也要留意。
遇到“FUNCTION xxx.TIMESTAMPADD does not exist”错误怎么办？
这个错误只说明当前数据库不是 MySQL（或 MariaDB），而是 PostgreSQL、SQL Server、Oracle 等。它们没有 TIMESTAMPADD 函数。替代方案如下：
- PostgreSQL：
current_timestamp + INTERVAL '7 days' - SQL Server：
DATEADD(day, 7, GETDATE()) - Oracle：
SYSDATE + 7（天）或ADD_MONTHS(SYSDATE, 3)
跨数据库迁移 SQL 时，别只替换函数名，得整体重写时间计算逻辑。因为单位语义、月末处理、时区行为都可能不同——比如 Oracle 的 ADD_MONTHS 在月末处理上就跟 MySQL 的 TIMESTAMPADD(MONTH, ...) 有细微差别。真正麻烦的不是语法，而是不同数据库对“加一个月”这件事的理解差异。哪怕同是 MySQL，5.6 和 8.0 在边界日期上的表现也可能微调。上线前务必用真实业务日期做验证，尤其涉及月末、闰年、夏令时切换点。
