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

我是埃因霍温丰提斯大学的一名学生，我目前正在进行一系列访谈，以帮助开发SQL Server工具，并且我希望获得该领域专家的反馈。

我的问题之一是：

您的SQL Server实例遇到的前3个性能问题是什么？如何识别这些问题？

我特别对用于测量此内容的脚本和工具感兴趣。

让我烦恼的是-前3个查询问题：

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

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

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

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

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

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.

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

• 缺乏适当的指标
• 有人尝试在生产代码中使用nolock尝试解决性能问题。如果代码修改表中的数据，尤其糟糕
• 应用程序选择的数据多于所需的次数。即使您只想要同一张表的文本数据，Ex也会每次返回一个二进制文件。

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

只需一次查询所有内容。

包含“描述性” varchar /文本字段的表，必须通过每个查询进行搜索。

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

• 数据库和应用程序设计不佳
• 平台优势使用不佳（开发人员希望拥有平台所依赖的数据库访问代码。无SP，无功能等）
• 当然，索引编制不好。

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

• 数据库设计不佳
• 索引策略差（包括索引过多，索引丢失以及索引维护不足）
• 糟糕的硬件架构决策

索引对于性能至关重要，但是我发现大多数DBA都知道这一点，因此它往往是通过查询优化解决的第一件事。经常无法解决的领域：

1. DB往返次数过多。聊天是我看到的主要性能问题之一。
2. 获取正确的交易界限。处理每个INSERT / UPDATE / DELETE可能是一个巨大的性能杀手。
3. 无法优化硬件方面；特别是，将数据库日志放置在与数据库数据不同的卷上。

如果我可以在列表中添加第四个项目，那将是过多和不恰当地使用触发器和/或游标。这些天似乎并没有发生太多，但是当它发生时，从性能的角度来看这是很痛苦的。