关键字：SQL Server NEWID（）；BSON；MongoDB UUID
1.遇到的问题和困惑
SQL Server中的NEWID数据存储到MongoDB中会是什么样子呢？发现不能简单的通过此数据查询了。
例如我们将SQL Server 数据库中的QQStatements2019表迁移至MongoDB 中，集合命名也为QQStatements2019。
在SQL Server中选择4个OrderId,数据作为演示实例，查看如下：
经过程序转换后，在mongodb的客户端工具nosqlbooster上查看。
此时没有文档。
但是查看文档数据量，SQL Server 和 MongoDB 二者一致，说明确实导入成功了。
问题出在哪儿？难得数据失真了？如果是失真的话？是只有这一个字段失真还是全部字段失真？
我们用这些Orderid对应的SerialNumber数据去MongoDB中查询验证下。
现在SQL Server数据库中查看，数据显示如下：
然后去MongoDB查看，此条件查询竟然有数据。
但仔细查看确实失真了，两者显示的不一样。例如：SerialNumber为XX41107960HEZE的Orderid，在SQL Server中是 32C8C3A1-3444-4440-9AE4-9B7631968080，但是在MongoDB中，就变成了如下模样，点击打开又是另外一个样子。
JSON Viewer的界面显示的OrderId数据就是二进制类型。
如上所示，MongoDB查询显示的数据有LUUID（），那我们在每个orderid数据上加上一个LUUID（），是不是就可以查找到了呢？
以SQL Server 的Orderid查看（失真前 32C8C3A1-3444-4440-9AE4-9B7631968080），没有数据。
以MongoDB”失真”后的a1c3c832-4434-4044-9ae4-9b7631968080去查看。
直接查看没有。
加上 LUUID(）查看有了。
但验证到这儿，还是不能根据SQL Server 中OrderID 去关联查看 MongoDB中的数据啊！！！
并且仔细查看 32C8C3A1-3444-4440-9AE4-9B7631968080（SQL Server中数据） 和 a1c3c832-4434-4044-9ae4-9b7631968080（MongoDB数据） 相似度很高。后面的几个字节9AE4-9B7631968080 都是一样的。前面的几个字节，也都是在每个段内 以2位为单位重新排列组合。
这看着应该和数据的存储 和类型有关，并且这个变化的只是GUID类型的”失真”了。
回头再比较看看"失真"OrderId和没失真的 SerialNumber在SQL Server 数据库中是怎么定义的。
OrderID在SQL Server数据中的数据类型是 [OrderId] [uniqueidentifier] NOT NULL，而 SerialNumber的类型如下： [SerialNumber] [varchar](50) NULL
现在回头去看看MongoDB存储和SQL Server uniqueidentifier类型相关的知识。争取从这方面找到突破口。
2. MongoDB存储格式和SQL Server uniqueidentifier类型相关的知识
2.1 MongoDB 存储格式
从内部讲，MongoDB以二进制JSON格式存储文档数据或者叫BSON。BSON有相似的数据结构，但是专门为文档存储设计。当查询MongoDB并返回结果时，这些数据就会转换为易于阅读的数据格式。MongoDB Shell使用JavaScript获取JSON格式的文档数据。所有的MongoDB驱动都执行三个主要的功能：首先，生成MongoDB对象ID。默认都存储在所有文档的_id字段里。其次，驱动会把任意语言表示的文档对象转换为BSON或者从BSON转换回来，BSON是MongoDB使用的二进制JSON格式。最后，使用TCP socket与数据库连接通信，此时使用的是MongoDB自定义协议。
所有的文档在发送给MongoDB之前都序列化为BSON格式，以后再从BSON反序列化。驱动库会处理底层的数据类型转换工作。绝大部分驱动都提供了从BSON序列化的简单接口，当读/写文档的时候会自动完成。二进制数据是一个任意字节的字符串。它不能直接在shell中使用。如果要将非UTF-8字符保存到数据库中，二进制数据是唯一的方式。
2.2 SQL Server uniqueidentifier类型
uniqueidentifier 全局唯一标识符 (GUID)。
使用 NEWID 函数。
将字符串常量转换为如下形式（xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx，其中每个 x 是 0-9 或 a-f 范围内的一个十六进制的数字）。例如，6F9619FF-8B86-D011-B42D-00C04FC964FF 即为有效的 uniqueidentifier 值。
3. 解决小窍门
通过以上知识了解，我们可能定位到数据“失真”应该和 BSON格式和驱动有关，那么可以推测，这个工具（nosqlbooster）应该也有类似的驱动。
皇天不负苦心人，找找就找到了。
如下操作 管理设置图标-->Display Legacy UUID in -->.NET Format
然后，执行点击查看，结果变成了如下格式。
这个MongoDB结果中的数据和SQL Server 中的数据长的比较像了。
此时再次以SQL Server 数据库中的一个OrderId 查看。
此时还是没有数据
添加CSUUID(）函数，再次查看有数据了
到此，我们可以松口气了，总算可以，拿到 SQL Server 中的某个Order Id，也可以去转换后的MongoDB查看了。
本文版权归作者所有，未经作者同意不得转载,谢谢配合！！！