在具有超过 100 万条记录的未索引 VARCHAR(MAX) 列的类似语句中使用通配符

Question

为了解决问题，我有一个关于特定varchar(max)字段是否包含非打印 ASCII 字符（空格除外）的一次性问题。以下是我关于如何确定我们的生产数据库中是否存储了此类字符的简单想法。

SELECT TOP 10 [CaseNoteId]
      ,[CaseId]
      ,[CaseNote]
  FROM [DB].[XY].[ReferralCaseNotes]
  WHERE CaseNote LIKE ('%[' + CHAR(1) + '-' + CHAR(8) + CHAR(11) + CHAR(12) + CHAR(14) + '-' + CHAR(31) + CHAR(127) + ']%')

我对实际运行这件事的犹豫源于在 LIKE 模式中使用通配符，有问题的表中有超过一百万条记录，该列缺少全文索引，这可能是一个详尽的搜索，因为我们不相信任何这样的角色存在。

我是新手。我如何估计运行此查询是否会对我们的生产系统造成重大负载？另外，有没有更好的方法来获取相同的信息？

可能的改进：

1. 我不担心查询运行时数据会发生变化。我可以更改此查询，以一种有益的方式一次查看几行吗？
2. 我可以将此查询设置为不妨碍任何其他查询的后台操作吗？
3. 我可以在有限的时间内运行它并确定搜索了表的百分比，以便我可以估计完整搜索所需的时间吗？
4. 会WITH(READPAST)提高我的表现吗？

为什么？

有问题的数据库涉及敏感数据、政府和制定规则的安全人员。将备份恢复到不同的服务器很有意义，但纳税人的成本比任何意义都要高几个数量级。

如果答案是“别担心，你只是在做一个 SELECT”，那么我会说，“太棒了！”

Answer 1

如果您担心查询的性能，您可以充分利用 SQL Server 内置的查询执行计划工具，该工具应该告诉您查询预计需要花费多少精力，以及查询的哪些部分对性能的影响最大以便您稍后可以对其进行微调。

您可以尝试几种您认为查询最有效的方案以及您在此处发布的代码，然后对结果进行计时并查看每个方案的执行计划。通过这种方式，您将了解每个查询的优点和权衡，并可以相应地解决问题。

PS：由于这将是一个生产数据库，我真的建议将此数据放入与生产尽可能相似的测试环境中，因为拥有功能较弱的服务器或专用于 MSSQL 实例的资源较少可能会给您带来错误关于预期性能时间的想法，并导致在优化某些东西时付出大量努力，超出了投入生产时收益递减的程度。