简介TimescaleDB是构建于PostgreSQL之上的开源时序数据库扩展这个Windows 64位安装包针对PostgreSQL 12提供v2.3.0版本特别适合物联网监控、金融行情、日志分析等产生大量时间戳数据的场景开发与运维人员可以继续使用标准SQL完成插入、聚合和窗口查询同时获得自动分片、压缩和水平扩展能力。包体共40个文件仅4.27MB结构清晰3个DLL为运行核心库33个SQL脚本覆盖从1.1.0至2.2.1多个旧版本到2.3.0的平滑升级路径2个EXE分别负责图形化安装与配置调优另附control元数据与README说明。借助自带的timescaledb-tune工具可依据服务器资源自动建议缓存大小和并行度参数减少手工调优成本。当前已有279人学习下载适合需要在Windows环境快速集成TimescaleDB的PostgreSQL 12用户免去四处寻找组件和适配版本兼容性的时间。1. 看到这个 zip 先别急着解压它是 Windows 上跑时间序列数据库的钥匙如果你是在找 timescaledb 的 Windows 安装包那这个timescaledb-postgresql-12_2.3.0-windows-amd64.zip大概率就是你需要的那个压缩包。它不是一个独立数据库而是 PostgreSQL 12 的时间序列扩展打包成 Windows 64 位版本后以 zip 形式分发。你需要的 PostgreSQL 本体还要另外装这个扩展负责把普通表变成能高效存储海量时序数据 hypertable顺带做压缩、连续聚合和数据保留策略。适合谁一是监控系统、IoT 平台、行情数据这类写入频繁且查询带时间范围的业务二是已经在用 PostgreSQL 但被数据量增长拖垮的团队想在不换库的前提下加一层时序能力。后面我按「先搞懂版本关系 → 三步部署 → 建表验证 → 避坑排查」的顺序讲保证你从下载到跑通第一条查询不会超过半小时。2. 装 TimescaleDB 前必须搞清的事版本、目录结构与那个 zip 的命名规则很多人在解压这个 zip 之前就踩了第一个坑把 zip 当成 PostgreSQL 本体装了或者拿它去配 PostgreSQL 14/15/16。这个压缩包的命名其实已经写清楚了所有关键信息先把它拆开看明白再动手。2.1 文件名里的版本密码postgresql-12 与 2.3.0 分别指什么timescaledb-postgresql-12_2.3.0-windows-amd64这一串字符可以切成四段来读timescaledb扩展名称官方称为「适用于 PostgreSQL 的时间序列数据库」。postgresql-12针对 PostgreSQL 12 编译的版本。TimescaleDB 对 PostgreSQL 主版本有严格绑定同一个扩展的源码在不同 PG 版本下编译出的二进制文件不通用。你如果已经装了 PostgreSQL 14这个包就不能用需要去找timescaledb-postgresql-14的对应版本。2.3.0TimescaleDB 的版本号。2.x 系列最大的变化是把原来 1.x 里独立的timescaledb_tune、timescaledb_scale工具整合进主扩展并且直接支持连续聚合、数据保留、压缩等能力。2.3.0 属于这个系列里比较稳定的一个版本至少在 Windows 上的表现比 2.0/2.1 要稳。windows-amd64平台和架构标记。amd64表示 x86_64 位架构对应绝大多数 Windows 10/11 和 Windows Server 的 64 位安装。如果你用的是 32 位系统这个包装不进去。还有一层隐藏信息zip 格式表示它不需要像 MSI 安装包那样执行交互式安装向导本质是一堆预编译好的 DLL、SQL 脚本和控制文件解压后手动拷贝到 PostgreSQL 的目录里即可。这和 Linux 上apt install timescaledb-postgresql-12装出来的一整套环境不太一样Windows 下更接近于「绿色版插件」。2.2 解压前检查三件事PG 版本、安装路径、权限动手解压之前我建议你先在命令行里确认 PostgreSQL 本体真的可以运行。打开 CMD 或者 Windows Terminal执行psql --version能正常输出版本号才算第一步通过。如果提示psql 不是内部或外部命令那说明 PostgreSQL 没有把bin目录加进系统 PATH或者你根本没装。很多人只下载了 pgAdmin 图形工具却没装数据库服务端这种最容易在最后CREATE EXTENSION时翻车。接着确认你安装的 PostgreSQL 是 12.x。用 psql 连上默认库psql -U postgres -c SHOW server_version;注意-U postgres是默认超级用户Windows 安装时设置的密码要输对。如果这里查出来的版本是 13 或 14那你这个 zip 直接作废去 TimescaleDB 官网找对应版本别硬装。第三步是看安装路径。通常 Windows 下 PostgreSQL 12 装在这个位置C:\Program Files\PostgreSQL\12这个路径下的share\extension是扩展的 SQL 控制文件目录lib是 DLL 存放目录后面拷贝文件要用。如果 PostgreSQL 装在D:\PostgreSQL\12这类非默认路径那你需要记住自己实际的根路径后面所有命令都以它为准。这一步其实没有技术门槛但经常有同事把文件复制到Program Files (x86)下面折腾半天问题就出在没搞清前缀。我给的建议是用一个有道笔记或记事本先写下自己的 PG 安装根路径比如PG_ROOTC:\Program Files\PostgreSQL\12后面每一步都用这个变量去推算路径能省掉大量无效搜索。2.3 Windows 下 zip 安装与 MSI 安装的本质差别PostgreSQL 官方在 Windows 上默认用 EDB 安装器也就是图形化向导那套它会把服务注册写到系统服务管理器里并在注册表中写入数据目录。TimescaleDB 的 zip 包则完全没有注册表行为纯粹是文件拷贝。这两者的定位差异很明显zip 包适合已经在跑 PG 实例、不想为了加扩展重装数据库的人MSI 安装包适合从零起步、愿意让安装向导帮你处理路径和配置的。如果你是新装机器、还没有任何 PostgreSQL 进程我更推荐先装官方 EDB 安装器再用这个 zip 补充扩展如果你已经有一个跑了好久的 PG 服务那 zip 方式是最小侵入的路径。网上也有人用 Docker 方式在 Windows 上跑 TimescaleDB但在生产环境Windows Docker 容器和宿主机共享内核镜像拉取和端口映射都要额外维护如果不是为了临时试验我还是建议直接装原生扩展。3. 三步落地插件文件拷贝、配置加载与 CREATE EXTENSION 验证确认版本匹配后实际的安装动作压缩下来只有三个步骤把文件放进 Postgres 目录、改配置让扩展预加载、执行建扩展 SQL。这三步分别对应对 DLL 的识别、对shared_preload_libraries的依赖、对数据库对象的注册顺序不能乱下面逐个说清楚。3.1 第一步解压并拷贝文件到 PG 的 lib 与 share/extension先解压 zip你会看到里面大致有lib和share两个目录。用文件管理器打开你的 PostgreSQL 12 安装根目录把lib下的 DLL 文件复制到C:\Program Files\PostgreSQL\12\lib把share\extension下的.sql和.control文件复制到C:\Program Files\PostgreSQL\12\share\extension。如果你不确定哪些文件属于扩展直接看文件名带timescaledb前缀的就行。# PowerShell 执行注意替换 $zip 和 $pg_root 为实际路径 $zip D:\downloads\timescaledb-postgresql-12_2.3.0-windows-amd64.zip $pg_root C:\Program Files\PostgreSQL\12 Expand-Archive -Path $zip -DestinationPath D:\timescale_temp Copy-Item D:\timescale_temp\lib\*timescaledb* $pg_root\lib\ -Force Copy-Item D:\timescale_temp\share\extension\*timescaledb* $pg_root\share\extension\ -Force这里有两个细节值得注意。第一C 盘Program Files目录写操作需要管理员权限PowerShell 窗口要以管理员身份运行否则Copy-Item会报Access to the path is denied。第二复制时只筛选名字带timescaledb的文件避免把 zip 里可能携带的同名postgresql.dll之类系统库覆盖掉那个文件版本如果和 PG 12 不匹配会导致整个数据库服务起不来。复制完成后可以验证一下文件是否到位dir C:\Program Files\PostgreSQL\12\lib\*timescaledb*在 CMD 下看lib目录里是否有timescaledb.dll再用dir看share\extension下是否有timescaledb--*.sql一批脚本。如果这两个都有第一步就算完成。3.2 第二步打开 postgresql.conf 修改 shared_preload_librariesTimescaleDB 不能像普通扩展那样在需要时才从磁盘加载它要求数据库进程启动时就把 DLL 预加载进内存。这个行为由postgresql.conf里的shared_preload_libraries参数控制。打开C:\Program Files\PostgreSQL\12\data\postgresql.conf找到这一行#shared_preload_libraries 把它改成shared_preload_libraries timescaledb如果该参数原本已经写了别的库比如pg_stat_statements要改成逗号分隔的列表shared_preload_libraries pg_stat_statements,timescaledb这个参数的修改必须重启 PostgreSQL 服务才会生效。回到 CMD用管理员权限执行net stop postgresql-x64-12 net start postgresql-x64-12如果你的 Windows 服务名不叫postgresql-x64-12可以在服务管理器里搜postgres找到对应名字。为什么必须用共享预加载而不是CREATE EXTENSION时动态加载因为 TimescaleDB 需要注册自定义的 SQL 函数、类型和后台 worker 进程后台 worker 必须在启动时被加载器识别否则CREATE EXTENSION执行到一半会报could not load library timescaledb之类的错。另外要注意改完配置后重启失败的概率不低常见原因是对应 DLL 依赖的 VC 运行库缺失或者文件名被拼错。这个时候先别急着查 postgresql.conf先去 Windows 事件查看器里看 PostgreSQL 日志通常会把 DLL 加载失败的具体原因写在log目录下的postgresql-*.log文件里。日志里看到The specified module could not be found时优先下载对应版本的 VC 2015-2022 Redistributable x64 装掉再做一次服务启动。很多第一次上手的人卡在这一步觉得是扩展文件没放好其实是运行库的问题。3.3 第三步用 psql 执行 CREATE EXTENSION 并验证版本服务重启后打开终端连上你的目标数据库。注意TimescaleDB 是「装库级」的扩展要在哪一个数据库里用就在哪一个库里执行创建。通常我们会建一个专门给时序数据的库CREATE DATABASE iot_data; \c iot_data CREATE EXTENSION IF NOT EXISTS timescaledb;执行成功后用下面的 SQL 确认版本SELECT extversion FROM pg_extension WHERE extname timescaledb;如果输出2.3.0恭喜你基础环境已经通了。这一步执行后还有一个隐藏验证点查看是否弹出了关于telemetry的提示。TimescaleDB 默认开启匿名遥测上报会在首次建库时输出一句提示。在意数据隐私的可以直接关掉ALTER SYSTEM SET timescaledb.telemetry_level off; SELECT pg_reload_conf();这一步做掉之后扩展的基础安装就算结束。很多教程在这里就收尾了但实际生产环境还要确认chunk表空间位置和内存上限这些放到第 5 章避坑里再展开。你可能还会注意到同样的扩展用psql连接本地库和连接远程库时CREATE EXTENSION都会执行成功但远程库需要把timescaledb加到该库的shared_preload_libraries里才能用后台 worker这个坑在后面细说。3.4 参数说明安装涉及的关键路径与配置项一栏对象路径/参数名说明扩展 DLL%PG_ROOT%\lib\timescaledb.dll主二进制文件服务启动时加载控制文件%PG_ROOT%\share\extension\timescaledb.control声明默认版本与依赖SQL 脚本%PG_ROOT%\share\extension\timescaledb--2.3.0.sql建对象用的脚本名称格式与版本绑定服务参数shared_preload_libraries timescaledb必须出现在服务启动参数里运行库VC 2015-2022 x64缺失时 DLL 加载失败遥测参数timescaledb.telemetry_level可设off不影响功能上面的表里%PG_ROOT%指你实际的 PostgreSQL 12 安装根目录比如C:\Program Files\PostgreSQL\12。理解这张表之后排查问题会快很多因为大部分安装失败不是配置语法问题而是文件路径或运行库不对。4. 装完别急着导数据用 hypertable、连续聚合和数据保留验证 2.3.0 的地基扩展能创建成功只代表组件齐全真正验证它值不值得投入要看工作时间负载下的表现。第 4 章用来验证两件核心能力hypertable 建表与查询提速路径以及 2.x 系列主推的连续聚合。顺带把数据保留策略的配置语法跑一遍这三样够覆盖监控类业务 90% 的需求。4.1 建一张带时间分区的普通表为什么要用 time 列做分区键TimescaleDB 的核心抽象是 hypertable它是把一张逻辑表按时间拆成很多物理小表chunk的壳。建表语法和 PostgreSQL 基本一致差别在最后一句用create_hypertable函数把普通表变成超表CREATE TABLE sensor_data ( time TIMESTAMPTZ NOT NULL, device_id INTEGER NOT NULL, temperature REAL, humidity REAL, battery REAL ); SELECT create_hypertable(sensor_data, time, chunk_time_interval INTERVAL 7 days);第一段是普通建表语句字段里必须有时间列第二段是转换函数指定time作为分区键chunk_time_interval参数决定每个 chunk 装多长时间的数据。对于sensor_data这种高频写入的表7 days是一个稳妥起点意味着每 7 天一个物理分片方便按时间快速裁剪。如果采集频率很高比如每秒一条建议把chunk_time_interval缩短到1 day甚至6 hours因为单 chunk 数据量太大时自动分区和后续压缩处理都会变慢。反之低频数据用30 days更合适。这个参数不是写完就固定后续可以用set_chunk_time_interval动态调整SELECT set_chunk_time_interval(sensor_data, INTERVAL 1 day);调整后新生成的 chunk 按新间隔切分已生成的 chunk 不受影响。另外create_hypertable还可以传partitioning_column参数在时间列之外加一列哈希分区比如SELECT create_hypertable(sensor_data, time, partitioning_column device_id, number_partitions 8);对device_id做哈希分片是为了在时间分区之外把不同设备的数据进一步拆到不同 chunk写入并发和并行查询都会受益。但要注意number_partitions一旦设太大chunk 数量会成倍增长元数据开销反而明显实测下来 4 到 8 个是常见范围。生产环境开始前可以先用真实数据量跑一遍用SELECT * FROM chunks_detailed_size(sensor_data)查看每个 chunk 的空间占用再决定要不要加哈希分区。4.2 写一个自动化降采样的连续聚合让 1.5 亿行原始数据不再是查询噩梦时序数据一个典型痛点是原始表动辄上亿行直接GROUP BY date_trunc做报表不是不行但每次都扫全表很浪费。TimescaleDB 2.3.0 的连续聚合机制能让我们把常见的降采样查询变成增量刷新的物化视图。它的配置很简单一个CREATE MATERIALIZED VIEW加一个WITH (timescaledb.continuous)选项CREATE MATERIALIZED VIEW sensor_data_hourly WITH (timescaledb.continuous) AS SELECT time_bucket(1 hour, time) AS bucket, device_id, AVG(temperature) AS avg_temp, MAX(temperature) AS max_temp, MIN(temperature) AS min_temp, COUNT(*) AS sample_count FROM sensor_data GROUP BY bucket, device_id WITH NO DATA;这里有两个关键点。第一聚合函数必须和GROUP BY一起用而且GROUP BY里必须包含time_bucket表达式这是连续聚合的硬要求第二我故意加了WITH NO DATA如果你让它在建视图时立刻回填历史数据大表可能会把前台查询拖垮。WITH NO DATA建完后初始为空后台 worker 会从当前时间开始自动维护历史数据可以通过手动刷新补CALL refresh_continuous_aggregate(sensor_data_hourly, NULL, NULL);refresh_continuous_aggregate的两个时间参数分别代表刷新窗口的起止时间。传NULL, NULL表示全量刷新数据量很大时会跑很久生产环境更常见的是只刷最近两天CALL refresh_continuous_aggregate(sensor_data_hourly, now() - INTERVAL 2 days, now());连续聚合的增量刷新是由后台定时任务完成的默认刷新窗口策略需要单独配置。在 2.3.0 里刷新策略由add_job和alter_job控制通常配置成每小时刷新一次窗口SELECT add_job( refresh_continuous_aggregate, 1 hour, config {continuous_agg:sensor_data_hourly} );这个 job 会把过去一段时间内的新数据增量合并到物化视图里避免每次查报表都扫原始大表。不过在实际使用中我们并不是所有报表都适合连续聚合。比如要查单台设备某分钟内所有原始采样点这属于明细查询该走原始 hypertable 就按时间范围直接查只有按小时聚合、按天聚合这类固定粒度统计才适合做连续聚合主次分清能避免为了一张低频使用的报表维护一堆无用任务。4.3 让超表数据只保留 90 天数据保留策略与压缩的配合时序数据越积越多磁盘迟早要爆。TimescaleDB 2.x 提供add_retention_policy自动删除超过指定时间跨度的 chunkSELECT add_retention_policy(sensor_data, INTERVAL 90 days);这个策略执行后每间隔一段时间会扫描 hypertable把时间范围早于now() - INTERVAL 90 days的 chunk 直接删掉。要说坑就是它删除的粒度是 chunk 而不是单行配合chunk_time_interval使用效果最好——7 天一个 chunk90 天约等于 13 个 chunk每个 chunk 的边界都很清晰。如果你的chunk_time_interval设成 1 天90 天策略就是删 90 个 chunk元数据清理的开销会更大。在删除之前更稳妥的做法是先压缩再删除。压缩是 TimescaleDB 的另一个卖点2.3.0 里对普通 hypertable 的压缩已经成熟ALTER TABLE sensor_data SET ( timescaledb.compress, timescaledb.compress_segmentby device_id, timescaledb.compress_orderby time ); SELECT add_compression_policy(sensor_data, INTERVAL 7 days);compress_segmentby等于device_id会让同一设备的数据在压缩后仍能连续存储解压和查询时对单设备的过滤更高效compress_orderby按时间排序把同一时刻的数据排在一起进一步压缩相邻记录。add_compression_policy则负责每隔一段时间自动把超过 7 天的旧 chunk 压缩。实测下来压缩比通常在 5 到 10 倍之间具体取决于数据重复度。注意add_retention_policy与add_compression_policy同时使用时保留策略的删除动作会自动跳过已经压缩的 chunk 吗答案是不会自动需要把保留时间设置得比压缩策略更长比如压缩 7 天前的数据、删除 90 天前的 chunk这样没有冲突。另外压缩后的 chunk 不是只读的写入新数据时会触发解压再写入然后由后台任务重新压缩所以压缩策略的间隔不能设得太小否则频繁解压压缩会让 CPU 白白空转。4.4 验证表结构两个常用系统视图2.3.0 提供了不少诊断视图日常最常用到的是下面两个SELECT * FROM timescaledb_information.hypertables WHERE hypertable_name sensor_data; SELECT * FROM timescaledb_information.chunks WHERE hypertable_name sensor_data ORDER BY range_start DESC LIMIT 5;第一个视图显示超表的分区列、chunk 间隔、压缩状态第二个显示当前 chunk 的时间范围和空间占用。每次跑完建表或调参数都用这两个视图确认一下状态能少走很多弯路。5. 避坑TimescaleDB 在 Windows 上最常见的 5 个翻车现场这部分都是我实际装环境时踩过或帮别人排查过的场景每一条都按「现象 → 原因 → 解决」写建议按顺序对照排查。5.1 找不到控制文件或扩展不存在现象CREATE EXTENSION timescaledb执行后报extension timescaledb is not available或者could not open extension control file C:/Program Files/PostgreSQL/12/share/extension/timescaledb.control。原因zip 里的share\extension文件没有正确复制到 PG 的共享目录或者路径不匹配。解决回到第 3 章第一步确认.control文件确实在$PG_ROOT/share/extension下。少数情况是 PostgreSQL 装在非 C 盘默认位置而 psql 数据目录由PGDATA环境变量指向另一处看不到实际的扩展目录用SHOW data_directory查询后核对即可。5.2 文件拷进去后 PostgreSQL 服务无法启动现象执行net start postgresql-x64-12后提示服务启动后又停止Windows 事件查看器显示 PostgreSQL 日志报错。原因不止可能是 DLL 本身加载失败还可能是 VC 运行库缺失或者共享预加载参数里拼写错误。解决先看logs\postgresql-*.log里的具体报错。如果日志里出现The specified module could not be found装一遍 VC 2015-2022 Redistributable x64如果出现could not access file timescaledb: No such file or directory回头确认lib路径下 DLL 的名字大小写是否一致Windows 对大小写不敏感但 PostgreSQL 日志里有时不会显示完整路径。另外确认shared_preload_libraries只用逗号分隔不要再加引号或空格。5.3 CREATE EXTENSION 提示版本不匹配现象扩展能建但执行SELECT extversion FROM pg_extension WHERE extnametimescaledb返回空或者提示version 2.3.0与控制文件不匹配。原因你安装的 PostgreSQL 主版本不是 12虽然CREATE EXTENSION可能因为兼容而部分成功但 SQL 脚本和 DLL 不对应。解决重新核对psql --version的输出如果是 13/14/15去官网下载对应主版本的 zip 包别试图用改控制文件版本号的方式绕过通常会导致运行时函数找不到血泪教训。5.4 写入时序数据后磁盘占用飙升压缩策略不生效现象跑了几天后磁盘增长非常快add_compression_policy已配置但chunks视图里旧数据仍是未压缩状态。原因压缩策略默认对最近 N 天数据不动其中 N 是compress_after参数而且如果 chunk 里包含未压缩的写入操作策略会跳过该 chunk。解决先确认策略配置SELECT * FROM timescaledb_information.jobs WHERE proc_namepolicy_compression;如果 job 存在但从未执行多半是后台调度器没跑起来检查timescaledb.background_workers配置。也可以手动压缩一个旧 chunk 验证压缩功能本身SELECT compress_chunk(_timescaledb_internal._hyper_1_1_chunk);如果手动压缩可以说明策略时间窗口没到如果手动压缩也报错优先检查字段类型和压缩参数。另外注意compress_segmentby里的列不能有 NULL 值太多否则压缩收益极低。5.5 查询变慢甚至出现内存不足现象hypertable 建好后单条时间范围查询第一次执行很快后续某些跨大范围查询响应要几十秒多并发场景下 PostgreSQL 进程内存持续偏高。原因时序查询通常会按时间范围扫描大量 chunk如果chunk_time_interval设得过大单个 chunk 体积很大查询裁剪和并行调度都受影响Windows 下共享缓冲区shared_buffers默认值偏保守内存放大效应明显。解决把chunk_time_interval调小比如 1 天或 6 小时并把shared_buffers调到物理内存的 25% 左右比如 16G 内存设4GB同时把effective_cache_size设为物理内存的 50% 到 75%。调完参数记得重启服务然后用EXPLAIN (ANALYZE, BUFFERS)看是否命中Append后只扫描目标 chunk。这个调优过程没有银弹但把 chunk 粒度降下来是投入产出比最高的做法。6. 验证与进阶用系统视图确认安装成果在真实监控场景里做一次端到端跑通如果你已经跑通了前面所有步骤现在可以用一个真实小型监控场景做最后的端到端演练。假设我们有一批传感器每秒上报一次温度需要保留最近 90 天数据并按小时做一次降采样监控报表。目标是把安装、建表、写入、聚合、清理这一整条链路完整验证一遍顺便确认 2.3.0 在 Windows 上各项后台任务能正常调度。第一步确认后台任务和工作进程都在正常运行SELECT * FROM timescaledb_information.jobs; SELECT count(*) FROM pg_stat_activity WHERE backend_type LIKE timescaledb%;如果pg_stat_activity里没有 TimescaleDB 的后台进程说明timescaledb没有被共享预加载回去查第 3 章的配置。第二步模拟写入 100 万行数据并测试时间范围裁剪INSERT INTO sensor_data (time, device_id, temperature, humidity, battery) SELECT now() - (random() * INTERVAL 100 days), (random() * 100)::int, 20 random() * 15, 40 random() * 30, 80 random() * 20 FROM generate_series(1, 1000000);注意这里random()生成的时间会横跨 100 天如果你的保留策略是 90 天那么多余 10 天的数据会在下一次策略调度时被清掉正好可以用来验证自动清理。第三步查连续聚合视图看数据能否在几秒内返回SELECT bucket, device_id, avg_temp, sample_count FROM sensor_data_hourly WHERE bucket now() - INTERVAL 24 hours ORDER BY bucket DESC LIMIT 20;如果历史刷新还没执行先调用refresh_continuous_aggregate补一次全量刷新。这一步能验证 2.3.0 的连续聚合实现在 Windows 上是否稳定。我见过有版本在 Windows 下连续聚合刷新任务偶发卡死如果 24 小时内没有新数据进入视图检查timescaledb_information.jobs里对应 job 的last_run_status失败的话手动刷新一次并把 job 调度间隔拉大通常能缓解。第四步看 chunk 分布和空间占用做最后的容量预判SELECT range_start, range_end, pg_size_pretty(total_bytes) AS total FROM chunk_compression_stats(sensor_data) LIMIT 10;chunk_compression_stats会把已经压缩和未压缩的 chunk 都列出来通过它确认 7 天前的 chunk 是否按计划落盘为压缩态。这个视图在生产排障中出镜率很高建议记下来。最后给你一个我自己的教训刚上手 TimescaleDB 时总想把所有参数一次调到位结果chunk_time_interval调小了又调大压缩策略和保留策略冲突折腾了一整晚。后来养成的习惯是把所有策略配完后模拟跑一批旧数据进去然后等 24 小时看后台 job 的实际执行情况。Windows 下 TimescaleDB 的调度没有 Linux 上那么激进首次部署多留一天观察期比较稳妥。希望这套从 zip 安装包到端到端验证的路径能帮你少走一段弯路。本文还有配套的精品资源点击获取
