背景：

在MySQL中，是有json字段类型的，同时也有json操作的相关方法，也提供json数据的校验，给我们保存json数据提供了方便；

但当我们向json中保存一个json时，其内容会被数据库重新格式化，并调整其中key的顺序，该动作并不受外界控制；

在一些特殊应用的场合，例如：与金蝶对接的过程中，他们有一个"特殊要求"，就是要求json中的key的顺序要与其模板中的一致，此时出现麻烦；

解决思路１－找金蝶：

首先金蝶这个特殊要求，本身不合理，因为，JSON字段本身就应该具有无序映射，这才是正常对接的方式；

所以我们第一时间想到找金蝶解决，但是金蝶很ＮＢ，其实施工程师给的回复是："不是我不愿意改，接口没问题，你让总部改，总部不可能改的啊，况且总部也不可能专门针对你改接口啊，就好比你做阿里微信接口，你也不可能让阿里微信为你改接口的啊"．

此路不通．

解决思路２－字符串替换：

即然定义为json字段时，其key会排序，那么我们把它改为text呢？

结果是，写入前与写入后结果一致，不会排序；但我们在写入前，是需要有json操作的，若需要按json类型操作就首先需要将之转为json，然后再更新其内容，这个过程仍然会引起字段的重新排序．

如果全部改成字符串拼接的方式操作，这将是巨大工程．

此路不通．

解决思路３－寻找key排序的规律：

我们尝试寻找key排序的规律，首先发现，不论将key弄的多么乱，保存至数据库时，它都是调整成了固定的顺序，并不是随机的，这是一个重大的发现．

是不是数据库版本问题？升级可以调整？进入官网，其并未对此说明．此路不通

比如：这两个字段，同级调整，不论它放在上面，还是放下面，保存至数据库会都恢复成这个状态．

正常ＭySQL排序

接着我们发现好像它也并不是按照字母排序的，按感觉说，如果是按字母顺序排的，"FP"开头的key，肯定应该在"F_"开头key的下面．

接着，我们将字段前方加上前缀"Z_"，发现有变化，key下移了，跑到了"FE"开头的key的前面去了．

增加前缀：Z_

继续调整，测试，又变化了：

增加前缀：ZZZZZZZZ_

前缀变成"ZZZZZ_"后，key继续下移，跑到了FE的后面去了．

前后比较，得出规律：同级别key，先按key的长度排序，后按字母顺序排序．

总结

金蝶这个霸王设计的方案肯定不规范，但时间条件下，也难以等到这个大笨象的转身．

最终，我们使用调整字段长度，以固定其顺序的方式来解决顺序，配合字符串的替换来解决字段对应的问题．虽说很蹩脚的方式，但是解决了问题．