通过看代码会发现，在获取所有字段的时候，都是调用table.getCols()方法，返回的是一个List<FieldSchema>，也就是说从Metastore获取的时候，这个List已经按照定义的顺序排列好了顺序。
然后转到Metastore的代码，一直追溯源头到jdo的query，都找不到最这个List做排序的地方。那也只能是jdo在底层做了什么事情。
一开始也没有什么线索，光靠一些自找的关键词来搜索jdo相关的文章，都没有找到。
最后是查看了一下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字段，猜想这个应该就是jdo自动生成的东西了。查了一下资料果然如此，事情的真相是这样的：
在使用jdo时，如果你定义Model的时候使用了List类型的字段（比如这里的List<FieldSchema>），datanucleus在构造MySQL表的时候，会自动生成一个索引字段INTEGER_IDX（在datanucleus2中是IDX）从0开始递增，然后在查询的时候自动会在查询语句中加入ORDER BY INTEGER_IDX，这样就保证了顺序了。
具体可以参考一下这个的说明Hive-11039
