如果你正在用 TDengine 做设备采集或指标存储,写入吞吐上不去几乎是第一个绕不过去的问题。这篇文章从用户实际会遇到的场景出发,讲清楚 TDengine 写入路径上真正影响性能的几个环节,以及对应的调优方法。所有结论都对照了 TDengine 社区版源码进行了核实。场景一:还在用 INSERT 语句拼 SQL 写数据很多用户最初接入 TDengine 时,是用普通 SQL(INSERT INTO ... VALUES ...)拼接后发给服务端。数据量小的时候没问题,但设备一多、频率一高,就会发现 CPU 和网络都跑不满,吞吐却上不去。原因很直接:每一条拼出来的 SQL 都要走一次完整的解析(parse)流程,文本转换成二进制再落盘的过程也有额外开销。TDengine 提供的STMT2(参数绑定写入)接口就是为了避免这些重复开销而设计的:SQL 只在第一次绑定时解析一次,后续绑定复用已经生成的执行计划,不再重复解析 SQL 文本。支持列式绑定(taos_stmt2_bind_param_column),数据按列整块传给驱动,而不是一行一行地做类型转换,减少了逐行转换的开销。客户端在发送前会把要写入的数据按目标 vgroup 分组打包,一次网络请求里可以携带多张表、多行数据,而不是一行一个请求。绑定过程还支持异步线程执行,不占用调用方主线程。建议:如果你的写入端是自己写的采集程序(C/Java/Python/Go 等连接器都支持),优先用 STMT2 而不是拼 SQL 字符串,这是提升写入吞吐最直接的一步。场景二:批量写,但批大小怎么定TDengine 客户端对单次插入的行数有一个可配置上限(配置项maxInsertBatchRows,默认 100 万行)。实际使用中不需要冲到这个上限,更常见的问题是批太小——每批几十上百行,网络往返次数太多,吞吐被攒批的开销吃掉。建议:用 taosBenchmark 先做一次基准测试,观察不同批大小(比如 1000、5000、20000 行)下的吞吐曲线,找到吞吐不再明显提升的拐点,作为生产环境的批大小参考,不必迷信越大越好。场景三:WAL 配置不清楚,不知道该在安全和速度之间怎么选建库时的WAL_LEVEL和WAL_FSYNC_PERIOD两个参数,直接决定了写入确认和磁盘落盘之间的关系:WAL_LEVEL 0:不写 WAL,最快,但完全没有断电/宕机保护,一般不建议生产使用。WAL_LEVEL 1:写 WAL,但不强制 fsync,由操作系统按自己的节奏把页缓存刷到磁盘——性能和安全性的折中,也是最常用的选择。WAL_LEVEL 2:写 WAL 并强制 fsync,是否每次写都强制刷盘取决于WAL_FSYNC_PERIOD:设为 0 表示每次写都强制 fsync(最安全,最慢);设一个大于 0 的值(比如几秒)则是周期性 fsync,把多次写的落盘开销摊薄,吞吐会明显好转,但极端宕机情况下可能丢失这个周期内的少量数据。建议:如果业务对数据丢失容忍度不是零(多数监控、IoT 场景是这样),用WAL_LEVEL 1,不需要额外调 fsync 周期。如果必须保证确认写入落盘,用WAL_LEVEL 2并根据可接受的丢失窗口调大WAL_FSYNC_PERIOD,不要一律设成 0。场景四:加了机器/加了线程,写入速度没涨TDengine 的并发写入能力是建立在 vgroup(虚拟节点组)之上的:每个 vgroup 内部的写入是严格按顺序串行执行的(可以理解成一个车道),但不同 vgroup 之间是相互独立、可以并行处理的。也就是说,如果你的库只建了 1~2 个 vgroup,不管客户端开多少个写入线程,最终都会挤到同样几条车道上,吞吐自然涨不上去。建议:建库时通过VGROUPS参数规划足够的 vgroup 数量(具体数值要结合子表数量、机器规格和后续扩容计划评估,不是越多越好)。写入端开多线程时,尽量让不同线程覆盖不同的子表/vgroup,而不是所有线程挤在同一批表上。taosBenchmark 内部就是按 vgroup 对线程做任务分配的,可以参考它的思路设计自己的写入程序。场景五:担心乱序写入会拖慢速度时序数据难免会有迟到的数据点(比如网络抖动导致某条数据晚到)。TDengine 本身支持乱序写入,这是时序数据库的常见需求。需要说明的是,关于乱序写入是否会带来额外性能损耗这一点,本次源码核实没有找到明确的、独立的乱序惩罚机制的实现证据(只在 taosBenchmark 测试工具里发现了模拟乱序写入的选项,用于压测),所以这里不做绝对断言。从工程经验出发,还是建议采集端尽量按时间顺序上报数据,更有利于底层数据的组织和后续压缩效果,但不必对少量乱序过度紧张。小结写入性能问题很少是单一原因,建议按这个顺序排查:先看是不是还在用普通 SQL 写入(换成 STMT2),再看批大小和 vgroup 数量是否匹配写入并发度,最后根据业务对数据安全的要求确认 WAL 配置是否求快过了头或者求稳过了头。