giip
SES案件登録
Aurora MySQL文字セット移行インデックスパラメータバージョン互換性

Aurora MySQLでutf8mb3からutf8mb4へ移行するときに確認すること

公開日 2026-08-13 · 更新日 2026-08-13 · 最終検証日 2026-08-13

結論

utf8mb3(MySQL 5.7では `utf8` がこの別名)からutf8mb4へ移行するときは、(1) インデックスのキー長上限、(2) 照合順序の選択、(3) サーバーパラメータと接続時の文字セット、の3つを先に確認します。特に問題になるのはキー長で、utf8mb4は1文字最大4バイトのため `VARCHAR(255)` の単独インデックスは1020バイトを要求し、767バイト上限の環境では `ALTER TABLE` が失敗します。変換はテーブルの作り直しを伴うため、計画作業として扱ってください。

この文書の適用条件

対象製品Aurora MySQL(MySQL互換エディション)/ MySQL
確認バージョンAurora MySQL 2.x(MySQL 5.7互換)/ 3.x(MySQL 8.0互換)。`utf8mb4_0900_ai_ci` はMySQL 8.0互換の 3.x のみ
適用環境Amazon Aurora、Amazon RDS for MySQL、オンプレミスのMySQL
必要権限調査は `information_schema` の参照権限。変換は対象テーブルへの `ALTER` 権限、パラメータ変更はIAMの `rds:ModifyDBClusterParameterGroup` など
実行影響調査SQLは影響なし。`CONVERT TO CHARACTER SET` はテーブルの作り直し(データコピー)を伴う
再起動テーブル変換は不要。サーバーパラメータの反映方法はパラメータごとに異なるため `ApplyType` を要確認
最終検証日2026-08-13

そのまま実行できるコマンド

サーバー側の文字セット・照合順序の現在値を確認する参照のみ
対象
Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0
権限
接続権限(グローバル変数の参照)
変更作業
なし(参照のみ)
Production実行
可能
-- 対象: Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0
-- 権限: 接続権限(グローバル変数の参照のみ)
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SHOW GLOBAL VARIABLES WHERE Variable_name IN (
    'character_set_server',
    'character_set_database',
    'character_set_client',
    'character_set_connection',
    'character_set_results',
    'collation_server',
    'collation_database',
    'collation_connection'
);

MySQL 5.7では `utf8` は `utf8mb3` の別名です。ここに `utf8` と表示されていても、実体は3バイト上限のutf8mb3だと理解してください。MySQL 8.0では `utf8` の別名としての使用が非推奨になっています。

utf8mb4になっていないテーブルを洗い出す参照のみ
対象
Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0
権限
`information_schema` の参照権限(メタデータ可視性に従う)
変更作業
なし(参照のみ)
Production実行
可能
-- 対象: Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0
-- 権限: information_schema の参照権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT
    TABLE_SCHEMA,
    TABLE_NAME,
    ENGINE,
    ROW_FORMAT,
    TABLE_COLLATION,
    ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 1) AS size_mb
FROM information_schema.TABLES
WHERE TABLE_TYPE = 'BASE TABLE'
  AND TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
  AND (TABLE_COLLATION IS NULL OR TABLE_COLLATION NOT LIKE 'utf8mb4%')
ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC;

`size_mb` の大きい順に並べています。変換はテーブル単位のデータコピーになるため、この順序がそのまま作業の重さの順序になります。

utf8mb4になっていない列を洗い出す参照のみ
対象
Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0
権限
`information_schema` の参照権限
変更作業
なし(参照のみ)
Production実行
可能
-- 対象: Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0
-- 権限: information_schema の参照権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT
    TABLE_SCHEMA,
    TABLE_NAME,
    COLUMN_NAME,
    DATA_TYPE,
    CHARACTER_MAXIMUM_LENGTH AS max_chars,
    CHARACTER_OCTET_LENGTH   AS max_bytes,
    CHARACTER_SET_NAME,
    COLLATION_NAME
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
  AND CHARACTER_SET_NAME IS NOT NULL
  AND CHARACTER_SET_NAME <> 'utf8mb4'
ORDER BY TABLE_SCHEMA, TABLE_NAME, ORDINAL_POSITION;

テーブル既定がutf8mb4でも、個々の列に明示的な文字セットが残っていることがあります。テーブル単位の確認だけでは漏れるため、列単位でも必ず確認してください。

utf8mb4化でキー長上限を超えるインデックスを事前に洗い出す参照のみ
対象
Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0(InnoDB)
権限
`information_schema` の参照権限
変更作業
なし(参照のみ)
Production実行
可能
-- 対象: Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0(InnoDB)
-- 権限: information_schema の参照権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
-- utf8mb4 は 1 文字最大 4 バイト。プレフィックス長指定の無い文字列列だけを対象に、
-- 変換後に必要となるキー長(バイト)を見積もる。
SELECT
    s.TABLE_SCHEMA,
    s.TABLE_NAME,
    s.INDEX_NAME,
    GROUP_CONCAT(s.COLUMN_NAME ORDER BY s.SEQ_IN_INDEX)  AS index_columns,
    SUM(c.CHARACTER_MAXIMUM_LENGTH * 4)                  AS bytes_after_utf8mb4
FROM information_schema.STATISTICS s
JOIN information_schema.COLUMNS c
      ON  c.TABLE_SCHEMA = s.TABLE_SCHEMA
      AND c.TABLE_NAME   = s.TABLE_NAME
      AND c.COLUMN_NAME  = s.COLUMN_NAME
WHERE s.TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
  AND c.CHARACTER_MAXIMUM_LENGTH IS NOT NULL
  AND s.SUB_PART IS NULL
GROUP BY s.TABLE_SCHEMA, s.TABLE_NAME, s.INDEX_NAME
HAVING bytes_after_utf8mb4 > 767
ORDER BY bytes_after_utf8mb4 DESC;

まず767バイト超を全部出し、そのうえで自環境の上限に照らして判定します。行フォーマットが `DYNAMIC` または `COMPRESSED` で3072バイト上限が有効な環境では、`HAVING` の閾値を3072に変えて絞り込んでください。`VARCHAR(255)` の単独インデックスは 255 × 4 = 1020バイトになり、767バイト上限の環境では必ず失敗します。

テーブルをutf8mb4へ変換する(テーブル作り直しを伴う)
対象
Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0
権限
対象テーブルへの `ALTER` 権限
変更作業
あり(テーブルの作り直しとデータコピー)
Production実行
大きなテーブルでは不可。計画作業として実施する
-- 対象: Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0
-- 権限: 対象テーブルへの ALTER 権限
-- 変更作業: あり(テーブル作り直し + 全行のデータコピー)
-- Production 実行: 大きなテーブルでは不可。所要時間を実測してから計画実行する

-- 1) 変換前に現在の定義を保存しておく(切り戻し判断の材料になる)
SHOW CREATE TABLE SampleDB.sample_table;

-- 2) テーブル既定と全文字列列をまとめて変換する
ALTER TABLE SampleDB.sample_table
    CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci,
    ALGORITHM = COPY,
    LOCK = SHARED;

-- 3) 変換結果を確認する
SELECT COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'SampleDB'
  AND TABLE_NAME   = 'sample_table'
  AND CHARACTER_SET_NAME IS NOT NULL;

`CONVERT TO CHARACTER SET` はテーブルを作り直すため、オンラインDDL(`ALGORITHM=INPLACE`)では実行できません。`LOCK=SHARED` は参照を許可し書き込みを止めます。書き込みを止められない大きなテーブルでは、`pt-online-schema-change` や `gh-ost` のようなオンラインスキーマ変更ツールを使う方法があります。所要時間はテーブルサイズ、インスタンスクラス、同時負荷で大きく変わるため、必ず本番同等データで実測してください(本記事では所要時間の目安を示しません)。

接続側の文字セットを揃える
対象
Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0(セッション単位)
権限
接続権限
変更作業
あり(現在のセッションの文字セット設定のみ)
Production実行
可能(セッション内で完結する)
-- 対象: Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0(セッション単位の設定)
-- 権限: 接続権限
-- 変更作業: あり(現在のセッションのみ。他セッションには影響しない)
-- Production 実行: 可能

-- クライアント・接続・結果の3つの文字セットをまとめて切り替える
SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci;

-- 現在のセッションの値を確認する
SHOW SESSION VARIABLES WHERE Variable_name IN (
    'character_set_client',
    'character_set_connection',
    'character_set_results',
    'collation_connection'
);

テーブルをutf8mb4にしても、接続がutf8mb3のままだと4バイト文字は保存時に落ちるか、エラーになります。JDBC・PDO・各言語のドライバにも接続文字セットの設定があるため、アプリケーション側の接続文字列も併せて確認してください。

サーバーパラメータをutf8mb4に変更する
対象
Aurora MySQL(DBクラスターパラメータグループ)
権限
IAM: `rds:DescribeDBClusterParameters`, `rds:ModifyDBClusterParameterGroup`
変更作業
あり(クラスター全体に効くパラメータの変更)
Production実行
変更管理を通したうえで実施。反映方法はパラメータごとに確認する
# 対象: Aurora MySQL(DBクラスターパラメータグループ)
# 権限: IAM rds:DescribeDBClusterParameters, rds:ModifyDBClusterParameterGroup
# 変更作業: あり(クラスター全体に効くパラメータ変更)
# Production 実行: 変更管理を通したうえで実施

# 1) まず現在値と反映方法(ApplyType)を確認する。static なら再起動が必要になる
aws rds describe-db-cluster-parameters \
  --db-cluster-parameter-group-name example-aurora-mysql-cluster-params \
  --query "Parameters[?starts_with(ParameterName, 'character_set') || starts_with(ParameterName, 'collation')].{Name:ParameterName,Value:ParameterValue,Apply:ApplyType}" \
  --output table

# 2) 既定の文字セットと照合順序を変更する
aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name example-aurora-mysql-cluster-params \
  --parameters '[
    {"ParameterName":"character_set_server","ParameterValue":"utf8mb4","ApplyMethod":"pending-reboot"},
    {"ParameterName":"collation_server","ParameterValue":"utf8mb4_unicode_ci","ApplyMethod":"pending-reboot"}
  ]'

サーバーパラメータの変更は「これから作られるオブジェクトの既定値」と「明示指定の無い接続の既定値」に効くだけで、既存テーブルの文字セットは変わりません。既存データの変換は `ALTER TABLE` が必要です。`ApplyMethod` は上記1)で確認した `ApplyType` に合わせてください(`static` のパラメータに `immediate` を指定するとエラーになります)。

結果の読み方

意味確認するポイント
TABLE_SCHEMA / TABLE_NAME対象スキーマとテーブルアプリケーションが実際に使うスキーマに絞れているか
INDEX_NAMEインデックス名主キーか二次インデックスかで対処の選択肢が変わる
index_columnsインデックスの構成列複合インデックスは全列のバイト長の合計が上限に当たる
bytes_after_utf8mb4utf8mb4化後に必要となるキー長の見積り(バイト)767を超えるなら旧設定の環境で失敗。3072を超えるならどの設定でも失敗する
ROW_FORMATInnoDBの行フォーマット`DYNAMIC` / `COMPRESSED` かどうかでキー長上限の判定が変わる
TABLE_COLLATIONテーブル既定の照合順序utf8mb4系になっているか。列単位の設定も別途確認する
CHARACTER_OCTET_LENGTH現在の文字セットでの最大バイト数utf8mb3では3倍、utf8mb4では4倍になる。行サイズ上限の見積りに使う
size_mbデータ+インデックスの概算サイズ変換作業の重さの順序。大きいものほど事前の実測が必要

こういう状況で使います

  • 絵文字や一部の漢字を保存すると `Incorrect string value` エラーになる
  • 保存はできるが、絵文字が `????` や空文字になって戻ってくる
  • `ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4` が `Specified key was too long` で失敗する
  • テーブルはutf8mb4にしたのに、アプリケーションからは依然として文字化けする
  • 同じ文字列の比較結果が、変換前後で変わった(重複エラーが増えた/減った)

考えられる原因(可能性の高い順)

  1. 01

    utf8(utf8mb3)は3バイトまでしか格納できない

    MySQL 5.7の `utf8` は `utf8mb3` の別名で、1文字あたり最大3バイトです。絵文字や一部のCJK拡張漢字は4バイト必要なため、格納できません。

  2. 02

    インデックスのキー長上限に当たっている

    InnoDBのインデックスキーには上限があり、旧来の設定(`innodb_large_prefix` 無効、`COMPACT` / `REDUNDANT` 行フォーマット)では767バイト、`DYNAMIC` / `COMPRESSED` では3072バイトです。utf8mb4は1文字4バイト換算になるため、`VARCHAR(255)` の単独インデックスで1020バイトを要求し、767バイト上限では失敗します。

  3. 03

    接続側の文字セットが揃っていない

    テーブルがutf8mb4でも、接続がutf8mb3なら4バイト文字はサーバーに届く前に落ちます。ドライバの接続文字列や `SET NAMES` の指定を確認してください。

  4. 04

    列単位の指定が残っている

    テーブル既定を変えても、列に明示的な文字セットが指定されていればその列は変わりません。列単位の洗い出しが必要です。

  5. 05

    照合順序の違いで比較結果が変わった

    `utf8mb4_general_ci` と `utf8mb4_unicode_ci` では等価とみなす文字の範囲が異なります。照合順序を変えると、一意制約に引っかかる行の集合が変わることがあります。

確認手順

  1. 1

    サーバー・データベース・テーブル・列の4階層で現在値を確認する

    参照のみ

    上位の設定は既定値にすぎず、下位に明示指定があればそちらが勝ちます。4階層すべてを参照専用SQLで確認します。

  2. 2

    utf8mb4でないテーブル・列を一覧化する

    参照のみ

    `information_schema.TABLES` と `information_schema.COLUMNS` で対象を確定します。

  3. 3

    キー長上限に当たるインデックスを洗い出す

    参照のみ

    変換を実行する前に必ず行います。ここで出た表は、変換前にインデックス定義の見直しが必要です。

  4. 4

    行フォーマットと `innodb_large_prefix` の状態を確認する

    参照のみ

    MySQL 5.7互換環境では `SELECT @@global.innodb_large_prefix, @@global.innodb_default_row_format;` で確認します。MySQL 8.0では `innodb_large_prefix` は削除されています。

  5. 5

    検証環境で1テーブルを変換して所要時間と結果を測る

    本番同等のデータ量で実測します。ここで得た時間が唯一の計画根拠になります。

  6. 6

    照合順序変更による比較結果の差を確認する

    一意制約のある列で、変換後に重複が発生しないかを検証環境で確認します。

対応方法

すぐに実施できる低リスクの対応

  • 接続側をutf8mb4に揃える

    アプリケーションの接続文字セットを `utf8mb4` にします。テーブル変換より先にこれを済ませておくと、変換直後から正しく扱えます。

  • 対象と規模を確定させる

    参照のみ

    洗い出しSQLの結果を作業一覧にします。テーブル数とサイズが分かるまで、日程は決められません。

事前検討が必要な変更

  • キー長超過のインデックスを先に手当てする

    列長を短くする(`VARCHAR(255)` → `VARCHAR(191)` など)、プレフィックス長を指定する、インデックス自体を見直す、のいずれかを選びます。いずれもスキーマ変更です。

  • 行フォーマットを `DYNAMIC` に揃える

    3072バイト上限を使えるようにします。MySQL 5.7互換環境では `innodb_large_prefix` の有効化とセットで確認が必要です。テーブルの作り直しを伴います。

  • 照合順序を決めて全テーブルで統一する

    テーブルごとに照合順序が異なると、結合時に照合順序の不一致エラーが起きます。移行時に統一してください。

再起動・サービス影響を伴う変更

  • `ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4` を実行する

    テーブルを作り直すため、大きなテーブルでは長時間かかり、その間の書き込みが止まります。所要時間は実測値をもとに計画してください。

  • オンラインスキーマ変更ツールで変換する

    `pt-online-schema-change` や `gh-ost` を使うと書き込みを止めずに変換できますが、コピー用テーブルの分だけストレージを消費し、レプリケーションやトリガーとの相互作用を事前検証する必要があります。

  • 新クラスターへ再ロードして切り替える

    専門家レビュー必須

    テーブル数が多い場合、utf8mb4で作った新環境へデータを入れ直し、切り替える方が確実なことがあります。切り替え計画は移行計画の記事を参照してください。

!注意事項

  • `CONVERT TO CHARACTER SET` はテーブルを作り直します。テーブルサイズに比例した時間とストレージ、そして書き込み停止が必要です。無停止で終わる作業ではありません。
  • 変換によって列の最大バイト数が増えるため、行サイズやインデックスキー長の上限に新たに当たることがあります。事前の洗い出しなしに実行しないでください。
  • 照合順序を変えると文字列の比較・並び替えの結果が変わります。一意制約のある列では、変換後に重複エラーが出る可能性があります。
  • サーバーパラメータの変更だけでは既存テーブルは変わりません。逆に、テーブルだけ変えても接続側がutf8mb3なら文字は落ちます。両方揃えてください。
  • 4バイト文字を含むデータを既にutf8mb3列へ入れようとして失敗している場合、失われたデータは変換では戻りません。アプリケーション側のエラーログを先に確認してください。
  • 所要時間の目安は本記事では示しません。テーブルサイズ・インスタンスクラス・同時負荷で大きく変わるため、必ず検証環境で実測した値を使ってください。

バージョン・環境による違い

MySQL 5.7互換(Aurora MySQL 2.x)`utf8` は `utf8mb3` の別名です。`innodb_large_prefix` と `innodb_default_row_format` の組み合わせによってキー長上限が767バイトになる場合があります。
MySQL 8.0互換(Aurora MySQL 3.x)`innodb_large_prefix` は削除され、既定の行フォーマットは `DYNAMIC` です。`utf8` を文字セット名として使うことは非推奨扱いになっています。`utf8mb4_0900_ai_ci` はMySQL 8.0系で追加された照合順序で、5.7互換環境では使えません。
照合順序の選び方`utf8mb4_general_ci` は比較規則が単純、`utf8mb4_unicode_ci` はUnicodeの照合規則に沿った比較を行います。`utf8mb4_0900_ai_ci` はMySQL 8.0の既定です。どれを選ぶかで比較結果が変わるため、既存データでの重複判定を検証してから決めてください。

これで解決しない場合に確認すること

  • アプリケーションのドライバ設定を確認する

    JDBCの `characterEncoding`、PHPの `charset`、各言語のクライアントライブラリの既定値が `utf8mb4` になっているかを確認します。

  • 結合するテーブル間で照合順序が揃っているかを確認する

    照合順序が異なる列を結合すると、実行時エラーやインデックス不使用の原因になります。

  • ストアドプロシージャ・ビュー・トリガーの文字セットを確認する

    ルーチンは作成時の文字セットを保持します。テーブル変換後に作り直しが必要な場合があります。

  • レプリカやDMSのターゲットも同時に変換されるかを確認する

    ソースだけ変換するとレプリケーション先で不整合や適用エラーが起きます。

  • バックアップからの復元手順で文字セットが維持されるかを確認する

    切り戻しの際に、変換前の定義に戻せることを事前に確認してください。

この文書の根拠と限界

製品の公式ドキュメントに基づく説明

MySQLの文字セット・照合順序(`utf8mb3` / `utf8mb4`、`utf8mb4_general_ci` / `utf8mb4_unicode_ci` / `utf8mb4_0900_ai_ci`)、InnoDBのインデックスキー長上限と行フォーマット、`ALTER TABLE ... CONVERT TO CHARACTER SET` の公開仕様、およびAmazon Auroraのクラスターパラメータグループの公開仕様に基づきます。変換の所要時間は環境依存のため記載していません。

よくある質問

utf8とutf8mb4は何が違いますか?

MySQL 5.7では `utf8` は `utf8mb3` の別名で、1文字あたり最大3バイトまでしか格納できません。絵文字や一部のCJK拡張漢字は4バイト必要なため、`utf8mb4` でなければ保存できません。MySQL 8.0では `utf8` を別名として使うことは非推奨になっています。

Productionで実行できますか?

洗い出し用のSQLはすべて参照専用なので本番で実行できます。`ALTER TABLE ... CONVERT TO CHARACTER SET` はテーブルの作り直しを伴い、その間の書き込みが止まるため、規模に応じて計画停止またはオンラインスキーマ変更ツールを使ってください。

ALTER TABLE が「キーが長すぎる」と失敗するのはなぜですか?

utf8mb4では1文字を4バイトとして計算するため、インデックスのキー長が増えるからです。`VARCHAR(255)` の単独インデックスは1020バイトになり、767バイト上限の環境では必ず失敗します。列長の短縮、プレフィックス長の指定、行フォーマットの見直しのいずれかを先に行ってください。

どの照合順序を選べばよいですか?

既存の比較結果を変えたくないかどうかで決まります。`utf8mb4_general_ci` と `utf8mb4_unicode_ci` では等価とみなす文字の範囲が異なり、一意制約のある列では重複判定が変わる可能性があります。`utf8mb4_0900_ai_ci` はMySQL 8.0互換環境でのみ使えます。検証環境で実データを使って重複を確認してから決めてください。

どの権限が必要ですか?

調査SQLは `information_schema` を参照できる権限で足ります(メタデータ可視性のルールに従うため、権限の無いオブジェクトは結果に出ません)。変換には対象テーブルへの `ALTER` 権限、パラメータグループの変更にはIAM権限が必要です。

サーバーパラメータをutf8mb4にすれば既存テーブルも変わりますか?

変わりません。パラメータはこれから作られるオブジェクトと、明示指定の無い接続の既定値に効くだけです。既存データはテーブルごとの `ALTER TABLE` が必要です。

この文書がカバーする質問

  • MySQLで絵文字を保存すると Incorrect string value になる
  • utf8mb4に変換したらインデックス作成に失敗する
  • utf8とutf8mb4のどちらを使うべきか
  • Aurora MySQLの既定文字セットをutf8mb4に変えたい

リスク表示の意味

  • 参照のみデータと設定を変更しません。
  • 影響は限定的ですが、権限と負荷の確認が必要です。
  • 性能・ロック・コストに影響する可能性があります。
  • 障害・データ損失・復旧作業が発生する可能性があります。
  • 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

文字セット移行は「一度やれば終わる」作業に見えますが、実際には移行後も列の追加やテーブルの新規作成のたびに設定が揺れます。GIIPでは、utf8mb4化の対象洗い出しSQLを定期実行して、utf8mb4以外の列が新たに増えていないかを継続的に点検しています。差分が出たときだけ通知し、スキーマ変更の是非は人が判断する形にしているため、移行が終わった後も設定が元に戻っていくことを防げます。

執筆・技術検証

GIIP プロダクション運用チーム

大規模Webサービス、SQL Server、Oracle、AWS、Azureの設計・移行・運用に約30年従事。x12largeクラスのAWS RDS for SQL Server環境12セット、約12万テーブルのOracle環境、約3TBのTiDBからAurora MySQLへの移行を経験。現在も複数のクラウドデータベースと約30のWebサービスを、AIエージェントと人間の専門家が継続的に監視・運用しています。

関連するナレッジ

関連サービス

文字セット変換の検証環境づくりを相談する

同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。

文字セット変換の検証環境づくりを相談する

ナレッジベース一覧へ