TimescaleDB的compression_policy生效前提是chunk已关闭且未压缩，需先启用表级压缩或手动压缩；segment_by应选局部稳定的高基数字段，order_by必须以time列开头；压缩后chunk只读，不可UPDATE/DELETE。
compression policy 生效的前提是 chunk 已经被压缩过，不是一建就压
TimescaleDB 的 compression_policy 不会立即压缩现有数据，它只对满足条件的、尚未压缩的 chunk 触发后台压缩任务。刚创建策略时，如果所有 chunk 都已写入且未标记为“可压缩”，策略就处于静默状态。
常见错误现象：SELECT * FROM timescaledb_information.compression_policies 显示策略存在，但 SELECT * FROM timescaledb_information.chunks 里 is_compressed 全是 f，数据体积没变化。
- 先手动运行
ALTER TABLE your_hypertable SET (timescaledb.compress = true)启用表级压缩能力（仅一次） - 再插入新数据，或用
SELECT compress_chunk(chunk_name)手动压缩已有 chunk（注意：chunk 必须处于 closed 状态才能压缩） - 确认 hypertable 的
chunk_time_interval设置合理——太小会导致 chunk 过多、压缩调度延迟；太大则冷数据滞留内存时间长
segment_by 字段选错，压缩率暴跌甚至查询变慢
segment_by 决定了每个压缩 chunk 内部如何分组存储列值。它不是索引，而是压缩时的“逻辑分块依据”：相同 segment_by 值的行会被尽量打包进同一压缩单元，利于字典编码和 delta 编码。
使用场景：适合高基数但局部稳定的字段，比如 device_id、sensor_type、location_id。不适合选 timestamp 或全表唯一 ID。
- 错误示例：
segment_by = 'id'→ 每行 id 都不同，压缩引擎无法聚合同质数据，压缩率接近 0% - 正确做法：优先选业务上天然“成组”的字段，且该字段在写入时有局部聚集性（如一批设备按时间顺序上报，
device_id在短时间内重复出现） - 若必须多字段，用逗号分隔：
segment_by = 'device_id, sensor_type'，但总长度不能超 128 字节（含逗号和空格）
order_by 必须包含 time 列，否则压缩后查询性能反降
order_by 控制压缩 chunk 内部行的物理排序方式，直接影响范围查询（尤其是时间范围）的 I/O 效率。TimescaleDB 强制要求 order_by 第一个字段必须是 hypertable 的时间列（通常是 time），否则建表时报错。
常见错误现象：加了 order_by = 'value DESC' 却漏掉 time，建表失败；或写了 order_by = 'time, device_id'，但查询只过滤 device_id，发现走不了索引。
- 必须以时间列为首：
order_by = 'time DESC'是最简安全配置 - 追加字段要符合查询模式：如果常查 “某设备最近 N 条”，可用
order_by = 'time DESC, device_id'；但若常查 “某时间段内所有设备”，device_id放后面意义不大 - 避免冗余排序：不要写
order_by = 'time, time DESC'，语法报错；也不建议用表达式如date_trunc('hour', time)，压缩不识别
压缩后不可直接 UPDATE/DELETE，但 INSERT 仍正常
压缩后的 chunk 被转为只读列存格式，PostgreSQL 层面禁止对 is_compressed = true 的 chunk 执行 DML。这是设计使然，不是 bug。
容易踩的坑：应用层逻辑假设“所有数据都可更新”，结果在压缩触发后突然报错 ERROR: cannot update compressed chunk。
- UPDATE/DELETE 只能在压缩前发生：靠
chunk_time_interval和compression_policy的 delay 参数控制“保留多久未压缩窗口”，例如设compress_after = '7 days'，那 7 天内的 chunk 还能改 - INSERT 不受影响：压缩不影响写入路径，新数据照常进入 open chunk
- 真要改历史数据？只能先
decompress_chunk()，改完再compress_chunk()—— 但会打断压缩流水线，慎用
真正麻烦的是 segment_by 和 order_by 一旦设错，重设需先解压全部 chunk，再重建 hypertable。这不是线上能轻易操作的事。
