您在使用 SQL Server 时遇到的前 3 个性能问题是什么？

Question

我是埃因霍温 Fontys 大学的学生，我目前正在进行一系列采访以帮助开发 SQL Server 工具，我想从该领域的专家那里得到反馈。

我的问题之一是：

您在使用 SQL Server 实例时遇到的前 3 个性能问题是什么？您如何确定这些问题？

我对用于衡量这一点的脚本和工具特别感兴趣。

Answer 1

关闭我的头顶 - 前 3 个查询问题：

• 隐式转换
• 错误的索引策略（太多或不够或类型错误）
• 使用 SELECT * 而不是仅命名您需要的字段

关于服务器级配置问题、数据库架构问题、硬件问题等还有很多。我编写了一个脚本来快速分析服务器以查找这些类型的问题：

http://www.brentozar.com/blitz/

Answer 2

• 糟糕的设计/查询/索引
• 不允许购买正确的硬件
• Braindead ORM（又名“SQL 已死”）

Answer 3

不是前三名，但我想我会提到尚未提到的事情：

1. SQL 放在虚拟机上，没有向 DBA 提供详细信息/透明度。主机服务器将动态更改来宾计算机设置，从而导致性能下降，并使 DBA 一无所知。超线程、网络组合和内存膨胀等功能使性能计数器成为需要监控的移动目标。Tools: sysmon/perfmon, DMVs, maintaining a history of performance counters in tables.
2. 同样，提供给 DBA 的 SAN 设置也没有透明度/可验证性。我的 LUN 设置了不同的读/写缓存首选项，但被告知它们都是相同的。Tools: IO DMVs, SQLIO.
3. 糟糕的数据库架构：比如数据和日志文件的大小和位置，以及 tempdb。并行性使用不当。在同一个物理磁盘上创建多个文件组。Tools: experience.

我现在正在检查的另一个工具是Project Lucy。看起来很整洁。

Answer 4

• 缺乏适当的索引
• 有人在生产代码中使用 with nolock 来尝试解决性能问题。如果代码修改表中的数据，则尤其糟糕
• 应用程序在不必要的时间选择比需要更多的数据。即使您只想要同一个表的文本数据，也每次都会返回一个二进制文件。

Answer 5

扩展性不佳的查询（获取所有客户 X 年的所有订单等，包括所有订单行，包括汇总数据和其他计算不当的平均数据）

只需一次查询所有内容。

包含必须在每个查询中搜索的“descript”varchar/text 字段的表。

Answer 6

• 维护不当，即没有索引重组、统计信息、没有日志备份
• 缺少索引
• 写得不好的查询

Answer 7

• 糟糕的数据库和应用程序设计
• 平台优势利用不足（开发人员希望拥有平台相关的数据库访问代码。没有 SP，没有功能等）
• 当然，索引不好。

Answer 8

• 对生产数据的临时查询 - 是的，开发人员确实认为这是必要的，有些甚至可能有访问权限 :-)
• 使用数据库的应用程序设计不佳 - 例如：添加了太多数据，即使不再需要也不会删除（这会导致性能问题，因为备份变大，维护任务需要更长的时间......等）
• 同一个raid上的所有数据库文件，或者更糟，同一个驱动器上的所有数据库文件（例如：系统dbs、tempdb、用户dbs都在同一个驱动器/raid上）