錯誤：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. 外鍵

外鍵加強爲數據庫開發人員提供了多項益處：

·         假定關聯設計恰當，外鍵約束使得程序員更難將不一致性引入數據庫。

·         數據庫服務器具備集中式約束檢查功能，於是沒有必要在應用程序一側執行這類檢查。這樣，就消除了不一樣應用程序使用不一樣方式檢查約束的可能性。

·         使用級聯更新和刪除，簡化了應用程序代碼。

·         設計恰當的外鍵有助於以文檔方式記錄表間的關係。

請記住，這些好處是以數據庫服務器爲執行必要檢查而需的額外開銷爲代價的。服務器額外檢查會影響性能，對於某些應用程序，該特性不受歡迎，應儘可能避免。（出於該緣由，在一些主要的商業應用程序中，在應用程序級別上實施了外鍵邏輯）。