- 締切済み
MySQLのvarchar型とtext型について
以下のURLのページを読んだのですがよく理解できません。。。 http://dev.mysql.com/doc/refman/4.1/ja/storage-requirements.html http://dev.mysql.com/doc/refman/4.1/ja/blob.html 例えば'abc'という文字列を格納するとした場合、記憶容量は varchar型では3+1バイト、text型では3+2バイトとなるようですが、 1バイト(varchar)と2バイト(text)の違い以外で、 text型の方がDBに負担がかかるとか不利になるようなことはありますか？ text型では格納する文字列の長さに関係無く、65535バイトを常に確保しているとか… text型の方が動作が遅いとか… 現状、255バイト以下を想定しているのでvarchar(255)にするつもりですが、 将来的に256バイト以上となることもありえるので 最初からtext型にしていた方がいいのでしょうか？ また、将来text型に変更した際にパフォーマンスが落ちる等といったことがありえるのでしょうか？ 宜しくお願い致します。
- karace
- お礼率57% (134/234)
- MySQL
- 回答数2
- ありがとう数1
- みんなの回答 （2）
- 専門家の回答
みんなの回答
- yambejp
- ベストアンサー率51% (3827/7415)
#１です。 そういえば部分インデックスがありましたね。 使ったことないので忘れてました。失礼しました。 私見でもうしわけないですが部分インデックスは若干 運用方法も気をつける必要がありそうなので、 微妙な気がします。 とりあえず＃１の私の回答は参考にならなかったような ので、あとは誰か別の人にきいてください
- yambejp
- ベストアンサー率51% (3827/7415)
容量よりむしろtextはindexがきかないということの 方が大きいのでは？ 当然プライマリにもユニークにも対応しませんので 正規化する場合のキーとして使用に耐えないでしょう 自然と、textとvarcharは使用方法が違ってくると思います。
関連するQ&A
- PostgreSQLのvarcharとtext
性能を考えた場合、文字列を格納するカラムはvarcharとtextではやはりvarcharの方が優れているのでしょうか？ 文字列には最大120文字しか入れない想定です。 それともバージョンによっては、特に差異はないとかありますか？
- ベストアンサー
- PostgreSQL
- mysqlで長さ無制限の文字列を格納することはできますか？
mysqlを用いて掲示板を作りたいです。その際に、簡素化のため、掲示板の全てのデータをmysqlに格納したいと思っています。 また、掲示板における本文の部分は、文字列の長さを無制限にするのが妥当だと思います。 しかし、mysqlのマニュアル（http://dev.mysql.com/doc/mysql/ja/BLOB.html）によると、一番大きい型であるLONGBLOB型の記憶容量は 2^32バイトとなっており、それを超える文字列は切り捨てられるとなっています。 そこで、ご教授いただきたいです。 長さ無制限の文字列をmysqlに格納する方法はありますか？そしてその場合はどうすればよいですか？ それとも、長さ無制限の文字列をmysqlに格納する方法ははなく、その場合は別ファイルを用意し、そちらに書き込むなどをする必要がありますか？ どうぞよろしくお願いします。
- ベストアンサー
- MySQL
- MySQL5.1の文字列サイズは文字数ではない？
blue-horse と申します。 お世話になります。 MySQL 5.1 でVARCHAR、CHAR などの字列型フィールドのサイズ指定は、文字数であると認識していたのですが、違うのでしょうか。 utf8の日本語を保存しようとすると、3倍のサイズを要してしまいます。 これはutf8の漢字は3バイトであることと符合するので、なんとなく理解できるのですが、MySQL5.1のリファレンス記述と一致しない様に見えて、納得できません。（不便ですし） >CHAR と VARCHAR タイプには、格納したい最大文字数を表す長さが宣言されています。例えば、CHAR(30) は最大30文字まで持つ事ができます。 「MySQL :: MySQL 5.1 リファレンスマニュアル :: 10.4.1 CHAR と VARCHAR タイプ」 より http://dev.mysql.com/doc/refman/5.1/ja/char.html あるいは、どこか設定を誤っているのでしょうか。 ご教示頂ければ有り難く存じます。 以上、失礼いたします。
- ベストアンサー
- MySQL
- My-SQLのUserと、予約文字列
http://dev.mysql.com/doc/refman/4.1/ja/reserved-words.html 予約されている文字列はUser名として使えないのでしょうか？ また大文字でも小文字でも区別はなく使えないのでしょうか？
- 締切済み
- MySQL
- MySQL5.1で varchar(100)のものを varchar(
MySQL5.1で varchar(100)のものを varchar(90)にする予定です。 （後ろの10バイトは無条件になくなっても構いません） 通常の手順ではalter tableを使います。 今回は、他の項目も変更（auto_incrementやキーの追加）するので 一度 mysqldumpでSQLを吐き出して、 CREATE文の以下を変更 varchar(100) → varchar(90) auto_incrementやキーの追加 そして、mysqlでリストアします。 この方法は、アリでしょうか？ 他のデータベース(PostgreSQL, SQLServer, Oracle)でも使える手法でしょうか？ 皆さんのvarchar(100) → varchar(90)する方法が知りたいです。
- ベストアンサー
- MySQL
- 「VARCHAR(255)」を「text」に。種別変更
MySQL 4.0.27を利用しております。 操作はphpMyAdminで行っております。 １つの項目がかなりの文字数になりつつあり、 VARCHAR(255)では、入りきらないデータがでてきました。 そこで「VARCHAR(255)」を「text」に変更しようと 思います。 この時、データが入ったまま種別変更を行っても データが消えたりすることはないでしょうか？ もしよければ「text」にした場合のデメリットも お教えください。よろしくお願いします。
- ベストアンサー
- MySQL
- MySQL TIMESTAMP型は、UTCですか?
MySQL5で、 TIMESTAMP型のカラムに格納されるのは、UTCでしょうか。 それともローカルタイムゾーンなのでしょうか？ あるいは、設定による、のでしょうか？ ＞TIMESTAMP カラムの値は、ストレージでは現在のタイム ゾーンから UTC へ、読み出しでは UTC からカレントのタイム ゾーンに変換します。 http://dev.mysql.com/doc/refman/5.1/ja/time-zone-support.html と書いてあったのを見て、TIMESTAMP型のカラムに格納されるのは、UTC(日本時間-9)だ、と思ったのですが、 実際にカラムの中を確認してみると、その時点の日本時間が格納されています。 ＞TIMESTAMP 値は、現在のタイムゾーンから変換されて格納され、また検索された時に現在のタイムゾーンに再変換されながら、ＵＴＣに格納されます。 http://dev.mysql.com/doc/refman/5.1/ja/timestamp-4-1.html こちらでも、「ＵＴＣに格納されます」って書かれているのですが、 これは、「現在のタイムゾーンをそれぞれの接続ごとに設定した場合」に限っての話なのでしょうか？ それとも、ストレージでは、って書かれているので、 ストレージのことが絡んでいるのでしょうか？(ストレージって何のことですか)
- ベストアンサー
- MySQL
- MySQLのvarcharについて
今までPostgreSQLを利用していたのですが、MySQLもテストで一回使ってみよと思い触ってみたところ・・・ varchar(20)のカラムに、文字列型で「4571170731101」という値を登録するとDB上では「2147483647」となってしまいます。 int型？とかに解釈されてるんでしょうか。意味がわかりません。 どなたか助けてください。
- ベストアンサー
- MySQL
- MySQL4.1以上でのchar,varcharの定義について
環境はWindowsXP + MySQL5.0です。 MySQL5.0でテーブルを作成したところ、varchar(10)の列に入力可能なデータは『10バイト分』でななく『10文字分』でした。 （「1234567890」や「abcdefghij」に加え、「あいうえおかきくけこ」も入力可能だった） 従来（？）の『varchar(10) = 10バイト分入力可能』で定義したいのですが、なにか方法はないでしょうか？ （「1234567890」や「あいうえお」は入力可能だが、「あいうえお1」は入力不可にしたい） http://www.mysql.gr.jp/frame/modules/bwiki/index.php?FAQ#u0cc977e ↑こちらのページによると、MySQL4.1からこのような仕様になったようですが、MySQLのバージョンは5.0のままでなにか方法はないものかと探しております。 よろしくお願いします。
- ベストアンサー
- MySQL
- ロールバックできないステートメントについて
こんばんは。 既存のテーブルのカラムを削除することになりまして、 以下の手順で変更をかけました。 環境：mysql_5.5 mysql>begin; mysql>alter table test_table drop column test_column; mysql>desc test_table; mysql>rollback; mysql>desc test_table; しかし、ロールバックをかけても元に戻らなかったのですが、 http://dev.mysql.com/doc/refman/5.1/ja/cannot-roll-back.htmlhttp://dev.mysql.com/doc/refman/5.1/ja/cannot-roll-back.html の記述にあるようにバージョン5.5でもalterでのロールバックは出来ないのでしょうか。 英語のサイトを見たのですが、ただしく訳せませんでした。 http://dev.mysql.com/doc/refman/5.5/en/implicit-commit.htmlhttp://dev.mysql.com/doc/refman/5.5/en/implicit-commit.html 回避方法があったら、教えてください。
- 締切済み
- MySQL
お礼
回答ありがとうございます。 ですが、MySQL3.23.2以降ではindexは効くようです。