最近從 MySQL 遷移 GoldenDB,遇到了一個奇怪的問題，今天來分享一下。

問題回放

我們先創(chuàng)建一張表 test_1，SQL 如下：

CREATE TABLE`test_1` (
`id`int(8) NOTNULL AUTO_INCREMENT,
`column1`varchar(1) COLLATE utf8_bin DEFAULTNULL,
`date_time` datetime DEFAULTNULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=11DEFAULTCHARSET=utf8 COLLATE=utf8_bin

往 test_1 插入 1 條數(shù)據(jù)，如下圖：

INSERT INTO test_1(column1,date_time)VALUES ('a',NOW());

然后我們創(chuàng)建一張跟 test1 表結構一樣的表 test2。

CREATE TABLE test_2 LIKE test_1;

執(zhí)行下面 SQL。

insert into test_2(column1,date_time) select "column1", now() from test_1;

這條 SQL 并不復雜，從 test1 表查出數(shù)據(jù)寫到 test2 表。但不知道寫代碼的小伙伴出于什么考慮在 column1 上加了雙引號。這個 SQL 在 MySQL(8.0 版本)上執(zhí)行是沒有問題的，但是放到了 GoldenDB 上就報錯了，因為雙引號包著的字段返回的是 column1 這個字符串，最終字段超長報錯（Data too long for column 'column1' at row 1）。

遷移注意

近年來，國內(nèi)不少公司都在做信創(chuàng)改造，也難免會遇到一些坑。那么涉及數(shù)據(jù)庫遷移改造的，需要注意哪些方面呢？

1. 語法兼容

這可能是首要考慮的點，也是特別關鍵的一步，語法不兼容直接會導致業(yè)務上的失敗，就像上面我遇到的問題。

一些主流的分布式數(shù)據(jù)庫會有兼容性掃描工具，可以幫助開發(fā)人員避開大多數(shù)的坑。而對于老系統(tǒng)，經(jīng)歷過多個開發(fā)人員之手，現(xiàn)有開發(fā)人員沒人能對存量代碼非常熟悉，也沒有測試同事知道要測試哪些點。除了工具掃描外，好多功能還是需要開發(fā)人員擼代碼來確認的。開發(fā)人員擼代碼的時候，要特別注意函數(shù)、存儲過程、自增 id、觸發(fā)器、長事務、事務隔離級別等。

別太相信數(shù)據(jù)庫廠商鼓吹的 100% 兼容 xxx 數(shù)據(jù)庫。出了事故，廠商可不背鍋。工具可以解決 90% 的問題，但剩下的 10% 是最復雜，最容易出問題的地方。還是需要靠程序員人工確認的。

2. 數(shù)據(jù)分片

根據(jù)業(yè)務規(guī)則為每張表選擇最合適的分片字段，比如客戶身份證，客戶 id，盡可能讓同一個維度的數(shù)據(jù)（比如單個客戶）在單個分片上。這樣對同一個維度的數(shù)據(jù)的操作可以在一個分片上完成，比如 JOIN 語句，跨分片查詢復雜度很高。

尤其需要注意的是不要選擇離散度高的字段來分片，很容易造成數(shù)據(jù)傾斜。

將數(shù)據(jù)量小、更新頻率低的表設置為全局表，比如行政區(qū)碼值，同步到到各個分片，避免跨分片關聯(lián)查詢。

3. 性能測試

性能測試是必須要進行的事情。從傳統(tǒng)數(shù)據(jù)庫遷移到國產(chǎn)分布式數(shù)據(jù)庫，很可能會出現(xiàn)性能問題，尤其原數(shù)據(jù)庫是 Oracle 并且數(shù)據(jù)量在千萬級別的情況。

對于復雜的業(yè)務系統(tǒng)，里面的 SQL 可能會達到上千條，對所有 SQL 做壓測不太現(xiàn)實，所以一定要做全面的評估，找出可能有性能問題的 SQL 進行壓測。

更難的是，因為業(yè)務場景的問題，一些 SQL 可能很難執(zhí)行到，要模擬特定的場景數(shù)據(jù)才能執(zhí)行到這些 SQL。很容易在壓測時漏掉這些場景，這也是為什么有時候測試環(huán)境性能測試沒發(fā)現(xiàn)問題，但上線后卻出了問題。

4.切換過程

有了上面三步的評估，接下來關注的就是切換過程，直接關系到整個切換的結果。

是否允許停機。如果業(yè)務上允許短暫停機，那就太好了，先把一個時間點前的存量數(shù)據(jù)讓新老庫完成同步，然后短暫停服，把增量數(shù)據(jù)同步完成。一定要注意的是服務重啟后，如果驗證有問題，能快速回切老庫，這又涉及到一個問題，重啟服務后增量數(shù)據(jù)需要考慮雙寫，以便切回時不丟失數(shù)據(jù)。

如果業(yè)務上不允許停服，那就比較復雜了。可以考慮增加一套服務連接新庫，在新服務上切換少量流量進行驗證并且雙寫。這里會涉及新老庫雙向數(shù)據(jù)同步，必須解決循環(huán)同步問題。

總結

隨著這些年國內(nèi)新創(chuàng)改造的開展，數(shù)據(jù)庫遷移是很多公司必須要做的一個工作，這項工作難度極大，要完全不出問題很難。做好影響分析、制定快速回切方案，最大限度降低業(yè)務損失，才能保證不出大事故。