一個看似糾結的MySQL標籤需求的梳理

我們日常工作中總是會有一些看起來繁瑣，吃力不討好的事情，但是這些需求我們不能一概而論，為了落實規範而動用規範的大棒。

對我來說，我喜歡那種開放型的問題，比如看起來很繁瑣無解，但是業務又迫切需要的事情。

比如業務同學今天提了一個問題：有一張表，資料量有600多萬，而且資料實時的寫入還挺多，記錄的是一些工作的備註資訊，比如客服同學接受了一個使用者請求，然後會把這些資訊記錄下來，比如是關於哪個業務方向的，關於哪個遊戲的等等，都當做一個欄位資訊儲存起來。之前的管理是一種相對籠統的方式，在管理中會難以衡量和控制。 所以現在想使用類似標籤的方式進行資訊歸類。

舉個例子來說，客服同學之前處理了幾個需求，假設記錄的格式是這樣的：

使用者xxx諮詢遊戲A的登入問題。

。

。

。

。

使用者xxx反饋遊戲B的充值問題，反饋遊戲C（可能錯別字）的經驗沒有生效。

。

。

使用者xxx反饋手機號登入遊戲B（可能縮寫）失敗，而且充值有問題。。。

所以使用者反饋的資訊是沒有嚴格的格式和規範，要對這些使用者請求打上標籤難度還是比較大的。

對一張600多萬的大表進行業務整改，勢必會有一些全流程的改變，首先業務同學給我們出了個難題，這個表的索引是比較多的，重建的過程遠遠超出了我們的預期，還好使用了pt-osc工具還算穩。

現在表的一個標籤欄位已經建立好了，就需要進行下一步的工作：打標籤。

業務同學進行梳理和討論，整理了大概12個種類的關鍵字，每個關鍵字會對應一個數字編碼，也就是能夠被識別業務標籤。

array（

1 => ‘關鍵字1’，

2 => ‘關鍵字2’，

3 => ‘關鍵字3’，

4 => ‘關鍵字4’，

5 => ‘關鍵字5’，

6 => ‘關鍵字6’，

7 => ‘關鍵字7’，

8 => ‘關鍵字8’，

9 => ‘關鍵字9’，

10 => ‘關鍵字10’，

11 => ‘關鍵字11’，

12 => ‘關鍵字12’

）；

面對這麼多的種類，難點來了，有些標籤是有互斥關係的，有些是可能存在關鍵字重合的，比如“膝上型電腦”“臺式電腦”這兩個詞是互斥的兩種型別，而“筆記本”和“膝上型電腦”又是互斥的。

如果讓業務部門去統計這麼多的重合標籤，估計會瘋掉，因為按照一個粗略的計算，比如6個標籤，4個重合的機率就是16+5+1=22種，如果是12類標籤，那方案複雜度要高得多，至少得上百種。

最關鍵的，哪怕這些都梳理出來，根據評估需要變更的資料有70萬，怎麼高效的把70萬資料都發布到線上，這是一個值得思考的問題。 整體的思路是：

1）線上的關鍵字模糊匹配工作要放到從庫來執行。

2）從庫端不光進行資料過濾，還需要進行一些資料的統計分析，進行去重和過濾

3）在經過需求確認後，把變更語句按照主鍵條件釋出到線上

對於標籤的衝突關係梳理，我提出了改進的思路。

既然有12類標籤，那麼我們完全可以按照12個數據子集進行單獨的關鍵字過濾，如果有一些標籤是重合的，那麼在12類標籤過濾中勢必會出現。

面對這種多對多的對映，我們可以完全統計出這些多標籤的比例來，如果佔比不到0。1%，那麼這些單據我們完全可以透過人工來判別，這樣一來，99%以上的資料都可以自動完成，人工只需要進行判斷很少的單據，避免我們的需求從開始就進入本末倒置的狀態。

所以我按照單號（order_id，tag_name，tag_id）來進行資料抽取，很快就得到了12個數據子集，我們假設為dataset1-dataset12

然後我們把這些自己的資料寫入一個共同的集合dataset中。

select order_id，count（*）from dataset group by order_id having count（*）>1就可以得到多標籤的單據了。

而經過初步的統計，這個資料量級確實是很低的，5個重合標籤的單據都是個位數，99%以上的單據都是單標籤。

所以這一層關係確定之後，我們就可以考慮進行線上的資料部署優化了，而這也正是DBA要做的專業的事情。

如果變更語句有30萬，那麼我們構造出30萬條SQL語句是成本比較高的。

我們可以把dataset的結果匯入線上環境中，建立索引（order_id，tag_id）

然後分批次變更，儘可能避免半連線操作，根據實踐的效果來看，每一步基本都控制在毫秒級完成。