分析エンジンはカラムナストレージでデータを構築しているため、特定のMySQL使用シナリオではサポートされない場合があります。以下の通りです：
主キーなしかつユニークキーなしのテーブルサポート説明
1.2404.x バージョンでは：テーブルに主キーもユニークキーもない場合、そのテーブルは分析エンジンにロードできません。このため、テーブルには主キーまたはユニークキーが必須です。LibraDBエンジンでは、デフォルトでテーブルの主キーまたはユニークキーを使用してカラムナデータを構築します。また1.2404.x バージョンでは、テーブルの主キーを変更するあらゆる形式のDDL文をサポートしていません。TDSQL-C for MySQLで主キーを変更すると、分析エンジンにおける当該テーブルのロードは停止し、クエリ不可となります。使用を再開するには、当該テーブルのロードを解除してから、再度データをロードする必要があります。
2.2410.x バージョンでは：テーブルに主キーもユニークキーもない場合でも、分析エンジンにロードできます。同時にテーブルの主キー変更操作もサポートしています。ただし、依然として一部の特殊なシナリオではサポートされず、サポートされないシナリオは以下の通りです：
テーブルには time、date、timestamp、datetime、float、double のフィールドのみが存在し、他のフィールドタイプはありません。
テーブルに対して主キーのDDLを実行した結果、テーブルには上記のフィールドタイプのみが存在し、他のフィールドタイプが存在しない場合となります。
フロート型、ダブル型のフィールドを主キーとして使用するテーブルは分析エンジンへのロードをサポートしていません
float、doubleフィールドは浮動小数点型フィールドであり、これら2種類のフィールドタイプを主キーとして使用するテーブルの分析エンジンへのロードはサポートされていません。
ストアドプロシージャ、ユーザー定義関数、トリガー、外部キー制約、イベント、インデックスはいずれも分析エンジンにロードされません
カラムナストレージでの上記特殊オブジェクトの構築はサポートしていません。
空間データ型のフィールドが存在するテーブルは分析エンジンにロードできません。Json フィールドタイプはロード可能ですが、クエリ不可となります
空間フィールドタイプが存在するテーブルは分析エンジンにロードできません。Jsonフィールドが存在するテーブルを分析エンジンでクエリする場合、Json列の値は空になります。
一時テーブルの分析エンジンへのロードはサポートしていません
一時テーブルのデータ変更はログに記録されないため、一時テーブルのデータを分析エンジンにロードできません。
分析エンジンにロードされたテーブルがリネームされた後の動作
あるテーブルが分析エンジンにロードされた後、rename文を使用してテーブル名を変更すると、リネーム後のテーブルも分析エンジンに自動的にロードされます。その後、リネーム前のテーブルと同じ名前で新規テーブルを作成すると、この新規テーブルも分析エンジンに自動ロードされます。例えば、表Aが分析エンジンに列ストレージとしてロードされている状態で、表Aを表Bにリネームすると、分析エンジン内の当該テーブルも表Bに変更されます。同時に、読み書きインスタンスで新たに表Aを作成した場合、表Aも同様に分析エンジンに自動ロードされます。
主キーフィールドが超長数値型のテーブルの列ストレージへのロードはサポートされていません
バージョン1.2404.xでは、主キーがDecimal型で128を超える長さのテーブルを列ストレージとしてロードすることはサポートしていません。
バージョン2.2410.xでは、主キーがDecimal型で256を超える長さのテーブルを列ストレージとしてロードすることはサポートしていません。
カラムレベル権限はサポートしていません
分析エンジンはデフォルトで読み書きインスタンス内の全ユーザーオブジェクトに対するクエリ権限を同期しますが、カラムレベル権限は同期しません。したがって、分析エンジンではカラムレベル権限の管理を実現できません。
サポートされていないデータ型
分析エンジンでは一部のデータ型がサポートされていません。オブジェクトにサポートされていないデータ型が含まれる場合、当該テーブルは分析エンジンにロードできません。 サポートされていないテーブル構造
分析エンジンは生成カラム構文（仮想カラムおよび物理カラムのいずれも）をサポートしていません。生成カラムを含むテーブルは分析エンジンにロードできません。
サポートされていないフィールドタイプのコンバージョン
分析エンジンでは一部のフィールドタイプ変換がサポートされていません。TDSQL-C for MySQLの読み書きインスタンスでフィールドタイプを変更した場合、分析エンジンのデータロードタスクが中止され、すべてのテーブルのロード状態が一時停止中になる可能性があります。詳細な型変換のサポート状況については、型変換関数のサポート説明をご参照ください。 注意：
TDSQL-C for MySQL でテーブルのフィールドタイプを変更する場合、その変更が分析エンジンでサポートされていないと、すべてのテーブルのロード状態が一時停止します。使用を再開する必要がある場合、当該テーブルをロードから削除した後、再度そのテーブルに対してデータの再ロードを行う必要があります。
パーティションテーブルのDDL同期説明
バージョン1.2404.xにおいて：パーティションテーブルはデフォルトで分析エンジンにロード可能であり、クエリをサポートします。ただし、パーティションテーブルのパーティションに対する関連するDDLの同期（例：パーティションの再構築、パーティションのOPTIMIZE、パーティションの修復、パーティションのCHECK、パーティションの交換、パーティションの削除、パーティションの統合など）はサポートされません。また、分析エンジンでは個別のサブパーティションに対するクエリもサポートされていません。
注意：
TDSQL-C for MySQLの読み書きインスタンスでパーティションテーブルのサブパーティションをドロップする場合、パーティションをtruncateする場合、またはパーティションをexchangeする場合、当該テーブルは分析エンジンでクエリ不可となります。使用を再開する必要がある場合、当該テーブルをロードから削除した後、再度データの再ロードを行う必要があります。
バージョン2.2410.xにおいて：パーティションテーブルを分析エンジンにロードすることをサポートし、ソース側でパーティションテーブルに対する以下のDDL変更をサポートします。
Range/ListパーティションテーブルのDrop Partition/Subpartitionテンプレートをサポートします。
Range/ListパーティションテーブルのAdd Partition/Subpartition templateをサポートします。
関数を使用しないシナリオでは、サポートされているパーティションデータ型は以下の通りです：Uint8、Uint16、Uint32、Uint64、Int8、Int16、Int32、Int64。
サポートされているパーティション関数は以下の通りです：year、month、day、to_days、unix_timestamp。これらの関数がサポートするデータ型は：DATE、DATETIME、TIMESTAMPです。なお、to_days関数は文字列を関数の引数としてサポートします。
通常テーブルのDDL同期説明
TDSQL-C MySQLの読み書きインスタンスにおいて、テーブルに対するDDL操作はすべて正常に分析エンジンに同期されます。ただし、以下のようなシナリオでは、分析エンジン下でのテーブル使用時に異常な挙動が発生する可能性があります：
分析エンジンでは一部の
テーブルに対するPT変更、Gh-ost変更、Alibaba Cloud DMSのロックフリー変更シナリオは、いずれも正常に同期されます。
行数が100万を超えるテーブルに対する主キー関連の変更（追加、削除、主キー変更）は、当該テーブルの分析エンジンへの同期が一時停止される原因となります。100万行を超えるテーブルの主キー変更操作については、PTツールなどを用いたDDL実行をおすすめします。