通過看代碼會發(fā)現(xiàn)，在獲取所有字段的時候，都是調(diào)用table.getCols()方法巷挥，返回的是一個List<FieldSchema>，也就是說從Metastore獲取的時候恰聘，這個List已經(jīng)按照定義的順序排列好了順序句各。
然后轉(zhuǎn)到Metastore的代碼，一直追溯源頭到j(luò)do的query晴叨，都找不到最這個List做排序的地方凿宾。那也只能是jdo在底層做了什么事情。
一開始也沒有什么線索兼蕊，光靠一些自找的關(guān)鍵詞來搜索jdo相關(guān)的文章初厚，都沒有找到。
最后是查看了一下MySQL中存儲字段的那個表的定義：
CREATE TABLE `COLUMNS_V2` (
`CD_ID` bigint(20) NOT NULL,
`COMMENT` varchar(256) CHARACTER SET utf8 DEFAULT NULL,
`COLUMN_NAME` varchar(128) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,
`TYPE_NAME` varchar(4000) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,
`INTEGER_IDX` int(11) NOT NULL,
PRIMARY KEY (`CD_ID`,`COLUMN_NAME`),
KEY `COLUMNS_V2_N49` (`CD_ID`),
CONSTRAINT `COLUMNS_V2_FK1` FOREIGN KEY (`CD_ID`) REFERENCES `CDS` (`CD_ID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
里面有一個INTEGER_IDX字段孙技，猜想這個應(yīng)該就是jdo自動生成的東西了产禾。查了一下資料果然如此，事情的真相是這樣的：
在使用jdo時牵啦，如果你定義Model的時候使用了List類型的字段（比如這里的List<FieldSchema>）亚情，datanucleus在構(gòu)造MySQL表的時候，會自動生成一個索引字段INTEGER_IDX（在datanucleus2中是IDX）從0開始遞增哈雏，然后在查詢的時候自動會在查詢語句中加入ORDER BY INTEGER_IDX楞件，這樣就保證了順序了。
具體可以參考一下這個的說明Hive-11039
