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

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

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

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

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

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

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

2.索引文件（.head）

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

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

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

4.碎片文件（.stt）

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

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

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

5.性能影響：

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

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

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

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

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

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

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

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