在时序数据库场景下，乱序数据的定义为：“时间戳（timestamp）不按照递增顺序到达数据库的数据。”虽然它的定义很简单，但时序数据库需要有相应的处理逻辑来保证数据存储时的顺序性，这势必会增加数据库架构的复杂性，从而影响数据库的性能表现。
已知完全乱序的数据处理是业界的难题，因此 TDengine 需要重点解决的问题应该是——从实际的业务场景出发，如何对偶发乱序数据的进行高效处理（比如设备损坏断电，网络异常，数据补录等问题）。
TDengine 的数据流向是：硬盘（WAL）→ 内存（Vnode Buffer）→ 硬盘（Data File）。
在 WAL 中，我们记录的是数据到达数据库的顺序，但是数据入库后，是一定要保证时间戳的有序的。因此，乱序数据的处理发生在写入 WAL 后的两个阶段：
基于以上逻辑，我们对乱序数据分为两类：
一. 内存乱序数据：在同一张表的范畴内，指时间戳与内存数据的时间范围相交的数据。
二. 硬盘乱序数据：在同一张表的范畴内，指时间戳与硬盘数据的时间范围相交的数据。
对于类型一的乱序数据，TDengine 会在内存中通过为每张表建立一个跳表结构做好排序，从而解决问题。
场景： 创建某表后，我们写入了从 1970 年到 2023 年的一小批数据（由于数据量较少不足以触发落盘）。当我们再写入一条 1998 年时间戳的乱序数据时，会由跳表进行排序，排序后数据在内存中以“1970-1998-2023”的顺序有序存在。该排序操作的成本由写入操作承担，但由于内存中保留的只是极少数数据，因此影响极小。
当来到落盘阶段时（落盘的细节可参考：文章：与 TDengine 性能直接相关——3.0 的落盘机制优化及使用原则），这三条有序的数据，又都有可能成为乱序数据的存在——即类型二：
首先，我们交代一下硬盘上数据文件的设计背景：由于 TDengine 通过建库参数 duration(days) 做数据分区，假设某库 duration 设置为 10 日，那么自打 1970 年 1 月 1 日 0 时起，每隔 10 天就会划分一个数据文件组。写入的数据时间戳归属于哪个时间范围，便会写入哪个数据文件组中——即每个数据文件组中都包含了固定时间范围内的数据。而这些数据以数据块的形式存在，每个数据块所包含的时间范围视落盘时实际情况而定。
落盘时，数据会各自找到自己所属的数据文件组，根据该数据文件组中已有的数据块的时间范围计算，来判断数据的乱序与否。由此，会衍生出各种不同的情况。我们选出属于 2023、1998、1970 年份的三条数据，分别举例三种情况：
- “2023-01-01 xxxxxxx” 这条数据落盘时，并没有和这个表的任何数据块的产生时间交集——也就是非乱序的正常数据。
- “1998-01-01 xxxxxxxx”：这条数据落盘时虽然和该表的整体时间范围（1970–2023）产生交集，但是局部时间范围内没有和该表任何数据块产生交集。这种乱序通常发生于历史数据的数据补录。比如：被采集的设备断电很久后恢复使用。因此这条数据虽然看似乱序，但实际上和正常数据差别不大。
- “1970-01-01 xxxxxxxx” ，这条数据在落盘时和该表数据块的时间范围产生了交集：早在 2.0 当中，如果落盘时的数据和已有数据块时间戳相交的时候，乱序数据会形成一个子块追加在数据文件中，查询时需要把子块的数据读到内存中再做排序，当子块比较多的时候就会影响查询性能——经过重新设计后，在 3.0 当中乱序数据和原有数据将会合并重写为新的数据块，以追加的方式写入数据文件中并且重写索引，而旧的数据块则被视为碎片文件。这样一来，处理数据的成本就被转嫁给了落盘操作，因此对后续的查询基本没有影响。
综上，在乱序数据写入硬盘的时候，由于数据块和索引文件均是新生成的，因此它对于后续的查询是比较友好的。考虑到乱序数据一定是业务上的偶发场景，因此这样处理基本不会造成性能负担。即便是产生了少部分由于乱序带来的碎片数据、无效数据块也都可以由企业版功能 compact 清除或者重组。
从很多角度来说，TDengine 3.0 都已经达成了长足的优化。因此随着 2.0 时代逐步进入尾声，我们也希望大家可以尽早从 2.0 切换到 3.0 之上：《如何把数据从 TDengine 2.x 迁移到 3.x ？》。
