我正在处理的 OTLP 项目遇到 Db 性能问题。我和另一位开发人员已经达到了我们积累的性能知识的终点，并寻找个人加入团队以帮助我们加快应用程序的速度。
对于某些背景，我们已经完成了架构更改以对数据片段进行非规范化，优化每个查询，运行多个数据库调整顾问以使我们的索引正确，调整 MSSql 的服务器选项。
我们不需要有人进来告诉我们加入可能很慢以及什么是死锁，我们需要在用尽上面列出的所有步骤后知道该做什么的人。
任何人有任何雇佣 OLTP DBA 的技巧或经验可以分享吗？在面试过程中我们可以问 DBA 什么样的问题？
这是一个奇怪的情况，我们知道我们需要比当前团队了解更多的人，但我们不知道要问什么问题，因为我们不知道下一步是什么。那有意义吗？
好的，这告诉我一些事情：
对于某些背景，我们已经完成了架构更改以对数据片段进行非规范化，优化每个查询，运行多个数据库调整顾问以使我们的索引正确，调整 MSSql 的服务器选项。
您已经达到或超过了 90% 自称为 DBA 的人的能力。
问题是很多 DBA 并不是真正的程序员，他们更多的是在系统管理方面。您需要一位不仅非常擅长 TSQL，而且还了解您的其他编程语言的 DBA 程序员。
我将大部分时间花在这样的数据库调优问题上，解决方案通常涉及从前端到数据库模式的整个过程中的重大重新设计。您无法孤立地解决这些问题，如果没有对整个架构的完全控制（和完全理解），您将永远无法获得所需的性能。
您可能是这项工作的最佳人选，而且您可能更明智地聘请某人来让您摆脱繁忙的工作，这样您就可以专注于 OLTP 性能问题。
您必须在这里小心谨慎，您最终可能会聘请 Guru DBA，让他显着提高数据库性能，但您的应用程序仍然存在根植于其架构的问题。
一些想法：
将您优化的最复杂的查询交给具有 QA 的候选人 DBA，并让他/她再次对其进行优化。让他们描述他们做了什么以及他们是如何做到的。
确保此人了解硬件，当您使用多个文件组、RAID 阵列、数据分区、64 位与 32 位性能等时...
寻找也有一些软件架构背景的人。
问他们一些更难的 SQL 服务器问题，例如。什么是 OVER 语句？GUID 是好的主键吗？为什么，int 身份更可取？
将您的数据库调回到您自己的优化之前，然后将其提供给他们。看看他们是否可以将其调整为与您所做的更改相比表现得一样好或更好。
问他们为什么选择这种技术。
查阅参考资料并找出他们所来自的环境最有可能与您的环境相匹配。
一个好的 DBA 将能够在面试中从高层次上告诉你他们下一步将采取什么步骤。你应该更多地关注这里的思维过程，而不是问题的解决方案。当 DBA 给出了一些解决方案时，回去对他们进行测验，并询问他们为什么应该以这些方式解决问题。
这种方法可以很快将男人和男孩区分开来。
你离数据库的最大性能有多近？使用该技术很容易产生无法解决的 OLTP 问题。正如 Eric 所说，总体架构重新设计可能是有序的。更多内存，只需添加更多内存 :)
当然，如果没有看到数据库，很难说什么是最好的优化方法。鉴于您所做的工作，您可能需要聘请一名数据库设计师 - 一位具有设计和调整您拥有的大小范围内的数据库经验的人。在询问他们将如何解决问题时，看看面试官是否会首先查看性能不佳的查询并运行分析器以查看正在发生的事情并识别它们。该人应该能够回答有关参数嗅探以及如何避免它的具体问题，可以使用哪些方法来避免游标，为什么需要更新统计信息，是什么使查询变得可靠。在性能调优中我会考虑一些常见的事情。网络是否已用尽（有时不是数据库），整体设计是否经过深思熟虑，您是否在使用通常表现不佳的 SQl 代码？例如，如果您的所有搜索都允许通配符作为第一个字符，那么甚至不可能让它们变得快速。如果您的联接是在多列自然键上，它们会比应有的速度慢。您是否在一个字段中存储了多个信息，从而导致大量操作以获取数据？你在使用游标吗？你在使用函数吗？你是否在不应该重用代码的时候？不是吗？您是否总是返回所需的最少信息？你要关闭连接吗？你遇到死锁了吗？您的表格行是否太宽？您是否在特定表中有太多记录（清除旧记录或将它们放入存档数据库会产生巨大差异）？您的代码中有多少是面向行而不是面向集合的？这些是经验丰富的数据库人员会看的事情的例子，因此他们应该在面试中谈论的事情。
一些糟糕的代码示例（你知道你已经优化了什么）可以让你很好地了解他们如何调整它们的方法。您需要有条不紊且具有 SQL 知识深度的人。
有一些关于性能调优的好书——我建议在面试之前获取它们并熟悉它们。