错误：mysql foreign key errno 150

Mysql错误：ERROR 1005 (HY000): Can't create table 'mytable.#sql-191_1c5e4' (errno: 150)

alter table message_demo add cons
traint foreign key(type) references message_type(id) on delete cascade;

缘由是message_demo表的type（外键）属性和message_type表的id（主键）定义不一样，因为我是在创建表以后再创建的外键关系，以前给type字段加了个unsigned，而id字段又没加，所以报错。

参考：http://forums.devarticles.com/mysql-development-50/mysql-foreign-key-problem-errno-150t-7704.html

Finally. I found out what the problem was. It wasn't about the definition of the foreign key. actually it was the definition of the primary key field.

很久不使用外键，对级联操做都有点不记得了。

如下资料来自官方文档（MySQL 5.1 Reference Manual-cn）：

15.2.6.4节，“FOREIGN KEY约束”

外键定义服从下列状况：

·         全部tables必须是InnoDB型，它们不能是临时表。

·         在引用表中，必须有一个索引，外键列以一样的顺序被列在其中做为第一列。这样一个索引若是不存在，它必须在引用表里被自动建立。

·         在引用表中，必须有一个索引，被引用的列以一样的顺序被列在其中做为第一列。

·         不支持对外键列的索引前缀。这样的后果之一是BLOB和TEXT列不被包括在一个外键中，这是由于对这些列的索引必须老是包含一个前缀长度。

·         若是CONSTRAINTsymbol被给出，它在数据库里必须是惟一的。若是它没有被给出，InnoDB自动建立这个名字。  

1.8.5.5. 外键

外键加强为数据库开发人员提供了多项益处：

·         假定关联设计恰当，外键约束使得程序员更难将不一致性引入数据库。

·         数据库服务器具备集中式约束检查功能，于是没有必要在应用程序一侧执行这类检查。这样，就消除了不一样应用程序使用不一样方式检查约束的可能性。

·         使用级联更新和删除，简化了应用程序代码。

·         设计恰当的外键有助于以文档方式记录表间的关系。

请记住，这些好处是以数据库服务器为执行必要检查而需的额外开销为代价的。服务器额外检查会影响性能，对于某些应用程序，该特性不受欢迎，应尽可能避免。（出于该缘由，在一些主要的商业应用程序中，在应用程序级别上实施了外键逻辑）。