テーブルに最初はvarchar(255)だった列がありますが、いくつかの設計変更によりvarchar(1536)= 1024 + 512になりました。このフィールドを検索したりインデックスを付けたりすることはありません。パフォーマンスのためにこれを最適化する場合、varchar以外の異なるデータ型にこの値を保存するには?
他の人が言ったようにTEXT
を使用する必要がありますが、TEXTまたはBLOBを使用するたびにいくつかの重要なアドバイスがあります:ベーステーブルからそれらを分離します次の構造を想像してください。
CREATE TABLE article (
id INT(10) UNSIGNED,
title VARCHAR(40),
author_id INT(10) UNSIGNED,
created DATETIME,
modified DATETIME
);
CREATE TABLE article_body (
id INT(10) UNSIGNED,
body TEXT
);
記事をリストするときはいつでも、article
テーブルを使用できます(著者33の最後の5件の記事):
SELECT id, title FROM article WHERE author_id=33 ORDER BY created DESC LIMIT 5
そして、誰かが本当に記事を開くとき、あなたは次のようなものを使うことができます:
SELECT a.title, ab.body
FROM article AS a
LEFT JOIN article_body AS ab ON ab.id = a.id
WHERE a.id=82
これを保存するには、データベースではなくファイルを使用する必要があります。特にMySQLではありません。たとえば、データベースBLOBから画像をダウンロードした場合に何が起こるかを説明した記事を書きました。 http://mysqldump.azundris.com/archives/36-Serving-Images-From-A-Database.htmlを参照してください。 。ファイルを使用すると、sendfile(2)システムコールを使用してWebサーバーの高速パスを使用できます。これを使用する方がはるかに高速です。
MySQLにはBLOB APIもありません。つまり、max_allowed_packetより大きいオブジェクトをアップロードまたはダウンロードすることは不可能であり、SUBSTRING()を使用してサーバーメモリ内の文字列の不必要なコピーを作成するため、回避するのは困難です。
サーバーにBLOBまたはTEXTデータを絶対に保存する必要がある場合、サーバーで255、65535、16 MB、および4GBのデータに制限されているTINYTEXT、TEXT、MEDIUMTEXTおよびLARGETEXTを選択でき、さらにmax_allowed_packetによって制限されます。
大きなBLOBまたはTEXT情報は、テーブル内のデータ密度を完全に破壊します。 BLOBテーブルへの人為的な1:1または1:0の関係を作成し、この追加のテーブルにBLOBを保存すると便利です。
MySQLが「テンポラリーを使用している」クエリプランを表示する場合、サーバーは結果を配信する前にサーバーで結果セットテーブルを具体化する必要があることを意味します。可能であれば、これはMEMORYテーブルを使用して行われます。 TEXT型またはBLOB型はMEMORYテーブルで表すことができないため、一時テーブルは代わりにMyISAMテーブルとしてディスクにヒットします。
そのようなクエリプランをスキャンし、代わりにBLOB/TEXT値のID値をロードするものに変換する必要があります。 2番目のクエリでは、IDを選択し、text FROM texttable WHERE id in(...)でTEXT/BLOB値を取得します。これにより、「temporaryを使用」するクエリはTEXT型またはBLOB型を使用せず、「temporaryを使用する」ことなく実行される簡単なクエリでTEXTフィールドを取得できます。
http://www.mysqlperformanceblog.com/2010/02/09/blob-storage-in-innodb/ を読むことで、MySQL TEXTおよびBLOBストレージの内部について詳しく知ることができます。
可変長の列にはtext
を使用します。