Timescale中为何优先使用timestamptz而非timestamp？

首先明确：这不是强制要求，但属于生产环境的最佳实践，核心原因不是直接提升性能，而是避免隐性的一致性问题，同时间接保障查询效率，具体如下：

• 时区一致性保障：timestamp存储的是不带时区的本地时间，当不同时区的用户或服务访问时，会出现时间显示混乱。比如东八区用户存的2024-01-01 12:00，西五区用户查询时会直接显示这个时间，实际对应的UTC时间差了13小时；而timestamptz存储的是UTC时间，查询时会自动转换为当前会话的时区，确保所有用户看到的是自己时区下的正确时间点。
• 超表分区的准确性：Timescale超表依赖时间列做分区，若用timestamp，当数据库会话时区变更时，分区边界的计算会出错。比如你在东八区创建的分区是2024-01-01 00:00到2024-01-02 00:00（本地时间），切换到UTC时区后，这个分区对应的UTC范围就变了，查询时可能会扫描错误的分区——表面上运行正常，但实际会悄悄增加不必要的分区扫描，降低查询性能，极端情况下还会出现数据找不到的问题。
• 性能层面的间接影响：timestamp和timestamptz的存储开销、基础查询速度几乎无差别，timestamptz的时区转换开销可以忽略。但如果因为时区问题导致分区命中错误，就会显著降低查询效率，这才是性能相关的核心点。
• 你当前用timestamp正常的原因：你的环境是单时区，会话时区和存储数据时的时区完全一致，没有触发上述时区不一致或分区计算错误的场景。但一旦扩展到多时区部署、调整数据库时区配置，问题就会暴露。

总结：个人测试或单时区封闭环境下，timestamp可以凑合用；但生产环境、尤其是涉及跨时区访问的场景，必须用timestamptz，这是避免隐性问题的关键最佳实践。

内容的提问来源于stack exchange，提问作者Konstantinos Gallis