MySQLでTEXTの代わりにVARCHARフィールドを使用する理由

背景

データベースに、長さが不確かなシリアライズされたデータを格納する場合、多くの人がテーブルスキーマでフィールドを VARCHAR(2000) として設計します。

しかし、長さが不確かな場合、なぜ TEXT 型を使用しないのでしょうか？一部の人は言います。「TEXTはクエリのパフォーマンスに影響を与える」と。

それは本当に理由なのでしょうか？この記事では、それを探求します。

TEXTとは

TEXT は、MySQLの可変長データ型であり、TINYTEXT、TEXT、MEDIUMTEXT、LONGTEXT が含まれます。これらは通常、大量のテキストデータを格納するために使用され、以下のストレージ制限があります。

• TINYTEXT: 0 - 255 バイト
• TEXT: 0 - 65,535 バイト
• MEDIUMTEXT: 0 - 16,777,215 バイト
• LONGTEXT: 0 - 4,294,967,295 バイト

TEXTの保存方法

各 BLOB または TEXT の値は、内部的には個別に割り当てられたオブジェクトによって表現されます。一方、他のデータ型は、テーブルが開かれたときにカラムごとに一度だけストレージスペースが割り当てられます。

文字列型のデータを格納する場合、InnoDBは768バイト以上の固定長フィールドを可変長フィールドとしてエンコードし、オーバーフローページに格納します。768バイト未満のデータは、データ行に直接格納されます。 したがって、他の文字列型を使用する場合は、768バイト以上のデータを格納することは避けてください。

TEXTの制限

• TEXT はデフォルト値を持つことができません。
• TEXT フィールドにインデックスを作成する場合、プレフィックス長を指定する必要があります。
• インデックスエントリを比較する際、末尾のスペースがパディングされます。一意のインデックスが必要な場合、これにより重複キーエラーが発生する可能性があります。
• TEXT フィールドは特に長くなる可能性があります。ソート時、最初の max_sort_length バイト（デフォルトは1024）のみが使用されます。この値は、変数を変更することで調整できます。

-- View max_sort_length
SELECT @@max_sort_length;

-- Set max_sort_length
SET max_sort_length = 2048;

• 一時テーブルで処理される場合、MEMORY ストレージエンジンは TEXT 型をサポートしていないため、サーバーはメモリ内ではなくディスク上のテーブルを使用します。

• TEXT オブジェクトのサイズはその型によって決定されますが、実際に転送可能な最大サイズは、利用可能なコンテンツと通信バッファサイズによって制限されます。これは、max_allowed_packet 変数を変更することで調整できます。

-- View max_allowed_packet
SELECT @@max_allowed_packet;

-- Set max_allowed_packet
SET max_allowed_packet = 67108864;

結論

TEXT は大量のテキストデータを格納するために使用できます。ただし、いくつかの理由から、TEXT を使用することはお勧めできません。

パフォーマンスの問題

• TEXT は内部的には個別に割り当てられたオブジェクトとして表現されるため、保存と検索の際に追加の操作とリソース消費が必要になります。
• TEXT フィールドが特に大きい場合、それを読み込むとメモリ圧迫が増加し、システム全体のパフォーマンスに影響を与える可能性があります。
• MEMORY ストレージエンジンは TEXT をサポートしていない ため、一時テーブルが使用される場合、TEXT フィールドからのデータはメモリから直接ではなく、ディスクから読み込まれます。

インデックスの制限

インデックスはクエリのパフォーマンスを向上させることができますが、TEXT フィールドにインデックスを作成するには、特定の制限と複雑さが伴います。

• 一意のインデックスとして使用すると、重複キーエラーが発生する可能性があります。
• フルテキストインデックスを作成するには、追加の計算とスペースを維持する必要があります。TEXT フィールドが大きすぎると、パフォーマンスに悪影響を与える可能性があります。

したがって、テーブルスキーマの設計では TEXT 型の使用を避ける ことをお勧めします。どうしても使用する必要がある場合は、次のアプローチを検討してください。

• TEXT フィールドを独立したテーブルに分離し、主キーを介してメインテーブルにリンクします。
• 必要がない限り、TEXT フィールドの読み込みを避けます。たとえば、SELECT * を使用しないようにします。
• 大きなフィールドの場合は、OSS（オブジェクトストレージサービス）に格納することを検討してください。

---

Leapcellは、バックエンドプロジェクトをホストするための最高の選択肢です。

Leapcell は、Webホスティング、非同期タスク、およびRedis向けの次世代サーバーレスプラットフォームです。

多言語サポート

• Node.js、Python、Go、またはRustで開発します。

無制限のプロジェクトを無料でデプロイ

• 使用量に対してのみ支払い - リクエストも料金もありません。

圧倒的なコスト効率

• アイドル料金なしの従量課金制。
• 例：25ドルで、平均応答時間60ミリ秒で694万リクエストをサポートします。

合理化された開発者エクスペリエンス

• 簡単なセットアップのための直感的なUI。
• 完全に自動化されたCI/CDパイプラインとGitOps統合。
• 実用的な洞察のためのリアルタイムのメトリクスとロギング。

容易なスケーラビリティと高パフォーマンス

• 高い同時実行性を簡単に処理するための自動スケーリング。
• 運用上のオーバーヘッドはゼロ - 構築に集中するだけです。

ドキュメントで詳細をご覧ください!

X: @LeapcellHQをフォローしてください