組表是集算器提供的高效能儲存格式，其原理在於將資料事先排序並以壓縮方式緊緻儲存，好處是占用空間更小，可利用有序進行快速定位。
但這種儲存方式在資料更新時會遇到麻煩，這是因為新資料也要和歷史資料一起排序並壓縮，常常會要求重寫整個組表，重寫操作非常耗時，但又不得不做。
不過，有些場景下卻有高效能的資料更新手段，我們來看一下。
尾部更新
我們知道，組表允許修改少量資料。但修改量積累較多時，就要做一下reset（重整），否則會影響運算效能（因為修改部分無法緊緻壓縮儲存，細節原理可參考其它文件）。
但是reset動作相當於重寫整個組表，在組表很大時就會花費大量時間。有沒有更快的手段呢？
如果組表中修改的記錄都是近期的（鍵順序靠後），則重整組表時可以使用reset@q，能夠大幅度減少重整時間。
原理如下：
如前所述，組表資料分成了兩個區域：緊緻且高效的正文區、鬆散且低效的補充區，修改的資料只存放在補充區，並不會改動正文區。執行reset時將重寫整個檔案，把補充區資料和正文區合併。而reset@q時，組表會先在正文區找到重整位置（補充區中最早被修改的記錄位置），將該位置之後的資料與補充區合併整理就可以了。
比如組檔案以時間為鍵，儲存了1-12月的資料，其中12月份的資料有改動。執行reset@q時，不會動前11月的資料，只將12月份的正文區資料和補充區合併，在重整過程中，只涉及12這1個月的資料。
如果不用@q選項，組表在reset時會把1-12月資料全部重寫一遍，涉及12個月的資料，時間就會長很多。
非時間排序資料
按賬戶查詢歷史記錄是很常見的需求，我們只需把資料按帳戶排序，就能獲得較好的查詢效能，即使併發較多也可以支援。
比如下面**，將歷史報稅單按帳戶排序並生成組表：
然後基於這個有序的組表，按帳戶查詢就能獲得很好的效能：
但是，生產系統會源源不斷產生新增資料，而這些新增資料卻不是按賬戶排序的（一般來講會按產生時間為序）。如果要將新增資料也加入到歷史中，就需要將兩者歸併排序。
那麼，有什麼好辦法能減少歸併排序的時間，從而提高資料更新的效能呢？
使用組表檔案組可以解決該問題。
檔案組原理是將多個同構檔案模擬成乙個檔案，該檔案在邏輯上可當作普通檔案使用，即支援普通檔案所有的函式。特別地，檔案組還支援自動歸併。我們可以把資料分為歷史組表和增量組表兩個檔案，查詢時使用這兩個檔案構成的檔案組，這相當於對乙個組表進行查詢。每次定時更新時只對增量組表做小歸併，這樣可以提高日常更新的效能。而積累到一定程度後，才將增量組表和歷史組表做一次大歸併。
實現業務計算時，可將歷史組表與增量組表在邏輯上合併，以檔案組的形式進行查詢，其效能和單一組表檔案相差不大。**如下：
效能優化技巧 組表資料更新
組表是集算器提供的高效能儲存格式，其原理在於將資料事先排序並以壓縮方式緊緻儲存，好處是占用空間更小，可利用有序進行快速定位。但這種儲存方式在資料更新時會遇到麻煩，這是因為新資料也要和歷史資料一起排序並壓縮，常常會要求重寫整個組表，重寫操作非常耗時，但又不得不做。不過，有些場景下卻有高效能的資料更新手...
mysql批量更新資料 效能優化
最近做的遊戲，上線後出了不少問題，所以我就經常去查資料庫資料，翻各種日誌等，但是在查詢的時候發現好蛋疼，有些地方的時間是寫 2016 08 11 20 13 02 這種格式，有些地方的時間是寫 1470917582000 這種格式，然後多張表資料進行對比的時候就很蛋疼，我得不停進行時間轉換，噁心得不...
Mysql更新效能優化 MySQL效能優化
效能優化是通過某些有效的方法來提高mysql的執行速度，減少占用的磁碟空間。效能優化包含很多方面，例如優化查詢速度，優化更新速度和優化mysql伺服器等。本文介紹方法的主要有 優化查詢 優化資料庫結構 優化mysql伺服器 資料庫管理人員可以使用show status語句來查詢mysql資料庫的效能...