Question

数据库结构不是最常见的性能瓶颈是什么？

Answer 1

让我们看一下（没有特别的顺序）

光标
不可搜索的where子句
无法索引外键字段
无法索引where子句中常用的字段
相关子查询
意外交叉连接导致需要区分结果集
执行来自ORM的代码
导致读取次数过多的代码，或者在不需要的情况下多次调用的代码（我看到应用程序在不需要时或每次发送时多次发送相同的代码页面已打开）
网络管道重载
用户定义的函数导致逐行处理
参数嗅探
过时的统计数据
联盟代替联合所有

Answer 2

表扫描因为：

索引不存在
统计信息已过期
where子句中的函数阻止使用

Answer 3

服务器 - 与内存和存储类似类型。
网络 - 延迟和带宽的问题。
索引 - 不确定您是否考虑过这个数据库结构
查询 - 带有连接的错误查询可能导致全表的问题扫描。

Answer 4

物理....耗尽内存，不得不转到磁盘。

Answer 5

使用游标。对于任何数据库。

Answer 6

将标量函数应用于结果集中的每一行

SELECT fn_EveluateSomeValue([ColumnName]) FROM LargeTable

Answer 7

一些低调的果实：

标量UDF
在XPath查询中省略text()
缺少索引中的列（导致键查找）
使用游标
- 在需要游标时尽可能不使用fast_forward
在JOIN执行时使用APPLY，反之亦然（测试！）

Answer 8

一次使用一行表数据而不是一次使用一个表（即游标）。

不必要的（或设计不当的）锁。

记录记录不需要记录的内容（从表中删除而不是删除Truncate表等）

在批量加载数据时受到限制。严重减慢插入速度。关闭它们，加载数据，然后重新打开它们。

Answer 9

Ditto ref游标，也写得很糟糕的客户端应用程序得到了一个巨大的记录集然后自己处理它，因为开发人员不明白sql只是一个巨大的堆来保存数据。

尝试在一个巨大的查询中执行所有操作，而不是将其分解为合理的步骤。有时这不会让SQL有机会正确地减少必须查看的索引（希望！）页面的数量。与此相关，不了解如何在更新大型索引表之前使用临时表来处理操作。

没有连接或常见查询字段的索引。

当您一直寻找并返回相同的值时（例如，当您使用EmployeeID查找时，员工的格式化名称）导致两个操作而不是一个操作时，不包括索引中的字段。

Answer 10

我倾向于遇到以下瓶颈（按频率顺序）：

缺少或不正确的索引（导致表扫描）
写得不好的查询
I / O争用

Answer 11

对我们来说，调整 BIOS设置和电源计划设置可以使CPU密集型查询（搜索时间大约为5秒）的速度提高〜2倍。

1）BIOS设置从“每瓦性能优化（DAPC）”更改为“性能”或“每瓦优化性能（OS）”。这两个选项似乎表现相似但是“OS”控制的选项没有连续运行风扇。

2）Windows电源计划已从“Balanced”更改为“High performance”。

这是在升级CPU并且几乎没有任何改进后发现的。

从SQLServerCentral检查CPU速度的命令：

PS> gwmi -class win32_Processor | SELECT CurrentClockSpeed, MaxClockSpeed

Update 6/13/2017：警告：该号码可能会报告当前=最大值，但任务管理器可能会显示不同的（低得多）数字。在一些硬件更改后，BIOS模式“每瓦性能优化（OS）”突然停止为我们工作。无论负载如何，CPU都锁定在最大频率的50％只有“性能”模式（大风扇模式）仍然达到最大CPU。我们必须缺少固件/软件补丁。