A、MySQLのデータ型
これは、次の5つのカテゴリが含まれています。
整数型:BIT、BOOL、TINY INT、SMALL INT、MEDIUM INT、INT、BIG INT
浮動小数点型:FLOAT、DOUBLE、DECIMAL
文字列型:CHAR、VARCHAR、TINY TEXT、TEXT、MEDIUMのTEXT、LONGTEXT、TINY BLOB、BLOB、MEDIUM BLOB、LONG BLOB
日付タイプ:日付、日時、タイムスタンプ、時間、年
他のデータ型:BINARY、VARBINARY、ENUM、SET、ジオメトリ、ポイント、マルチポイント、ラインストリング、MultiLineStringの、ポリゴン、ジオメトリコレクションなど
1、整数
MySQLのデータ型 | (署名)の意味 |
TINYINT(M) | バイト範囲(127 -128) |
SMALLINT(M) | 2バイトの範囲(-32768〜32767) |
MEDIUMINT(M) | 3バイトの範囲(〜-8388608 8388607) |
INT(M) | 4バイトの範囲(2147483647に-2147483648) |
BIGINT(M) | 8バイト(18 + -9.22 * 10番目)の範囲 |
符号なしの範囲が増加した場合、最大値は、符号なしTINYINT範囲(0〜256)と、倍になります。
mは、実際の値の範囲に影響を与えません幅SELECTクエリの結果セットの表示でINT(m)は、私はこのメートルの使用であるかわからない、ディスプレイの幅に影響を与えませんでした。
図2に示すように、浮動小数点(floatとdouble)
MySQLのデータ型 | 意味 |
フロート(M、D) | 8ビット(4バイト)m個、D小数点以下の桁数の合計単精度浮動小数点精度 |
二重(M、D) | 合計16ビットの倍精度浮動小数点精度(8バイト)m個、D小数点 |
数123.45678挿入された場合、フィールドは、実際にデータベースに格納され、設定されたフロート(6,3)として定義されている123.457であるが、実際の被写体の総数、すなわち、6。12.12を挿入した場合に挿入12.123456の数は、12.1234は、格納されている場合、最大の整数部分は、3であり、ストレージは12.1200です。
図3に示すように、固定小数点
データベースに格納されたフロートは近似値であり、固定小数点型は、データベースに正確な値を記憶します。
小数(M、D)パラメーターM <65総数、D <30およびdは<mは小数です。
4、文字列(CHAR、VARCHAR、_TEXT)
MySQLのデータ型 | 意味 |
CHAR(n)は | 255文字までの長さを修正 |
VARCHAR(n)は | 65,535文字までの長さを修正しました。 |
TINYTEXT | 可変長、255文字まで |
テキスト | 可変長、65,535文字まで。 |
MEDIUMTEXT | 可変長、24文字の最大パワー-1 2 |
LONGTEXT | 可変長、2の32文字までパワー-1 |
文字和varchar型:
1.char(n)は文字数が少ないn個以上である場合、それはスペースを置き、その後、クエリのスペースを削除保存されています。char型は、文字列の末尾にスペースを持つことができないので、VARCHARは、これに限定され記憶されます。
2.char(n)は固定長、CHAR(4)のいずれかのいくつかの文字には、4バイトとなり、文字のVARCHAR実際の数はバイト+ 1(N <= 255)又は2に格納されていますバイト(N> 255)、
VARCHAR(4)は、3つの文字に4つのバイトを占有します。
文字列の検索速度より速い3.charタイプVARCHARタイプより。
varchar型とテキスト:
1.varcharを指定することができ、N、テキストを指定することができず、内部ストレージVARCHAR + 1に記憶されている実際の文字の数(N <= 255)または2バイト(N> 255)バイト、テキストは文字の実際の数である+2言葉
セクション。
2.textタイプには、デフォルト値を持つことができません。
3.varcharは、あなたがどのように多くの文字を指定したいのインデックスを作成する前に、テキストを直接インデックスを作成することができます。場合には、インデックスを作成しますvarchar型が速くテキストより照会し、テキストインデックスには効果がないようです。
図5に示すように、バイナリデータ(_Blob)
バイナリ、ケース鈍感に格納された様々な方法、テキスト、英語記憶大文字と小文字を区別として格納_TEXT、及び_Blobで1._BLOBと_textストレージ。
保存された2._BLOBデータは、全体として読み出すことができます。
3._TEXTは_BLOは、文字セットを指定していない、文字セットを指定することができます。
6.日付時間タイプ
MySQLのデータ型 | 意味 |
日付 | 日付「2008年12月2日」 |
時間 | 時刻'12:25:36 ' |
日付時刻 | 日付時刻「2008年12月2日夜09時06分44秒 " |
タイムスタンプ | 変更されたレコードを自動的に保存します |
フィールドがタイムスタンプとして定義されている場合、他のフィールドとフィールドデータに今回は、オートリフレッシュ時間を変更するので、フィールド・データのこのタイプは、このレコードが最後に変更された格納することができます。
属性のデータタイプ
MySQLのキーワード | 意味 |
ヌル | データ列は、NULL値が含まれています |
NOT NULL | NULL値は、データ列を許可されていません |
デフォルト | デフォルト値 |
PRIMARY KEY | 主キー |
自動増加 | 整数型の自動インクリメント |
UNSIGNED | 符号無し |
文字セット名 | 文字セットを指定します。 |
二つ、MySQLデータ型と長さの範囲
各データ型とバイト長のリスト:
データの種類 | バイト長 | 範囲または用法 |
ビット | 1 | 符号なし[0255]、署名[-128127]、天元のブログ注:BITとBOOLブール値は1つのバイトを占めています |
TINYINT | 1 | 整数[0255] |
SMALLINT | 2 | 署名された符号なし[0から65535]、[-32768、32767] |
MEDIUMINT | 3 | 署名された符号なし[0,2 ^ 24-1]、[-2 ^ 23、2 ^ 23-1] |
int型 | 4 | 署名された符号なし[0,2 ^ 32-1]、[31,2 ^ -2 ^ 31-1] |
BigInt | 8 | 署名された符号なし[0,2 ^ 64-1]、[-2 ^ 63 ^ 63 2 -1] |
フロート(M、D) | 4 | 単精度浮動小数点数。Dは精度の日のアラートマージンブログ、D場合は<= 24デフォルトFLOATと比較して、Dあれば> 24が自動的に変換DOUBLE型になります。 |
二重(M、D) | 8 | 倍精度浮動小数点。 |
小数(M、D) | M + 1、M + 2 | 未打包的浮点数,用法类似于FLOAT和DOUBLE,天缘博客提醒您如果在ASP中使用到Decimal数据类型,直接从数据库读出来的Decimal可能需要先转换成Float或Double类型后再进行运算。 |
Date | 3 | 以YYYY-MM-DD的格式显示,比如:2009-07-19 |
Date Time | 8 | 以YYYY-MM-DD HH:MM:SS的格式显示,比如:2009-07-19 11:22:30 |
TimeStamp | 4 | 以YYYY-MM-DD的格式显示,比如:2009-07-19 |
Time | 3 | 以HH:MM:SS的格式显示。比如:11:22:30 |
Year | 1 | 以YYYY的格式显示。比如:2009 |
Char(M) | M | 定长字符串。 |
VarChar(M) | M | 变长字符串,要求M<=255 |
Binary(M) | M | 类似Char的二进制存储,特点是插入定长不足补0 |
VarBinary(M) | M | 类似VarChar的变长二进制存储,特点是定长不补0 |
Tiny Text | Max:255 | 大小写不敏感 |
Text | Max:64K | 大小写不敏感 |
Medium Text | Max:16M | 大小写不敏感 |
Long Text | Max:4G | 大小写不敏感 |
TinyBlob | Max:255 | 大小写敏感 |
Blob | Max:64K | 大小写敏感 |
MediumBlob | Max:16M | 大小写敏感 |
LongBlob | Max:4G | 大小写敏感 |
Enum | 1或2 | 最大可达65535个不同的枚举值 |
Set | 可达8 | 最大可达64个不同的值 |
Geometry | ||
Point | ||
LineString | ||
Polygon | ||
MultiPoint | ||
MultiLineString | ||
MultiPolygon | ||
GeometryCollection |
三、使用建议
1、在指定数据类型的时候一般是采用从小原则,比如能用TINY INT的最好就不用INT,能用FLOAT类型的就不用DOUBLE类型,这样会对MYSQL在运行效率上提高很大,尤其是大数据量测试条件下。
2、不需要把数据表设计的太过复杂,功能模块上区分或许对于后期的维护更为方便,慎重出现大杂烩数据表
3、数据表和字段的起名字也是一门学问
4、设计数据表结构之前请先想象一下是你的房间,或许结果会更加合理、高效
5、数据库的最后设计结果一定是效率和可扩展性的折中,偏向任何一方都是欠妥的