Data Types - MariaDB - Databases - Software - Computers
Data Types | ||
---|---|---|
Prev | Next |
Data Types
Table of Contents
- Data Type Overview
- Numeric Types
- Date and Time Types
- String Types
- Data Type Storage Requirements
- Choosing the Right Type for a Column
- Using Data Types from Other Database Engines
- Choosing the Right Type for a Column
MySQL supports a number of data types in several categories: numeric types, date and time types, and string (character and byte) types. This chapter provides an overview of these data types, a more detailed description of the properties of the types in each category, and a summary of the data type storage requirements. The initial overview is intentionally brief. The more detailed descriptions later in the chapter should be consulted for additional information about particular data types, such as the permissible formats in which you can specify values.
MySQL also supports extensions for handling spatial data. For information about these data types, see , "Spatial Extensions".
Data type descriptions use these conventions:
M
indicates the maximum display width for integer types. For floating-point and fixed-point types,M
is the total number of digits that can be stored (the precision). For string types,M
is the maximum length. The maximum permissible value ofM
depends on the data type.D
applies to floating-point and fixed-point types and indicates the number of digits following the decimal point (the scale). The maximum possible value is 30, but should be no greater thanM
-2.fsp
applies to theTIME
,DATETIME
, andTIMESTAMP
types and represents fractional seconds precision; that is, the number of digits following the decimal point for fractional parts of seconds. Thefsp
value, if given, must be in the range 0 to 6. A value of 0 signifies that there is no fractional part. If omitted, the default precision is 0. (This differs from the standard SQL default of 6, for compatibility with previous MariaDB versions.)- Square brackets ("
[
" and "]
") indicate optional parts of type definitions.
Data Type Overview
Numeric Type Overview
A summary of the numeric data types follows. For additional information about properties and storage requirements of the numeric types, see , "Numeric Types", and , "Data Type Storage Requirements".
M
indicates the maximum display width for integer types. The maximum legal display width is 255. Display width is unrelated to the range of values a type can contain, as described in , "Numeric Types". For floating-point and fixed-point types, M
is the total number of digits that can be stored.
If you specify ZEROFILL
for a numeric column, MariaDB automatically adds the UNSIGNED
attribute to the column.
Numeric data types that permit the UNSIGNED
attribute also permit SIGNED
. However, these data types are signed by default, so the SIGNED
attribute has no effect.
SERIAL
is an alias for BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE
.
SERIAL DEFAULT VALUE
in the definition of an integer column is an alias for NOT NULL AUTO_INCREMENT UNIQUE
.Warning
When you use subtraction between integer values where one is of type UNSIGNED
, the result is unsigned unless the NO_UNSIGNED_SUBTRACTION
SQL mode is enabled. See , "Cast Functions and Operators".
BIT[(
M
)]
A bit-field type.
M
indicates the number of bits per value, from 1 to 64. The default is 1 ifM
is omitted.TINYINT[(
M
)] [UNSIGNED] [ZEROFILL]
A very small integer. The signed range is
-128
to127
. The unsigned range is0
to255
.BOOL
,BOOLEAN
These types are synonyms for
TINYINT(1)
. A value of zero is considered false. Nonzero values are considered true:mysql>
SELECT IF(0, 'true', 'false');
+------------------------+ | IF(0, 'true', 'false') | +------------------------+ | false | +------------------------+ mysql>SELECT IF(1, 'true', 'false');
+------------------------+ | IF(1, 'true', 'false') | +------------------------+ | true | +------------------------+ mysql>SELECT IF(2, 'true', 'false');
+------------------------+ | IF(2, 'true', 'false') | +------------------------+ | true | +------------------------+However, the values
TRUE
andFALSE
are merely aliases for1
and0
, respectively, as shown here:mysql>
SELECT IF(0 = FALSE, 'true', 'false');
+--------------------------------+ | IF(0 = FALSE, 'true', 'false') | +--------------------------------+ | true | +--------------------------------+ mysql>SELECT IF(1 = TRUE, 'true', 'false');
+-------------------------------+ | IF(1 = TRUE, 'true', 'false') | +-------------------------------+ | true | +-------------------------------+ mysql>SELECT IF(2 = TRUE, 'true', 'false');
+-------------------------------+ | IF(2 = TRUE, 'true', 'false') | +-------------------------------+ | false | +-------------------------------+ mysql>SELECT IF(2 = FALSE, 'true', 'false');
+--------------------------------+ | IF(2 = FALSE, 'true', 'false') | +--------------------------------+ | false | +--------------------------------+The last two statements display the results shown because
2
is equal to neither1
nor0
.SMALLINT[(
M
)] [UNSIGNED] [ZEROFILL]
A small integer. The signed range is
-32768
to32767
. The unsigned range is0
to65535
.MEDIUMINT[(
M
)] [UNSIGNED] [ZEROFILL]
A medium-sized integer. The signed range is
-8388608
to8388607
. The unsigned range is0
to16777215
.INT[(
M
)] [UNSIGNED] [ZEROFILL]
A normal-size integer. The signed range is
-2147483648
to2147483647
. The unsigned range is0
to4294967295
.INTEGER[(
M
)] [UNSIGNED] [ZEROFILL]
This type is a synonym for
INT
.BIGINT[(
M
)] [UNSIGNED] [ZEROFILL]
A large integer. The signed range is
-9223372036854775808
to9223372036854775807
. The unsigned range is0
to18446744073709551615
.SERIAL
is an alias forBIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE
.Some things you should be aware of with respect to
BIGINT
columns:- All arithmetic is done using signed
BIGINT
orDOUBLE
values, so you should not use unsigned big integers larger than9223372036854775807
(63 bits) except with bit functions! If you do that, some of the last digits in the result may be wrong because of rounding errors when converting aBIGINT
value to aDOUBLE
.
MySQL can handle
BIGINT
in the following cases:- When using integers to store large unsigned values in a
BIGINT
column. - In
MIN(
orcol-name
)MAX(
, wherecol_name
)col_name
refers to aBIGINT
column. - When using operators (
+
,-
,*
, and so on) where both operands are integers.
- When using integers to store large unsigned values in a
- You can always store an exact integer value in a
BIGINT
column by storing it using a string. In this case, MariaDB performs a string-to-number conversion that involves no intermediate double-precision representation. - The
-
,+
, and*
operators useBIGINT
arithmetic when both operands are integer values. This means that if you multiply two big integers (or results from functions that return integers), you may get unexpected results when the result is larger than9223372036854775807
.
- All arithmetic is done using signed
DECIMAL[(
M
[,D
])] [UNSIGNED] [ZEROFILL]
A packed "exact" fixed-point number.
M
is the total number of digits (the precision) andD
is the number of digits after the decimal point (the scale). The decimal point and (for negative numbers) the "-
" sign are not counted inM
. IfD
is 0, values have no decimal point or fractional part. The maximum number of digits (M
) forDECIMAL
is 65. The maximum number of supported decimals (D
) is 30. IfD
is omitted, the default is 0. IfM
is omitted, the default is 10.UNSIGNED
, if specified, disallows negative values.All basic calculations (
+, -, *, /
) withDECIMAL
columns are done with a precision of 65 digits.DEC[(
,M
[,D
])] [UNSIGNED] [ZEROFILL]NUMERIC[(
,M
[,D
])] [UNSIGNED] [ZEROFILL]FIXED[(
M
[,D
])] [UNSIGNED] [ZEROFILL]
These types are synonyms for
DECIMAL
. TheFIXED
synonym is available for compatibility with other database systems.FLOAT[(
M
,D
)] [UNSIGNED] [ZEROFILL]
A small (single-precision) floating-point number. Permissible values are
-3.402823466E+38
to-1.175494351E-38
,0
, and1.175494351E-38
to3.402823466E+38
. These are the theoretical limits, based on the IEEE standard. The actual range might be slightly smaller depending on your hardware or operating system.M
is the total number of digits andD
is the number of digits following the decimal point. IfM
andD
are omitted, values are stored to the limits permitted by the hardware. A single-precision floating-point number is accurate to approximately 7 decimal places.UNSIGNED
, if specified, disallows negative values.Using
FLOAT
might give you some unexpected problems because all calculations in MariaDB are done with double precision. See "Solving Problems with No Matching Rows".DOUBLE[(
M
,D
)] [UNSIGNED] [ZEROFILL]
A normal-size (double-precision) floating-point number. Permissible values are
-1.7976931348623157E+308
to-2.2250738585072014E-308
,0
, and2.2250738585072014E-308
to1.7976931348623157E+308
. These are the theoretical limits, based on the IEEE standard. The actual range might be slightly smaller depending on your hardware or operating system.M
is the total number of digits andD
is the number of digits following the decimal point. IfM
andD
are omitted, values are stored to the limits permitted by the hardware. A double-precision floating-point number is accurate to approximately 15 decimal places.UNSIGNED
, if specified, disallows negative values.DOUBLE PRECISION[(
,M
,D
)] [UNSIGNED] [ZEROFILL]REAL[(
M
,D
)] [UNSIGNED] [ZEROFILL]These types are synonyms for
DOUBLE
. Exception: If theREAL_AS_FLOAT
SQL mode is enabled,REAL
is a synonym forFLOAT
rather thanDOUBLE
.FLOAT(
p
) [UNSIGNED] [ZEROFILL]A floating-point number.
p
represents the precision in bits, but MariaDB uses this value only to determine whether to useFLOAT
orDOUBLE
for the resulting data type. Ifp
is from 0 to 24, the data type becomesFLOAT
with noM
orD
values. Ifp
is from 25 to 53, the data type becomesDOUBLE
with noM
orD
values. The range of the resulting column is the same as for the single-precisionFLOAT
or double-precisionDOUBLE
data types described earlier in this section.FLOAT(
syntax is provided for ODBC compatibility.p
)
Date and Time Type Overview
A summary of the temporal data types follows. For additional information about properties and storage requirements of the temporal types, see , "Date and Time Types", and , "Data Type Storage Requirements". For descriptions of functions that operate on temporal values, see , "Date and Time Functions".
For the DATE
and DATETIME
range descriptions, "supported" means that although earlier values might work, there is no guarantee.
MySQL 5.6.4 and up permits fractional seconds for TIME
, DATETIME
, and TIMESTAMP
values, with up to microseconds (6 digits) precision. To define a column that includes a fractional seconds part, use the syntax
, where type_name
(fsp
)type_name
is TIME
, DATETIME
, or TIMESTAMP
, and fsp
is the fractional seconds precision. For example:
CREATE TABLE t1 (t TIME(3), dt DATETIME(6));
The fsp
value, if given, must be in the range 0 to 6. A value of 0 signifies that there is no fractional part. If omitted, the default precision is 0. (This differs from the standard SQL default of 6, for compatibility with previous MariaDB versions.)
MySQL 5.6.5 introduces expanded automatic initialization and updating of temporal types. Any TIMESTAMP
column in a table can have these properties, rather than at most one column per table. In addition, these properties are now available for DATETIME
columns.
DATE
A date. The supported range is
'1000-01-01'
to'9999-12-31'
. MariaDB displaysDATE
values in'YYYY-MM-DD'
format, but permits assignment of values toDATE
columns using either strings or numbers.DATETIME[(
fsp
)]
A date and time combination. The supported range is
'1000-01-01 00:00:00.000000'
to'9999-12-31 23:59:59.999999'
. MariaDB displaysDATETIME
values in'YYYY-MM-DD HH:MM:SS[.fraction]'
format, but permits assignment of values toDATETIME
columns using either strings or numbers.As of MariaDB 5.6.4, an optional
fsp
value in the range from 0 to 6 may be given to specify fractional seconds precision. A value of 0 signifies that there is no fractional part. If omitted, the default precision is 0.As of MariaDB 5.6.5, automatic initialization and updating to the current date and time for
DATETIME
columns can be specified usingDEFAULT
andON UPDATE
column definition clauses, as described in , "Automatic Initialization and Updating forTIMESTAMP
andDATETIME
".TIMESTAMP[(
fsp
)]
A timestamp. The range is
'1970-01-01 00:00:01.000000'
UTC to'2038-01-19 03:14:07.999999'
UTC.TIMESTAMP
values are stored as the number of seconds since the epoch ('1970-01-01 00:00:00'
UTC). ATIMESTAMP
cannot represent the value'1970-01-01 00:00:00'
because that is equivalent to 0 seconds from the epoch and the value 0 is reserved for representing'0000-00-00 00:00:00'
, the "zero"TIMESTAMP
value.As of MariaDB 5.6.4, an optional
fsp
value in the range from 0 to 6 may be given to specify fractional seconds precision. A value of 0 signifies that there is no fractional part. If omitted, the default precision is 0.Unless specified otherwise, the first
TIMESTAMP
column in a table is defined to be automatically set to the date and time of the most recent modification if not explicitly assigned a value. This makesTIMESTAMP
useful for recording the timestamp of anINSERT
orUPDATE
operation. You can also set anyTIMESTAMP
column to the current date and time by assigning it aNULL
value, unless it has been defined with theNULL
attribute to permitNULL
values.Automatic initialization and updating to the current date and time can be specified using
DEFAULT
andON UPDATE
column definition clauses. By default, the firstTIMESTAMP
column has these properties, as previously noted. As of MariaDB 5.6.5, anyTIMESTAMP
column in a table can be defined to have these properties. Before 5.6.5, at most oneTIMESTAMP
column per table can have them, but it is possible to suppress them for the first column and instead assign them to a differentTIMESTAMP
column. See , "Automatic Initialization and Updating forTIMESTAMP
andDATETIME
".NoteThe
TIMESTAMP
format that was used prior to MariaDB is not supported in MariaDB 5.6; see MySQL 3.23, 4.0, 4.1 Reference Manual for information regarding the old format.TIME[(
fsp
)]
A time. The range is
'-838:59:59.000000'
to'838:59:59.000000'
. MariaDB displaysTIME
values in'HH:MM:SS[.fraction]'
format, but permits assignment of values toTIME
columns using either strings or numbers.As of MariaDB 5.6.4, an optional
fsp
value in the range from 0 to 6 may be given to specify fractional seconds precision. A value of 0 signifies that there is no fractional part. If omitted, the default precision is 0.YEAR[(2|4)]
A year in two-digit or four-digit format. The default is four-digit format. In four-digit format, the permissible values are
1901
to2155
, and0000
. In two-digit format, the permissible values are70
to69
, representing years from 1970 to 2069. MariaDB displaysYEAR
values inYYYY
format, but permits assignment of values toYEAR
columns using either strings or numbers.
The SUM()
and AVG()
aggregate functions do not work with temporal values. (They convert the values to numbers, losing everything after the first nonnumeric character.) To work around this problem, convert to numeric units, perform the aggregate operation, and convert back to a temporal value. Examples:
SELECT SEC_TO_TIME(SUM(TIME_TO_SEC(Notetime_col
))) FROMtbl_name
; SELECT FROM_DAYS(SUM(TO_DAYS(date_col
))) FROMtbl_name
;
The MariaDB server can be run with the MAXDB
SQL mode enabled. In this case, TIMESTAMP
is identical with DATETIME
. If this mode is enabled at the time that a table is created, TIMESTAMP
columns are created as DATETIME
columns. As a result, such columns use DATETIME
display format, have the same range of values, and there is no automatic initialization or updating to the current date and time. See , "Server SQL Modes".
String Type Overview
A summary of the string data types follows. For additional information about properties and storage requirements of the string types, see , "String Types", and , "Data Type Storage Requirements".
In some cases, MariaDB may change a string column to a type different from that given in a CREATE TABLE
or ALTER TABLE
statement. See , "Silent Column Specification Changes".
MySQL interprets length specifications in character column definitions in character units. This applies to CHAR
, VARCHAR
, and the TEXT
types.
Column definitions for many string data types can include attributes that specify the character set or collation of the column. These attributes apply to the CHAR
, VARCHAR
, the TEXT
types, ENUM
, and SET
data types:
- The
CHARACTER SET
attribute specifies the character set, and theCOLLATE
attribute specifies a collation for the character set. For example:
CREATE TABLE t ( c1 VARCHAR(20) CHARACTER SET utf8, c2 TEXT CHARACTER SET latin1 COLLATE latin1_general_cs );
This table definition creates a column named
c1
that has a character set ofutf8
with the default collation for that character set, and a column namedc2
that has a character set oflatin1
and a case-sensitive collation.The rules for assigning the character set and collation when either or both of the
CHARACTER SET
andCOLLATE
attributes are missing are described in , "Column Character Set and Collation".CHARSET
is a synonym forCHARACTER SET
. - Specifying the
CHARACTER SET binary
attribute for a character data type causes the column to be created as the corresponding binary data type:CHAR
becomesBINARY
,VARCHAR
becomesVARBINARY
, andTEXT
becomesBLOB
. For theENUM
andSET
data types, this does not occur; they are created as declared. Suppose that you specify a table using this definition:
CREATE TABLE t ( c1 VARCHAR(10) CHARACTER SET binary, c2 TEXT CHARACTER SET binary, c3 ENUM('a','b','c') CHARACTER SET binary );
The resulting table has this definition:
CREATE TABLE t ( c1 VARBINARY(10), c2 BLOB, c3 ENUM('a','b','c') CHARACTER SET binary );
- The
ASCII
attribute is shorthand forCHARACTER SET latin1
. - The
UNICODE
attribute is shorthand forCHARACTER SET ucs2
. - The
BINARY
attribute is shorthand for specifying the binary collation of the column character set. In this case, sorting and comparison are based on numeric character values.
Character column sorting and comparison are based on the character set assigned to the column. For the CHAR
, VARCHAR
, TEXT
, ENUM
, and SET
data types, you can declare a column with a binary collation or the BINARY
attribute to cause sorting and comparison to use the underlying character code values rather than a lexical ordering.
, "Character Set Support", provides additional information about use of character sets in MySQL.
[NATIONAL] CHAR[(
M
)] [CHARACTER SETcharset_name
] [COLLATEcollation_name
]
A fixed-length string that is always right-padded with spaces to the specified length when stored.
M
represents the column length in characters. The range ofM
is 0 to 255. IfM
is omitted, the length is 1.NoteTrailing spaces are removed when
CHAR
values are retrieved unless thePAD_CHAR_TO_FULL_LENGTH
SQL mode is enabled.CHAR
is shorthand forCHARACTER
.NATIONAL CHAR
(or its equivalent short form,NCHAR
) is the standard SQL way to define that aCHAR
column should use some predefined character set. MariaDB and up usesutf8
as this predefined character set. , "National Character Set".The
CHAR BYTE
data type is an alias for theBINARY
data type. This is a compatibility feature.MySQL permits you to create a column of type
CHAR(0)
. This is useful primarily when you have to be compliant with old applications that depend on the existence of a column but that do not actually use its value.CHAR(0)
is also quite nice when you need a column that can take only two values: A column that is defined asCHAR(0) NULL
occupies only one bit and can take only the valuesNULL
and''
(the empty string).[NATIONAL] VARCHAR(
M
) [CHARACTER SETcharset_name
] [COLLATEcollation_name
]
A variable-length string.
M
represents the maximum column length in characters. The range ofM
is 0 to 65,535. The effective maximum length of aVARCHAR
is subject to the maximum row size (65,535 bytes, which is shared among all columns) and the character set used. For example,utf8
characters can require up to three bytes per character, so aVARCHAR
column that uses theutf8
character set can be declared to be a maximum of 21,844 characters. See "Table Column-Count and Row-Size Limits".MySQL stores
VARCHAR
values as a one-byte or two-byte length prefix plus data. The length prefix indicates the number of bytes in the value. AVARCHAR
column uses one length byte if values require no more than 255 bytes, two length bytes if values may require more than 255 bytes.NoteMySQL 5.6 follows the standard SQL specification, and does not remove trailing spaces from
VARCHAR
values.VARCHAR
is shorthand forCHARACTER VARYING
.NATIONAL VARCHAR
is the standard SQL way to define that aVARCHAR
column should use some predefined character set. MariaDB and up usesutf8
as this predefined character set. , "National Character Set".NVARCHAR
is shorthand forNATIONAL VARCHAR
.BINARY(
M
)
The
BINARY
type is similar to theCHAR
type, but stores binary byte strings rather than nonbinary character strings.M
represents the column length in bytes.VARBINARY(
M
)
The
VARBINARY
type is similar to theVARCHAR
type, but stores binary byte strings rather than nonbinary character strings.M
represents the maximum column length in bytes.TINYBLOB
A
BLOB
column with a maximum length of 255 (28 - 1) bytes. EachTINYBLOB
value is stored using a one-byte length prefix that indicates the number of bytes in the value.TINYTEXT [CHARACTER SET
charset_name
] [COLLATEcollation_name
]
A
TEXT
column with a maximum length of 255 (28 - 1) characters. The effective maximum length is less if the value contains multi-byte characters. EachTINYTEXT
value is stored using a one-byte length prefix that indicates the number of bytes in the value.BLOB[(
M
)]
A
BLOB
column with a maximum length of 65,535 (216 - 1) bytes. EachBLOB
value is stored using a two-byte length prefix that indicates the number of bytes in the value.An optional length
M
can be given for this type. If this is done, MariaDB creates the column as the smallestBLOB
type large enough to hold valuesM
bytes long.TEXT[(
M
)] [CHARACTER SETcharset_name
] [COLLATEcollation_name
]
A
TEXT
column with a maximum length of 65,535 (216 - 1) characters. The effective maximum length is less if the value contains multi-byte characters. EachTEXT
value is stored using a two-byte length prefix that indicates the number of bytes in the value.An optional length
M
can be given for this type. If this is done, MariaDB creates the column as the smallestTEXT
type large enough to hold valuesM
characters long.MEDIUMBLOB
A
BLOB
column with a maximum length of 16,777,215 (224 - 1) bytes. EachMEDIUMBLOB
value is stored using a three-byte length prefix that indicates the number of bytes in the value.MEDIUMTEXT [CHARACTER SET
charset_name
] [COLLATEcollation_name
]
A
TEXT
column with a maximum length of 16,777,215 (224 - 1) characters. The effective maximum length is less if the value contains multi-byte characters. EachMEDIUMTEXT
value is stored using a three-byte length prefix that indicates the number of bytes in the value.LONGBLOB
A
BLOB
column with a maximum length of 4,294,967,295 or 4GB (232 - 1) bytes. The effective maximum length ofLONGBLOB
columns depends on the configured maximum packet size in the client/server protocol and available memory. EachLONGBLOB
value is stored using a four-byte length prefix that indicates the number of bytes in the value.LONGTEXT [CHARACTER SET
charset_name
] [COLLATEcollation_name
]
A
TEXT
column with a maximum length of 4,294,967,295 or 4GB (232 - 1) characters. The effective maximum length is less if the value contains multi-byte characters. The effective maximum length ofLONGTEXT
columns also depends on the configured maximum packet size in the client/server protocol and available memory. EachLONGTEXT
value is stored using a four-byte length prefix that indicates the number of bytes in the value.ENUM('
value1
','value2
',...) [CHARACTER SETcharset_name
] [COLLATEcollation_name
]
An enumeration. A string object that can have only one value, chosen from the list of values
'
,value1
''
,value2
'...
,NULL
or the special''
error value. AnENUM
column can have a maximum of 65,535 distinct values.ENUM
values are represented internally as integers.SET('
value1
','value2
',...) [CHARACTER SETcharset_name
] [COLLATEcollation_name
]A set. A string object that can have zero or more values, each of which must be chosen from the list of values
'
,value1
''
,value2
'...
ASET
column can have a maximum of 64 members.SET
values are represented internally as integers.
Data Type Default Values
The DEFAULT
clause in a data type specification indicates a default value for a column. With one exception, the default value must be a constant; it cannot be a function or an expression. This means, for example, that you cannot set the default for a date column to be the value of a function such as value
NOW()
or CURRENT_DATE
. The exception is that you can specify CURRENT_TIMESTAMP
as the default for TIMESTAMP
and DATETIME
columns. See , "Automatic Initialization and Updating for TIMESTAMP
and DATETIME
".
BLOB
and TEXT
columns cannot be assigned a default value.
If a column definition includes no explicit DEFAULT
value, MariaDB determines the default value as follows:
If the column can take NULL
as a value, the column is defined with an explicit DEFAULT NULL
clause.
If the column cannot take NULL
as the value, MariaDB defines the column with no explicit DEFAULT
clause. Exception: If the column is defined as part of a PRIMARY KEY
but not explicitly as NOT NULL
, MariaDB creates it as a NOT NULL
column (because PRIMARY KEY
columns must be NOT NULL
), but also assigns it a DEFAULT
clause using the implicit default value. To prevent this, include an explicit NOT NULL
in the definition of any PRIMARY KEY
column.
For data entry into a NOT NULL
column that has no explicit DEFAULT
clause, if an INSERT
or REPLACE
statement includes no value for the column, or an UPDATE
statement sets the column to NULL
, MariaDB handles the column according to the SQL mode in effect at the time:
- If strict SQL mode is enabled, an error occurs for transactional tables and the statement is rolled back. For nontransactional tables, an error occurs, but if this happens for the second or subsequent row of a multiple-row statement, the preceding rows will have been inserted.
- If strict mode is not enabled, MariaDB sets the column to the implicit default value for the column data type.
Suppose that a table t
is defined as follows:
CREATE TABLE t (i INT NOT NULL);
In this case, i
has no explicit default, so in strict mode each of the following statements produce an error and no row is inserted. When not using strict mode, only the third statement produces an error; the implicit default is inserted for the first two statements, but the third fails because DEFAULT(i)
cannot produce a value:
INSERT INTO t VALUES(); INSERT INTO t VALUES(DEFAULT); INSERT INTO t VALUES(DEFAULT(i));
See , "Server SQL Modes".
For a given table, you can use the SHOW CREATE TABLE
statement to see which columns have an explicit DEFAULT
clause.
Implicit defaults are defined as follows:
- For numeric types, the default is
0
, with the exception that for integer or floating-point types declared with theAUTO_INCREMENT
attribute, the default is the next value in the sequence. - For date and time types other than
TIMESTAMP
, the default is the appropriate "zero" value for the type. For the firstTIMESTAMP
column in a table, the default value is the current date and time. See , "Date and Time Types". - For string types other than
ENUM
, the default value is the empty string. ForENUM
, the default is the first enumeration value.
SERIAL DEFAULT VALUE
in the definition of an integer column is an alias for NOT NULL AUTO_INCREMENT UNIQUE
.
Numeric Types
- Integer Types (Exact Value)
- Fixed-Point Types (Exact Value)
- Floating-Point Types (Approximate Value)
- Bit-Value Type
- Numeric Type Attributes
- Out-of-Range and Overflow Handling
- Fixed-Point Types (Exact Value)
MySQL supports all standard SQL numeric data types. These types include the exact numeric data types (INTEGER
, SMALLINT
, DECIMAL
, and NUMERIC
), as well as the approximate numeric data types (FLOAT
, REAL
, and DOUBLE PRECISION
). The keyword INT
is a synonym for INTEGER
, and the keywords DEC
and FIXED
are synonyms for DECIMAL
. MariaDB treats DOUBLE
as a synonym for DOUBLE PRECISION
(a nonstandard extension). MariaDB also treats REAL
as a synonym for DOUBLE PRECISION
(a nonstandard variation), unless the REAL_AS_FLOAT
SQL mode is enabled.
The BIT
data type stores bit-field values and is supported for MyISAM
, MEMORY
, InnoDB
, and NDBCLUSTER
tables.
For information about how MariaDB handles assignment of out-of-range values to columns and overflow during expression evaluation, see , "Out-of-Range and Overflow Handling".
For information about numeric type storage requirements, see , "Data Type Storage Requirements".
The data type used for the result of a calculation on numeric operands depends on the types of the operands and the operations performed on them. For more information, see , "Arithmetic Operators".
Integer Types (Exact Value)
MySQL supports the SQL standard integer types INTEGER
(or INT
) and SMALLINT
. As an extension to the standard, MariaDB also supports the integer types TINYINT
, MEDIUMINT
, and BIGINT
. The following table shows the required storage and range for each integer type.
Type | Storage | Minimum Value | Maximum Value |
---|---|---|---|
(Bytes) | (Signed/Unsigned) | Signed/Unsigned) | |
TINYINT
| 1 | -128
| 127
|
0
| 255
| ||
SMALLINT
| 2 | -32768
| 32767
|
0
| 65535
| ||
MEDIUMINT
| 3 | -8388608
| 8388607
|
0
| 16777215
| ||
INT
| 4 | -2147483648
| 2147483647
|
0
| 4294967295
| ||
BIGINT
| 8 | -9223372036854775808
| 9223372036854775807
|
0
| 18446744073709551615 |
Fixed-Point Types (Exact Value)
The DECIMAL
and NUMERIC
types store exact numeric data values. These types are used when it is important to preserve exact precision, for example with monetary data. In MySQL, NUMERIC
is implemented as DECIMAL
, so the following remarks about DECIMAL
apply equally to NUMERIC
.
MySQL 5.6 stores DECIMAL
values in binary format. See , "Precision Math".
In a DECIMAL
column declaration, the precision and scale can be (and usually is) specified; for example:
salary DECIMAL(5,2)
In this example, 5
is the precision and 2
is the scale. The precision represents the number of significant digits that are stored for values, and the scale represents the number of digits that can be stored following the decimal point.
Standard SQL requires that DECIMAL(5,2)
be able to store any value with five digits and two decimals, so values that can be stored in the salary
column range from -999.99
to 999.99
.
In standard SQL, the syntax DECIMAL(
is equivalent to M
)DECIMAL(
. Similarly, the syntax M
,0)DECIMAL
is equivalent to DECIMAL(
, where the implementation is permitted to decide the value of M
,0)M
. MariaDB supports both of these variant forms of DECIMAL
syntax. The default value of M
is 10.
If the scale is 0, DECIMAL
values contain no decimal point or fractional part.
The maximum number of digits for DECIMAL
is 65, but the actual range for a given DECIMAL
column can be constrained by the precision or scale for a given column. When such a column is assigned a value with more digits following the decimal point than are permitted by the specified scale, the value is converted to that scale. (The precise behavior is operating system-specific, but generally the effect is truncation to the permissible number of digits.)
Floating-Point Types (Approximate Value)
The FLOAT
and DOUBLE
types represent approximate numeric data values. MariaDB uses four bytes for single-precision values and eight bytes for double-precision values.
For FLOAT
, the SQL standard permits an optional specification of the precision (but not the range of the exponent) in bits following the keyword FLOAT
in parentheses. MariaDB also supports this optional precision specification, but the precision value is used only to determine storage size. A precision from 0 to 23 results in a four-byte single-precision FLOAT
column. A precision from 24 to 53 results in an eight-byte double-precision DOUBLE
column.
MySQL permits a nonstandard syntax: FLOAT(
or M
,D
)REAL(
or M
,D
)DOUBLE PRECISION(
. Here, "M
,D
)(
" means than values can be stored with up to M
,D
)M
digits in total, of which D
digits may be after the decimal point. For example, a column defined as FLOAT(7,4)
will look like -999.9999
when displayed. MariaDB performs rounding when storing values, so if you insert 999.00009
into a FLOAT(7,4)
column, the approximate result is 999.0001
.
Because floating-point values are approximate and not stored as exact values, attempts to treat them as exact in comparisons may lead to problems. They are also subject to platform or implementation dependencies. For more information, see "Problems with Floating-Point Values"
For maximum portability, code requiring storage of approximate numeric data values should use FLOAT
or DOUBLE PRECISION
with no specification of precision or number of digits.
Bit-Value Type
The BIT
data type is used to store bit-field values. A type of BIT(
enables storage of M
)M
-bit values. M
can range from 1 to 64.
To specify bit values, b'
notation can be used. value
'value
is a binary value written using zeros and ones. For example, b'111'
and b'10000000'
represent 7 and 128, respectively. See , "Bit-Field Literals".
If you assign a value to a BIT(
column that is less than M
)M
bits long, the value is padded on the left with zeros. For example, assigning a value of b'101'
to a BIT(6)
column is, in effect, the same as assigning b'000101'
.
Numeric Type Attributes
MySQL supports an extension for optionally specifying the display width of integer data types in parentheses following the base keyword for the type. For example, INT(4)
specifies an INT
with a display width of four digits. This optional display width may be used by applications to display integer values having a width less than the width specified for the column by left-padding them with spaces. (That is, this width is present in the metadata returned with result sets. Whether it is used or not is up to the application.)
The display width does not constrain the range of values that can be stored in the column. Nor does it prevent values wider than the column display width from being displayed correctly. For example, a column specified as SMALLINT(3)
has the usual SMALLINT
range of -32768
to 32767
, and values outside the range permitted by three digits are displayed in full using more than three digits.
When used in conjunction with the optional (nonstandard) attribute ZEROFILL
, the default padding of spaces is replaced with zeros. For example, for a column declared as INT(4) ZEROFILL
, a value of 5
is retrieved as 0005
.Note
The ZEROFILL
attribute is ignored when a column is involved in expressions or UNION
queries.
If you store values larger than the display width in an integer column that has the ZEROFILL
attribute, you may experience problems when MariaDB generates temporary tables for some complicated joins. In these cases, MariaDB assumes that the data values fit within the column display width.
All integer types can have an optional (nonstandard) attribute UNSIGNED
. Unsigned type can be used to permit only nonnegative numbers in a column or when you need a larger upper numeric range for the column. For example, if an INT
column is UNSIGNED
, the size of the column's range is the same but its endpoints shift from -2147483648
and 2147483647
up to 0
and 4294967295
.
Floating-point and fixed-point types also can be UNSIGNED
. As with integer types, this attribute prevents negative values from being stored in the column. Unlike the integer types, the upper range of column values remains the same.
If you specify ZEROFILL
for a numeric column, MariaDB automatically adds the UNSIGNED
attribute to the column.
Integer or floating-point data types can have the additional attribute AUTO_INCREMENT
. When you insert a value of NULL
(recommended) or 0
into an indexed AUTO_INCREMENT
column, the column is set to the next sequence value. Typically this is
, where value
+1value
is the largest value for the column currently in the table. AUTO_INCREMENT
sequences begin with 1
.
Out-of-Range and Overflow Handling
When MariaDB stores a value in a numeric column that is outside the permissible range of the column data type, the result depends on the SQL mode in effect at the time:
- If strict SQL mode is enabled, MariaDB rejects the out-of-range value with an error, and the insert fails, in accordance with the SQL standard.
- If no restrictive modes are enabled, MariaDB clips the value to the appropriate endpoint of the range and stores the resulting value instead.
When an out-of-range value is assigned to an integer column, MariaDB stores the value representing the corresponding endpoint of the column data type range. If you store 256 into a
TINYINT
orTINYINT UNSIGNED
column, MariaDB stores 127 or 255, respectively.When a floating-point or fixed-point column is assigned a value that exceeds the range implied by the specified (or default) precision and scale, MariaDB stores the value representing the corresponding endpoint of that range.
Column-assignment conversions that occur due to clipping when MariaDB is not operating in strict mode are reported as warnings for ALTER TABLE
, LOAD DATA INFILE
, UPDATE
, and multiple-row INSERT
statements. In strict mode, these statements fail, and some or all the values will not be inserted or changed, depending on whether the table is a transactional table and other factors. For details, see , "Server SQL Modes".
In MariaDB 5.6, overflow during numeric expression evaluation results in an error. For example, the largest signed BIGINT
value is 9223372036854775807, so the following expression produces an error:
mysql> SELECT 9223372036854775807 + 1;
ERROR 1690 (22003): BIGINT value is out of range in '(9223372036854775807 + 1)'
To enable the operation to succeed in this case, convert the value to unsigned;
mysql> SELECT CAST(9223372036854775807 AS UNSIGNED) + 1;
+-------------------------------------------+
| CAST(9223372036854775807 AS UNSIGNED) + 1 |
+-------------------------------------------+
| 9223372036854775808 |
+-------------------------------------------+
Whether overflow occurs depends on the range of the operands, so another way to handle the preceding expression is to use exact-value arithmetic because DECIMAL
values have a larger range than integers:
mysql> SELECT 9223372036854775807.0 + 1;
+---------------------------+
| 9223372036854775807.0 + 1 |
+---------------------------+
| 9223372036854775808.0 |
+---------------------------+
Subtraction between integer values, where one is of type UNSIGNED
, produces an unsigned result by default. Prior to MariaDB 5.5.5, if the result would otherwise have been negative, it becomes the maximum integer value:
mysql>SET sql_mode = '';
mysql>SELECT CAST(0 AS UNSIGNED) - 1;
+-------------------------+ | CAST(0 AS UNSIGNED) - 1 | +-------------------------+ | 18446744073709551615 | +-------------------------+
As of MariaDB 5.5.5, if the result would otherwise have been negative, an error results:
mysql>SET sql_mode = '';
Query OK, 0 rows affected (0.00 sec) mysql>SELECT CAST(0 AS UNSIGNED) - 1;
ERROR 1690 (22003): BIGINT UNSIGNED value is out of range in '(cast(0 as unsigned) - 1)'
If the NO_UNSIGNED_SUBTRACTION
SQL mode is enabled, the result is negative:
mysql>SET sql_mode = 'NO_UNSIGNED_SUBTRACTION';
mysql>SELECT CAST(0 AS UNSIGNED) - 1;
+-------------------------+ | CAST(0 AS UNSIGNED) - 1 | +-------------------------+ | -1 | +-------------------------+
If the result of such an operation is used to update an UNSIGNED
integer column, the result is clipped to the maximum value for the column type, or clipped to 0 if NO_UNSIGNED_SUBTRACTION
is enabled. If strict SQL mode is enabled, an error occurs and the column remains unchanged.
Date and Time Types
- The
DATE
,DATETIME
, andTIMESTAMP
Types- The
TIME
Type- The
YEAR
Type- Automatic Initialization and Updating for
TIMESTAMP
andDATETIME
- Fractional Seconds in Time Values
- Conversion Between Date and Time Types
- Two-Digit Years in Dates
- The
The date and time types for representing temporal values are DATE
, TIME
, DATETIME
, TIMESTAMP
, and YEAR
. Each temporal type has a range of legal values, as well as a "zero" value that may be used when you specify an illegal value that MariaDB cannot represent. The TIMESTAMP
type has special automatic updating behavior, described later. For temporal type storage requirements, see , "Data Type Storage Requirements".
Keep in mind these general considerations when working with date and time types:
- MySQL retrieves values for a given date or time type in a standard output format, but it attempts to interpret a variety of formats for input values that you supply (for example, when you specify a value to be assigned to or compared to a date or time type). For a description of the permitted formats for date and time types, see , "Date and Time Literals". It is expected that you supply legal values. Unpredictable results may occur if you use values in other formats.
- Although MariaDB tries to interpret values in several formats, date parts must always be given in year-month-day order (for example,
'98-09-04'
), rather than in the month-day-year or day-month-year orders commonly used elsewhere (for example,'09-04-98'
,'04-09-98'
). - Dates containing two-digit year values are ambiguous because the century is unknown. MariaDB interprets two-digit year values using these rules:
- Year values in the range
70-99
are converted to1970-1999
. - Year values in the range
00-69
are converted to2000-2069
.
See also , "Two-Digit Years in Dates".
- Year values in the range
- Conversion of values from one temporal type to another occurs according to the rules in , "Conversion Between Date and Time Types".
- MySQL automatically converts a date or time value to a number if the value is used in a numeric context and vice versa.
- By default, when MariaDB encounters a value for a date or time type that is out of range or otherwise illegal for the type, it converts the value to the "zero" value for that type. The exception is that out-of-range
TIME
values are clipped to the appropriate endpoint of theTIME
range. - By setting the SQL mode to the appropriate value, you can specify more exactly what kind of dates you want MariaDB to support. (See , "Server SQL Modes".) You can get MariaDB to accept certain dates, such as
'2009-11-31'
, by enabling theALLOW_INVALID_DATES
SQL mode. This is useful when you want to store a "possibly wrong" value which the user has specified (for example, in a web form) in the database for future processing. Under this mode, MariaDB verifies only that the month is in the range from 1 to 12 and that the day is in the range from 1 to 31. - MySQL permits you to store dates where the day or month and day are zero in a
DATE
orDATETIME
column. This is extremely useful for applications that need to store birthdates for which you may not know the exact date. In this case, you simply store the date as'2009-00-00'
or'2009-01-00'
. If you store dates such as these, you should not expect to get correct results for functions such asDATE_SUB()
orDATE_ADD()
that require complete dates. To disallow zero month or day parts in dates, enable theNO_ZERO_IN_DATE
SQL mode. - MySQL permits you to store a "zero" value of
'0000-00-00'
as a "dummy date." This is in some cases more convenient than usingNULL
values, and uses less data and index space. To disallow'0000-00-00'
, enable theNO_ZERO_DATE
SQL mode. - "Zero" date or time values used through Connector/ODBC are converted automatically to
NULL
because ODBC cannot handle such values.
The following table shows the format of the "zero" value for each type. The "zero" values are special, but you can store or refer to them explicitly using the values shown in the table. You can also do this using the values '0'
or 0
, which are easier to write. Use of these values produces warnings if the NO_ZERO_DATE
SQL mode is enabled.
Data Type | "Zero" Value |
---|---|
DATE
| '0000-00-00'
|
TIME
| '00:00:00'
|
DATETIME
| '0000-00-00 00:00:00'
|
TIMESTAMP
| '0000-00-00 00:00:00'
|
YEAR
| 0000 |
The DATE
, DATETIME
, and TIMESTAMP
Types
The DATE
, DATETIME
, and TIMESTAMP
types are related. This section describes their characteristics, how they are similar, and how they differ. MariaDB recognizes DATE
, DATETIME
, and TIMESTAMP
values in several formats, described in , "Date and Time Literals". For the DATE
and DATETIME
range descriptions, "supported" means that although earlier values might work, there is no guarantee.
The DATE
type is used for values with a date part but no time part. MariaDB retrieves and displays DATE
values in 'YYYY-MM-DD'
format. The supported range is '1000-01-01'
to '9999-12-31'
.
The DATETIME
type is used for values that contain both date and time parts. MariaDB retrieves and displays DATETIME
values in 'YYYY-MM-DD HH:MM:SS'
format. The supported range is '1000-01-01 00:00:00'
to '9999-12-31 23:59:59'
.
The TIMESTAMP
data type is used for values that contain both date and time parts. TIMESTAMP
has a range of '1970-01-01 00:00:01'
UTC to '2038-01-19 03:14:07'
UTC.
A DATETIME
or TIMESTAMP
value can include a trailing fractional seconds part in up to microseconds (6 digits) precision. In particular, as of MariaDB 5.6.4, any fractional part in a value inserted into a DATETIME
or TIMESTAMP
column is stored rather than discarded. With the fractional part included, the format for these values is 'YYYY-MM-DD HH:MM:SS[.fraction]'
, the range for DATETIME
values is '1000-01-01 00:00:00.000000'
to '9999-12-31 23:59:59.999999'
, and the range for TIMESTAMP
values is '1970-01-01 00:00:01.000000'
to '2038-01-19 03:14:07.999999'
. For information about fractional seconds support in MySQL, see , "Fractional Seconds in Time Values".
The TIMESTAMP
and (as of MariaDB 5.6.5) DATETIME
data types offer automatic initialization and updating to the current date and time. For more information, see , "Automatic Initialization and Updating for TIMESTAMP
and DATETIME
".
MySQL converts TIMESTAMP
values from the current time zone to UTC for storage, and back from UTC to the current time zone for retrieval. (This does not occur for other types such as DATETIME
.) By default, the current time zone for each connection is the server's time. The time zone can be set on a per-connection basis. As long as the time zone setting remains constant, you get back the same value you store. If you store a TIMESTAMP
value, and then change the time zone and retrieve the value, the retrieved value is different from the value you stored. This occurs because the same time zone was not used for conversion in both directions. The current time zone is available as the value of the time_zone
system variable. For more information, see , "MySQL Server Time Zone Support".
Illegal DATE
, DATETIME
, or TIMESTAMP
values are converted to the "zero" value of the appropriate type ('0000-00-00'
or '0000-00-00 00:00:00'
).
Be aware of certain properties of date value interpretation in MySQL:
- MySQL permits a "relaxed" format for values specified as strings, in which any punctuation character may be used as the delimiter between date parts or time parts. In some cases, this syntax can be deceiving. For example, a value such as
'10:11:12'
might look like a time value because of the ":
" delimiter, but is interpreted as the year'2010-11-12'
if used in a date context. The value'10:45:15'
is converted to'0000-00-00'
because'45'
is not a legal month. - The server requires that month and day values be legal, and not merely in the range 1 to 12 and 1 to 31, respectively. With strict mode disabled, invalid dates such as
'2004-04-31'
are converted to'0000-00-00'
and a warning is generated. With strict mode enabled, invalid dates generate an error. To permit such dates, enableALLOW_INVALID_DATES
. See , "Server SQL Modes", for more information. - MySQL does not accept
TIMESTAMP
values that include a zero in the day or month column or values that are not a valid date. The sole exception to this rule is the special "zero" value'0000-00-00 00:00:00'
. - Dates containing two-digit year values are ambiguous because the century is unknown. MariaDB interprets two-digit year values using these rules:
- Year values in the range
00-69
are converted to2000-2069
. - Year values in the range
70-99
are converted to1970-1999
.
See also , "Two-Digit Years in Dates".
- Year values in the range
The MariaDB server can be run with the MAXDB
SQL mode enabled. In this case, TIMESTAMP
is identical with DATETIME
. If this mode is enabled at the time that a table is created, TIMESTAMP
columns are created as DATETIME
columns. As a result, such columns use DATETIME
display format, have the same range of values, and there is no automatic initialization or updating to the current date and time. See , "Server SQL Modes".
The TIME
Type
MySQL retrieves and displays TIME
values in 'HH:MM:SS'
format (or 'HHH:MM:SS'
format for large hours values). TIME
values may range from '-838:59:59'
to '838:59:59'
. The hours part may be so large because the TIME
type can be used not only to represent a time of day (which must be less than 24 hours), but also elapsed time or a time interval between two events (which may be much greater than 24 hours, or even negative).
MySQL recognizes TIME
values in several formats, some of which can include a trailing fractional seconds part in up to microseconds (6 digits) precision. See , "Date and Time Literals". For information about fractional seconds support in MySQL, see , "Fractional Seconds in Time Values". In particular, as of MariaDB 5.6.4, any fractional part in a value inserted into a TIME
column is stored rather than discarded. With the fractional part included, the range for TIME
values is '-838:59:59.000000'
to '838:59:59.000000'
.
Be careful about assigning abbreviated values to a TIME
column. MariaDB interprets abbreviated TIME
values with colons as time of the day. That is, '11:12'
means '11:12:00'
, not '00:11:12'
. MariaDB interprets abbreviated values without colons using the assumption that the two rightmost digits represent seconds (that is, as elapsed time rather than as time of day). For example, you might think of '1112'
and 1112
as meaning '11:12:00'
(12 minutes after 11 o'clock), but MariaDB interprets them as '00:11:12'
(11 minutes, 12 seconds). Similarly, '12'
and 12
are interpreted as '00:00:12'
.
By default, values that lie outside the TIME
range but are otherwise legal are clipped to the closest endpoint of the range. For example, '-850:00:00'
and '850:00:00'
are converted to '-838:59:59'
and '838:59:59'
. Illegal TIME
values are converted to '00:00:00'
. Note that because '00:00:00'
is itself a legal TIME
value, there is no way to tell, from a value of '00:00:00'
stored in a table, whether the original value was specified as '00:00:00'
or whether it was illegal.
For more restrictive treatment of invalid TIME
values, enable strict SQL mode to cause errors to occur. See , "Server SQL Modes".
The YEAR
Type
The YEAR
type is a one-byte type used for representing years. It can be declared as YEAR(2)
or YEAR(4)
to specify a display width of two or four characters. The default is four characters if no width is given.
For four-digit format, MariaDB displays YEAR
values in YYYY
format, with a range of 1901
to 2155
, or 0000
. For two-digit format, MariaDB displays only the last two (least significant) digits; for example, 70
(1970 or 2070) or 69
(2069).
You can specify input YEAR
values in a variety of formats:
- As a four-digit string in the range
'1901'
to'2155'
. - As a four-digit number in the range
1901
to2155
. - As a two-digit string in the range
'00'
to'99'
. Values in the ranges'00'
to'69'
and'70'
to'99'
are converted toYEAR
values in the ranges2000
to2069
and1970
to1999
. - As a two-digit number in the range
1
to99
. Values in the ranges1
to69
and70
to99
are converted toYEAR
values in the ranges2001
to2069
and1970
to1999
. Note that the range for two-digit numbers is slightly different from the range for two-digit strings, because you cannot specify zero directly as a number and have it be interpreted as2000
. You must specify it as a string'0'
or'00'
or it is interpreted as0000
. - As the result of a function that returns a value that is acceptable in a
YEAR
context, such asNOW()
.
Illegal YEAR
values are converted to 0000
.
See also , "Two-Digit Years in Dates".
Automatic Initialization and Updating for TIMESTAMP
and DATETIME
As of MariaDB 5.6.5, TIMESTAMP
and DATETIME
columns can be automatically initializated and updated to the current date and time (that is, the current timestamp). Before 5.6.5, this is true only for TIMESTAMP
, and for at most one TIMESTAMP
column per table. The following notes first describe automatic initialization and updating for MariaDB 5.6.5 and up, then the differences for versions preceding 5.6.5.
For any TIMESTAMP
or DATETIME
column in a table, you can assign the current timestamp as the default value, the auto-update value, or both:
- An auto-initialized column is set to the current timestamp for inserted rows that specify no value for the column.
- An auto-updated column is automatically updated to the current timestamp when the value of any other column in the row is changed from its current value. An auto-updated column remains unchanged if all other columns are set to their current values. To prevent an auto-updated column from updating when other columns change, explicitly set it to its current value. To update an auto-updated column even when other columns do not change, explicitly set it to the value it should have (for example, set it to
CURRENT_TIMESTAMP
).
In addition, you can initialize or update any TIMESTAMP
column to the current date and time by assigning it a NULL
value, unless it has been defined with the NULL
attribute to permit NULL
values.
To specify automatic properties, use the DEFAULT CURRENT_TIMESTAMP
and ON UPDATE CURRENT_TIMESTAMP
clauses in column definitions. The order of the clauses does not matter. If both are present in a column definition, either can occur first. Any of the synonyms for CURRENT_TIMESTAMP
have the same meaning as CURRENT_TIMESTAMP
. These are CURRENT_TIMESTAMP()
, NOW()
, LOCALTIME
, LOCALTIME()
, LOCALTIMESTAMP
, and LOCALTIMESTAMP()
.
Use of DEFAULT CURRENT_TIMESTAMP
and ON UPDATE CURRENT_TIMESTAMP
is specific to TIMESTAMP
and DATETIME
. The DEFAULT
clause also can be used to specify a constant (nonautomatic) default value; for example, DEFAULT 0
or DEFAULT '2000-01-01 00:00:00'
.Note
The following examples that use DEFAULT 0
do not work if the NO_ZERO_DATE
SQL mode is enabled because that mode causes "zero" date values (specified, for example, as 0
'0000-00-00 00:00:00'
) to be rejected. Be aware that the TRADITIONAL
SQL mode includes NO_ZERO_DATE
.
TIMESTAMP
or DATETIME
column definitions can specify the current timestamp for both the default and auto-update values, for one but not the other, or for neither. Different columns can have different combinations of automatic properties. The following rules describe the possibilities:
- With both
DEFAULT CURRENT_TIMESTAMP
andON UPDATE CURRENT_TIMESTAMP
, the column has the current timestamp for its default value and is automatically updated to the current timestamp.
CREATE TABLE t1 ( ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, dt DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );
- With a
DEFAULT
clause but noON UPDATE CURRENT_TIMESTAMP
clause, the column has the given default value and is not automatically updated to the current timestamp.
The default depends on whether the
DEFAULT
clause specifiesCURRENT_TIMESTAMP
or a constant value. WithCURRENT_TIMESTAMP
, the default is the current timestamp.CREATE TABLE t1 ( ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP, dt DATETIME DEFAULT CURRENT_TIMESTAMP );
With a constant, the default is the given value. In this case, the column has no automatic properties at all.
CREATE TABLE t1 ( ts TIMESTAMP DEFAULT 0, dt DATETIME DEFAULT 0 );
- With an
ON UPDATE CURRENT_TIMESTAMP
clause and a constantDEFAULT
clause, the column is automatically updated to the current timestamp and has the given constant default value.
CREATE TABLE t1 ( ts TIMESTAMP DEFAULT 0 ON UPDATE CURRENT_TIMESTAMP, dt DATETIME DEFAULT 0 ON UPDATE CURRENT_TIMESTAMP );
- With an
ON UPDATE CURRENT_TIMESTAMP
clause but noDEFAULT
clause, the column is automatically updated to the current timestamp but does not have the current timestamp for its default value.The default in this case is type dependent.
TIMESTAMP
has a default of 0 unless defined with theNULL
attribute, in which case the default isNULL
.CREATE TABLE t1 ( ts1 TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, -- default 0 ts2 TIMESTAMP NULL ON UPDATE CURRENT_TIMESTAMP -- default NULL );
DATETIME
has a default ofNULL
unless defined with theNOT NULL
attribute, in which case the default is 0.CREATE TABLE t1 ( dt1 DATETIME ON UPDATE CURRENT_TIMESTAMP, -- default NULL dt2 DATETIME NOT NULL ON UPDATE CURRENT_TIMESTAMP -- default 0 );
TIMESTAMP
and DATETIME
columns have no automatic properties unless they are specified explicitly, with this exception: By default, the first TIMESTAMP
column has both DEFAULT CURRENT_TIMESTAMP
and ON UPDATE CURRENT_TIMESTAMP
if neither is specified explicitly. To suppress automatic properties for the first TIMESTAMP
column, do either of the following:
- Define the column with a
DEFAULT
clause that specifies a constant default value. - Specify the
NULL
attribute. This also causes the column to permitNULL
values, which means that you cannot assign the current timestamp by setting the column toNULL
. AssigningNULL
sets the column toNULL
.
Consider these table definitions:
CREATE TABLE t1 ( ts1 TIMESTAMP DEFAULT 0, ts2 TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP); CREATE TABLE t2 ( ts1 TIMESTAMP NULL, ts2 TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP); CREATE TABLE t3 ( ts1 TIMESTAMP NULL DEFAULT 0, ts2 TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP);
The tables have these properties:
- In each table definition, the first
TIMESTAMP
column has no automatic initialization or updating. - The tables differ in how the
ts1
column handlesNULL
values. Fort1
,ts1
isNOT NULL
and assigning it a value ofNULL
sets it to the current timestamp. Fort2
andt3
,ts1
permitsNULL
and assigning it a value ofNULL
sets it toNULL
. t2
andt3
differ in the default value forts1
. Fort2
,ts1
is defined to permitNULL
, so the default is alsoNULL
in the absence of an explicitDEFAULT
clause. Fort3
,ts1
permitsNULL
but has an explicit default of 0.
If a TIMESTAMP
or DATETIME
column definition includes an explicit fractional seconds precision value anywhere, the same value must be used throughout the column definition. This is legal:
CREATE TABLE t1 ( ts TIMESTAMP(6) DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6) );
This is not legal:
CREATE TABLE t1 ( ts TIMESTAMP(6) DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP(3) );
Automatic Timestamp Properties Before MariaDB 5.6.5
Before MariaDB 5.6.5, support for automatic initialization and updating is more limited:
DEFAULT CURRENT_TIMESTAMP
andON UPDATE CURRENT_TIMESTAMP
cannot be used withDATETIME
columns.DEFAULT CURRENT_TIMESTAMP
andON UPDATE CURRENT_TIMESTAMP
can be used with at most oneTIMESTAMP
column per table. It is not possible to have the current timestamp be the default value for one column and the auto-update value for another column.
You can choose whether to use these properties and which TIMESTAMP
column should have them. It need not be the first one in a table that is automatically initialized or updated to the current timestamp. To specify automatic initialization or updating for a different TIMESTAMP
column, you must suppress the automatic properties for the first one, as previously described. Then, for the other TIMESTAMP
column, the rules for the DEFAULT
and ON UPDATE
clauses are the same as for the first TIMESTAMP
column, except that if you omit both clauses, no automatic initialization or updating occurs.
TIMESTAMP
Initialization and the NULL
Attribute
By default, TIMESTAMP
columns are NOT NULL
, cannot contain NULL
values, and assigning NULL
assigns the current timestamp. To permit a TIMESTAMP
column to contain NULL
, explicitly declare it with the NULL
attribute. In this case, the default value also becomes NULL
unless overridden with a DEFAULT
clause that specifies a different default value. DEFAULT NULL
can be used to explicitly specify NULL
as the default value. (For a TIMESTAMP
column not declared with the NULL
attribute, DEFAULT NULL
is illegal.) If a TIMESTAMP
column permits NULL
values, assigning NULL
sets it to NULL
, not to the current timestamp.
The following table contains several TIMESTAMP
columns that permit NULL
values:
CREATE TABLE t ( ts1 TIMESTAMP NULL DEFAULT NULL, ts2 TIMESTAMP NULL DEFAULT 0, ts3 TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP );
A TIMESTAMP
column that permits NULL
values does not take on the current timestamp at insert time except under one of the following conditions:
- Its default value is defined as
CURRENT_TIMESTAMP
and no value is specified for the column CURRENT-TIMESTAMP
or any of its synonyms such asNOW()
is explicitly inserted into the column
In other words, a TIMESTAMP
column defined to permit NULL
values auto-initializes only if its definition includes DEFAULT CURRENT_TIMESTAMP
:
CREATE TABLE t (ts TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP);
If the TIMESTAMP
column permits NULL
values but its definition does not include DEFAULT CURRENT_TIMESTAMP
, you must explicitly insert a value corresponding to the current date and time. Suppose that tables t1
and t2
have these definitions:
CREATE TABLE t1 (ts TIMESTAMP NULL DEFAULT '0000-00-00 00:00:00'); CREATE TABLE t2 (ts TIMESTAMP NULL DEFAULT NULL);
To set the TIMESTAMP
column in either table to the current timestamp at insert time, explicitly assign it that value. For example:
INSERT INTO t1 VALUES (NOW()); INSERT INTO t2 VALUES (CURRENT_TIMESTAMP);
Fractional Seconds in Time Values
Before MariaDB 5.6.4, the instances are limited in which a fractional seconds part is permitted in temporal values. A trailing fractional part is permissible in contexts such as literal values, and in the arguments to or return values from some temporal functions. Example:
mysql> SELECT MICROSECOND('2010-12-10 14:12:09.019473');
+-------------------------------------------+
| MICROSECOND('2010-12-10 14:12:09.019473') |
+-------------------------------------------+
| 19473 |
+-------------------------------------------+
However, when MariaDB stores a value into a column of any temporal data type, it discards any fractional part and does not store it.
MySQL 5.6.4 and up expands fractional seconds support for TIME
, DATETIME
, and TIMESTAMP
values, with up to microseconds (6 digits) precision:
- To define a column that includes a fractional seconds part, use the syntax
, wheretype_name
(fsp
)type_name
isTIME
,DATETIME
, orTIMESTAMP
, andfsp
is the fractional seconds precision. For example:
CREATE TABLE t1 (t TIME(3), dt DATETIME(6));
The
fsp
value, if given, must be in the range 0 to 6. A value of 0 signifies that there is no fractional part. If omitted, the default precision is 0. (This differs from the standard SQL default of 6, for compatibility with previous MariaDB versions.) - Functions that take temporal arguments accept values with fractional seconds. Return values from temporal functions include fractional seconds as appropriate.
- Syntax for temporal literals produces temporal values:
DATE '
,str
'TIME '
, andstr
'TIMESTAMP '
, and the ODBC-syntax equivalents. Previously, the temporal type keyword was ignored and these constructs produced the string value. See Standard SQL and ODBC Date and Time Literalsstr
'
In some cases, previously accepted syntax may produce different results. The following items indicate where existing code may need to be changed to avoid problems:
- Some expressions produce results that differ from previous results. Examples: The
timestamp
system variable returns a value that includes a microseconds fractional part rather than an integer. Functions that return a result that includes the current time (such asCURTIME()
,SYSDATE()
, orUTC_TIMESTAMP()
) interpret an argument as anfsp
value and the return value includes a fractional seconds part of that many digits. Previously, these functions permitted an argument but ignored it. TIME
values are converted toDATETIME
by adding the time to the current date. (This means that the date part of the result differs from the current date if the time value is outside the range from'00:00:00'
to'23:59:59'
.) Previously, conversion ofTIME
values toDATETIME
was unreliable. See , "Conversion Between Date and Time Types".TIMESTAMP(
was permitted in old MariaDB versions, butN
)N
was a display width rather than fractional seconds precision. Support for this behavior was removed in MariaDB 5.5.3, so applications that are reasonably up to date should not be subject to this issue. Otherwise, code must be rewritten.
Conversion Between Date and Time Types
To some extent, you can convert a value from one temporal type to another. However, there may be some alteration of the value or loss of information. In all cases, conversion between temporal types is subject to the range of legal values for the resulting type. For example, although DATE
, DATETIME
, and TIMESTAMP
values all can be specified using the same set of formats, the types do not all have the same range of values. TIMESTAMP
values cannot be earlier than 1970
UTC or later than '2038-01-19 03:14:07'
UTC. This means that a date such as '1968-01-01'
, while legal as a DATE
or DATETIME
value, is not valid as a TIMESTAMP
value and is converted to 0
.
Conversion of DATE
values:
- Conversion to a
DATETIME
orTIMESTAMP
value adds a time part of'00:00:00'
because theDATE
value contains no time information. - Conversion to a
TIME
value is not useful; the result is'00:00:00'
.
Conversion of DATETIME
and TIMESTAMP
values:
- Conversion to a
DATE
value discards the time part because theDATE
type contains no time information. - Conversion to a
TIME
value discards the date part because theTIME
type contains no date information.
Conversion of TIME
values to other temporal types is version specific:
- As of MariaDB 5.6.4, the value of
CURRENT-DATE()
is used for the date part. TheTIME
is interpreted as elapsed time (not time of day) and added to the date. This means that the date part of the result differs from the current date if the time value is outside the range from'00:00:00'
to'23:59:59'
.
Suppose that the current date is
'2012-01-01'
.TIME
values of'12:00:00'
,'24:00:00'
, and'-12:00:00'
, when converted toDATETIME
orTIMESTAMP
values, result in'2012-01-01 12:00:00'
,'2012-01-02 00:00:00'
, and'2011-12-31 12:00:00'
, respectively.Conversion of
TIME
toDATE
is similar but discards the time part from the result:'2012-01-01'
,'2012-01-02'
, and'2011-12-31'
, respectively. - Before 5.6.4, MariaDB converts a time value to a date or date-and-time value by parsing the string value of the time as a date or date-and-time. This is unlikely to be useful. For example,
'23:12:31'
interpreted as a date becomes'2032-12-31'
. Time values not valid as dates become'0000-00-00'
orNULL
.
Explicit conversion can be used to override implicit conversion. For example, in comparison of DATE
and DATETIME
values, the DATE
value is coerced to the DATETIME
type by adding a time part of '00:00:00'
. To perform the comparison by ignoring the time part of the DATETIME
value instead, use the CAST()
function in the following way:
date_col
= CAST(datetime_col
AS DATE)
Conversion of TIME
or DATETIME
values to numeric form (for example, by adding +0
) results in a double-precision value with a microseconds part of .000000
:
mysql>SELECT CURTIME(), CURTIME()+0;
+-----------+---------------+ | CURTIME() | CURTIME()+0 | +-----------+---------------+ | 10:41:36 | 104136.000000 | +-----------+---------------+ mysql>SELECT NOW(), NOW()+0;
+---------------------+-----------------------+ | NOW() | NOW()+0 | +---------------------+-----------------------+ | 2007-11-30 10:41:47 | 20071130104147.000000 | +---------------------+-----------------------+
Two-Digit Years in Dates
Date values with two-digit years are ambiguous because the century is unknown. Such values must be interpreted into four-digit form because MariaDB stores years internally using four digits.
For DATETIME
, DATE
, TIMESTAMP
, and YEAR
types, MariaDB interprets dates specified with ambiguous year values using these rules:
- Year values in the range
00-69
are converted to2000-2069
. - Year values in the range
70-99
are converted to1970-1999
.
Remember that these rules are only heuristics that provide reasonable guesses as to what your data values mean. If the rules used by MariaDB do not produce the values you require, you must provide unambiguous input containing four-digit year values.
In MySQL, the YEAR
data type can store the years 0
and 1901
to 2155
in one byte and display them using two or four digits. All two-digit years are considered to be in the range 1970
to 2069
, which means that if you store 01
in a YEAR
column, MariaDB Server treats it as 2001
.
ORDER BY
properly sorts YEAR
values that have two-digit years.
Some functions like MIN()
and MAX()
convert a YEAR
to a number. This means that a value with a two-digit year does not work properly with these functions. The fix in this case is to convert the YEAR
to four-digit year format.
String Types
- The
CHAR
andVARCHAR
Types- The
BINARY
andVARBINARY
Types- The
BLOB
andTEXT
Types- The
ENUM
Type- The
SET
Type - The
The string types are CHAR
, VARCHAR
, BINARY
, VARBINARY
, BLOB
, TEXT
, ENUM
, and SET
. This section describes how these types work and how to use them in your queries. For string type storage requirements, see , "Data Type Storage Requirements".
The CHAR
and VARCHAR
Types
The CHAR
and VARCHAR
types are similar, but differ in the way they are stored and retrieved. They also differ in maximum length and in whether trailing spaces are retained.
The CHAR
and VARCHAR
types are declared with a length that indicates the maximum number of characters you want to store. For example, CHAR(30)
can hold up to 30 characters.
The length of a CHAR
column is fixed to the length that you declare when you create the table. The length can be any value from 0 to 255. When CHAR
values are stored, they are right-padded with spaces to the specified length. When CHAR
values are retrieved, trailing spaces are removed unless the PAD_CHAR_TO_FULL_LENGTH
SQL mode is enabled.
Values in VARCHAR
columns are variable-length strings. The length can be specified as a value from 0 to 65,535. The effective maximum length of a VARCHAR
is subject to the maximum row size (65,535 bytes, which is shared among all columns) and the character set used. See "Table Column-Count and Row-Size Limits".
In contrast to CHAR
, VARCHAR
values are stored as a one-byte or two-byte length prefix plus data. The length prefix indicates the number of bytes in the value. A column uses one length byte if values require no more than 255 bytes, two length bytes if values may require more than 255 bytes.
If strict SQL mode is not enabled and you assign a value to a CHAR
or VARCHAR
column that exceeds the column's maximum length, the value is truncated to fit and a warning is generated. For truncation of nonspace characters, you can cause an error to occur (rather than a warning) and suppress insertion of the value by using strict SQL mode. See , "Server SQL Modes".
For VARCHAR
columns, trailing spaces in excess of the column length are truncated prior to insertion and a warning is generated, regardless of the SQL mode in use. For CHAR
columns, truncation of excess trailing spaces from inserted values is performed silently regardless of the SQL mode.
VARCHAR
values are not padded when they are stored. Trailing spaces are retained when values are stored and retrieved, in conformance with standard SQL.
The following table illustrates the differences between CHAR
and VARCHAR
by showing the result of storing various string values into CHAR(4)
and VARCHAR(4)
columns (assuming that the column uses a single-byte character set such as latin1
).
Value | CHAR(4)
| Storage Required | VARCHAR(4)
| Storage Required |
---|---|---|---|---|
''
| ' '
| 4 bytes | ''
| 1 byte |
'ab'
| 'ab '
| 4 bytes | 'ab'
| 3 bytes |
'abcd'
| 'abcd'
| 4 bytes | 'abcd'
| 5 bytes |
'abcdefgh'
| 'abcd'
| 4 bytes | 'abcd'
| 5 bytes |
The values shown as stored in the last row of the table apply only when not using strict mode; if MariaDB is running in strict mode, values that exceed the column length are not stored, and an error results.
If a given value is stored into the CHAR(4)
and VARCHAR(4)
columns, the values retrieved from the columns are not always the same because trailing spaces are removed from CHAR
columns upon retrieval. The following example illustrates this difference:
mysql>CREATE TABLE vc (v VARCHAR(4), c CHAR(4));
Query OK, 0 rows affected (0.01 sec) mysql>INSERT INTO vc VALUES ('ab ', 'ab ');
Query OK, 1 row affected (0.00 sec) mysql>SELECT CONCAT('(', v, ')'), CONCAT('(', c, ')') FROM vc;
+---------------------+---------------------+ | CONCAT('(', v, ')') | CONCAT('(', c, ')') | +---------------------+---------------------+ | (ab ) | (ab) | +---------------------+---------------------+ 1 row in set (0.06 sec)
Values in CHAR
and VARCHAR
columns are sorted and compared according to the character set collation assigned to the column.
All MariaDB collations are of type PADSPACE
. This means that all CHAR
and VARCHAR
values in MariaDB are compared without regard to any trailing spaces. For example:
mysql>CREATE TABLE names (myname CHAR(10), yourname VARCHAR(10));
Query OK, 0 rows affected (0.09 sec) mysql>INSERT INTO names VALUES ('Monty ', 'Monty ');
Query OK, 1 row affected (0.00 sec) mysql>SELECT myname = 'Monty ', yourname = 'Monty ' FROM names;
+--------------------+----------------------+ | myname = 'Monty ' | yourname = 'Monty ' | +--------------------+----------------------+ | 1 | 1 | +--------------------+----------------------+ 1 row in set (0.00 sec)
This is true for all MariaDB versions, and is not affected by the server SQL mode.Note
For more information about MariaDB character sets and collations, see , "Character Set Support".
For those cases where trailing pad characters are stripped or comparisons ignore them, if a column has an index that requires unique values, inserting into the column values that differ only in number of trailing pad characters will result in a duplicate-key error. For example, if a table contains 'a'
, an attempt to store 'a '
causes a duplicate-key error.
The BINARY
and VARBINARY
Types
The BINARY
and VARBINARY
types are similar to CHAR
and VARCHAR
, except that they contain binary strings rather than nonbinary strings. That is, they contain byte strings rather than character strings. This means that they have no character set, and sorting and comparison are based on the numeric values of the bytes in the values.
The permissible maximum length is the same for BINARY
and VARBINARY
as it is for CHAR
and VARCHAR
, except that the length for BINARY
and VARBINARY
is a length in bytes rather than in characters.
The BINARY
and VARBINARY
data types are distinct from the CHAR BINARY
and VARCHAR BINARY
data types. For the latter types, the BINARY
attribute does not cause the column to be treated as a binary string column. Instead, it causes the binary collation for the column character set to be used, and the column itself contains nonbinary character strings rather than binary byte strings. For example, CHAR(5) BINARY
is treated as CHAR(5) CHARACTER SET latin1 COLLATE latin1_bin
, assuming that the default character set is latin1
. This differs from BINARY(5)
, which stores 5-bytes binary strings that have no character set or collation. For information about differences between nonbinary string binary collations and binary strings, see , "The _bin
and binary
Collations".
If strict SQL mode is not enabled and you assign a value to a BINARY
or VARBINARY
column that exceeds the column's maximum length, the value is truncated to fit and a warning is generated. For cases of truncation, you can cause an error to occur (rather than a warning) and suppress insertion of the value by using strict SQL mode. See , "Server SQL Modes".
When BINARY
values are stored, they are right-padded with the pad value to the specified length. The pad value is 0x00
(the zero byte). Values are right-padded with 0x00
on insert, and no trailing bytes are removed on select. All bytes are significant in comparisons, including ORDER BY
and DISTINCT
operations. 0x00
bytes and spaces are different in comparisons, with 0x00
< space.
Example: For a BINARY(3)
column, 'a '
becomes 'a \0'
when inserted. 'a\0'
becomes 'a\0\0'
when inserted. Both inserted values remain unchanged when selected.
For VARBINARY
, there is no padding on insert and no bytes are stripped on select. All bytes are significant in comparisons, including ORDER BY
and DISTINCT
operations. 0x00
bytes and spaces are different in comparisons, with 0x00
< space.
For those cases where trailing pad bytes are stripped or comparisons ignore them, if a column has an index that requires unique values, inserting into the column values that differ only in number of trailing pad bytes will result in a duplicate-key error. For example, if a table contains 'a'
, an attempt to store 'a\0'
causes a duplicate-key error.
You should consider the preceding padding and stripping characteristics carefully if you plan to use the BINARY
data type for storing binary data and you require that the value retrieved be exactly the same as the value stored. The following example illustrates how 0x00
-padding of BINARY
values affects column value comparisons:
mysql>CREATE TABLE t (c BINARY(3));
Query OK, 0 rows affected (0.01 sec) mysql>INSERT INTO t SET c = 'a';
Query OK, 1 row affected (0.01 sec) mysql>SELECT HEX(c), c = 'a', c = 'a\0\0' from t;
+--------+---------+-------------+ | HEX(c) | c = 'a' | c = 'a\0\0' | +--------+---------+-------------+ | 610000 | 0 | 1 | +--------+---------+-------------+ 1 row in set (0.09 sec)
If the value retrieved must be the same as the value specified for storage with no padding, it might be preferable to use VARBINARY
or one of the BLOB
data types instead.
The BLOB
and TEXT
Types
A BLOB
is a binary large object that can hold a variable amount of data. The four BLOB
types are TINYBLOB
, BLOB
, MEDIUMBLOB
, and LONGBLOB
. These differ only in the maximum length of the values they can hold. The four TEXT
types are TINYTEXT
, TEXT
, MEDIUMTEXT
, and LONGTEXT
. These correspond to the four BLOB
types and have the same maximum lengths and storage requirements. See , "Data Type Storage Requirements".
BLOB
values are treated as binary strings (byte strings). They have no character set, and sorting and comparison are based on the numeric values of the bytes in column values. TEXT
values are treated as nonbinary strings (character strings). They have a character set, and values are sorted and compared based on the collation of the character set.
If strict SQL mode is not enabled and you assign a value to a BLOB
or TEXT
column that exceeds the column's maximum length, the value is truncated to fit and a warning is generated. For truncation of nonspace characters, you can cause an error to occur (rather than a warning) and suppress insertion of the value by using strict SQL mode. See , "Server SQL Modes".
Truncation of excess trailing spaces from values to be inserted into TEXT
columns always generates a warning, regardless of the SQL mode.
If a TEXT
column is indexed, index entry comparisons are space-padded at the end. This means that, if the index requires unique values, duplicate-key errors will occur for values that differ only in the number of trailing spaces. For example, if a table contains 'a'
, an attempt to store 'a '
causes a duplicate-key error. This is not true for BLOB
columns.
In most respects, you can regard a BLOB
column as a VARBINARY
column that can be as large as you like. Similarly, you can regard a TEXT
column as a VARCHAR
column. BLOB
and TEXT
differ from VARBINARY
and VARCHAR
in the following ways:
- For indexes on
BLOB
andTEXT
columns, you must specify an index prefix length. ForCHAR
andVARCHAR
, a prefix length is optional. See , "Column Indexes". BLOB
andTEXT
columns cannot haveDEFAULT
values.
If you use the BINARY
attribute with a TEXT
data type, the column is assigned the binary collation of the column character set.
LONG
and LONG VARCHAR
map to the MEDIUMTEXT
data type. This is a compatibility feature.
MySQL Connector/ODBC defines BLOB
values as LONGVARBINARY
and TEXT
values as LONGVARCHAR
.
Because BLOB
and TEXT
values can be extremely long, you might encounter some constraints in using them:
- Only the first
max_sort_length
bytes of the column are used when sorting. The default value ofmax_sort_length
is 1024. You can make more bytes significant in sorting or grouping by increasing the value ofmax_sort_length
at server startup or runtime. Any client can change the value of its sessionmax_sort_length
variable:
mysql>
SET max_sort_length = 2000;
mysql>SELECT id, comment FROM t
->ORDER BY comment;
Another way to use
GROUP BY
orORDER BY
on aBLOB
orTEXT
column containing long values when you want more thanmax_sort_length
bytes to be significant is to convert the column value into a fixed-length object. The standard way to do this is with theSUBSTRING()
function. For example, the following statement causes 2000 bytes of thecomment
column to be taken into account for sorting:mysql>
SELECT id, SUBSTRING(comment,1,2000) FROM t
->ORDER BY SUBSTRING(comment,1,2000);
- Instances of
BLOB
orTEXT
columns in the result of a query that is processed using a temporary table causes the server to use a table on disk rather than in memory because theMEMORY
storage engine does not support those data types (see , "How MariaDB Uses Internal Temporary Tables"). Use of disk incurs a performance penalty, so includeBLOB
orTEXT
columns in the query result only if they are really needed. For example, avoid usingSELECT *
, which selects all columns. - The maximum size of a
BLOB
orTEXT
object is determined by its type, but the largest value you actually can transmit between the client and server is determined by the amount of available memory and the size of the communications buffers. You can change the message buffer size by changing the value of themax_allowed_packet
variable, but you must do so for both the server and your client program. For example, both mysql and mysqldump enable you to change the client-sidemax_allowed_packet
value. See , "Tuning Server Parameters", , "mysql - The MariaDB Command-Line Tool", and , "mysqldump - A Database Backup Program". You may also want to compare the packet sizes and the size of the data objects you are storing with the storage requirements, see , "Data Type Storage Requirements"
Each BLOB
or TEXT
value is represented internally by a separately allocated object. This is in contrast to all other data types, for which storage is allocated once per column when the table is opened.
In some cases, it may be desirable to store binary data such as media files in BLOB
or TEXT
columns. You may find MySQL's string handling functions useful for working with such data. See , "String Functions". For security and other reasons, it is usually preferable to do so using application code rather than giving application users the FILE
privilege. You can discuss specifics for various languages and platforms in the MariaDB Forums (http://forums.mysql.com/).
The ENUM
Type
An ENUM
is a string object with a value chosen from a list of permitted values that are enumerated explicitly in the column specification at table creation time.
An enumeration value must be a quoted string literal; it may not be an expression, even one that evaluates to a string value. For example, you can create a table with an ENUM
column like this:
CREATE TABLE sizes ( name ENUM('small', 'medium', 'large') );
However, this version of the previous CREATE TABLE
statement does not work:
CREATE TABLE sizes ( c1 ENUM('small', CONCAT('med','ium'), 'large') );
You also may not employ a user variable as an enumeration value. This pair of statements do not work:
SET @mysize = 'medium'; CREATE TABLE sizes ( name ENUM('small', @mysize, 'large') );
If you wish to use a number as an enumeration value, you must enclose it in quotation marks. If the quotation marks are omitted, the number is regarded as an index. For this and other reasons-as explained later in this section-we strongly recommend that you do not use numbers as enumeration values.
Duplicate values in the definition cause a warning, or an error if strict SQL mode is enabled.
The value may also be the empty string (''
) or NULL
under certain circumstances:
- If you insert an invalid value into an
ENUM
(that is, a string not present in the list of permitted values), the empty string is inserted instead as a special error value. This string can be distinguished from a "normal" empty string by the fact that this string has the numeric value 0. More about this later.
If strict SQL mode is enabled, attempts to insert invalid
ENUM
values result in an error. - If an
ENUM
column is declared to permitNULL
, theNULL
value is a legal value for the column, and the default value isNULL
. If anENUM
column is declaredNOT NULL
, its default value is the first element of the list of permitted values.
Each enumeration value has an index:
- Values from the list of permissible elements in the column specification are numbered beginning with 1.
- The index value of the empty string error value is 0. This means that you can use the following
SELECT
statement to find rows into which invalidENUM
values were assigned:
mysql>
SELECT * FROM
tbl_name
WHEREenum_col
=0; - The index of the
NULL
value isNULL
. - The term "index" here refers only to position within the list of enumeration values. It has nothing to do with table indexes.
For example, a column specified as ENUM('one', 'two', 'three')
can have any of the values shown here. The index of each value is also shown.
Value | Index |
---|---|
NULL
| NULL
|
''
| 0 |
'one'
| 1 |
'two'
| 2 |
'three'
| 3 |
An enumeration can have a maximum of 65,535 elements.
Trailing spaces are automatically deleted from ENUM
member values in the table definition when a table is created.
When retrieved, values stored into an ENUM
column are displayed using the lettercase that was used in the column definition. Note that ENUM
columns can be assigned a character set and collation. For binary or case-sensitive collations, lettercase is taken into account when assigning values to the column.
If you retrieve an ENUM
value in a numeric context, the column value's index is returned. For example, you can retrieve numeric values from an ENUM
column like this:
mysql> SELECT enum_col
+0 FROM tbl_name
;
If you store a number into an ENUM
column, the number is treated as the index into the possible values, and the value stored is the enumeration member with that index. (However, this does not work with LOAD DATA
, which treats all input as strings.) If the numeric value is quoted, it is still interpreted as an index if there is no matching string in the list of enumeration values. For these reasons, it is not advisable to define an ENUM
column with enumeration values that look like numbers, because this can easily become confusing. For example, the following column has enumeration members with string values of '0'
, '1'
, and '2'
, but numeric index values of 1
, 2
, and 3
:
numbers ENUM('0','1','2')
If you store 2
, it is interpreted as an index value, and becomes '1'
(the value with index 2). If you store '2'
, it matches an enumeration value, so it is stored as '2'
. If you store '3'
, it does not match any enumeration value, so it is treated as an index and becomes '2'
(the value with index 3).
mysql>INSERT INTO t (numbers) VALUES(2),('2'),('3');
mysql>SELECT * FROM t;
+---------+ | numbers | +---------+ | 1 | | 2 | | 2 | +---------+
ENUM
values are sorted according to the order in which the enumeration members were listed in the column specification. (In other words, ENUM
values are sorted according to their index numbers.) For example, 'a'
sorts before 'b'
for ENUM('a', 'b')
, but 'b'
sorts before 'a'
for ENUM('b', 'a')
. The empty string sorts before nonempty strings, and NULL
values sort before all other enumeration values. To prevent unexpected results, specify the ENUM
list in alphabetic order. You can also use ORDER BY CAST(
or col
AS CHAR)ORDER BY CONCAT(
to make sure that the column is sorted lexically rather than by index number.
col
)
Functions such as SUM()
or AVG()
that expect a numeric argument cast the argument to a number if necessary. For ENUM
values, the cast operation causes the index number to be used.
To determine all possible values for an ENUM
column, use SHOW COLUMNS FROM
and parse the tbl_name
LIKE 'enum_col
'ENUM
definition in the Type
column of the output.
In the C API, ENUM
values are returned as strings. For information about using result set metadata to distinguish them from other strings, see , "C API Data Structures".
The SET
Type
A SET
is a string object that can have zero or more values, each of which must be chosen from a list of permitted values specified when the table is created. SET
column values that consist of multiple set members are specified with members separated by commas (",
"). A consequence of this is that SET
member values should not themselves contain commas.
For example, a column specified as SET('one', 'two') NOT NULL
can have any of these values:
'' 'one' 'two' 'one,two'
A SET
can have a maximum of 64 different members.
Duplicate values in the definition cause a warning, or an error if strict SQL mode is enabled.
Trailing spaces are automatically deleted from SET
member values in the table definition when a table is created.
When retrieved, values stored in a SET
column are displayed using the lettercase that was used in the column definition. Note that SET
columns can be assigned a character set and collation. For binary or case-sensitive collations, lettercase is taken into account when assigning values to the column.
MySQL stores SET
values numerically, with the low-order bit of the stored value corresponding to the first set member. If you retrieve a SET
value in a numeric context, the value retrieved has bits set corresponding to the set members that make up the column value. For example, you can retrieve numeric values from a SET
column like this:
mysql> SELECT set_col
+0 FROM tbl_name
;
If a number is stored into a SET
column, the bits that are set in the binary representation of the number determine the set members in the column value. For a column specified as SET('a','b','c','d')
, the members have the following decimal and binary values.
SET Member
| Decimal Value | Binary Value |
---|---|---|
'a'
| 1
| 0001
|
'b'
| 2
| 0010
|
'c'
| 4
| 0100
|
'd'
| 8
| 1000 |
If you assign a value of 9
to this column, that is 1001
in binary, so the first and fourth SET
value members 'a'
and 'd'
are selected and the resulting value is 'a,d'
.
For a value containing more than one SET
element, it does not matter what order the elements are listed in when you insert the value. It also does not matter how many times a given element is listed in the value. When the value is retrieved later, each element in the value appears once, with elements listed according to the order in which they were specified at table creation time. For example, suppose that a column is specified as SET('a','b','c','d')
:
mysql> CREATE TABLE myset (col SET('a', 'b', 'c', 'd'));
If you insert the values 'a,d'
, 'd,a'
, 'a,d,d'
, 'a,d,a'
, and 'd,a,d'
:
mysql> INSERT INTO myset (col) VALUES
-> ('a,d'), ('d,a'), ('a,d,a'), ('a,d,d'), ('d,a,d');
Query OK, 5 rows affected (0.01 sec)
Records: 5 Duplicates: 0 Warnings: 0
Then all these values appear as 'a,d'
when retrieved:
mysql> SELECT col FROM myset;
+------+
| col |
+------+
| a,d |
| a,d |
| a,d |
| a,d |
| a,d |
+------+
5 rows in set (0.04 sec)
If you set a SET
column to an unsupported value, the value is ignored and a warning is issued:
mysql>INSERT INTO myset (col) VALUES ('a,d,d,s');
Query OK, 1 row affected, 1 warning (0.03 sec) mysql>SHOW WARNINGS;
+---------+------+------------------------------------------+ | Level | Code | Message | +---------+------+------------------------------------------+ | Warning | 1265 | Data truncated for column 'col' at row 1 | +---------+------+------------------------------------------+ 1 row in set (0.04 sec) mysql>SELECT col FROM myset;
+------+ | col | +------+ | a,d | | a,d | | a,d | | a,d | | a,d | | a,d | +------+ 6 rows in set (0.01 sec)
If strict SQL mode is enabled, attempts to insert invalid SET
values result in an error.
SET
values are sorted numerically. NULL
values sort before non-NULL
SET
values.
Functions such as SUM()
or AVG()
that expect a numeric argument cast the argument to a number if necessary. For SET
values, the cast operation causes the numeric value to be used.
Normally, you search for SET
values using the FIND_IN_SET()
function or the LIKE
operator:
mysql>SELECT * FROM
mysql>tbl_name
WHERE FIND_IN_SET('value
',set_col
)>0;SELECT * FROM
tbl_name
WHEREset_col
LIKE '%value
%';
The first statement finds rows where set_col
contains the value
set member. The second is similar, but not the same: It finds rows where set_col
contains value
anywhere, even as a substring of another set member.
The following statements also are legal:
mysql>SELECT * FROM
mysql>tbl_name
WHEREset_col
& 1;SELECT * FROM
tbl_name
WHEREset_col
= 'val1
,val2
';
The first of these statements looks for values containing the first set member. The second looks for an exact match. Be careful with comparisons of the second type. Comparing set values to '
returns different results than comparing values to val1
,val2
''
. You should specify the values in the same order they are listed in the column definition.
val2
,val1
'
To determine all possible values for a SET
column, use SHOW COLUMNS FROM
and parse the tbl_name
LIKE set_col
SET
definition in the Type
column of the output.
In the C API, SET
values are returned as strings. For information about using result set metadata to distinguish them from other strings, see , "C API Data Structures".
Data Type Storage Requirements
The storage requirements for table data on disk depend on several factors. Different storage engines represent data types and store raw data differently. Table data might be compressed, either for a column or an entire row, complicating the calculation of storage requirements for a table or column.
Despite differences in storage layout on disk, the internal MariaDB APIs that communicate and exchange information about table rows use a consistent data structure that applies across all storage engines.
This section includes guidelines and information for the storage requirements for each data type supported by MySQL, including the internal format and size for storage engines that use a fixed-size representation for data types. Information is listed by category or storage engine.
The internal representation of a table has a maximum row size of 65,535 bytes, even if the storage engine is capable of supporting larger rows. This figure excludes BLOB
or TEXT
columns, which contribute only 9 to 12 bytes toward this size. For BLOB
and TEXT
data, the information is stored internally in a different area of memory than the row buffer. Different storage engines handle the allocation and storage of this data in different ways, according to the method they use for handling the corresponding types. For more information, see , Storage Engines, and "Table Column-Count and Row-Size Limits".
InnoDB
Tables
See , "Physical Row Structure" for information about storage requirements for InnoDB
tables.
NDBCLUSTER
Tables
Important
NDB
tables use 4-byte alignment; all NDB
data storage is done in multiples of 4 bytes. Thus, a column value that would typically take 15 bytes requires 16 bytes in an NDB
table. For example, in NDB
tables, the TINYINT
, SMALLINT
, MEDIUMINT
, and INTEGER
(INT
) column types each require 4 bytes storage per record due to the alignment factor.
Each BIT(
column takes M
)M
bits of storage space. Although an individual BIT
column is not 4-byte aligned, NDB
reserves 4 bytes (32 bits) per row for the first 1-32 bits needed for BIT
columns, then another 4 bytes for bits 33-64, and so on.
While a NULL
itself does not require any storage space, NDBCLUSTER
reserves 4 bytes per row if the table definition contains any columns defined as NULL
, up to 32 NULL
columns. (If a MariaDB Cluster table is defined with more than 32 NULL
columns up to 64 NULL
columns, then 8 bytes per row are reserved.)
Every table using the NDBCLUSTER
storage engine requires a primary key; if you do not define a primary key, a "hidden" primary key is created by NDB
. This hidden primary key consumes 31-35 bytes per table record.
You can use the ndb_size.pl
Perl script to estimate NDB
storage requirements. It connects to a current MariaDB (non-Cluster) database and creates a report on how much space that database would require if it used the NDBCLUSTER
storage engine. See ndb_size.pl for more information.
Storage Requirements for Numeric Types
Data Type | Storage Required |
---|---|
TINYINT
| 1 byte |
SMALLINT
| 2 bytes |
MEDIUMINT
| 3 bytes |
INT , INTEGER
| 4 bytes |
BIGINT
| 8 bytes |
FLOAT(
| 4 bytes if 0 <= p <= 24, 8 bytes if 25 <= p <= 53
|
FLOAT
| 4 bytes |
DOUBLE [PRECISION] , REAL
| 8 bytes |
DECIMAL( , NUMERIC(
| Varies; see following discussion |
BIT(
| approximately (M +7)/8 bytes |
Values for DECIMAL
(and NUMERIC
) columns are represented using a binary format that packs nine decimal (base 10) digits into four bytes. Storage for the integer and fractional parts of each value are determined separately. Each multiple of nine digits requires four bytes, and the "leftover" digits require some fraction of four bytes. The storage required for excess digits is given by the following table.
Leftover Digits | Number of Bytes |
---|---|
0 | 0 |
1 | 1 |
2 | 1 |
3 | 2 |
4 | 2 |
5 | 3 |
6 | 3 |
7 | 4 |
8 | 4 |
Storage Requirements for Date and Time Types
For TIME
, DATETIME
, and TIMESTAMP
columns, the storage required for tables created before MariaDB 5.6.4 differs from tables created from 5.6.4 on. This is due to a change in 5.6.4 that permits these types to have a fractional part, which requires from 0 to 3 bytes.
Data Type | Storage Required Before MariaDB 5.6.4 | Storage Required as of MariaDB 5.6.4 |
---|---|---|
YEAR
| 1 byte | 1 byte |
DATE
| 3 bytes | 3 bytes |
TIME
| 3 bytes | 3 bytes + fractional seconds storage |
DATETIME
| 8 bytes | 5 bytes + fractional seconds storage |
TIMESTAMP
| 4 bytes | 4 bytes + fractional seconds storage |
As of MariaDB 5.6.4, storage for YEAR
and DATE
remains unchanged. However, TIME
, DATETIME
, and TIMESTAMP
are represented differently. DATETIME
is packed more efficiently, requiring 5 rather than 8 bytes for the nonfractional part, and all three parts have a fractional part that requires from 0 to 3 bytes, depending on the fractional seconds precision of stored values.
Fractional Seconds Precision | Storage Required |
---|---|
0 | 0 bytes |
1, 2 | 1 byte |
3, 4 | 2 bytes |
5, 6 | 3 bytes |
For example, TIME(0)
, TIME(2)
, TIME(4)
, and TIME(6)
use 3, 4, 5, and 6 bytes, respectively. TIME
and TIME(0)
are equivalent and require the same storage.
For details about internal representation of temporal values, see MySQL Internals: Important Algorithms and Structures.
Storage Requirements for String Types
In the following table, M
represents the declared column length in characters for nonbinary string types and bytes for binary string types. L
represents the actual length in bytes of a given string value.
Data Type | Storage Required |
---|---|
CHAR(
| M × w bytes, 0 <= 255, where w is the number of bytes required for the maximum-length character in the character set
|
BINARY(
| M bytes, 0 <= 255
|
VARCHAR( , VARBINARY(
| L + 1 bytes if column values require 0 - 255 bytes, L + 2 bytes if values may require more than 255 bytes
|
TINYBLOB , TINYTEXT
| L + 1 bytes, where L < 28
|
BLOB , TEXT
| L + 2 bytes, where L < 216
|
MEDIUMBLOB , MEDIUMTEXT
| L + 3 bytes, where L < 224
|
LONGBLOB , LONGTEXT
| L + 4 bytes, where L < 232
|
ENUM('
| 1 or 2 bytes, depending on the number of enumeration values (65,535 values maximum) |
SET('
| 1, 2, 3, 4, or 8 bytes, depending on the number of set members (64 members maximum) |
Variable-length string types are stored using a length prefix plus data. The length prefix requires from one to four bytes depending on the data type, and the value of the prefix is L
(the byte length of the string). For example, storage for a MEDIUMTEXT
value requires L
bytes to store the value plus three bytes to store the length of the value.
To calculate the number of bytes used to store a particular CHAR
, VARCHAR
, or TEXT
column value, you must take into account the character set used for that column and whether the value contains multi-byte characters. In particular, when using the utf8
(or utf8mb4
) Unicode character set, you must keep in mind that not all characters use the same number of bytes and can require up to three (four) bytes per character. For a breakdown of the storage used for different categories of utf8
or utf8mb4
characters, see , "Unicode Support".
VARCHAR
, VARBINARY
, and the BLOB
and TEXT
types are variable-length types. For each, the storage requirements depend on these factors:
- The actual length of the column value
- The column's maximum possible length
- The character set used for the column, because some character sets contain multi-byte characters
For example, a VARCHAR(255)
column can hold a string with a maximum length of 255 characters. Assuming that the column uses the latin1
character set (one byte per character), the actual storage required is the length of the string (L
), plus one byte to record the length of the string. For the string 'abcd'
, L
is 4 and the storage requirement is five bytes. If the same column is instead declared to use the ucs2
double-byte character set, the storage requirement is 10 bytes: The length of 'abcd'
is eight bytes and the column requires two bytes to store lengths because the maximum length is greater than 255 (up to 510 bytes).
The effective maximum number of bytes that can be stored in a VARCHAR
or VARBINARY
column is subject to the maximum row size of 65,535 bytes, which is shared among all columns. For a VARCHAR
column that stores multi-byte characters, the effective maximum number of characters is less. For example, utf8
characters can require up to three bytes per character, so a VARCHAR
column that uses the utf8
character set can be declared to be a maximum of 21,844 characters. See "Table Column-Count and Row-Size Limits".
The size of an ENUM
object is determined by the number of different enumeration values. One byte is used for enumerations with up to 255 possible values. Two bytes are used for enumerations having between 256 and 65,535 possible values. See , "The ENUM
Type".
The size of a SET
object is determined by the number of different set members. If the set size is N
, the object occupies (
bytes, rounded up to 1, 2, 3, 4, or 8 bytes. A N
+7)/8SET
can have a maximum of 64 members. See , "The SET
Type".
Choosing the Right Type for a Column
For optimum storage, you should try to use the most precise type in all cases. For example, if an integer column is used for values in the range from 1
to 99999
, MEDIUMINT UNSIGNED
is the best type. Of the types that represent all the required values, this type uses the least amount of storage.
All basic calculations (+
, -
, *
, and /
) with DECIMAL
columns are done with precision of 65 decimal (base 10) digits. See , "Numeric Type Overview".
If accuracy is not too important or if speed is the highest priority, the DOUBLE
type may be good enough. For high precision, you can always convert to a fixed-point type stored in a BIGINT
. This enables you to do all calculations with 64-bit integers and then convert results back to floating-point values as necessary.
PROCEDURE ANALYSE
can be used to obtain suggestions for optimal column data types. For more information, see , "PROCEDURE ANALYSE
".
Using Data Types from Other Database Engines
To facilitate the use of code written for SQL implementations from other vendors, MariaDB maps data types as shown in the following table. These mappings make it easier to import table definitions from other database systems into MariaDB.
Other Vendor Type | MySQL Type |
---|---|
BOOL
| TINYINT
|
BOOLEAN
| TINYINT
|
CHARACTER VARYING(
| VARCHAR(
|
FIXED
| DECIMAL
|
FLOAT4
| FLOAT
|
FLOAT8
| DOUBLE
|
INT1
| TINYINT
|
INT2
| SMALLINT
|
INT3
| MEDIUMINT
|
INT4
| INT
|
INT8
| BIGINT
|
LONG VARBINARY
| MEDIUMBLOB
|
LONG VARCHAR
| MEDIUMTEXT
|
LONG
| MEDIUMTEXT
|
MIDDLEINT
| MEDIUMINT
|
NUMERIC
| DECIMAL |
Data type mapping occurs at table creation time, after which the original type specifications are discarded. If you create a table with types used by other vendors and then issue a DESCRIBE
statement, MariaDB reports the table structure using the equivalent MariaDB types. For example:
tbl_name
mysql>Copyright 1997, 2012, Oracle and/or its affiliates. All rights reserved. Legal NoticesCREATE TABLE t (a BOOL, b FLOAT8, c LONG VARCHAR, d NUMERIC);
Query OK, 0 rows affected (0.00 sec) mysql>DESCRIBE t;
+-------+---------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+---------------+------+-----+---------+-------+ | a | tinyint(1) | YES | | NULL | | | b | double | YES | | NULL | | | c | mediumtext | YES | | NULL | | | d | decimal(10,0) | YES | | NULL | | +-------+---------------+------+-----+---------+-------+ 4 rows in set (0.01 sec)
Prev | Next | |
Globalization | Home | Chapter 11. Functions and Operators |