背景

由於各種原因，成本啊、擴展性等，公司決定把線上的業務從sql server遷移到mysql RDS。

遷移過程主要包括了程序修改和數據庫的遷移。程序修改我們略過不談，我們重點關註數據庫遷移。

大概過程

由於是異構的數據庫，沒有找到數據實時同步的方法（若哪位大俠可以異構實時同步，還請多多指教），所有使用ETL工具定時同步數據。

同步的數據包括insert和update的數據（還好業務中沒有物理的delete）。

待萬事俱備，切換數據庫之前，再進行一次數據同步。

切換完成之後，在進行數據檢查，把最後一次同步之後，寫入到sqlserver中的數據，傳輸到mysql上。

大功告成！！！

那些坑

本文主要介紹遷移過程中的那些坑，主要是結構和語法上的。

1，時間戳timestamp數據類型

sqlserver和mysql都有timestamp數據類型，但是兩者的實現區別很大。

在sql server中，該類型表明數據庫中數據修改發生的相對順序，它的值本質上是一個bigint類型的一個遞增數字，與時間和日期無關， 該數字在數據庫實例級別不會重讀。

在mysql中，該類型表明數據庫中數據修改發生的相對順序， 它的本質是一個時間，該時間再表級別都有可能重復。

最坑的是該類型的字段是我們業務的關鍵字段，用於用戶從服務器上拉去數據。

最後的解決辦法，該字段的數據按照bigint的值從sql server遷移到mysql，mysql在添加一個timastamp數據類型，程序添加判斷機制。

2，字符集和emoji表情

sqlserver中默認直接可以保存emoji表情。開始遷移過程沒有註意到該問題。歷史數據遷移完畢以後，才發現該問題。omg！！

mysql中需要使用utf8mb4來保存此數據。

3，索引不能超過大小

mysql中索引長度不能超過767字節，這可是個大坑啊！！！

這個只能是優化數據類型。

比如有的字段保存設備的macid，數據類型是varchar(50)，經過調研發現macid只有12位，可以修改成varchar(12)。

再有int是否可以改為tinyint或者smallint、是否可以用latin1代替utf8(當然最好是都統一使用utf8)等

這裏主要就是數據類型的優化，稍後會有專門的文章來介紹數據類型優化。

4，varchar(max)類型

mysql沒有該數據類型，如果使用power designer反向工程的話，從sqlserver到mysql，該數據類型會變為char(1)。mysql中需要使用text類型。

5，常見的不兼容的語法

sqlserver中一個使用top取前幾行的數據，mysql使用limit完成此功能。這個相對還比較好修改。

兩者使用臨時表的方法也不一樣。

存儲過程和函數的格式。

6，CTE遞歸

在存在遞歸查詢的操作裏，sqlserver有一個非常棒的功能就是CTE遞歸查詢。

7，over窗口查詢

sqlserver中的over窗口函數也是我非常喜歡的一個功能，比如分組排序、分組範圍等查詢。

sqlserver遷移到mysql遇到的那些坑