Back in April, I issued a challenge to identify any compelling use case for the YEAR(2) data type.  Months later, I still don’t have such a use case, and the release of 5.6.6 brings deprecation of support for the YEAR(2) datatype.  Trying to create a table with a YEAR(2) column in 5.6.6 or greater will result in conversion to YEAR(4) and a warning:

mysql> SELECT VERSION();
+-----------+
| VERSION() |
+-----------+
| 5.6.6-m9  |
+-----------+
1 row in set (0.00 sec)

mysql> CREATE TABLE y (y YEAR(2));
Query OK, 0 rows affected, 1 warning (0.13 sec)

mysql> SHOW WARNINGS\G
*************************** 1. row ***************************
Level: Warning
Code: 1818
Message: YEAR(2) column type is deprecated. Creating YEAR(4) column instead.
1 row in set (0.00 sec)

The change logs for 5.6.6 highlight this change, and reference the excellent documentation of YEAR(2) limitations and migration strategies.  If you’re not sure whether you have YEAR(2) columns or not, the following command will identify any such columns:

SELECT table_schema, table_name, column_name, column_type
FROM information_schema.columns
WHERE data_type = 'YEAR'
AND column_type != 'year(4)';

Note that some queries (including this one) against INFORMATION_SCHEMA tables can be slow, and may not be suitable for running in against a busy production database server.  In such instances, you may want to execute this against a slave, backup or development machine loaded with the current schema.