db2數據庫遷移mysql,db2數據庫遷移

本文目錄一覽：

• 1、如何遷移MySQL數據庫
• 2、mysql有沒有好的據庫之間數據轉移的方法或思路呢？
• 3、如何將數據庫從SQL Server遷移到MySQL
• 4、怎麼將DB2導出的txt數據導入Mysql中
• 5、求高手傳授DB2移植MySQL數據庫的方法

如何遷移MySQL數據庫

caching_sha2_password認證插件提供更多的密碼加密方式，並且在加密方面具有更好的表現，目前MySQL 8.0選用caching_sha2_password作為默認的認證插件，MySQL 5.7的認證插件是MySQL_native_password。如果客戶端版本過低，會造成無法識別MySQL 8.0的加密認證方式，最終導致連接問題。

MySQL存儲引擎現在負責提供自己的分區處理程序，而MySQL服務器不再提供通用分區支持，InnoDB和NDB是唯一提供MySQL 8.0支持的本地分區處理程序的存儲引擎。 如果分區表用的是別的存儲引擎，存儲引擎必須進行修改。要麼將其轉換為InnoDB或NDB，要麼刪除其分區。通過MySQLdump從5.7獲取的備份文件，在導入到8.0環境前，需要確保創建分區表語句中指定的存儲引擎必須支持分區，否則會報錯。

MySQL 8.0的默認字符集utf8mb4，可能會導致之前數據的字符集跟新建對象的字符集不一致，為了避免新舊對象字符集不一致的情況，可以在配置文件將字符集和校驗規則設置為舊版本的字符集和校驗規則。

MySQL 8.0啟動使用的lower_case_table_names值必須跟初始化時使用的一致。使用不同的設置重新啟動服務器會引入與標識符的排序和比較方式不一致的問題。

 lower_case_table_names 

要避免MySQL 8.0上的啟動失敗，MySQL配置文件中的sql_mode系統變量不能包含NO_AUTO_CREATE_USER。

從MySQL 5.7.24和MySQL 8.0.13開始，MySQLdump從存儲程序定義中刪除了NO_AUTO_CREATE_USER。必須手動修改使用早期版本的MySQLdump創建的轉儲文件，以刪除NO_AUTO_CREATE_USER。

在MySQL 8.0.11中，刪除了這些不推薦使用的兼容性SQL Mode：DB2，MAXDB，MSSQL，MySQL323，MySQL40，ORACLE，POSTGRESQL，NO_FIELD_OPTIONS，NO_KEY_OPTIONS，NO_TABLE_OPTIONS。從5.7到8.0的複製場景中，如果語句使用到廢棄的SQL Mode會導致複製異常。

在執行到MySQL 8.0.3或更高版本的in-place升級時，BACKUP_ADMIN權限自動授予具有RELOAD權限的用戶。

本文對MySQL 5.7到MySQL 8.0的升級過程中出現部分易出現問題進行整理：升級對MySQL版本的要求、升級都做了哪些內容、數據庫升級做了哪些步驟以及注意事項，希望對大家版本升級有幫助。

mysql有沒有好的據庫之間數據轉移的方法或思路呢？

gh-ost 是 GitHub 發布的一款用於 MySQL 的無觸發器在線模式遷移解決方案。它是可測試的，並提供暫停，動態控制/重新配置，審計和許多操作特權。它在整個遷移過程中，對主服務器產生的工作量很少，與已遷移表上的現有工作分離。

gh-ost與所有現有的在線模式更改工具都以類似的方式操作：它們以與原始表相似的方式創建幽靈表，將數據從原始表緩慢且增量地複製到幽靈表，同時應用正在進行的更改（INSERT，DELETE，UPDATE）到幽靈表。最後，在適當的時候，它用幽靈表替換了原始表。gh-ost使用相同的模式。但是，它與所有現有工具的不同之處在於不使用觸發器。取而代之的是，gh-ost使用二進制日誌流捕獲表的更改，然後將其異步應用到幽靈表。

gh-ost 承擔一些其他工具留給數據庫執行的任務。gh-ost 可以更好地控制遷移過程；可以真正暫停它；可以真正將遷移的寫入負載與主服務器的工作負載分離。此外，它還提供了許多可操作的特權，使其更安全、可信賴且易於使用。

如何將數據庫從SQL Server遷移到MySQL

以下有幾款遷移工具的對比，可以參考，比較推薦DB2DB.

軟件易用性主要是指軟件在導入前的配置是否容易。由於很多軟件設計是面向程序員而非一般的數據庫管理人員、甚至是普通的應用程序實施人員，而這一類人員很多時候並沒有數據源配置經驗。因為一些使用 ODBC 或者 ADO 進行配置的程序往往會讓這類用戶造成困擾（主要是不知道應該選擇什麼類型的數據庫驅動程序）。下面讓我們看看四個工具的設計界面：

1、SQLyog

SQLyog 使用的是古老的 ODBC 連接，但對於新一代的程序來說，這種方式的非常的不熟悉並且不容易使用，並且必須要求本機安裝好相應的數據庫的 ODBC 驅動程序（SQL Server 一般自帶好）。

2、Navicat Premium

NavicatPremium是四個應用工具中設計最不人性化的一個：從上圖怎麼也想像不到要點按那個小按鈕來添加一個新的連接，並且這個連接設置不會保存，每次導入時都必須重新設置。NavicatPremium使用的是比 ODBC 稍先進的 ADO 設置方式（199X年代的產物），但使用上依然是針對老一代的程序員。

3、Mss2sql

Mss2sql 是最容易在百度上搜索出來的工具，原因之一是它出現的時間較早。

Mss2sql由於是很有針對性的從 SQLServer 遷移到 MySQL，因為界面使用了操作嚮導設計，使用非常容易。同時在設置的過程中，有非常多的選項進行細節調整，可以感覺到軟件經過了相當長一段時間的使用漸漸完善出來的。

4、DB2DB

DB2DB 由於是由國人開發，因此無論是界面還是提示信息，都是全程漢字。另外，由於 DB2DB 在功能上很有針對性，因為界面設計一目了然和易使用。和 mss2sql 一樣， DB2DB 提供了非常多的選項供用戶進行選擇和設置。

三、處理速度和內存佔用評測

在本評測前，本人的一位資深同事曾經從網上下載了某款遷移軟件，把一個大約2500萬記錄數的數據錶轉送到阿里雲 MySQL，結果經過了三天三夜（好在其中兩天是星期六和星期日兩個休息日）都未能遷移過來。因此這一次需要對這四個工具的處理速度作一個詳細的測試。

考慮到從 SQL Server 遷移到 MySQL 會出現兩種不同的場景：

從 SQL Server 遷移到本地 MySQL 進行代碼測試和修改；

從 SQL Server 遷移到雲端 MySQL 數據庫正式上線使用；

以下為測試過程中的截圖：

1、SQLyog

請點擊輸入圖片描述

2、Navicat Premium

請點擊輸入圖片描述

請點擊輸入圖片描述

注意：我們在測試 Navicat Premium 遷移到  MySQL 時發現，對於 SQL Server 的 Money 類型支持不好（不排除還有其它的數據類型支持不好）。Money 類型字段默認的小數位長度為 255，使得無法創建數據表導致整個測試無法成功，需要我們逐張表進行表結構修改才能完成測試過程。

Navicat Premium 的處理速度屬於中等，不算快也不算慢，但 CPU 佔用還有內存佔用都處於高位水平。不過以現在的電腦硬件水平來說，還是可以接受。但 CPU 佔用率太高，將使得數據在導入的過程中，服務器不能用於其它用途。

3、Mss2sql

Mss2sql 並沒有提供計時器，因此我們使用人工計時的方法，整個過程處理完畢大於是 726 秒。Mss2sql 的 CPU 佔用率相對其它工具來說較高，但仍屬於可以接受的範圍之內。

4、DB2DB

請點擊輸入圖片描述

DB2DB 同樣遷移 300萬數據時，僅僅使用了 2 分 44 秒，這個速度相當驚人。不過最後的結果出現一個 BUG，就是提示了轉換成功，但後面的進度條卻沒有走完（在後面的數據完整性評測中，我們驗證了數據其實是已經全部處理完畢了）。

怎麼將DB2導出的txt數據導入Mysql中

db2 import from c:\aaa.txt of del modify by coldel| insert into table1

其中c:\aaa.txt為原始文本文件全名，可以帶有完整路徑

of del表示文件的類型為定界ASCII類型，即每個列有分隔符的文本文件

coldel參數用於指定每個列的分隔符，後面的豎線“|”與coldel之間不要有空格

求高手傳授DB2移植MySQL數據庫的方法

通過網頁的方式將頁面上顯示的所有信息導入到一個EXCEL表裡，然後將EXCEL導入到數據庫，我只是設想，不知道行不行，SQL SERVER的我試過，是可以的，其他的不知道