在数据分析过程中，想当然地对TIMESTAMP字段进行运算，导致结果谬之千里，计算公式如下：
-- create_time与week_time的声明都是TIMESTAMP(), 要求精确到分钟 --
SELECT (sa.create_time - sa.week_time)/(1000 * 60)
from alarm_sla_1 sa当然正确的解法是利用timestampdiff函数，如下：
SELECT timestampdiff(minute, sa.create_time, sa.week_time)
from alarm_sla_1 sa但有意思的问题在于，MYSQL明明支持减法操作，为何操作的结果又大相径庭？类似的问题还有，TIMESTAMP字段的时间精度是什么？
从MYSQL的官方实例中可以看到（请见后续的参考文档），TIMESTAMP字段的小数部分确定了秒的经度，3位小数精确到毫秒，6位小数精确到微秒，如下：
| 声明方式 | 小数长度 | 精度 |
|---|---|---|
| TIMESTAMP(3) | 3 | 毫秒 |
| TIMESTAMP(6) | 6 | 微秒 |
按照上面的推论，那么默认的声明TIMESTAMP应该精确到秒，那么应该相减的结果应该得到秒，测试语句如下：
SELECT sa.week_time - sa.create_time, timestampdiff(second, sa.create_time, sa.week_time)
from alarm_sla_1 sa但最后的结果见下表：
| 相减结果 | 函数结果 |
|---|---|
| 1000012 | 86412 |
显然，并不存在相关性，差异何止里计？
后来继续进行了指定经度的操作运算，结论依旧如此。
DATETIME 与 TIMESTAMP的区别
| 特性 | DATETIME | TIMESTAMP |
|---|---|---|
| 时间范围 | 1000-01-01 00:00:00到9999-12-31 23:59:59 | 1970-01-01 00:00:01到2038-01-09 03:14:07 |
| 存储空间 | 8+3(秒的精度) | 4+3(秒的精度) |
| 格式转换 | 不支持 | 支持UTC |
| 多时区支持 | 不支持，固定时区 | 不支持 |
| 创建索引 | 不能 | 能 |
| 查询后缓存结果 | 否 | 是 |
结论
MYSQL中TIMESTAMP字段直接进行相减操作，可能得到难以理解的结果，请慎用。