如果需要對數(shù)據(jù)庫性能優(yōu)化，了解數(shù)據(jù)文件的存儲方式和工作原理是必要的。

對于時序數(shù)據(jù)庫（Time Series Database） TDengine 來說，在 2.x 版本中時序數(shù)據(jù)的保留策略是由keep和days這兩個參數(shù)把控的。（詳情可見：《五分鐘掌握TDengine時序數(shù)據(jù)的保留策略》）我們通過 keep 和 days 來對時序數(shù)據(jù)進(jìn)行分段保留，而每一段時間的數(shù)據(jù)就可以便對應(yīng)著數(shù)據(jù)庫中數(shù)據(jù)vnode目錄下的一組數(shù)據(jù)文件，也就是我們這篇文章的主角。

在 3.0 版本中，此處邏輯保持一致，只是為了更好的體現(xiàn)“每一段時間的數(shù)據(jù)”，我們把 “days” 參數(shù)更名為了“duration”。而上文提到的一個數(shù)據(jù)文件組，在 2.x 版本中是這個樣子的，他們代表了 vnode24 中所有表在某 10 天（days 默認(rèn)參數(shù)值）內(nèi)的所有數(shù)據(jù)，關(guān)于這些文件的具體含義可以參考文章：《五分鐘掌握TDengine數(shù)據(jù)文件的工作原理》

在 2.x 的后期版本中，為了提升預(yù)計算（sum、max、min）的性能，又把 .data/.last 文件中所有數(shù)據(jù)塊的預(yù)計算結(jié)果抽離出來形成了 smad/smal 文件，于是文件組變成了如下 5 個文件：

到了 3.0 版本中，這個數(shù)據(jù)文件組繼續(xù)演變成了下圖這樣的形態(tài)。那么，他們有哪些具體的變化呢？

1.數(shù)據(jù)文件（.data）

其中，.data類文件邏輯保持不變，存儲的是實(shí)際入庫的時序數(shù)據(jù)，為多個數(shù)據(jù)塊構(gòu)成。一個數(shù)據(jù)塊只屬于一張表，除此之外，每一個數(shù)據(jù)塊也都記錄著預(yù)計算中的行數(shù)數(shù)據(jù)，屬于預(yù)計算中的count 函數(shù)計算結(jié)果。

2.索引文件（.head）

.head 文件和此前邏輯保持不變，存儲的是 .data 文件中數(shù)據(jù)塊的索引信息。查詢請求正是通過這些索引信息，來迅速定位表，定位時間范圍，從而在 .data 文件中找到對應(yīng)的數(shù)據(jù)返回給用戶。

3.預(yù)計算文件（.sma）

.sma 文件：存儲數(shù)據(jù)塊中每列數(shù)據(jù)預(yù)計算數(shù)據(jù)的文件。文件中只存儲了 .data 文件中數(shù)據(jù)塊的預(yù)計算。預(yù)計算是為了加速查詢，盡可能避免從硬盤中讀取原始數(shù)據(jù)。.sma 等于 2.x 后期版本中的 smad 文件，而 smal 則被移除了。

4.碎片文件（.stt）

.stt 文件則是取代了 2.x 版本的 .last 文件，他們的大體功能保持一致，簡單來說就是保存每一張表從內(nèi)存落盤到磁盤時的碎片數(shù)據(jù)（小于 minrows），但是他們的運(yùn)行機(jī)制有了一些區(qū)別：

在 2.x 版本中，當(dāng).last文件小于32k的時候，即便是當(dāng)中某表的碎片數(shù)據(jù)已經(jīng)滿足行數(shù)（大于等于 minrows）要求合并到了.data文件，但是.last 文件仍然只是會被追加寫入，而并不會清理掉這部分?jǐn)?shù)據(jù)，該 32k 的限制是為了防止對文件頻繁的操作影響性能。

而到了 3.0 的時候，在 .stt 文件中，屬于同一個超級表的數(shù)據(jù)會存儲在同一個數(shù)據(jù)塊中，且數(shù)據(jù)塊中的數(shù)據(jù)按照 （uid（表的唯一標(biāo)識）, timestamp, version）遞增排列。每次落盤，數(shù)據(jù)文件組都會生成一個新的 stt 文件，用來放本次落盤中的散碎數(shù)據(jù)。當(dāng) .stt 文件個數(shù)超過一定的閾值 （由建庫參數(shù)：stt_trigger?控制），則首先將多個 .stt 文件的碎片數(shù)據(jù)合并后，就會根據(jù)實(shí)際情況來決定寫入 .data 文件，或?qū)懭胄碌?.stt 文件中。

5.性能影響：

在刨除函數(shù)本身的性能問題，和數(shù)據(jù)本身質(zhì)量問題（如數(shù)據(jù)版本過多），硬件資源不足問題，數(shù)據(jù)建模不科學(xué)等因素之外。上述幾個數(shù)據(jù)文件的配置對數(shù)據(jù)庫性能的影響是根本性的。

整體的性能影響因素包括：

一. 關(guān)于 .data 文件，它的工作原理，整體上仍可以參考：《五分鐘掌握TDengine數(shù)據(jù)文件的工作原理》

二. 關(guān)于 .head 文件，它記錄的是.data 文件中數(shù)據(jù)塊的索引，因此數(shù)據(jù)塊的數(shù)量會直接影響索引塊的數(shù)量，也就會直接影響到查詢性能，細(xì)節(jié)可以參考這篇文章：TDengine 3.0.2.5 查詢再優(yōu)化！揭秘索引文件的工作原理

三. 關(guān)于 .stt 文件，記錄的是碎片化數(shù)據(jù)，對于性能的影響因素大致如下：

1. 數(shù)據(jù)庫級別 buffer 參數(shù) (2.x 中，cache 和 block 的乘積) 的設(shè)置是否合理，如果buffer過小，導(dǎo)致落盤數(shù)據(jù)行數(shù)少，便會形成大量碎片影響性能。相對的，如果表過寬，導(dǎo)致單行數(shù)據(jù)過大，同樣會導(dǎo)致落盤行數(shù)變少，同樣影響性能，兩者原理相同。
2. minrows 設(shè)置過大，符合標(biāo)準(zhǔn)的數(shù)據(jù)塊變少，導(dǎo)致碎片增多。
3. 關(guān)于上文的 STT_TRIGGER 這個參數(shù) https://docs.taosdata.com/taos-sql/database/：它代表觸發(fā) .stt 文件合并時的個數(shù)。默認(rèn)為 1，范圍 1 到 16。對于少表高頻寫入頻繁觸發(fā)落盤的場景，此參數(shù)建議使用默認(rèn)配置，或較小的值；而對于多表場景，此參數(shù)建議配置較大的值。核心思想是會經(jīng)常合并size較大的 .stt 會比較浪費(fèi)磁盤io影響寫入。

四. 關(guān)于 .sma 文件，預(yù)計算的聚合查詢性能主要受 .sma 文件大小所影響。所以表寬/buffer/minRows/maxRows 參數(shù)都會影響，具體優(yōu)化邏輯可以結(jié)合上述內(nèi)容反復(fù)調(diào)試。

性能調(diào)優(yōu)是十分復(fù)雜的工作，尤其是對于場景特殊，比如寬列、多表、并發(fā)、大字段等情況，各有不同的優(yōu)化思路。開源版用戶可以結(jié)合文章與文檔進(jìn)行調(diào)試，企業(yè)版用戶可以直接由TDengine 團(tuán)隊協(xié)助定制部署、以及后面持續(xù)的運(yùn)維和性能優(yōu)化工作。