SQL Server里master库排序规则改了，可能影响数据处理啥的你得注意下

根据微软官方文档（MSDN）和众多数据库管理员的实践经验，直接修改SQL Server实例中master数据库的排序规则是一项影响深远的操作，绝不仅仅是改变一两个设置那么简单，如果你已经做了或者计划这么做，那么后续在数据处理和系统运行中，确实有一系列非常具体的问题需要你密切关注和应对，这就像给一栋大楼换了地基，虽然主体结构没变，但所有门窗的契合度、管线的连接方式都可能发生变化。

最直接的影响体现在所有新创建的数据库上，master数据库的排序规则充当着实例级的默认排序规则，当你使用简单的CREATE DATABASE MyNewDB语句而不显式指定排序规则时，这个新数据库就会继承当前master库的排序规则，如果你的应用程序代码期望新数据库是原来的排序规则（之前是区分大小写的，现在新建的却不区分了），那么之前能正确运行的SQL查询可能会突然报错或者返回意想不到的结果，查询WHERE Name = 'apple'可能会把'Apple'、'APPLE'都找出来,而这在以前是不会的。

也是更棘手的问题，存在于临时表（#temp）和变量（@variable）中，临时对象的元数据（比如列名、数据类型）的排序规则，默认并不是继承自你正在使用的用户数据库，而是继承自tempdb数据库，而tempdb数据库又是在每次SQL Server服务重启时，根据当前master数据库的排序规则重建的，这意味着，一旦你修改了master的排序规则并重启了SQL Server服务，新的tempdb就会采用新的排序规则，这会引发一种非常隐蔽的错误：当你的用户数据库的排序规则与tempdb的排序规则不同时，在涉及临时表和用户表进行连接（JOIN）或比较操作时，可能会因为排序规则冲突而直接导致查询失败，错误信息通常会明确指出“无法解决排序规则冲突”。

第三点需要留意的是服务器级别的对象，比如登录名（Logins），登录名的名称本身也受到服务器排序规则（即master库排序规则）的约束，如果你修改了排序规则，特别是涉及到大小写敏感性的改变，可能会遇到一种情况：以前创建的两个仅在大小写上有区别的登录名（UserA'和'usera'），在修改后系统可能会认为它们是相同的，这会造成混乱甚至登录失败，在跨服务器进行数据库复制（Replication）或链接服务器（Linked Server）查询时，排序规则的不匹配也会成为数据传输和比较的障碍,可能导致数据同步失败或查询错误。

第四，对于已经存在的用户数据库，其本身的排序规则在修改master时并不会自动改变，这并不意味着就高枕无忧了，当你需要在这些旧数据库和新的临时表，或者和其他排序规则不同的数据库进行交互时，问题依然会出现，你不得不在编写SQL语句时，频繁地使用COLLATE子句来显式指定排序规则，以消除冲突，这会大大增加代码的复杂度和维护成本，而且很容易遗漏,导致生产环境下的间歇性错误。

第五，影响会蔓延到应用程序层面，你的应用程序代码，特别是那些动态构建SQL语句或者对字符串比较有严格要求的代码，可能是在特定的排序规则环境下开发和测试的，排序规则改变后，应用程序返回的数据顺序（ORDER BY）、分组情况（GROUP BY）都可能发生变化，进而影响前端页面的显示、报表的生成，甚至是业务的逻辑判断，一个依赖按字母顺序生成唯一编码的功能,在排序规则改变后可能会产生不同的结果序列。

不要忘记备份和恢复操作，虽然不常见，但在某些恢复场景下，如果备份文件中的元数据排序规则与目标服务器的排序规则不兼容,也可能会遇到问题。

修改master数据库的排序规则是一个“牵一发而动全身”的操作，它不是一个独立的设置变更，而是会渗透到实例的每一个角落，从新数据库的创建、临时对象的处理、服务器级对象的管理，到现有数据库的交互乃至应用程序的行为，都可能受到影响，在进行此项操作前，务必在非生产环境中进行彻底的测试，评估对所有现有数据库和应用程序的影响，并制定详尽的回滚方案，事后，则需要系统地检查所有可能受影响的环节，特别是那些涉及字符串比较、排序和连接的地方,做好应对各种潜在错误的准备。