不灵活应用程序的 SQL Server 优化/配置

Question

我负责监督使用 SQL Server 作为其后端存储解决方案的应用程序。不幸的是，该应用程序没有关于如何使用 RDBMS 的概念，似乎主要像使用 NoSQL 解决方案一样使用它。应用程序最需要的是获取和存储单个记录，并且不使用任何外键来保证数据完整性。

正如预期的那样，这种出色的设计导致了相当差的性能，因为将 RDBMS 用于仅需要磁盘散列样式方案的问题就像对蚊子使用大炮一样。但可惜的是，我无法修改该软件，因为它是第三方软件。

我已经看到许多提示，很高兴告诉我应该使用更有效的查询，但这根本不是一个选择。SQL Server 似乎主要受 CPU 限制，而且大部分数据似乎也缓存在内存中。有没有一种方法可以优化/配置 SQL 处理来自该应用程序的请求的方式？（整个 SQL Server 实例仅供应用程序使用。）或者，是否有另一种解决方案，其行为与 SQL Server 相似，但在简单查询的速度上与 NoSQL 相似？SQL Server 是否有某种单进程模式使锁定记录变得不必要？

我应该尝试一下任何离奇的想法吗？

更新： 因此，在对带有自动生成的游标准备、执行、获取等的跟踪进行大量处理之后，看起来在关注的特定应用程序功能中的大部分时间都浪费在填充表上，只有第一行实际上是获取的。这实际上似乎是应用程序编写方式的常见问题。

由于游标后面的 select 语句对数据进行排序，游标不能有效地使用动态计划。最终，应用程序试图获取的数据是下一个记录，field A = document_id并且下一个field B值大于先前寻求的field B值。当然，这是游标的典型应用——如果应用程序以典型方式使用游标的话。

我想再次联系供应商，因为这...很糟糕。我认为它们更有可能出现在一个简单的两行已经存在的修复中。因此，我希望生成一个更高效的查询版本（仍然使用游标，具有相同的客户端语义“给我下一条记录，k？”）。我不确定如何在 TSQL 中制定这样的查询，因为我给出的所有结果都会导致扫描，即使是我认为有用的索引。（真的，只需要一个 b 树搜索，但不知何故我似乎无法到达那里。）

Answer 1

我们都去过那里。那些没有的人有一天会遇到这种情况！

有一种教科书方法来处理第三方恐怖软件：

1. 证明有问题。识别并记录疯狂的查询和数据访问模式。
2. 将您的问题证据与供应商联系。如果您可以证明重写查询表明改进是可能的，那么供应商就更难忽视您的担忧。
3. 如果您的供应商联系人没有回应，请升级。如果你不能发出足够多的声音让别人听到，也许你的 CTO 可以。
4. 如果您已完成第 4 步但没有任何成功，您可能会牺牲卵泡或注意到明显的灰色迹象。这是第三方开发负责人的巫毒娃娃可以缓解当天压力的地方。带有公司标志的飞镖是一种可接受的替代品。

回到现实世界，我们有哪些实用的方法：

• 用铁杀死它。说出来总是让我很痛苦，但有时将硬件投入问题可能是最快、最便宜、风险最低的解决方案。
• 了解根本原因。对完全由您控制的系统运行相同的分析。识别最频繁的查询，那些具有最高 CPU、最高读取、最长持续时间的查询，查看 tempdb 使用情况，分析计划缓存（在这些场景中经常会出现单次使用临时查询）。
• 索引。Database Tuning Advisor (DTA) 是一种有用的工具，可用于分析您几乎无法控制的工作负载。特别是，它可以发现索引视图的候选对象和可能不明显的多列统计信息的缺失。
• 计划指南。如果您发现一个可以重新制定执行计划的查询，计划指南会为您提供一种无需修改源查询即可强制执行该计划的方法。