DBMS

DATA TYPES









An overview of available data type
Numeric data types
The BIT data type
String data types
Temporal data types
Attributes that modify how column ara handled
The auto_increment attribute for sequence generation
Controlling how my sql handling missing or invalid data values

DATA TYPE OVERVIEW
MySQL enables you to store several different types of
data, and it‟s important to understand what data types are
available so that you can define your tables appropriately
for the information they‟ll contain. Generally speaking,
data values can be grouped into the following
categories:
• Numeric values
• String values
• Temporal values

 Numbers may or may not have a fractional part and may
have a leading sign.
For example:
14, -428.948, and +739 all are legal numbers. Integer
values have no fractional part.

Strings may be non-binary or binary, to store
characters or raw bytes, respectively. Strings that
store characters have a character set and
collation; they can be case sensitive or case
insensitive.

 Strings are written within quotes (for example, „I
am a string‟). String columns can be declared as

either fixed length or variable length.

 BLOB values (binary large objects) are
treated as strings in MySQL.

Temporal values include dates (such as „200511-03‟), times (such as „14:23:00‟), and values
that have both a date and a time part („2005-1103 14:23:00‟).
MySQL also supports a special temporal type
that represents year-only values efficiently.

 Date and time values can be written as quoted
strings and may sometimes be written as

numbers in contexts where numeric temporal
values are understood

HOW TO WRITE MY SQL PROGRAMS

 When you create a table, the declaration for each
of its columns includes the column name,a data
type that indicates what kind of values the column

may hold, and possibly some attributes (options)
that more specifically define how MySQL should
handle the column.

For example,
the following statement creates a table named
people, which contains an integer-valued numeric

column named id and two 30-character string
columns named first_name and last_name:

Example program:
CREATE TABLE people
(
id INT,
first_name CHAR(30),
last_name CHAR(30)
);

WHAT ARE THE ATTRIBUTES IN IN DATA TYPES

 The column definitions in that CREATE TABLE
statement contain only names and data types.To
more specifically control how MySQL handles a
column, add attributes to the column definition. The
modified CREATE TABLE statement looks like this:

CREATE TABLE people

For example,
 To disallow negative values in the id column,
add the UNSIGNED attribute.

 To disallow missing or unknown values in the
columns, add NOT NULL to each column
definition so that NULL values cannot be stored.

(
id INT UNSIGNED NOT NULL,
first_name CHAR(30) NOT NULL,

last_name CHAR(30) NOT NULL
);

 For storing numeric data, MySQL provides

integer data types, floating-point types that store
approximate-value numbers, a fixed-point type
that stores exact-value numbers, and a BIT type
for bit-field values. When you choose a numeric
data type, consider the following factors:

N The range of values the data type represents
N The amount of storage space that column

values require

 N The display width indicating the maximum
number of characters to use when presenting

column values in query output
 N The column precision and scale for floatingpoint and fixed-point values

Integer data types include
 TINYINT
 SMALLINT
 MEDIUMINT
 INT
 BIGINT

Smaller integer types require less storage space,
but are more limited in the range of values they
represent.

For example,
 TINYINT column values take only one byte each
to store, but the type has a small range (–128 to
127).

 INT column values require four bytes each, but
the type has a much larger range (–
2,147,483,648 to 2,147,483,647).

 The integer data types are summarized range.

 in the following table, which indicates the amount
of storage per value that each type requires as
well as its range.

 For integer values declared with the UNSIGNED
attribute, negative values are not allowed, and
the high end of the range shifts upward to

approximately double the maximum positive
value of the signed

Type
storage required
signed range
unsigned range
TINYINT
1 byte
–128 to 127
0 to 255
SMALLINT
2 bytes
32,768
to
32,767
0 to 65,535
MEDIUMINT
3 bytes
–8,388,608
to
8,388,607
0 to 16,777,215
INT
4 bytes
–2,147,683,648 to2,147,483,647
0 to
4,294,967,295
BIGINT
8 bytes
–9,223,372,036,854,775,808
to
0 to 18,446,744,073, 709,551,615
9,223,372,036,854,775,807

Integer data types may be declared with a display
width, which affects the number of digits used to
display column values in query output.
For example,
assume that you declare an INT column with a
display width of 4 like this:

century INT(4)

 The result is that values in the century column
usually are displayed four digits wide.
 However, it‟s important to understand that the

display width is unrelated to the range of the data
type.

 The display width specified for a column affects
only the maximum number of digits
 MySQL uses to display column values. Values

shorter than the display width are padded with
spaces as necessary.

Note:
italso that the display width is not a hard limit; it
won‟t cause output truncation of a value that‟s
too long to fit within the width. Instead, the full
value is shown.

For example,
 assume that you‟ve inserted the number 57622
into the century column.

 When you SELECT the column in a query,
MySQL displays the entire value (57622),not just

the first four digits of the value

The display width for integer types also is
unrelated to storage requirements.
For example,
an INT(4) column does not require half as much
storage per value as INT(8). All values for the INT
data type require four bytes.

The floating-point data types include FLOAT and
DOUBLE. Each of these types may be used to
represent approximate-value numbers that have
an integer part, a fractional part, or both.

FLOAT and DOUBLE data types represent values
in the native binary floating-point format used by
the server host‟s CPU. This is a very efficient type

for storage and computation, but values are
subject to rounding error

FLOAT represents single-precision floating-point
values that require four bytes each for storage.
DOUBLE represents double-precision floatingpoint values that require eight bytes each for
storage.

You can specify explicit precision and scale values
in the column definition to indicate the number of
significant digits and the number of decimal places
to the right of the decimal point.

If you specify no precision or scale, MySQL

represents values stored in FLOAT and DOUBLE
columns to the maximum accuracy allowed by the
hardware of the MySQL server host.

The following definitions include no explicit
precision or scale:
 float_col FLOAT

 double_col DOUBLE

The following definitions specify a single-precision
column with a precision of 10digits and scale of 3
decimals, and a double-precision column with a

precision of 20 digits and scale of 7 decimals

For example:
 weight FLOAT(10,3)
 avg_score DOUBLE(20,7)

 The fixed-point data type is DECIMAL. It is used
to represent exact-value numbers that havean

integer part, a fractional part, or both.

 DECIMAL uses a fixed-decimal storage format:
All values in a DECIMAL column have the same

number of decimal places and are stored exactly
as given when possible

DECIMAL values are not processed quite as
efficiently as FLOAT or DOUBLE values but

DECIMAL values are not subject to rounding error,
so they are more accurate.
In other words, there is an accuracy versus speed
tradeoff in choosing which type to use.

For example,
 the DECIMAL data type is a popular choice for
financial applications involving currency

calculations, because accuracy is most
important.

 DECIMAL columns may be declared with a
precision and scale to indicate the number of

significant digits and the number of decimal places
to the right of the decimal point.

For example,
 if you want to represent values such as dollarand-cents currency figures, you can do so using

a two-digit scale:
cost DECIMAL(10,2)

The precision and scale can be omitted, or just the
scale. The defaults for omitted precision and scale
are 10 and 0, respectively, so the following

declarations are equivalent:
total DECIMAL

total DECIMAL(10)
total DECIMAL(10,0)

 The amount of storage required for DECIMAL
column values depends on the precision and

scale. Approximately four bytes are required per
nine digits on each side of the decimal point.

 The NUMERIC data type in MySQL is a synonym
for DECIMAL. Standard SQL allows for a
difference between the two types, but in MySQL

they are the same.

 In standard SQL, the precision for NUMERIC
must be exactly the number of digits given in the
column definition. The precision for DECIMAL

must be at least that many digits but is allowed to
be more. In MySQL, the precision is exactly as
given, for both types.

The BIT data type represents bit-field values. BIT
column specifications take a width indicating the
number of bits per value, from 1 to 64 bits. The
following columns store 4 and 20 bits per value,

respectively:
bit_col1 BIT(4)
bit_col2 BIT(20)

For a BIT(n) column, the range of values is 0 to 2 n
– 1, and the storage requirement is approximately
INT((n+7)/8) bytes per value.

BIT columns can be assigned values using numeric

expressions. To write literal bit values in binary format, the
literal-value notation b‟val‟ can be used, where val indicates
a value consisting of the binary digits 0 and 1.
For example,
b‟1111‟ equals 15 and b‟1000000‟ equals 64.

The following table lists the string data types provided
in MySQL.
Type
Description
CHAR
Fixed-length non-binary
string
VARCHAR
Variable-length non-binary string
TEXT
Variable-length non-binary
string
BINARY
Fixed-length binary
string
VARBINARY
Variable-length binary string
BLOB
Variable-length binary string
ENUM
Enumeration consisting of a fixed

When you choose a string data type, consider
the following factors:

Whether you need to store non-binary or binary
strings; are character set and collationimportant?

 The maximum length of values you need to
store.

 Whether to use a fixed or variable amount of
storage.

 How trailing spaces are handled for comparison,
storage, and retrieval.

 n The number of distinct values required; ENUM
or SET may be useful if the set of values is fixed.
The following discussion first describes the general
differences between non-binary and binary strings,
and then the specific characteristics of each of the
string data types.

 Strings in MySQL may be treated as non-binary
or binary. The differences between these types of
strings make them suited to different purposes.

 The most general difference is that non-binary
strings have a character set and consist of
characters in that character set, whereas binary

strings consist simply of bytes that are
distinguished only by their numeric values. This
section explores the implications of this
difference.

 Non-binary strings have the following
characteristics:
A non-binary string is a sequence of characters

that belong to a specific character set Characters
may consist of a single byte, or multiple bytes if
the character set allows it.

For example,

 MySQL‟s default character set is latin1 The
latin1 character set uses one byte per character.

 In contrast, contains so many characters that
they cannot all be represented in a single byte,
so each character requires multiple bytes to

store.

n Multi-byte character sets may require a fixed or
variable number of bytes per character.The ucs2
Unicode character set uses two bytes per
character, whereas the utf8 Unicode character
set uses from one to three bytes per character.
n Multi-byte character comparisons are
performed in character units, not in byte units.

Non-binary string comparisons are based on the
collation (sorting order) of the character set
associated with the string. A given character set

may have one or more collations, but a given
string has only one of those collations.

 The collation determines whether uppercase and
lowercase versions of a given characterare equivalent. If

the collation is not case sensitive, strings such as „ABC‟,
„Abc‟,and „abc‟ are all considered equal. If the collation is
case sensitive, the strings are all considered different.

The collation determines whether uppercase and
lowercase versions of a given character are
equivalent. If the collation is not case sensitive,
strings such as „ABC‟, „Abc‟,and „abc‟ are all
considered equal. If the collation is case
sensitive, the strings are all considered different.

The collation also determines whether to treat
instances of a given character with different
accent marks as equivalent. The result is that
comparisons of non-binary stringsmay not be
accent sensitive. For example, an „a‟ with no
accent may be considered thesame as the „á‟
and „à‟ characters. A given collation may be case
or accent sensitive, or both.

• A collation can be a binary collation. In this
case, comparisons are based on numeric
character values. One effect of this is that
for character sets with uppercase and
lowercase characters or accented
characters, the collation is case sensitive
and accent sensitive because each of
these characters has a different numeric
value

Comparison based on inary collation differs
from comparison of binary strings:

 A binary collation is performedper
character, and characters might consist of
multiple bytes. Comparisons for binary
strings are always byte-based

• A given character set may have several
collations to choose from. This enables
you to select different sort orders for the
same character set.
• you can choose from any of the following
collations, many of which correspond to
the sorting order rules of specific
languages:

mysql> SHOW COLLATION LIKE ‘latin1%’;
----------------------------------------------------------------------------------------------| Collation
|Charset | Id | Default | Compiled | Sortlen |
----------------------------------------------------------------------------------------------| latin1_german1_ci | latin1 | 5 |
|
|
0 | |
latin1_swedish_ci | latin1 | 8 |
Yes
|
Yes
|
1 |
| latin1_danish_ci | latin1 | 15 |
|
|
0 |
| latin1_german2_ci | latin1 | 31 |
|
Yes
|
2 |
| latin1_bin
| latin1 | 47 |
|
Yes
|
1 |
| latin1_general_ci | latin1 | 48 |
|
|
0 |
| latin1_general_cs | latin1 | 49 |
|
|
0 |
| latin1_spanish_ci | latin1 | 94 |
|
|
0 |
-----------------------------------------------------------------------------------------------

Binary strings have the following
characteristics:
• A binary string is treated as a sequence of byte values. It
might appear to contain characters because you can write
a binary string value as a quoted string, but it “really”
contains binary data as far as MySQL is concerned.

• Because binary strings contain bytes, not characters,

comparisons of binary strings are performed on the basis
of the byte values in the string. This has the implication
that the concept of lettercase does not apply the same
way as for non-binary strings.

• Binary strings may appear to be case sensitive,
but that is because uppercase and lowercase
versions of a given character have different

numeric byte values.

 A binary string also may appear to be accent
sensitive, but that is because versions of a

character with differentaccents have different
byte values.

 The following example shows the difference in
how non-binary and binary strings are treated
with respect to lettercase. The non-binary string

is converted to uppercase by UPPER() because
it contains characters for which lettercase
applies. The binary string remains unchanged
because it consists of byte values that have no
lettercase.

mysql> SELECT UPPER(‘AaBb’),
UPPER(BINARY ‘AaBb’);
-------------------------------------------------------------------------------------------------------------------------- |
UPPER(„AaBb‟)
|
UPPER(BINARY
„AaBb‟)
|
-------------------------------------------------------------------------------------------------------------------------|
AABB
|
AaBb
|
--------------------------------------------------------------------------------------------------------------------------

 A multi-byte character, if stored in a binary string,
is treated simply as multiple individual bytes.

 Character boundaries of the original data no
longer apply.String comparison rules are

addressed in more detail in Section 10.3.1,
“Case Sensitivity in String Comparisons

 The different treatment of non-binary and binary
strings in MySQL is important when it comes to

choosing data types for table columns. You
normally base the decision on whether you want
to treat column values as containing characters
or raw bytes.

 Thus, non-binary columns are more suitable for
character strings such as textual descriptions,

and binary columns are more suitable for raw
data such as images or compressed data.

Three data types store non-binary strings: CHAR,
VARCHAR, and TEXT. Three data types store
binary strings:
BINARY, VARBINARY, and BLOB. They’re
each described further in the following
sections.

 You can mix non-binary and binary string
columns within a single table. Also, for nonbinary

string columns, different columns can use
different character sets and collations.

 For example, assume that you want to create a
table named auth_info, to store login name and
password authorization information for users of

an application, as well as a picture to associate
with each user. You want login names to match
in any lettercase, passwords to be case
sensitive, and the picture column must store
binary image data.

Program:
The following table definition satisfies these requirements:
CREATE TABLE auth_info
(
login CHAR(32) CHARACTER SET latin1,
password CHAR(32) CHARACTER SET latin1 COLLATE
latin1_general_cs,picture MEDIUMBLOB
);

CHAR, VARCHAR, TEXT
The CHAR, VARCHAR, and TEXT data types
store non-binary strings (that is, strings of
characters
that have a character set and collation). The types
differ in terms of their maximum allowable length
and in how trailing spaces are handled

The CHAR data type is a fixed-length type. To define a
CHAR column, provide the column name, the keyword
CHAR, and the maximum length of acceptable values in
parentheses. The length should be a number from 0 to 255.

The CHAR data type holds strings up to the length
specified in the column definition.
Values in a CHAR column always take the same
amount of storage.
For example, a column defined as CHAR(30)
requires 30 characters for each value, even empty
values.

Values shorter than the designated length are
padded with spaces to that length when they are

stored. Trailing spaces are removed from CHAR
values when they are retrieved, so retrieved values
might not be the same length as when stored.

VARCHAR is a variable-length data type.
VARCHAR columns are defined similarly to CHAR
columns, but the maximum length can be a
number up to 65,535. (The actual allowable
maximum length is a few characters less due to
internal restrictions imposed by storage engines.)

 A string stored into a VARCHAR column takes
only the number of characters required to store

it, plus one or two bytes to record the string‟s
length. (One byte forcolumns declared with a
length less than 256, two bytes otherwise.)

Values in a VARCHAR column are stored as given.
Trailing spaces are not removed or added for
storage or retrieval.

 The TEXT data type comes in four different
sizes, differing in the maximum length of values
they can store. All are variable-length types, so

an individual value requires storage equal to the
length (in characters) of the value, plus 1 to 4
bytes to record the length of the value.
 Trailing spaces are not removed or added for
storage or retrieval.

• The following table summarizes the non-binary string data
types. For the storage requirement values, M represents the
maximum length of a column. L represents the actual length of
a given value, which may be 0 to M.
Type
Storage Required
Maximum
Length
CHAR(M)
M characters
255 characters
VARCHAR(M)
L characters plus 1 or 2 bytes 65,535
characters
TINYTEXT
L characters + 1 byte
255
characters
TEXT
L characters + 2 bytes
65,535
characters
MEDIUMTEXT
L characters + 3 bytes

• For fixed-length (CHAR) columns, MySQL must
allocate enough space to store any value
containing up to as many characters allowed by

the column declaration. For CHAR(10), 10 bytes
are required if the column has a single-byte
character set.

• If the column has a multibyt character set,
MySQL must allocate 10 times the width of the
widest allowed character. For utf8, each

character takes from one to three bytes, so
MySQL must allocate three bytes per character,
or 30 bytes per column value. This amount of
storage is required even for storing an empty
string.

For variable-length (VARCHAR, TEXT) columns,
MySQL allocates only the required amount of
space for each stored value. A 10-character utf8

VARCHAR column requires 10 bytes (plus alength
byte) for a value that contains only single-byte
characters, but 30 bytes (plus a length byte) if it
contains only triple-byte characters.

• Non-binary strings have a character set and
collation, and non-binary string columns by
default are assigned the character set and

collation of the table that contains them. The
CHARACTER SET and COLLATE attributes can
be used to designate specific values for a
column,as described in Section 5.6, “Column
Attributes.”

 BINARY

 VARBINARY
 BLOB

• The BINARY, VARBINARY, and BLOB data types
are the binary string equivalents of the nonbinary
CHAR, VARCHAR, and TEXT data types.

 That is, they store strings that consist of bytes
rather than characters, and they have no
character set or collation

 BINARY is a fixed-length data type. The length
should be a number from 0 to 255. Values
shorter than the designated length are padded

with spaces to that length when they are stored.

 Trailing spaces are removed from BINARY
values when they are retrieved, so retrieved
values might not be the same length as when

stored.

 For this reason, BINARY may not be suited
for applications that store binary data if
stored values can have trailing spaces.

 For example, if an encrypted value happens to
end with spaces, the retrieved value will be
differentfrom the value that was stored

• VARBINARY is a variable-length data type. The
maximum length can be a number up to 65,535.

 Values in a VARBINARY column are stored as
given. Trailing spaces are not removed or added
for storage or retrieval

The BLOB data type comes in four different sizes,
differing in the maximum length of values they can
store. All are variable-length types, so an individual

value requires storage equal to the length (in
bytes) of the value, plus 1 to 4 bytes to record the
length of the value.

The following table summarizes the binary string
data types. For the storage requirement values, M
represents the maximum length of a column. L

represents the actual length of a given value,
which may be 0 to M.

Type
Storage Required
Maximum Length
-------------------------------------------------------------------------------------------------------BINARY(M)
M bytes
255 bytes
VARBINARY(M)
L bytes plus
1 or 2 bytes 65,535 bytes
TINYBLOB
L + 1 bytes
255 bytes
BLOB
L + 2 bytes

The ENUM and SET string data types are used
when the values to be stored in a column are
chosen from a fixed set of values. You define

columns for both types in terms of string values,
but MySQL represents them internally as integers.
This leads to very efficient storage, but can have
some results that are unintuitive unless you keep
this string/integer duality in mind.

ENUM is an enumeration type. An ENUM column
definition includes a list of allowable values;
each value in the list is called a “member” of the

list. Every value stored in the column must equal
one of the values in the list. A simple (and very
common) use for ENUM is to create a twoelement list for columns that store yes/no or
true/false choices

The following table shows how to declare such
columns:
CREATE TABLE booleans
(
yesno ENUM(„Y‟,‟N‟),
truefalse ENUM(„T‟,‟F‟)
);

Enumeration values aren‟t limited to being single
letters or uppercase. The columns could also be
defined like this:
CREATE TABLE booleans
(
yesno ENUM(„yes‟,‟no‟),
truefalse ENUM(„true‟,‟false‟)
);

An ENUM column definition may list up to 65,535
members. Enumerations with up to 255 members
require one byte of storage per value.

Enumerations with 256 to 65,535 members require
two bytes per value.

The following table contains an enumeration
column continent
that lists continent names as valid enumeration
members:
CREATE TABLE Countries
(
name char(30),
continent ENUM („Asia‟,‟Europe‟,‟North
America‟,‟Africa‟, „Oceania‟,‟Antarctica‟,‟South
America‟)
);

The values in an ENUM column definition are given as a
comma-separated list of quoted strings. Internally, MySQL
stores the strings as integers, using the values 1 through n
for a column with n enumeration members. The following
statement assigns the enumeration value „Africa‟ to the
continent column; MySQL actually stores the value 4
because „Africa‟ is the fourth continent name listed in the
enumeration definition:
Syntax:
INSERT INTO Countries
(name,continent)VALUES(„Kenya‟,‟Africa‟);

MySQL reserves the internal value 0 as an implicit
member of all ENUM columns. It‟s used to
represent illegal values assigned to an
enumeration column.

 For example, if you assign „USA‟ to the continent
column, MySQL will store the value 0, rather than
any of the values 1 through 7, because „USA‟ is

not a valid enumeration member. If you select
the column later, MySQL displays 0 values as the
empty string

The SET data type, like ENUM, is declared using a
comma-separated list of quoted strings that define
its valid members. But unlike ENUM, a given SET
column may be assigned a value consisting of any
combination of those members. The following
definition contains a list of symptoms exhibited by
allergy sufferers:
CREATE TABLE allergy
(
symptom SET(„sneezing‟,‟runny nose‟,‟stuffy
head‟,‟red eyes‟)

A patient may have any or all (or none) of these
symptoms, and symptom values therefore might
contain zero to four individual SET members,
separated by commas. The following statements
set the symptom column to the empty string (no
SET members), a single SET member, and
multiple SET members, respectively:
INSERT INTO allergy (symptom) VALUES(„‟);
INSERT INTO allergy (symptom) VALUES(„stuffy
head‟);
INSERT INTO allergy (symptom)

MySQL represents SET columns as a bitmap
using one bit per member, so the elements in the
symptom definition have internal values of 1, 2, 4,

and 8 (that is, they have the values of bits 0
through 3 in a byte). Internally, MySQL stores the
values shown in the preceding INSERT statements
as 0 (no bits set), 4 (bit 2 set), and 9 (bits 0 and 3
set; that is, 1 plus 8).

A SET definition may contain up to 64 members.
The internal storage required for set values varies
depending on the number of SET elements (1, 2,

3, 4, or 8 bytes for sets of up to 8, 16, 24, 32, or 64
members).

 If you try to store an invalid list member
into a SET column, it‟s ignored because it
does not correspond to any bit in the
column definition.

 For example, setting a symptom value
to„coughing,sneezing,wheezing‟ results in an
internal value of 1 („sneezing‟). The „coughing‟

and „wheezing‟ elements are ignored because
they aren‟t listed in the column definition as legal
set members. (In strict SQL mode, an error
occurs if you try to store an illegal SETvalue.)

As mentioned earlier in this section, the conversion
between string and numeric representations of
ENUM and SET values can have unintuitive
results.
For example, although you would normally refer to
an enumeration column using the string forms of
its values, you can also use the internal numeric
values. The effect of this can be very subtle if the
string values look like numbers. Suppose that you
define a table t like this:
Syntax:

In this case, the enumeration values are the
strings „0‟, „1‟, „2‟, „3‟, and „>3‟, and the matching
internal numeric values are 1, 2, 3, 4, and 5,

respectively. Now suppose that you issue the
following statement:
Syntax:
INSERT INTO t (age,siblings) VALUES(14,‟3‟);

The siblings value is specified here as the string
„3‟, and that is the value assigned to the column in
the new record. However, you can also specify the

siblings value as a number, as follows:
Syntax:
INSERT INTO t (age,siblings) VALUES(14,3);

But in this case, 3 is interpreted as the internal
value, which corresponds to the enumeration value
„2‟! The same principle applies to retrievals.
Consider the following two statements:
Syntax:
SELECT * FROM t WHERE siblings = „3‟;
SELECT * FROM t WHERE siblings = 3;

MySQL provides data types for storing different
kinds of temporal information. In the following
descriptions, the terms YYYY, MM, DD, hh, mm,

and ss stand for a year, month, day of month, hour,
minute, and second value, respectively.

The following table summarizes the storage requirements
and ranges for the date and timedata types.
Type
Storage Required
Range
DATE
3 bytes
„1000-01-01‟ to
„9999-12-31‟
TIME
3 bytes
„-838:59:59‟ to
„838:59:59‟
DATETIME
8 bytes
„1000-01-01
00:00:00‟ to9999- 12-31 23:59:59‟ TIMESTAMP
4
bytes
„1970-01-01 00:00:00‟ to mid-year 2037
YEAR
1 byte
1901 to 2155 (for
YEAR(4)),1970 to 2069 YEAR(2))

Each temporal data type also has a “zero” value
that‟s used when you attempt to store an illegal
value. The “zero” value is represented in a format

appropriate for the type
(such as„0000-00-00‟ for DATE values and
„00:00:00‟ for TIME) values.

MySQL represents date values in „YYYY-MM-DD‟
format when it displays them. This representation
corresponds to the ANSI SQL date format, also

known as ISO 8601 format.
If necessary, you can reformat date values into
other display formats using the
DATE_FORMAT() function.

MySQL also expects to receive dates in ISO
format, or at least close to ISO format. That is,
date values must be given in year-month-day

order, although some deviation from strict ISO
format is allowed:

 Leading zeros on month and day values may be
omitted. For example, both „2000-1-1‟ and „200001-01‟ are accepted as legal.
 The delimiter between date parts need not be „-‟;
you can use other punctuation characters, such
as „/‟.
 Two-digit years are converted to four-digit years.
You should be aware that this conversion is done
based on the rule that year values from 70 to 99
represent the years 1970 to 1999, whereas
values from 00 to 69 represent the years 2000 to
2069.

If you need to load values that aren‟t in an
acceptable format into a DATE column, you should
convert them into ISO format before loading them.

An alternative approach that‟s useful in some
circumstances is to load the values into a string
column and perform reformatting operations using
SQL string functions to produce ISO format values
that can be assigned to a DATE column.

MySQL represents time values in „hh:mm:ss‟
format. For TIME value entry, some variation on
this format is allowed.

For example,
leading zeros on TIME parts may be omitted.

MySQL represents time values in „hh:mm:ss‟
format when displaying them.
If necessary,you can reformat time values into

other display formats using the TIME_FORMAT()
function.

For time value entry, some variation on this format
is allowed.
For example,

leading zeroson TIME parts may be omitted.

The DATE data type represents date values in
„YYYY-MM-DD‟ format. The supported range of
DATE values is „1000-01-01‟ to „9999-12-31‟. You

might be able to use earlier dates than that, but it‟s
better to stay within the supported range to avoid
unexpected behavior.

The TIME data type represents time values in
„hh:mm:ss‟ format. The range of TIME columns is „838:59:59‟ to „838:59:59‟. This is outside the time-

of-day range of „00:00:00‟ to „23:59:59‟ because
TIME columns can be used to represent elapsed
time. Thus, values might be larger than time-of-day
values, or even negative.

• The DATETIME data type stores date-and-time
values in „YYYY-MM-DD hh:mm:ss‟ format. It‟s
similar to a combination of DATE and TIME

values, but the TIME part represents time of day
rather than elapsed time and has a range limited
to „00:00:00‟ to „23:59:59‟.

The date part of DATETIME columns has the
same range as DATE columns; combined with the
TIME part, this results in a DATETIME range from

„1000-01-01 00:00:00‟ to „9999-12-31 23:59:59‟.

The YEAR data type represents year-only values.
You can declare such columns as YEAR(4) or
YEAR(2) to obtain a four-digit or two-digit display

format. If you don‟t specify any display width, the
default is four digits.

If you don‟t need a full date and the range of
values you need to store falls into the YEAR
range, consider using YEAR to store temporal

values. It‟s a very space-efficient data type
because values require only one byte of storage
each.

The TIMESTAMP type, like DATETIME,
stores date-and-time values, but has a
different range and some special properties
that make it especially suitable for tracking
data modification times.

MySQL displays TIMESTAMP values using the
same format as DATETIME values; that is,
„YYYY-MM-DD hh:mm:ss‟.

The range of TIMESTAMP values begins at 197001-01 00:00:00 (UTC) and extends partway into
the year 2037. TIMESTAMP values actually

represent the number of seconds elapsed since
the beginning of 1970 and are stored using four
bytes.

This provides room for sufficient seconds to represent a

date in the year 2037.
MySQL Server stores TIMESTAMP values internally in
UTC. It converts TIMESTAMP values from the server‟s
current time zone for storage, and converts back to the
current time zone for retrieval.

The TIMESTAMP data type in MySQL is special in
that you can cause a TIMESTAMP column to be
initialized or updated automatically to the current

date and time without explicitly assigning it a
value.

That is, you can specify that any single
TIMESTAMP column in a table should be initialized
with the current timestamp when the record is

created with INSERT or REPLACE, updated with
the current timestamp when the record is changed
with UPDATE, or both.

It‟s important to know about the automatic
initialization and update properties of TIMESTAMP.
• These properties make TIMESTAMP columns

useful for tracking record modification times, but
can be a source of confusion if you‟re not aware
of them.

Do not choose TIMESTAMP for a column on the
basis of the fact that it stores date-and-time values
unless you also understand the circumstances

under which the column will update automatically
when other columns in a record change.

To control the initialization and update behavior of
a TIMESTAMP column, you add either or both of
the DEFAULT CURRENT_TIMESTAMP and ON

UPDATE CURRENT_TIMESTAMP attributes to the
column definition when creating the table with
CREATE TABLE or changing it with ALTER
TABLE.

The DEFAULT CURRENT_TIMESTAMP attribute
causes the column to be initialized with the current
timestamp at the time the record is created. The

ON UPDATE CURRENT_TIMESTAMP attribute
causes the column to be updated with the current
timestamp when the value of another column in
the record is changed from its current value.

For backward compatibility with older versions of
MySQL if you do not specify either of the
DEFAULT CURRENT_TIMESTAMP or ON

UPDATE CURRENT_TIMESTAMP attributes when
creating a table, the MySQL server automatically
assigns both attributes to the first TIMESTAMP
column:

Example program
mysql> CREATE TABLE ts_test1 (
-> ts1 TIMESTAMP,
-> ts2 TIMESTAMP,
-> data CHAR(30)
-> );
Query OK, 0 rows affected (0.00 sec)

mysql> DESCRIBE ts_test1;
| Field | Type
| Null | Key |
Default
|
Extra
-------------------------------------------------------------------------------------------------------| ts1 | timestamp | YES |
|
CURRENT_TIMESTAMP | |
| ts2 | timestamp | YES |
| 0000-00-00
00:00:00
||
| data | char(30) | YES |
| NULL
|

mysql> INSERT INTO ts_test1 (data) VALUES
Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM ts_test1
|
ts1
|
ts2
|
data
|
----------------------------------------------------------------------------------------------------| 2005-01-04 14:45:51 | 0000-00-00 00:00:00
|
original_value |
1 row in set (0.00 sec)
mysql> . . . time passes . . .

The same behavior occurs if you specify both
DEFAULT CURRENT_TIMESTAMP and ON
UPDATE CURRENT_TIMESTAMP explicitly for the
first TIMESTAMP column.
It is also possible to use just one of the attributes.
The following example uses DEFAULT
CURRENT_TIMESTAMP, but omits ON UPDATE
CURRENT_TIMESTAMP.

-> created_time TIMESTAMP DEFAULT
CURRENT_TIMESTAMP,

-> data CHAR(30)
-> );


• Note that even though the record is updated, the
created_time column is not. In versions ofMySQL
Server before 4.1, the UPDATE statement would

have caused the created_time columnto be
updated as well.

The next example demonstrates how to create a
TIMESTAMP column that is not set to the current
timestamp when the record is created, but only

when it is updated. In this case,the column
definition includes ON UPDATE
CURRENT_TIMESTAMP but omits DEFAULT
CURRENT_TIMESTAMP:

-> updated_time TIMESTAMP ON UPDATE
CURRENT_TIMESTAMP,
-> data CHAR(30)
-> );

mysql> INSERT INTO ts_test3 (data) VALUES
(‘original_value’);
mysql> SELECT * FROM ts_test3;
|
updated_time |
data
|
-----------------------------------------------------| 0000-00-00 00:00:00 | original_value |
-----------------------------------------------------1 row in set (0.00 sec)

-> created TIMESTAMP DEFAULT
CURRENT_TIMESTAMP,

-> updated TIMESTAMP ON UPDATE
CURRENT_TIMESTAMP,
-> data CHAR(30)
-> );

Nevertheless, you can achieve the effect of having
one column with the creation time and another with
the time of the last update. To do this, create two
TIMESTAMP columns. Define the column that
should hold the creation time with DEFAULT 0 and
explicitly set it to NULL whenever you INSERT a
new record. Define the column that should hold the
updated time with DEFAULT
CURRENT_TIMESTAMP

-> created TIMESTAMP DEFAULT 0,
-> updated TIMESTAMP ON UPDATE
CURRENT_TIMESTAMP,
-> data CHAR(30)
-> );

mysql> CREATE TABLE ts_null (ts TIMESTAMP NULL);
mysql> DESCRIBE ts_null;
| Field | Type
| Null | Key | Default | Extr |
------------------------------------------------------------------| ts | timestamp | YES |
| NULL |
|

In MySQL Server, it is possible to set the current
time zone on a per-connection basis.
To discuss time zones, we must first introduce a

number of concepts:

UTC is “Coordinated Universal Time” and is the
common reference point for timemeasurement. For
purposes of this discussion, UTC is the same as

Greenwich Mean Time (GMT), although time zone
aficionados get into long discussions about
astronomicalobservations, atomic clocks,
“Universal Time” versus “Greenwich Mean
Time”versus “Coordinated Universal Time,” and

There are three time zone formats available to use
with MySQL:
The signed hour/minute offset of a time zone is

expressed as „+hh:mm‟ or „-hh:mm‟,where hh and
mm stand for two-digit hours and minutes,
respectively. UTC is, inthis format, commonly
expressed as „+00:00‟.

Each time zone bases its offset according to the
distance between it and the UTC time zone. Berlin,

Germany, is one hour ahead of Greenwich,
England

for example,
the sun rises in Berlin approximately one hour
before it does in Greenwich), so the hour/minute

offset for Berlin is expressed as „+01:00‟. In New
York, where the sun rises some five hours after it
does in Greenwich, the hour/minute offset is
expressed as „-05:00‟.

The named time zone for a given location is
defined by a string such as „US/Eastern‟, which is
translated into the correct time zone by the server.
MySQL supports named time zones through a set
of time zone tables in the mysql database.
(For named time zones to work, these tables must
be properly populated by the MySQL administrator.

See Section 24.6, “Loading Time Zone Tables.”)

The third format is the SYSTEM time zone. This
stands for the time zone value that the MySQL
server retrieves from the server host. The server

uses this value as its default time zone setting
when it begins executing.

The exact details of support for named time zones
differ slightly from one operating system to the
next, and are not covered in any detail on the

Developer certification exam. However,nknowing
how to use time zone support using signed offsets
is mandatory.

Time zone settings are determined by the
time_zone system variable. The server maintains a
global time_zone value, as well as a session

time_zone value for each client that connects. The
session value is initialized for a given client, from
the current value of the global time_zone variable,
when the client connects.

The default setting for the global value is
SYSTEM, which thus also becomes each client‟s
initial session time_zone value. The global and
session time zone settings can be retrieved with
the following statement:
mysql> SELECT @@global.time_zone,
@@session.time_zone;
| @@global.time_zone | @@session.time_zone
|
-------------------------------------------------------------------------

MySQL Server stores TIMESTAMP values
internally in UTC. It converts TIMESTAMP values
from the server‟s current time zone for storage,

and converts back to the current time zone for
retrieval. The standard setting for both the server
and the per-client connection is to use the
SYSTEM setting, which the server retrieves from
the host at startup.

If the time zone setting is the same for both
storage and retrieval, you will get back the same
value you store. If you store a TIMESTAMP value,

and then change the time zone to a different value,
the returned TIMESTAMP value will be different
from the one you stored.

The following examples demonstrate how to
change the session time zone settings to store and
retrieve TIMESTAMP data. First, we set the
session time zone to UTC, that is, „+00:00‟:
mysql> SET time_zone = „+00:00‟;
mysql> SELECT @@session.time_zone;
| @@session.time_zone |
|
+00:00
|

Next, we create a simple table containing just a
TIMESTAMP column named ts and insert one
record that assigns the current time to ts. Then we

retrieve the record:
mysql> CREATE TABLE ts_test (ts TIMESTAMP);

mysql> INSERT INTO ts_test (ts) VALUES
(NULL);
mysql> SELECT * FROM ts_test;
|
ts
|
| 2005-01-04 20:50:18 |

Finally, we change the session time zone twice,
each time retrieving the value after the change.
This demonstrates that, even though we‟re

retrieving the same TIMESTAMP value, the
change in time zone setting causes the “localized”
display value to be different each time:

mysql> SET time_zone = „+02:00‟;
mysql> SELECT * FROM ts_test
|
ts
|
------------------------------------| 2005-01-04 22:50:18
|

mysql> SET time_zone = „-05:00‟;

mysql> SELECT * FROM ts_test;

|

ts

|

-----------------------------------| 2005-01-04 15:50:18 |


The per-connection time zone settings also influence other
aspects of the MySQL server that depend on the current
time, most notably the function NOW().MySQL Server also
supports the CONVERT_TZ() function, which performs time
zone conversions of datetime values:
mysql> SELECT CONVERT_TZ(„2005-01-27 13:30:00‟,
„+01:00‟, „+03:00‟);
+-------------------------------------------------------------------------------| CONVERT_TZ(„2005-01-27 13:30:00‟, „+01:00‟, „+03:00‟) |
+---------------------------------------------------------------------------------|
2005-01-27 15:30:00
|

CONVERT_TZ() assumes that the given datetime
value has the time zone represented by the first
hour/minute offset argument, and converts it to a

value in the time zone represented by the second
offset argument. The result is that you get the
same datetime value, from the point of view of a
different time zone.

The final part of a column definition (following the
data type) can include optional attributesthat
modify how MySQL handles the column. The

following table contains an integercolumn that is
UNSIGNED and cannot contain NULL values, a
string column that has a characterset of utf8, and a
date column that has a default value of „1999-1231‟:

CREATE TABLE t
(
i INT UNSIGNED NOT NULL,
c CHAR(10) CHARACTER SET utf8,
d DATE DEFAULT „1999-12-31‟
);
The following sections describe the allowable
column attributes.

Numeric data types other than BIT may have the
following attributes:
 UNSIGNED causes negative values to be

disallowed.

 ZEROFILL causes retrieved values to be leftpadded with leading zeros up to the column‟
display width. For example, if you store the

values 0, 14, and 1234 in a column that‟s defined
as INT(5) ZEROFILL, MySQL displays them as
00000, 00014, and 01234 when you retrieve
them.

• AUTO_INCREMENT applies to integer data
types. It‟s used to generate sequences of
successive unique values. Defining a column

with AUTO_INCREMENT causes a special
behavior:

 When you insert NULL into the column, MySQL
generates the next value in thesequence

automatically and stores that in the column
instead.

• Use of AUTO_INCREMENTcarries with it other
requirements: There may be only one
AUTO_INCREMENT column per table, the
column must be indexed, and the column must
be defined as NOT NULL. Section 5.7, “Using
the AUTO_INCREMENT Column Attribute,”
provides further details on AUTO_INCREMENT
columns

The following attributes apply to the non-binary string data

types (CHAR, VARCHAR, and TEXT):
• CHARACTER SET specifies the character set to use for
the column. CHARSET is a synonym for CHARACTER
SET.

• COLLATE specifies the character set collation.
• BINARY is shorthand for specifying the binary
collation of the column‟s character set.Note that

the BINARY attribute differs from the BINARY
data type. The former sets thecollation for a nonbinary string column. The latter creates a binary
string column

If both CHARACTER SET and COLLATE are
given, the collation must be legal for the character
set. Specifying CHARACTER SET without

COLLATE sets the collation to the default collation
for the character set. Specifying COLLATE without
CHARACTER SET sets the character set to the
collation‟s character set. (Each collation is unique
to a specific character set.)

 If both the CHARACTER SET and
COLLATE attributes are omitted, the table
defaults are used.

 The character set binary is special and modifies
the column‟s data type: It causes columns
declared using the CHAR, VARCHAR, and TEXT

non-binary string types to be created using the
BINARY, VARBINARY, and BLOB binary string
types, respectively.

The following attributes can be used with all data
types, subject to the exceptions noted:
• NULL and NOT NULL apply to all types of
columns. They indicate whether a column
cancontain NULL values. If you specify neither
attribute, the default is to allow NULL values in
the column. The exceptions are that NULL
cannot be stored in AUTO_INCREMENT
columns or in TIMESTAMP columns that are
defined to update automatically with the current
timestamp when set to NULL.

DEFAULT value provides a column with a default
value to be used when you create a new record
but don‟t explicitly specify a value for the column.
For example, default valuesnare used when you
execute an INSERT statement that doesn‟t provide
values for all columns in the table.

There are certain limitations on when DEFAULT
can be given and on the values that you can
specify:

 DEFAULT can be used with all data types with
the exception of TEXT and BLOB columns, or
integer columns that have the
AUTO_INCREMENT attribute.

A default value must be a constant, not an
expression whose value is calculated at recordcreation time. The exception is that DEFAULT for a

single TIMESTAMP column in a table can be given
as the CURRENT_TIMESTAMP function to specify
a default ofn“the current date and time.” The rules
for declaring TIMESTAMP columns are discussed
in Section 5.5.2, “The TIMESTAMP Data Type.”

 It is an error to specify a default value of NULL for a NOT
NULL column.

 It is an error to specify a default value that is out
of range for the data type, such as a negative

number for an UNSIGNED numeric column.

 It is an error to specify a default value of NULL
for a NOT NULL column. n It is an error to
specify a default value that is out of range for the

data type, such as a negative number for an
UNSIGNED numeric column.
 If the column allows NULL, MySQL adds
DEFAULT NULL to the column definition. If the
column does not allow NULL, MySQL adds no

this case, the default value is implicit and may or
may not be used when the column is missing from
an INSERT statement, depending on whether the

server is operating in strict SQL mode. Treatment
of missing values is described in Section 5.8,
“HandlingnMissing or Invalid Data Values.” Implicit
default values are defined as follows:

Implicit default values are defined as follows:
 For numeric columns, the default is zero.
 For string columns other than ENUM, the default
is the empty string. For ENUM columns, the
default is the first enumeration member.

 For temporal columns, the default value is the
“zero” value for the data type, represented in
whatever format is appropriate to the type (for

example, „0000-00-00‟ for DATE and „00:00:00‟
for TIME). For TIMESTAMP, the implicit default is
the current timestamp if the column is defined to
be automatically initialized, or the “zero” value
otherwise.

For all data types except BLOB and TEXT, it‟s also
possible to specify a PRIMARY KEY or UNIQUE
clause at the end of a column definition, although

these aren‟t really column attributes as such.

They cause the creation of a PRIMARY KEY or
UNIQUE index for the column. Adding either of
these clauses to a column definition is the same as
defining the index in a separateclause.
For example, the following table definitions are
equivalent:
• CREATE TABLE t (i INT NOT NULL PRIMARY
KEY);

• CREATE TABLE t (i INT NOT NULL, PRIMARY
KEY (i));

The AUTO_INCREMENT attribute may be added
to an integer column definition to create a column
for which MySQL automatically generates a new

sequence number each time you create a new
row. There may be only one AUTO_INCREMENT
column per table, the columnnmust be indexed,
and the column must be defined as NOT NULL.

The AUTO_INCREMENT attribute is used in
conjunction with an index (usually a primary key)
and provides a mechanism whereby each value is

a unique identifier that can be used to refer
unambiguously to the row in which it occurs.
MySQL also provides a LAST_INSERT_ID()
function that returns the most recently generated
AUTO_INCREMENT value.

The value returnedby LAST_INSERT_ID() is specific
to the client that generates the AUTO_INCREMENT

value. It cannotmbe affected by other clients. The
LAST_INSERT_ID() function is useful for
determining the identifier when you need to look up
the record just created, or when you need to know
the identifier to create related records in other tables.

The following scenario illustrates how you can set
up and use an AUTO_INCREMENT column.
Assume that you‟re organizing a conference and

need to keep track of attendees and the seminars
for which each attendee registers.

Your task is to record seminar registrations and
associate them with the appropriate attendee.
Unique ID numbers provide a way to keep track of

attendees and an AUTO_INCREMENT column
makes the implementation for the task relatively
easy

Set up an attendee table to record information about each
person attending the conference. The table shown here
includes columns for ID number, name, and job title:
mysql> CREATE TABLE attendee
-> (
-> att_id
INT UNSIGNED NOT NULL
AUTO_INCREMENT,
-> att_name CHAR(100),
-> att_title CHAR(40),
-> PRIMARY KEY (att_id)
-> );

The att_id column is created as a PRIMARY KEY
because it must contain unique values, and as an
AUTO_INCREMENT column because it‟s

necessary for MySQL to generate values for the
column automatically.

Set up a seminar table to record the seminars for
which each attendee registers.
Assume that there are fourDatabase Design,

Query Optimization, SQL Standards, and Using
Replication. There are various ways in which these
seminars can be represented; an ENUM column is
one that works well because the seminar titles
form a small fixed list of values seminars

The table can be created with this statement:
mysql> CREATE TABLE seminar
-> (
-> att_id
INT UNSIGNED NOT NULL,
-> sem_title ENUM(„Database Design‟,‟Query
Optimization‟,
->
„SQL Standards‟,‟Using Replication‟),
-> INDEX (att_id)
-> )

Note both the differences and similarities of the
att_id column declarations in the two tables. In
attendee, att_id is an AUTO_INCREMENT column

and is indexed as a PRIMARY KEY to ensure that
each value in the column is unique. In seminar,
att_id is indexed for faster lookups, but it isn‟t
indexed as a PRIMARY KEY.

Nor is the column declared in the seminar table with
the AUTO_INCREMENT attribute because ID
values should be tied to existing IDs in the attendee

table, not generated automatically. Aside from these
differences, the column is declared using the same
data type (INT) and attributes (UNSIGNED, NOT
NULL) as the att_id column in the attendee table.

Each time a conference registration form is
received, enter the attendee information into the
attendee table.

For example:
mysql> INSERT INTO attendee
(att_name,att_title)
-> VALUES(‘Charles Loviness’,’IT Manager’);

 Note that the INSERT statement doesn‟t include

a value for the att_id column. Because att_id is
an AUTO_INCREMENT column, MySQL
generates the next sequence number and sets
the att_id column in the new row to that value.
 You can use the new att_id value to look up the

record just inserted, but how do you know what
value to use? The answer is that you don‟t need

Instead, you can get the ID by invoking the
LAST_INSERT_ID() function, which returns the
most recent AUTO_INCREMENT value generated
during your current connection with the server.
Thus, the record for Charles Loviness can be
retrieved like this:
Mysql> SELECT * FROM attendee WHERE att_id
= LAST_INSERT_ID();
| att_id | att_name
| att_title |
-----------------------------------------------------| 3 | Charles Loviness | IT Manager |

Next, enter new records into the seminar table for
each seminar marked on the entry form. The att_id
value in each of these records must match the

att_id value in thenewly created attendee record.
Here again, the LAST_INSERT_ID() value can be
used.

If Loviness will participate in Database Design,
SQL Standards, and Using Replication, create
records for those seminars as follows:
mysql> INSERT INTO seminar (att_id,sem_title)
-> VALUES(LAST_INSERT_ID(),’Database
Design’);
-> VALUES(LAST_INSERT_ID(),’SQL
Standards’);
-> VALUES(LAST_INSERT_ID(),’Using

To see what the new seminar records look like, use
the LAST_INSERT_ID() value to retrieve them:
mysql> SELECT * FROM seminar WHERE att_id
LAST_INSERT_ID();
| att_id | sem_title
|
------------------------------------------| 3
| Database Design |
| 3
| SQL Standards
|
| 3
| Using Replication |

When you receive the next registration form,
repeat the process just described. For every new
attendee record, the value of LAST_INSERT_ID()

will change to reflect the new value in the att_id
column.

The preceding description shows how to use an
AUTO_INCREMENT column:
how to declare thecolumn, how to generate new ID

values when inserting new records, and how to
use the ID values to tie together related tables.
However, the description glosses over some of the
details.

These are presented in the following discussion,
beginning with declaration syntax and then
providing further information about how

AUTO_INCREMENT columns work.

The att_id-related declarations in the attendee
table look like this:
Syntax:

att_id INT UNSIGNED NOT NULL
AUTO_INCREMENT, PRIMARY KEY (att_id)

These declarations involve the following factors,
which you should consider when creating an
AUTO_INCREMENT column:

The column must have an integer data type.
Choose the specific type based on the number of
values the column must be able to hold.

 For the largest range, use BIGINT. However,
BIGINT requires 8 bytes per value. If you want to
use less storage, INT requiresn only 4 bytes per

value and provides a range that‟s adequate for
many applications.
 You can use integer types smaller than INT as
well, but it‟s common error to choose one that‟s
too small

For example,
TINYINT has a range that allows very few unique
numbers, o you‟ll almost certainly run into

problems using it as an AUTO_INCREMENT
column for identification purposes.

 An AUTO_INCREMENT sequence contains only
positive values. For this reason, it‟s best to
declare the column to be UNSIGNED.

Syntactically, it isn‟t strictly required that you
declare the column this way, but doing so
doubles the range of the sequence because an
UNSIGNED integer column has a larger
maximum value.

 Defining the column as UNSIGNED also serves
as a reminder that you should never store
negative values in an AUTO_INCREMENT

column.

 The most common way to use an
AUTO_INCREMENT column is as a primary key,
which ensures unique values and prevents

duplicates.
 The column should thus be defined tocontain
unique values, either as a PRIMARY KEY or a
UNIQUE index. (MySQL allows you to declare an
AUTO_INCREMENT column with a non-unique

 An AUTO_INCREMENT column must
be NOT NULL.

After setting up an AUTO_INCREMENT column,
use it as follows:
 Inserting NULL into an AUTO_INCREMENT

column causes MySQL to generate the next
sequence value and store it in the column.

 Omitting the AUTO_INCREMENT column from
an INSERT statement is the same as inserting
NULL explicitly.

 In other words, an INSERT statement that does
not provide an explicit value for an
AUTO_INCREMENT column also generates the
next sequence value for the column.

For example,
if id is an AUTO_INCREMENT column in the table
t, the following two statements are equivalent:

INSERT INTO t (id,name) VALUES(NULL,‟Hans‟);
INSERT INTO t (name) VALUES(„Hans‟);

A positive value can be inserted explicitly into an
AUTO_INCREMENT column if the value isn‟t
already present in the column. If this value is larger

than the current sequence counter, subsequent
automatically generated values begin with the
value plus one:

Syntax:

mysql> CREATE TABLE t (id INT
AUTO_INCREMENT, PRIMARY KEY (id));
mysql> INSERT INTO t (id)

VALUES(NULL),(NULL),(17),(NULL),(NULL);
mysql> SELECT id FROM t;

Table:
| id |
|1|
|2|
| 17 |
| 18 |
| 19 |

 AUTO_INCREMENT behavior is the same for

REPLACE as it is for INSERT. Any existing
recordis deleted, and then the new record is
inserted.

 Consequently, replacing an AUTO_INCREMENT

column with NULL causes it to be set to the next
sequence value

 This also occurs if you replace the column
with 0 unless the
NO_AUTO_VALUE_ON_ZERO SQL mode
is enabled.

 When you reach the upper limit of an

AUTO_INCREMENT column, an attempt to
generate the next sequence value results in a
duplicate-key error.

 This is a manifestation of MySQL‟s general
out-of-range value clipping behavior.

For example,
 assume that you have a TINYINT UNSIGNED
column as an AUTO_INCREMENT column and

that it currently contains 254 as the maximum
sequence value.

 The upper limit for this data type is 255, so the
next insert generates a sequence value of 255

and successfully stores it in the new record.

 However, the insert after that fails because
MySQL generates the next sequence value,

which is 256.

 Because 256 is higher than the column‟s upper
limit of 255,MySQL clips 256 down to 255 and

attempts to insert that value. But because 255 is
already present in the table, a duplicate-key error
occurs.

 If you delete rows containing values at the high
end of a sequence, those values are not reused

for MyISAM or InnoDB tables when you insert
new records.

For example,

 if an AUTO_INCREMENT column contains the

values from 1 to 10 and you delete the record
containing 10, the next sequence value is 11, not
10.

 The MyISAM storage engine supports composite
indexes that include an AUTO_INCREMENT

column.
 This allows creation of independent sequences
within a single table.

Consider the following table definition:
CREATE TABLE multisequence
(
name CHAR(10) NOT NULL,
name_id INT UNSIGNED NOT NULL
AUTO_INCREMENT,
PRIMARY KEY (name, name_id)
);

 Inserting name values into the multisequence
table generates separate sequences for each
distinct name:

Syntax:
 mysql> INSERT INTO multisequence (name)
>

VALUES(„Petr‟),(„Ilya‟),(„Ilya‟),(„Yuri‟),(„Ilya‟),(„Petr‟
);
 mysql> SELECT * FROM multisequence
ORDER BY name, name_id;

Table:
| name | name_id |
------------------------| Ilya |
1
|
| Ilya |
2
|
| Ilya |
3
|
| Petr |
1
|
| Petr | 2
|

 Note that for this kind of AUTO_INCREMENT
column, values deleted from the high end of any
sequence are reused

 This differs from MyISAM behavior for singlecolumn AUTO_INCREMENT sequences.

 Many database servers perform a great deal of
value checking for data inserted into tables and
generate errors for invalid input values that don‟t

match column data types.

MySQL, on the other hand, historically has been
non-traditional and more “forgiving” in its data
handling:

 The MySQL server converts erroneous input
values to the closest legal values (asdetermined
from column definitions) and continues on its
way.

For example,

 if you attempt to store a negative value into an

UNSIGNED column, MySQL converts it to zero,
which is the nearest legal value for the column.

 This forgiving behavior stems from MySQL‟s
origins, which did not include transactional
storage engines.

 Because a failed or erroneous transaction could
not be rolled back, it was deemed preferable to
convert the input values as well as possible and

continue on, rather than perform a partial insert
or update operation that processes only some of
the rows specified in a data-modifying statement.

 MySQL now includes transactional storage
engines and in MySQL 5 you can tell the server

to check input values more restrictively and to
reject invalid values.

 The following discussion describes how to
control whether rejection of invalid input values
should occur, and the circumstances under

which conversions take place if you allow them.

 The discussion is framed in terms of INSERT
statements, but REPLACE and UPDATE are

handled similarly.

 The choice of how strict to be is up to individual
applications. If the default forgiving behavior is

suitable, you can continue to use that behavior

 An application that requires more restrictive
checking and needs to see errors for invalid input

data can select that behavior instead.

 The behavior is configurable for each client by
setting the SQL mode through use of the

sql_mode system variable.

 In this way, MySQL Server accommodates a
broad range of application requirements.

 General information about setting the SQL mode
nis given in Section 1.3, “Server SQL Modes.”

The following discussion focuses on using the
nSQL mode to control input data handling.

 default, the server uses a sql_mode value of „‟
(the empty string), which enables no restrictions.
Thus, the server operates in forgiving mode by

default. To set the mode this way explicitly, use
the following statement:

SET sql_mode = ‘’;

The most general means of enabling input value
restrictions is by using the

• STRICT_TRANS_TABLES or
STRICT_ALL_TABLES modes:

 SET sql_mode = „STRICT_TRANS_TABLES‟;
 SET sql_mode = „STRICT_ALL_TABLES‟;

 The term “strict mode” refers collectively to both
of these modes. They prevent entry of invalid

values such as those that are out of range, or
NULL specified for NOT NULL columns.

 Another SQL mode, TRADITIONAL, enables
strict mode plus other restrictions on date

checking and division by zero. Setting

setting the sql_mode system variable to
TRADITIONAL causes MySQL to act like more

traditional database servers in its input data
handling:
 SET sql_mode = „TRADITIONAL‟;

 The differences between the two strict modes
are discussed later, as are the additional

restrictions turned on by TRADITIONAL mode.

 In many cases, type conversion affords you the
flexibility to write a statement different ways and

get the same result

For example,
 if i is an integer column, the following statements
both insert 43 into it, even though the value is

specified as a number in one statement and as a
string in the other.

MySQL performs automatic string-to-number
conversion for the secondstatement:
 INSERT INTO t (i) VALUES(43);

 INSERT INTO t (i) VALUES(„43‟);

 In this case, the string „43x‟ is not completely
numeric, so you may want it to be rejected as

invalid with an error rather than a warning. You
can do this by enabling strict SQL mode.

 When MySQL performs type conversions that
change values, it generates warnings that can be

displayed with the SHOW WARNINGS
statement.

MySQL also performs a conversion to 43 for the
following statement, but it generates a warning as
well because the conversion changes the value:

 INSERT INTO t (i) VALUES(„43x‟);

In MySQL, INSERT statements may be incomplete
in the sense of not specifying a value for every
column in a table. Consider the following table
definition:
CREATE TABLE t
(
i INT NULL,
j INT NOT NULL,
k INT DEFAULT -1
);

For this table,
 An INSERT statement is incomplete unless it
specifies values for all threecolumns in the table.

Each of the following statements is an example
of a statement that ismissing column values:

Syntax:

INSERT INTO t (i) VALUES(0);
INSERT INTO t (i,k) VALUES(1,2);
INSERT INTO t (i,k) VALUES(1,2),(3,4);
INSERT INTO t VALUES();
In the last statement, the empty VALUES list means

“use the default value for all columns.”

MySQL handles missing values as follows:

 If the column definition contains a DEFAULT
clause, MySQL inserts the value specified by that
clause

 Note that MySQL adds a DEFAULT NULL clause
to the definition if it has no explicit DEFAULT
clause and the column can take NULL values.

 Thus, the definition ofcolumn i actually has
DEFAULT NULL in its definition:

mysql> SHOW CREATE TABLE tG
****************** 1. row *********************
Table: t
Create Table: CREATE TABLE `t` (
`i` int(11) default NULL,
`j` int(11) NOT NULL,
`k` int(11) default „-1‟
) ENGINE=MyISAM DEFAULT CHARSET=latin1

 If a column definition has no DEFAULT clause,
missing-value handling depends on whether

strict SQL mode is in effect and whether the table
is transactional:

 If strict mode is not in effect, MySQL inserts the
implicit default value for the column data type
and generates a warning.

If strict mode is in effect, an error occurs for
transactional tables .
An error occurs for non-transactional tables as

well, but a partial update might result:
If the error occurs for the second or later row of a
multiplerow insert, the earlier rows will already
have been inserted.

 The definition of column j has no DEFAULT
clause, so INSERT statements that provide no

value for j are handled according to these rules.

DEFAULT clause specification and implicit default
values are discussed in Section 5.6,
 “Column Attributes.”

 In general, when operating in non-strict mode,
MySQL performs type conversion based on the
constraints implied by a column‟s definition.

These constraints apply in several contexts:

 When you insert or update column values with
statements such as INSERT,
REPLACE,UPDATE, or LOAD DATA INFILE.

 When you change a column definition with
ALTER TABLE.

 When you specify a default value using a
DEFAULT value clause in a column definition.
For example,

 if you specify a default value of „43‟ for a numeric
column, that string is converted to 43 when the
default value is used.)

 If MySQL is not operating in strict mode, it
adjusts invalid input values to legal values when
possible and generates warning messages.

These messages can be displayed with the
SHOW
WARNINGS statement.

 The following list discusses some of the
conversions that MySQL performs. It isn‟t
exhaustive, but is sufficiently representative to

provide you with a good idea of how MySQL
treats input values and what you‟ll be tested on
for the exam.

 Conversion of out-of-range values to in-range
values. If you attempt to store a value that‟s
smaller than the minimum value allowed by the

range of a column‟s data type, MySQL stores the
minimum value in the range.

 If you attempt to store a value that‟s larger than
the maximum value in the range, MySQL stores
the range‟s maximum value.

For example,
 TINYINT has a range of –128 to 127.

 If you attempt to store values less than –
128 in a TINYINT column, MySQL stores –
128 instead. Similarly, MySQL stores
values greater than 127 as 127.

 If you insert a negative value into an UNSIGNED
numeric column,

MySQL converts the value to 0.

 String truncation. String values that are too long
are truncated to fit in the column. Ifyou attempt to

store „Sakila‟ into a CHAR(4) column, MySQL
stores it as „Saki‟ and discards the remaining
characters.

 It is not considered an error to trim trailing
spaces, so MySQL will insert „Saki „ into the

column as „Saki‟ without generating a warning.)

 If a value that‟s assigned to a SET column
contains elements that aren‟t listed in the SET

definition, MySQL discards those elements,
retaining only the legal elements

 Conversion to data type default. If you attempt to
store a value that cannot be converted to the

column data type, MySQL stores the implicit
default value for the type

For example,
 if you try to store the value „Sakila‟ in an INT
column, MySQL stores thevalue 0. The “zero”

value is „0000-00-00‟ for date columns and
„00:00:00‟ for time columns.

 The implicit default value for each data type is
given in Section 5.6, “Column Attributes.”

 Handling assignment of NULL to NOT NULL
columns. The effect of assigning NULL to a NOT

NULL column depends on whether the
assignment occurs in a single-row or multiplerow
INSERT statement.

 For a single-row INSERT, an error occurs and
the statement fails.For a multiple-row INSERT,

MySQL assigns the column the implicit default
value for its data type.

 Using ALTER TABLE to change a column‟s data
type maps existing values to new values
according to the constraints imposed by the new

data type. This might result in some values being
changed.
For example,
if you change a TINYINT to an INT, no values are
changed because all

 TINYINT values fit within the INT range.
However, if you change an INT to a TINYINT, any

values that lie outside the range of TINYINT are
clipped to the nearest endpoint of the TINYINT
range.

 Similar effects occur for other types of
conversions, such as TINYINT to TINYINT
UNSIGNED (negative values are converted to

zero), and converting a long string column to a
shorter one (values that are too long are
truncated to fit the new size).

 If a column is changed to NOT NULL using
ALTER TABLE, MySQL converts NULL values to

the implicit default value for the data type.

 The following table shows how several types of
string values are handled when converted to

DATE or INT data types

 It demonstrates several of the points just
discussed. Note that only string values that look

like dates or numbers convert properly without
loss of information.

String Value
Converted to INT
„2010-03-12‟
2010
„03-12-2010‟
3
„0017‟
17
„500 hats‟
500
„bartholomew‟

Converted to DATE
„2010-03-12‟
„0000-00-00‟
„0000-00-00‟

„0000-00-00‟
„0000-00-00‟

Input values may be invalid for a number of
reasons:
 For a numeric or temporal column, a value might

be out of range.
 For a string column, a string might be too long.

 For an ENUM column, a value might be specified
that is not a legal enumeration value or as part of
a value For a SET column, a value might contain

an element that is not a set member.
 For a column that is defined as NOT NULL, a
value of NULL might have been given.

 Enabling strict mode turns on general input value
restrictions. In strict mode, the server rejects
values that are out of range, have an incorrect

data type, or are missing for columns that have
no default.

 Strict mode is enabled using the
STRICT_TRANS_TABLES

andSTRICT_ALL_TABLES mode values.

 STRICT_TRANS_TABLES enables strict
behavior for errors that can be rolled back or

canceled without changing the table into which
data is being entered.

 If an error occurs for a transactional table, the
statement aborts and rolls back.

 For a non-transactional table, the statement can
be aborted without changing the table if an

invalid value occurs in a single-row insert or the
first row of a multiple-row insert.

 Otherwise, to avoid a partial update for a
nontransactional table, MySQL adjusts any

invalid value to a legal value, inserts it, and
generates a warning.

 STRICT_ALL_TABLES is similar to
STRICT_TRANS_TABLES but causes
statements for nontransactional tables to abort

even for errors in the second or later rows of a
multiple-row insert.
 This means that a partial update might occur,
because rows earlier in the statement will
already have been inserted.

 Strict mode turns on general input value
restrictions, but it is not as strict as you can tell

the,MySQL server to be.

 Strict mode turns on general input value
restrictions, but it is not as strict as you can tell

the MySQL server to be.

 Division by zero can be treated as an error for
data entry by enabling the

ERROR_FOR_DIVISION_BY_ZERO mode
value and strict mode.

 In this case, attempts to enter data via INSERT
or UPDATE statements produce an error if an

expression includes division by zero.

Syntax:
 SET sql_mode
=„STRICT_ALL_TABLES,ERROR_FOR_DIVISION_BY_ZER
O‟;

 By default, MySQL allows “zero” dates („0000-0000‟) and dates that have zero parts („2009-12-

00‟, „2009-00-01‟). Such dates are allowed even
if you enable strict mode, but if you want to
prohibit them, you can enable the
NO_ZERO_DATE and NO_ZERO_IN_DATE
mode values:

Syntax:
 SET sql_mode =
„STRICT_ALL_TABLES,NO_ZERO_DATE,NO_ZERO_IN_
DATE‟;

 The TRADITIONAL mode value is a composite
mode that enables strict mode as well as the

other restrictions just described.

 If you want your MySQL server to be as
restrictive as possible about input data checking

(and thus to act like other “traditional” database
servers), the simplest way to achieve this is to
enable TRADITIONAL mode rather than a list of
individual more-specific modes:

Syntax:
 SET sql_mode = „TRADITIONAL‟;

 Setting the SQL mode by using TRADITIONAL
has the additional advantage that if future

versions of MySQL implement other input data
restrictions that become part of TRADITIONAL
mode, you won‟t have to explicitly enable those
modes to take advantage of them.

 To override input data restrictions that may be
enabled, use INSERT IGNORE or UPDATE

IGNORE rather than just INSERT or UPDATE
(without IGNORE).

 The IGNORE keyword causes MySQL to use
non-strict behavior for the statement (for

example, to produce warnings rather than
errors).

 Before MySQL 5, date values were required only
to have month and day values in the range from
1 to 12 and 1 to 31, respectively. This means that

MySQL accepted dates such as„2009-02-31‟.
MySQL 5 requires that month and day values
correspond to an actual legal date, so „2009-0231‟ is not considered a valid date.

 MySQL converts it to „0000-00-00‟ and generates a
warning. In strict mode, „2009-02-31‟ results in an error.

 If you want relaxed date checking that requires
only that month and day values be in the
respective ranges of 1 to 12 and 1 to 31, enable
the ALLOW_INVALID_DATES SQL mode value:

Syntax:
 SET sql_mode =
„ALLOW_INVALID_DATES‟;

You can use ALLOW_INVALID_DATES for relaxed
date checking even in strict mode:
• SET sql_mode =

„STRICT_ALL_TABLES,ALLOW_INVALID_DATE
S‟;

DBMS

More Related Content

What's hot (20)

Similar to DBMS (20)

Recently uploaded (20)

DBMS