業(yè)務(wù)需求與現(xiàn)狀
- 大數(shù)據(jù)量的表，如幾千萬條記錄
- 業(yè)務(wù)需求伦籍，在該表加字段蓝晒，實際業(yè)務(wù)用不到，僅統(tǒng)計時需要用帖鸦；而且時不時的會有不同的這種字段需求添加拔创；實際上可以跨庫去取的字段，但是統(tǒng)計側(cè)存在跨庫不方便的情況富蓄，只能擴展添加字段剩燥。
問題
大數(shù)據(jù)量的表，執(zhí)行ddl立倍，alert列時會有鎖表的問題灭红。
思路1：采用json存儲
- 問題：varchar(255)，存儲的字符串長度也有限口注，存json字符串的話变擒，字段也有限；如果是Text會占用數(shù)據(jù)庫空間太多的問題寝志；
- 好處：可讀清晰娇斑，容易擴展
- 缺點：占用空間大，效率低
思路2: 采用二進制存儲
BIT（64）最多64位材部，tinyblob的話應(yīng)該更多(好像用于位運算很繁瑣)
2.1
如第一位用來存儲毫缆，是否單抽/十抽
后續(xù)如果有新的類型加入，比如五抽, 可以繼續(xù)約定第x位為改類型的字段
2.2
最好還是預(yù)留一些位乐导，方便擴展苦丁，連續(xù)的位計算更方便，但是總會存在超過預(yù)留位的場景
2.3
N+1位物臂，固定的一位用于擴展旺拉；如果是0，用后面的N位棵磷；如果是1蛾狗，表示是超過當(dāng)前設(shè)計的位范圍了，去一個新增的數(shù)據(jù)庫查詢
- 好處：位運算執(zhí)行效率高仪媒，節(jié)省空間
- 壞處：可讀性不強; 擴展差; 64位用完后還得繼續(xù)增加新字段沉桌；
思路3: 引入列存儲如MangoDb
列存儲適合這種場景，具體待研究
思路4: 表垂直拆分
將不用的字段拆分出來，改動也挺大蒲牧，增加字段依然存在問題
