從客戶的mysql數據庫中導出sql文件然後導入到本地庫中，沒有成功，報錯爲You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'USING BTREE) ENGINE=InnoDB DEFAULT CHARSET=utf8' at line 19[Msg] 完成 - 不成功
客戶的mysql版本爲：5.6.23，本機的mysql版本爲：5.0.24a-community-nt
經過網上搜索，解決方法爲：
把USING BTREE 放到索引字段前面即可。由此可見兩個版本的語法是不同的。
KEY `fk_user_role_relation_role_id` (`role_id`) USING BTREE,
改爲：
KEY `fk_user_role_relation_role_id` USING BTREE (`role_id`) 。
BTREE知識：
B-Tree 索引是 MySQL 數據庫中使用最爲頻繁的索引類型，除了 Archive 存儲引擎之外的其他所有的存儲引擎都支持 B-Tree 索引。不僅僅在 MySQL 中是如此，實際上在其他的很多數據庫管理系統中B-Tree 索引也同樣是作爲最主要的索引類型，這主要是因爲
B-Tree 索引的存儲結構在數據庫的數據檢 索中有非常優異的表現。
一般來說，
MySQL 中的 B-Tree 索引的物理文件大多都是以 Balance Tree 的結構來存儲的，也就是所有實際需要的數據都存放於 Tree 的 Leaf Node ，而且到任何一個 Leaf Node 的最短路徑的長度都是完全相同的，所以我們大家都稱之爲 B-Tree 索引當然，可能各種數據庫（或 MySQL 的各種存儲引擎）在存放自己的 B-Tree 索引的時候會對存儲結構稍作改造。如 Innodb 存儲引擎的 B-Tree 索引實際使用的存儲結構實際上是 B+Tree ，也就是在 B-Tree 數據結構的基礎上做了很小的改造，在每一個
Leaf Node 上面出了存放索引鍵的相關信息之外，還存儲了指向與該 Leaf Node 相鄰的後一個 LeafNode 的指針信息，這主要是爲了加快檢索多個相鄰 Leaf Node 的效率考慮。
在
Innodb 存儲引擎中，存在兩種不同形式的索引，一種是 Cluster 形式的主鍵索引（ Primary Key ），另外一種則是和其他存儲引擎（如 MyISAM 存儲引擎）存放形式基本相同的普通 B-Tree 索引，這種索引在 Innodb 存儲引擎中被稱爲 Secondary Index 。下面我們通過圖示來針對這兩種索引的存放
形式做一個比較。
圖示中左邊爲
Clustered 形式存放的 Primary Key ，右側則爲普通的 B-Tree 索引。兩種 Root Node 和 Branch Nodes 方面都還是完全一樣的。而 Leaf Nodes 就出現差異了。在 Prim中， Leaf Nodes 存放的是表的實際數據，不僅僅包括主鍵字段的數據，還包括其他字段的數據據以主鍵值有序的排列。而 Secondary Index 則和其他普通的 B-Tree 索引沒有太大的差異，Leaf Nodes 出了存放索引鍵 的相關信息外，還存放了 Innodb 的主鍵值。
所以，在
Innodb 中如果通過主鍵來訪問數據效率是非常高的，而如果是通過 Secondary Index 來訪問數據的話， Innodb 首先通過 Secondary Index 的相關信息，通過相應的索引鍵檢索到 Leaf Node之後，需要再通過 Leaf Node 中存放的主鍵值再通過主鍵索引來獲取相應的數據行。MyISAM 存儲引擎的主鍵索引和非主鍵索引差別很小，只不過是主鍵索引的索引鍵是一個唯一且非空 的鍵而已。而且 MyISAM 存儲引擎的索引和 Innodb 的 Secondary Index 的存儲結構也基本相同，主要的區別只是
MyISAM 存儲引擎在 Leaf Nodes 上面出了存放索引鍵信息之外，再存放能直接定位到 MyISAM 數據文件中相應的數據行的信息（如 Row Number ），但並不會存放主鍵的鍵值信息