我使用的是SQL Server 2012，需要使用Merge Join做一个完整的外连接，以便进行delta updatesinsertsdeletes。
我们真的很想避免使用排序转换，因为它是完全阻塞的，但我已经没有办法了。
两个源输出都是使用按子句排序，IsSorted属性设置为trueecolumnSort顺序设置为1。
MySQL数据库的字符集是UTF8，而在源查询的按子句排序中，我使用UTF8_bin进行整理
SQLServer数据库的整理是SQL_Latin1_General_CP1_CI_AS，但在源查询中的分句顺序中，我整理成了Latin1_General_bin(所以排序方法是一样的)
然而，我发现这些集合没有正确地连接。大多数记录都是匹配的，但我有这样的情况：左边和右边的值存在，但连接的另一边是空的（理论上它们应该是匹配的）。
我们要匹配的数值格式如下(9999-99999-9999 AAA BBB CCC)
我知道SQL server中的UTF8支持直到SQL Server 2019年才被引入，所以会不会是这个问题。我们是否不可避免地要使用排序转换？
如果你信任来自两个源的排序，你可以只在高级编辑部分为你的数据源的输出设置 "Is Sorted "属性。然后，你为应用排序的任何列设置一个位置。如果只有一列被排序，只需在该列上加一个1。
不过要小心，因为如果不在同一个顺序上，它就会杠杠的。如果是数字，你r大概可以，或者你说的那个格式也大概可以。但是一般的字符串，我就不相信了。
我在对字符编码做了一些研究后，设法解决了这个问题。
MySQL的UTF8更多的是以linux和UNIX为中心，Windows对UTF8的支持非常有限，所以UTF8的整理很可能会引起问题。
然而Windows确实支持UTF16...... 不过这仍然不是直接的问题。
在MySQL中，有UTF16和UTF16LE两个字符集。LE代表的是小英译，UTF16使用大英译。UTF16使用的是big endian，简而言之就是按照序列中最重要的值来排序，而little endian则是按照序列中最不重要的值来排序。欲了解更多信息，请阅读以下内容。
[https:/searchnetworking.techtarget.comdefinitionbig-endianand-little-endian][1] 。
Windows服务器使用的编码主要会使用little endian，因为正如上文中所解释的那样，它是由服务器的CPU决定的（Intel处理器就是一个使用little endian的例子）。
考虑到这一点，我将SQL Server Source中的JoinSort列(nvarchar(55))整理为Latin1_General_Bin，理论上应该是UTF16小恩迪安编码。
然后，我将MySQL源中的JoinSort列转换为UTF16LE字符集，在Order By整理中转换为UTF16LE_Bin。
SELECT
CONVERT(UPPER(CONCAT_WS('-', Column1, Column2, Column3, 'AAA BBB CCC')) USING UTF16LE) AS DerivedColumn,
...
...
ORDER BY DerivedColumn COLLATE UTF16LE_bin;
这样就可以正确地对数据进行排序，而不需要使用排序变换。