故事背景：

依照原系統的框子搞一個新的系統給其他人使用，因為新的系統配置庫依然需要使用原有的表，表中有欄位區分新的系統，然後就有了這個很沒勁的資料同步。

難點：配置庫碼錶資料的主鍵之前是自增，後來改造改成18位有意義的字元序列，但是由於部分小哥哥小姐姐不按照規範寫，導致表中主鍵有部分資料是前幾位一樣，有的是後幾位一樣。

資料同步方案一：

使用擷取原有主鍵一部分，再在其前面拼接上日期入表 （有主見衝突），本來規定的就是年份+日期+各組編號+個人編號+000三位的擴充套件，指令碼寫完執行時發現數據完全不是那麼回事，有很多就是前面改一位，其他不動。。。

INSERT INTO
 
 t_test (
    SELECT
        CONCAT(
            '1901',

        IF (
            length(col1) > 12,
            RIGHT (col1, 12),
            col1
        )
        ) col1,
        col2,
        col3
    FROM
        t_test
);

當 col1的長度大於12時，保留後面的12位，前拼接1901 當不大於12時 1901直接拼接原來的資料 防止主鍵長度超過限制長度

資料同步方案二：同步資料按順序造新的主鍵  本次同步資料總量5000+ 所以最長資料後面會有4位資料 前面安裝原有主鍵生成策略 往上湊 

INSERT INTO t_test (
    SELECT
        CONCAT(
            '1901071530044',
            @rownum :=@rownum + 1
        ) col1,
        col2,
        col3,
        CONCAT(id, 'aa')
    FROM
        t_test,
        (SELECT @rownum := 0) r
);

這樣其實主鍵的長度就會不一致，由於是拼接上去的主鍵長度不一樣長所以還是有點問題的 不過測試人員說可以了就這樣搞... GG不GG