Syntax:

SIGNAL condition_value
[SET signal_information_item
[, signal_information_item] ...]

condition_value:
SQLSTATE [VALUE] sqlstate_value
| condition_name

signal_information_item:
condition_information_item_name = simple_value_specification

condition_information_item_name:
CLASS_ORIGIN
| SUBCLASS_ORIGIN
| MESSAGE_TEXT
| MYSQL_ERRNO
| CONSTRAINT_CATALOG
| CONSTRAINT_SCHEMA
| CONSTRAINT_NAME
| CATALOG_NAME
| SCHEMA_NAME
| TABLE_NAME
| COLUMN_NAME
| CURSOR_NAME

condition_name, simple_value_specification:
(see following discussion)

SIGNAL is the way to "return" an error. SIGNAL provides error

information to a handler, to an outer portion of the application, or to
the client. Also, it provides control over the error's characteristics
(error number, SQLSTATE value, message). Without SIGNAL, it is
necessary to resort to workarounds such as deliberately referring to a
nonexistent table to cause a routine to return an error.

No special privileges are required to execute the SIGNAL statement.

The condition_value in a SIGNAL statement indicates the error value to

be returned. It can be an SQLSTATE value (a 5-character string literal)
or a condition_name that refers to a named condition previously defined
with DECLARE ... CONDITION (see [HELP DECLARE CONDITION]).

An SQLSTATE value can indicate errors, warnings, or "not found." The

first two characters of the value indicate its error class, as
discussed in
http://dev.mysql.com/doc/refman/5.5/en/signal.html#signal-condition-inf
ormation-items. Some signal values cause statement termination; see
http://dev.mysql.com/doc/refman/5.5/en/signal.html#signal-effects.

The SQLSTATE value for a SIGNAL statement should not start with '00'
because such values indicate success and are not valid for signaling an
error. This is true whether the SQLSTATE value is specified directly in
the SIGNAL statement or in a named condition referred to in the
statement. If the value is invalid, a Bad SQLSTATE error occurs.

To signal a generic SQLSTATE value, use '45000', which means "unhandled

user-defined exception."

The SIGNAL statement optionally includes a SET clause that contains

multiple signal items, in a comma-separated list of
condition_information_item_name = simple_value_specification
assignments.
Each condition_information_item_name may be specified only once in the
SET clause. Otherwise, a Duplicate condition information item error
occurs.

Valid simple_value_specification designators can be specified using

stored procedure or function parameters, stored program local variables
declared with DECLARE, user-defined variables, system variables, or
literals. A character literal may include a _charset introducer.

For information about permissible condition_information_item_name

values, see
http://dev.mysql.com/doc/refman/5.5/en/signal.html#signal-condition-inf
ormation-items.

URL: http://dev.mysql.com/doc/refman/5.5/en/signal.html

Syntax:
CREATE
[DEFINER = { user | CURRENT_USER }]
EVENT
[IF NOT EXISTS]
event_name
ON SCHEDULE schedule
[ON COMPLETION [NOT] PRESERVE]
[ENABLE | DISABLE | DISABLE ON SLAVE]
[COMMENT 'comment']
DO event_body;

schedule:
AT timestamp [+ INTERVAL interval] ...
| EVERY interval
[STARTS timestamp [+ INTERVAL interval] ...]
[ENDS timestamp [+ INTERVAL interval] ...]

interval:
quantity {YEAR | QUARTER | MONTH | DAY | HOUR | MINUTE |
WEEK | SECOND | YEAR_MONTH | DAY_HOUR | DAY_MINUTE |
DAY_SECOND | HOUR_MINUTE | HOUR_SECOND | MINUTE_SECOND}

This statement creates and schedules a new event. The event will not
run unless the Event Scheduler is enabled. For information about
checking Event Scheduler status and enabling it if necessary, see
http://dev.mysql.com/doc/refman/5.5/en/events-configuration.html.

CREATE EVENT requires the EVENT privilege for the schema in which the
event is to be created. It might also require the SUPER privilege,
depending on the DEFINER value, as described later in this section.

The minimum requirements for a valid CREATE EVENT statement are as

follows:

o The keywords CREATE EVENT plus an event name, which uniquely

identifies the event in a database schema.

o An ON SCHEDULE clause, which determines when and how often the event
executes.

o A DO clause, which contains the SQL statement to be executed by an

event.

This is an example of a minimal CREATE EVENT statement:

CREATE EVENT myevent

ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 1 HOUR
DO
UPDATE myschema.mytable SET mycol = mycol + 1;

The previous statement creates an event named myevent. This event

executes once---one hour following its creation---by running an SQL
statement that increments the value of the myschema.mytable table's
mycol column by 1.

The event_name must be a valid MySQL identifier with a maximum length

of 64 characters. Event names are not case sensitive, so you cannot
have two events named myevent and MyEvent in the same schema. In
general, the rules governing event names are the same as those for
names of stored routines. See
http://dev.mysql.com/doc/refman/5.5/en/identifiers.html.

An event is associated with a schema. If no schema is indicated as part

of event_name, the default (current) schema is assumed. To create an
event in a specific schema, qualify the event name with a schema using
schema_name.event_name syntax.

URL: http://dev.mysql.com/doc/refman/5.5/en/create-event.html

Syntax:
DO expr [, expr] ...

DO executes the expressions but does not return any results. In most
respects, DO is shorthand for SELECT expr, ..., but has the advantage
that it is slightly faster when you do not care about the result.

DO is useful primarily with functions that have side effects, such as

RELEASE_LOCK().

Example: This SELECT statement pauses, but also produces a result set:

mysql> SELECT SLEEP(5);

+----------+
| SLEEP(5) |
+----------+
| 0 |
+----------+
1 row in set (5.02 sec)

DO, on the other hand, pauses without producing a result set.:

mysql> DO SLEEP(5);
Query OK, 0 rows affected (4.99 sec)

This could be useful, for example in a stored function or trigger,

which prohibit statements that produce result sets.

DO only executes expressions. It cannot be used in all cases where

SELECT can be used. For example, DO id FROM t1 is invalid because it
references a table.

URL: http://dev.mysql.com/doc/refman/5.5/en/do.html

Syntax:
ALTER {DATABASE | SCHEMA} [db_name]
alter_specification ...
ALTER {DATABASE | SCHEMA} db_name
UPGRADE DATA DIRECTORY NAME
alter_specification:
[DEFAULT] CHARACTER SET [=] charset_name
| [DEFAULT] COLLATE [=] collation_name

ALTER DATABASE enables you to change the overall characteristics of a

database. These characteristics are stored in the db.opt file in the
database directory. To use ALTER DATABASE, you need the ALTER privilege
on the database. ALTER SCHEMA is a synonym for ALTER DATABASE.

The database name can be omitted from the first syntax, in which case
the statement applies to the default database.

National Language Characteristics

The CHARACTER SET clause changes the default database character set.
The COLLATE clause changes the default database collation.
http://dev.mysql.com/doc/refman/5.5/en/charset.html, discusses
character set and collation names.

You can see what character sets and collations are available using,
respectively, the SHOW CHARACTER SET and SHOW COLLATION statements. See
[HELP SHOW CHARACTER SET], and [HELP SHOW COLLATION], for more
information.

If you change the default character set or collation for a database,

stored routines that use the database defaults must be dropped and
recreated so that they use the new defaults. (In a stored routine,
variables with character data types use the database defaults if the
character set or collation are not specified explicitly. See [HELP
CREATE PROCEDURE].)

Upgrading from Versions Older than MySQL 5.1

The syntax that includes the UPGRADE DATA DIRECTORY NAME clause updates
the name of the directory associated with the database to use the
encoding implemented in MySQL 5.1 for mapping database names to
database directory names (see
http://dev.mysql.com/doc/refman/5.5/en/identifier-mapping.html). This
clause is for use under these conditions:

o It is intended when upgrading MySQL to 5.1 or later from older

versions.

o It is intended to update a database directory name to the current

encoding format if the name contains special characters that need
encoding.

o The statement is used by mysqlcheck (as invoked by mysql_upgrade).

For example, if a database in MySQL 5.0 has the name a-b-c, the name
contains instances of the - (dash) character. In MySQL 5.0, the
database directory is also named a-b-c, which is not necessarily safe
for all file systems. In MySQL 5.1 and later, the same database name is
encoded as a@002db@002dc to produce a file system-neutral directory
name.

When a MySQL installation is upgraded to MySQL 5.1 or later from an

older version,the server displays a name such as a-b-c (which is in the
old format) as #mysql50#a-b-c, and you must refer to the name using the
#mysql50# prefix. Use UPGRADE DATA DIRECTORY NAME in this case to
explicitly tell the server to re-encode the database directory name to
the current encoding format:
ALTER DATABASE `#mysql50#a-b-c` UPGRADE DATA DIRECTORY NAME;

After executing this statement, you can refer to the database as a-b-c
without the special #mysql50# prefix.

URL: http://dev.mysql.com/doc/refman/5.5/en/alter-database.html