高性能MySqlの進化(2): データ型の最適化_その2

T BLOB/Text

実際のアプリケーションでは、数万ワードの大容量の記事が 2 つ必要になります。 Oracle では、これら 2 つのタイプのデータを扱うために BOLB と CLOB がありますが、MySQL では、BLOB と TEXT に対応します。
これら 2 つのデータ型の特殊性を考慮して、BLOB と TEXT の特別な保存と操作が行われます。 MySQL 処理:
1) BLOB/TEXT 値はオブジェクトとして処理されることが多く、これらのオブジェクトには独自の ID と独立した記憶領域があります
2) BLOB/TEXT 値がソートに使用される場合、最初の N 文字のみがセクションになります。 N はデータベース内の定数値 (max_sort_length) に対応します。並べ替えに使用するバイト数を指定したい場合は、max_sort_length の値を増やすか、ORDER BY SUBSTRING(column, length ) 関数を使用して、ハンドル
3) BLOB/TEXT がインデックスまたはソートとして使用される場合、フィールド全体の値は使用できません
BOLB/TEXT をインデックスまたはソートとして使用することは最後の手段として避けてください

MySQL のせいで、メモリ エンジンが使用します。 BLOB および TEXT タイプはサポートされていないため、クエリ プロセスに BLOB /TEXT が含まれる場合は、データ行が数行しかない場合でも、MyISAM ディスク一時テーブルを使用する必要があります (最新の Percona サーバー メモリ エンジンは BLOB および TEXT をサポートしています)タイプ）。

メモリ エンジンがディスク一時テーブルに頻繁にアクセスすると、重大なパフォーマンス オーバーヘッドが発生します。最善の解決策は、BLOB 型と TEXT 型の使用をできるだけ避けることです。これを回避できない場合は、BLOB フィールドが使用されるすべての場所で SUBSTRING(column, length) を使用して、列の値を文字列に変換します (ORDER BY 句でも機能します)。これにより、in を使用できるようになります。 -memory 一時テーブル。ただし、一時テーブルのサイズが max_heap_table_size または tmp_table_size を超えないように、インターセプトされた部分文字列が十分に短いことを確認してください。制限を超えると、MySQL はメモリ一時テーブルを MyISAM ディスク一時テーブルに変換します。

最悪の場合の長さの割り当てはソートでも同じであるため、このトリックは、メモリ内での大きな一時テーブルの作成とファイルの並べ替え、およびディスク上での大きな一時テーブルの作成とファイルの並べ替えの両方に適しています。役立つ。たとえば、数ギガバイトのディスク領域を占有する 1,000 万行のテーブルがあるとします。 utf8 文字セットの VARCHAR(1000) 列があります。各文字は最大 3 バイトを使用し、最悪の場合は 3,000 バイトのスペースが必要になります。このカラムが ORDER BY で使用され、クエリがテーブル全体をスキャンする場合、ソートには 30GB を超える一時テーブルが必要になります

· DATETIME/TIMESTAMP

MySQL には、通常使用中に DATETIME と TIMESTAMP という 2 つの時間形式が含まれています。 2 つのタイプはそれほど大きなものではありませんが、細部にはまだ違いがあります

TMESSTAMP の方が使用するストレージ容量が小さいため、デフォルトの時刻形式として使用できます

・ ENUM

このタイプは主にフィールドが使用します列値を保存するための列挙型の使用プロセスには列挙位置と実際の値の変換が含まれるため、全体のパフォーマンスに一定の影響を与える可能性があり、列挙値は .frm (データ テーブル構造定義ファイル) に保存されます。 ) なので、ENUM 列を作成した後、EMUM の内容を更新する場合は、テーブル構造を更新することと同じになります。以下は ENUM 列の例です:


R

mysql> CREATE TABLEenum_test(
->  e ENUM('fish', 'apple', 'dog') NOT NULL
-> );
mysql> INSERT INTOenum_test(e) VALUES('fish'), ('dog'), ('apple');

E

· Bit

ブール値に必要なスペースが最小限であることを示すフィールドを設計する必要がある場合、どのように設計しますか? INT または CHAR(1) を使用しますか? INT と CHAR(1) と比較すると、BIT(1) は 1 つのビットのみを使用するため、より良い選択である可能性があります。複数の BIT の値を BIT(N) の形式で表現でき、BIT(64) までサポートします。

MySQL 5.0 より前のバージョンでは、BIT は TINYINT と同等とみなされていましたが、新しいバージョンでは、2 つの完全に異なる型として扱われます。

データベースから BIT フィールドを取得してコンソールに表示すると、フィールドの値が数値演算のコンテキストにある場合、その値は 10 進数値として扱われます。 BIT の値について、次の例はこれら 2 つの状況を明確に示しています

mysql>CREATE TABLE bittest(a bit(8));
mysql> INSERT INTObittest VALUES(b'00111001');
mysql> SELECT a, a+ 0 FROM bittest;
+------+-------+
| a | a + 0 |
+------+-------+
| 9 | 57 |
+------+-------+

上の例では混乱するかもしれませんが、個別のビットを保存するためにこのメカニズムを使用したくない可能性が非常に高いです。関連するフィールドを CHAR(0) に設定するには、NULL を使用して False を表し、"" (空の文字列) で True を表します

上記は、高性能 MySql の進化 (2): データ型の最適化_の内容です。コンテンツについては、PHP 中国語 Web サイト (www.php.cn) にご注意ください。