In some cases, MySQL silently changes column specifications from
those given in a
CREATE TABLE or
ALTER TABLE statement. These
might be changes to a data type, to attributes associated with a
data type, or to an index specification.
All changes are subject to the internal row-size limit of 65,535 bytes, which may cause some attempts at data type changes to fail. See Section C.10.4, “Limits on Table Column Count and Row Size”.
TIMESTAMPdisplay sizes are discarded.
Also note that
NOT NULLby default.
Columns that are part of a
PRIMARY KEYare made
NOT NULLeven if not declared that way.
MySQL maps certain data types used by other SQL database vendors to MySQL types. See Section 11.9, “Using Data Types from Other Database Engines”.
If you include a
USINGclause to specify an index type that is not permitted for a given storage engine, but there is another index type available that the engine can use without affecting query results, the engine uses the available type.
If strict SQL mode is not enabled, a
VARCHARcolumn with a length specification greater than 65535 is converted to
TEXT, and a
VARBINARYcolumn with a length specification greater than 65535 is converted to
BLOB. Otherwise, an error occurs in either of these cases.
CHARACTER SET binaryattribute for a character data type causes the column to be created as the corresponding binary data type:
BLOB. For the
SETdata 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 );
Certain other data type changes can occur if you compress a table using myisampack. See Section 188.8.131.52, “Compressed Table Characteristics”.