Posted inMySQL

MSSQLからMySQLへの移行：落とし穴を回避し、データ型エラーを解決する秘策

MySQL tutorial - IT technology blog
MySQL tutorial - IT technology blog

今すぐ実行：移行プロセスの6つのステップ

テスト用にいくつかのテーブルを急いで移行する必要がある場合、これが最短のルートです。開始前に、MySQL WorkbenchとSQL Server用ODBCドライバがインストールされていることを確認してください。

  1. ウィザードを開く： DatabaseメニューからMigration Wizardを選択します。
  2. ソース（MSSQL）への接続： Microsoft SQL Serverを選択します。接続エラーを避けるため、ODBC Data Sourceを使用することをお勧めします。
  3. ターゲット（MySQL）への接続： データをインポートするMySQLインスタンスを指定します。
  4. スキーマの選択： 移行対象のデータベースにチェックを入れます。
  5. リバースエンジニアリング： Workbenchがテーブル構造をスキャンします。すぐにNextを押さず、ここでマッピングをしっかり確認してください。
  6. データの転送： Nextをクリックすると、ツールが自動的にスキーマを作成し、データをコピーします。

現実はそう甘くありません。実際のデータベースでは、ステップ5と6でトラブルに遭遇する確率が非常に高いです。多くの場合、エラーはT-SQLとMySQLの仕様の乖離に起因します。

なぜMSSQLからMySQLへの移行は厄介なのか？

以前、200以上のテーブルと500GBのデータを持つERPシステムをSQL ServerからMySQLに移行するプロジェクトに参加しました。当初、チームはボタン一つで終わると思っていました。結果は？ Data truncation（データの切り捨て）エラーとクエリパフォーマンスの激減に対処するため、2晩徹夜することになりました。

主な原因は、ストレージ思想の違いにあります。MSSQLは柔軟なデータ型でユーザーを「甘やかして」くれますが、対照的にMySQLは長さやストレージ構成に対して絶対的な正確さを求めます。ツールの自動マッピングに完全に頼ってしまうと、ゴミデータの山が出来上がってしまうリスクがあります。

互換性処理の技術的詳細

1. ODBC経由の接続設定

Workbenchに直接IPを入力するのではなく、コントロールパネル -> ODBCデータソース (64ビット) を開き、SQL Serverを指す**System DSN**を作成してください。これにより、特に社内LAN経由で大量のデータを移行する際の接続が安定します。

# SQL Serverへのアクセス権限を素早くチェック
sqlcmd -S 192.168.1.10 -U sa -P YourStrongPassword

2. データ型のマッピング：注意すべきポイント

これはデータ損失（Data loss）を防ぐための、経験に基づいたマッピング表です。Object Migrationステップで**Show Selection**を選択し、手動で調整してください：

  • DATETIME2からDATETIME(6)へ： MSSQLのDATETIME2は100ナノ秒の精度を持ちます。MySQLのデフォルトのDATETIMEにマッピングすると、ミリ秒部分が失われます。精度を維持するにはDATETIME(6)を使用してください。
  • NVARCHAR(MAX)からVARCHAR(n)へ： Workbenchは通常LONGTEXTに変換しますが、実際のデータが4000文字未満であればVARCHAR(4000)に強制することをお勧めします。これにより、LONGTEXTではサポートが弱いIndexを有効活用できます。
  • BITからTINYINT(1)へ： MySQLには真のBoolean型がなく、TINYINT(1)を使用します。アプリケーション層（コード）で、0/1がTrue/Falseとして正しく解釈されるか確認してください。
  • UNIQUEIDENTIFIERからCHAR(36)へ： MySQLには専用のUUID型がありません。最善の方法はCHAR(36)を使用し、アプリケーション層でUUID()関数を処理することです。

3. ストアドプロシージャとトリガーの処理

重要な注意点：Workbench Migration Wizardはコードロジックの変換が非常に苦手です。T-SQLは@Variableを使用しますが、MySQLはDECLAREを使用します。また、MSSQLにはTOPがありますが、MySQLはLIMITを使用します。

私のアドバイスは、ウィザードでのRoutine/Triggerの移行は完全に**Skip**することです。まずデータを移行し、その後MySQLに最適化するように手動でロジックを書き直してください。

大規模データ処理（Big Data）の秘策

データベースが20GBを超える場合、Workbench経由で直接データを転送するのはタイムアウトのリスクが高く「無謀」です。プロが実践する3ステップのプロセスを適用しましょう：

  1. ウィザードを使用して**テーブル構造のみ**（Schema only）を作成する。
  2. MSSQLのbcp（Bulk Copy Program）ツールを使用して、データをCSVファイルにエクスポートする。
  3. LOAD DATA INFILEコマンドを使用して、CSVをMySQLにロードする。この方法により、移行時間を10時間から30分に短縮できる場合があります。
-- LOAD DATAによる超高速データロード
LOAD DATA INFILE '/var/lib/mysql-files/data.csv'
INTO TABLE users
FIELDS TERMINATED BY ',' 
ENCLOSED BY '"'
LINES TERMINATED BY '\n'
IGNORE 1 ROWS;

トラブルを避けるための実務経験

文字化けエラー： MSSQLは通常SQL_Latin1_General_CP1_CI_AS照合順序を使用します。MySQLに移行する際は、必ずutf8mb4（特にMySQL 8.0ではutf8mb4_0900_ai_ci）を選択してください。顧客の名前が文字化けして「?」にならないように注意しましょう。

大文字・小文字の区別： Linux上のMySQLでは、テーブル名の大文字・小文字が区別されます（例：Usersとusersは別物）。既存のコードの記述が統一されていない場合は、移行前にmy.cnfファイルでlower_case_table_names=1を設定してください。

外部キーのチェック： 古いデータには時折「孤立した」レコードが存在します。MySQLのStrict Modeでは、データが一致しない場合に外部キーの作成をブロックします。一時的にチェックを無効にして、後でクリーンアップしましょう。

SET FOREIGN_KEY_CHECKS = 0;
-- ここでデータのロードまたはエラー修正を実行
SET FOREIGN_KEY_CHECKS = 1;

要するに、移行は細部へのこだわりの戦いです。自動ツールを完全に信用してはいけません。本番環境で実行する前に、必ずバックアップで十分にテストしてください。もし解決の難しいマッピングエラーに遭遇したら、下のコメント欄で教えてください！

Share:
Tags: