我认为这可能是一个已知的困难，但是正在寻找任何人可能拥有的任何建议，经验或解决方法。
我有一个成熟的SQL Server 2014数据库，其中所有字符列均为nvarchar。我的应用程序是WPF应用程序.NET 4.6- +，它可以舒适地以任何语言编写和读取文本，因此从那时开始一切都很好。我使用MS全文搜索在nvarchar（max）列中搜索文本，这几乎可以在所有语言中正常工作，而且我了解这是如何在后台工作的。直到最近我需要搜索无效的日语文本为止。
我正在努力寻找有关此问题的足够信息，但我已经确定问题很可能与日语文本似乎没有多少词边界有关。看起来它的大部分文本都存储在一个大的长字符串中，并连接了我们称为单词的单词，这可以理解为什么SQL Server会遇到困难。我已经尝试使用CONTAINS / CONTAINSTABLE的通配符“” 要查找的文本””，但这仍然无法正常工作。使用LIKE是一种选择，但可能不会有20,000,000行。
我已经使用SQL Server一段时间了，并且非常了解它，尤其是从性能调整的角度来看，因此我当然不是新手。有没有其他人对此提出反对，您是否对此有解决方案？当然，SQL Server不能简单地排除日本。
Microsoft全文搜索实现的问题在于，它实际上仅允许one language per fulltext index，并且如果它与SQL Server实例的默认语言不同，则需要在索引定义中指定该语言。另一个限制是每个表或索引视图只能有一个全文索引。
有几种解决方法，具体取决于系统的体系结构和复杂性。例如，您可以创建多个表，每种语言一个表，这些表将存储索引的内容。不幸的是，您的应用程序需要以某种方式“理解”哪条记录到达何处，否则您的用户每次输入新数据时都必须设置正确的语言。
或者，所有文本都可以存储在同一表中，但是您可以创建多个索引视图，每个视图仅公开一个子集或使用相同语言的记录，然后在这些视图上创建全文本索引。同样，语言识别问题仍然存在。
当然，您的应用程序可以在用户输入文本时尝试检测当前的键盘布局（不确定在WPF中是否可行，但是我在WinForms中做到了）。如果您的系统存储了复制和上传的文档，则可能无法使用它。
根据我的经验，最可行的解决方案是允许客户在安装应用程序时自行指定FTS语言。如果您的受众是全球性的，则您可能无法开箱即用地讲所有语言。值得庆幸的是，根据我的观察，无论使用哪种索引语言，都可以或多或少可靠地找到英文文本。