如果需要(yao)對數據庫性能(neng)優化，了解數據文件(jian)的存儲方式和(he)工(gong)作(zuo)原(yuan)理是必要(yao)的。
對于時序數據庫（Time Series Database） TDengine 來說，在 2.x 版本中時(shi)序(xu)數據(ju)(ju)的保(bao)留策略(lve)是由keep和(he)days這兩個參數把控的。（詳情可(ke)見：《》）我們(men)通過 keep 和(he) days 來對時(shi)序(xu)數據(ju)(ju)進行分段保(bao)留，而(er)每一段時(shi)間(jian)的數據(ju)(ju)就可(ke)以便對應著(zhu)數據(ju)(ju)庫(ku)中數據(ju)(ju)vnode目錄下的一組數據(ju)(ju)文件，也就是我們(men)這篇文章的主角。
在(zai)(zai) 3.0 版本中，此處(chu)邏輯保持一致，只是(shi)(shi)為了更好的(de)體現(xian)“每一段時間(jian)的(de)數(shu)據”，我們把 “days” 參(can)數(shu)更名為了“duration”。而上(shang)文提到的(de)一個數(shu)據文件(jian)組，在(zai)(zai) 2.x 版本中是(shi)(shi)這個樣子的(de)，他們代(dai)表了 vnode24 中所(suo)有表在(zai)(zai)某 10 天（days 默認參(can)數(shu)值）內的(de)所(suo)有數(shu)據，關于(yu)這些文件(jian)的(de)具(ju)體含義可(ke)以參(can)考文章：《》
在 2.x 的(de)后期版(ban)本中(zhong)，為了提升預計算（sum、max、min）的(de)性能，又(you)把(ba) .data/.last 文(wen)(wen)件中(zhong)所有數據塊的(de)預計算結(jie)果抽離出來(lai)形成(cheng)了 smad/smal 文(wen)(wen)件，于是文(wen)(wen)件組(zu)變成(cheng)了如下(xia) 5 個文(wen)(wen)件：
到了 3.0 版本(ben)中，這個數據文件組繼(ji)續演變(bian)成了下圖這樣的(de)形態。那么，他們有哪些具體的(de)變(bian)化(hua)呢？
1.數據文件（.data）
其中，.data類文件邏輯保持不變(bian)，存儲的(de)是實際入庫的(de)時序數(shu)(shu)據(ju)，為多個數(shu)(shu)據(ju)塊構(gou)成。一(yi)(yi)個數(shu)(shu)據(ju)塊只(zhi)屬于(yu)一(yi)(yi)張表，除此之外，每(mei)一(yi)(yi)個數(shu)(shu)據(ju)塊也都記錄著預計算(suan)(suan)中的(de)行數(shu)(shu)數(shu)(shu)據(ju)，屬于(yu)預計算(suan)(suan)中的(de)count 函數(shu)(shu)計算(suan)(suan)結果。
2.索引文件（.head）
.head 文(wen)件(jian)(jian)和此前邏輯(ji)保持不(bu)變，存儲的(de)是(shi) .data 文(wen)件(jian)(jian)中數(shu)據(ju)塊(kuai)的(de)索引信息(xi)。查詢請求(qiu)正是(shi)通(tong)過這(zhe)些索引信息(xi)，來迅速定位表(biao)，定位時間范圍，從而在 .data 文(wen)件(jian)(jian)中找到(dao)對應的(de)數(shu)據(ju)返回給用戶。
3.預計算文件（.sma）
.sma 文件(jian)：存儲數據塊(kuai)中每列數據預計(ji)算(suan)數據的文件(jian)。文件(jian)中只存儲了 .data 文件(jian)中數據塊(kuai)的預計(ji)算(suan)。預計(ji)算(suan)是為了加(jia)速查(cha)詢，盡可能避(bi)免從硬盤中讀取原始數據。.sma 等于 2.x 后期版(ban)本(ben)中的 smad 文件(jian)，而 smal 則被移(yi)除了。
4.碎片文件（.stt）
.stt 文件(jian)則是(shi)取代(dai)了 2.x 版本的(de)(de)(de) .last 文件(jian)，他(ta)們的(de)(de)(de)大體功(gong)能(neng)保(bao)持一(yi)致(zhi)，簡單來說就是(shi)保(bao)存每一(yi)張(zhang)表從(cong)內存落(luo)盤(pan)到磁盤(pan)時的(de)(de)(de)碎片(pian)數據（小于 minrows），但(dan)是(shi)他(ta)們的(de)(de)(de)運行機(ji)制有了一(yi)些區(qu)別：
在 2.x 版本(ben)中，當(dang).last文(wen)件小于(yu)32k的時候，即便是(shi)當(dang)中某表的碎片數據(ju)已經滿足行(xing)數（大(da)于(yu)等于(yu) minrows）要求合并到了(le)(le).data文(wen)件，但是(shi).last 文(wen)件仍然(ran)只是(shi)會被追加寫入，而并不會清(qing)理掉(diao)這部分數據(ju)，該 32k 的限制是(shi)為了(le)(le)防止對文(wen)件頻繁的操(cao)作影響性能。
而到了 3.0 的(de)(de)時候(hou)，在(zai) .stt 文(wen)(wen)(wen)件(jian)(jian)中(zhong)(zhong)，屬于(yu)同一(yi)(yi)個(ge)超級表(biao)的(de)(de)數據會(hui)(hui)存(cun)儲在(zai)同一(yi)(yi)個(ge)數據塊中(zhong)(zhong)，且(qie)數據塊中(zhong)(zhong)的(de)(de)數據按照 （uid（表(biao)的(de)(de)唯一(yi)(yi)標識）, timestamp, version）遞增(zeng)排列。每次(ci)落盤(pan)，數據文(wen)(wen)(wen)件(jian)(jian)組都(dou)會(hui)(hui)生成一(yi)(yi)個(ge)新(xin)的(de)(de) stt 文(wen)(wen)(wen)件(jian)(jian)，用來放本(ben)次(ci)落盤(pan)中(zhong)(zhong)的(de)(de)散碎數據。當 .stt 文(wen)(wen)(wen)件(jian)(jian)個(ge)數超過一(yi)(yi)定的(de)(de)閾值 （由建庫參數：stt_trigger?控制），則首先將(jiang)多個(ge) .stt 文(wen)(wen)(wen)件(jian)(jian)的(de)(de)碎片數據合并后，就會(hui)(hui)根據實際情(qing)況(kuang)來決定寫入 .data 文(wen)(wen)(wen)件(jian)(jian)，或寫入新(xin)的(de)(de) .stt 文(wen)(wen)(wen)件(jian)(jian)中(zhong)(zhong)。
5.性能影響：
在(zai)刨除(chu)函數(shu)(shu)本(ben)身的(de)性(xing)能(neng)問(wen)題(ti)，和(he)數(shu)(shu)據(ju)本(ben)身質量問(wen)題(ti)（如數(shu)(shu)據(ju)版(ban)本(ben)過多），硬件資源(yuan)不足(zu)問(wen)題(ti)，數(shu)(shu)據(ju)建模不科學等因素之外(wai)。上(shang)述(shu)幾個數(shu)(shu)據(ju)文(wen)件的(de)配置對數(shu)(shu)據(ju)庫性(xing)能(neng)的(de)影響是(shi)根本(ben)性(xing)的(de)。
整體(ti)的性能影響因素包括：
一. 關于 .data 文(wen)件，它的工作原理，整體上仍可以參考：《》
二. 關于(yu) .head 文件，它記錄(lu)的(de)(de)是.data 文件中數據(ju)塊的(de)(de)索(suo)引，因此(ci)數據(ju)塊的(de)(de)數量(liang)會(hui)直(zhi)接(jie)影(ying)響(xiang)索(suo)引塊的(de)(de)數量(liang)，也(ye)就會(hui)直(zhi)接(jie)影(ying)響(xiang)到查(cha)詢性能，細(xi)節(jie)可(ke)以參考這篇文章：
三. 關于(yu) .stt 文件，記錄的是碎片化(hua)數據(ju)，對于(yu)性能的影響因素大致如下：
- 數據庫級別 buffer 參數 (2.x 中，cache 和 block 的乘積) 的設置是否合理，如果buffer過小，導致落盤數據行數少，便會形成大量碎片影響性能。相對的，如果表過寬，導致單行數據過大，同樣會導致落盤行數變少，同樣影響性能，兩者原理相同。
- minrows 設置過大，符合標準的數據塊變少，導致碎片增多。
- 關于上文的 STT_TRIGGER 這個參數 ：它代表觸發 .stt 文件合并時的個數。默認為 1，范圍 1 到 16。對于少表高頻寫入頻繁觸發落盤的場景，此參數建議使用默認配置，或較小的值；而對于多表場景，此參數建議配置較大的值。核心思想是會經常合并size較大的 .stt 會比較浪費磁盤io影響寫入。
四(si). 關于 .sma 文(wen)件，預計算的(de)聚合查詢性能主要受 .sma 文(wen)件大小所影(ying)響。所以表寬/buffer/minRows/maxRows 參數都會影(ying)響，具體(ti)優化邏輯(ji)可(ke)以結合上述內容反(fan)復(fu)調試(shi)。
性(xing)能(neng)調優(you)是十(shi)分復雜的(de)工作，尤(you)其是對于場(chang)景(jing)特殊(shu)，比如寬列(lie)、多表、并發、大字(zi)段等(deng)情況(kuang)，各有不同(tong)的(de)優(you)化思路(lu)。開源(yuan)版用戶可(ke)以(yi)結(jie)合文章(zhang)與文檔進行調試，企業版用戶可(ke)以(yi)直接由TDengine 團(tuan)隊協助定制部署、以(yi)及后面持(chi)續的(de)運(yun)維和性(xing)能(neng)優(you)化工作。
