问题标签 [sql-server-performance]

我相当精通 SQL 服务器的性能，但我总是不得不反驳 GUID 应该用作集群主键的默认类型的想法。

假设该表每天的插入量相当低（5000 +/- 行/天），我们会遇到什么样的性能问题？页面拆分将如何影响我们的搜索性能？我应该多久重新索引一次（或者我应该碎片整理）？我应该将填充因子设置为（100、90、80 等）吗？

如果我每天插入 1,000,000 行会怎样？

我为所有问题预先道歉，但我希望得到一些备份，因为我没有使用 GUID 作为 PK 的默认值。然而，我完全愿意让 StackOverflow 用户群的大量知识改变我的想法。

我正在开发一个使用 SQL 2005（标准版）数据库的数据驱动的 Web 应用程序。

其中一张表相当大（800 万多行，大约 30 列）。表的大小显然会影响通过存储过程从表中选择项目的网站的性能。该表已编入索引，但由于表中的行数过多，性能仍然很差 - 这是问题的一部分 - 表的读取与更新相同，因此我们无法添加/删除索引而不创建其中之一操作更糟。

我在这里的目标是提高从表中选择项目时的性能。该表具有“当前”数据和旧/几乎没有触及的数据。在这个阶段我们能想到的最有效的解决方案是将表格分成 2 个，即一个用于旧项目（在某个日期之前，例如 2005 年 1 月 1 日），一个用于新项目（等于或之前 2005 年 1 月 1 日） .

我们知道分布式分区视图之类的东西——但所有这些功能都需要企业版，客户不会购买（不，也不会向它扔硬件）。

我将对 SQL Server 数据库运行一些查询，然后进行删除。理想情况下，所有这些都发生在一个事务中（即原子事务）。

但实际上，由于数据早已从缓冲区中清除，SQL Server 将不得不执行大量物理 IO 才能完成事务处理的 T-SQL。这可能是个问题，因为如果整个批处理运行时间超过 30 秒，那么用户将遇到超时问题。

我注意到，如果我分段运行我select的 s，每次运行越来越多的最终 SQL，让 SQL Server 用越来越多的所需数据填充缓冲区。例如：

第一次运行：

第二次运行：

...

第 n 次运行：

当我到达最后一轮时：

整个批次运行速度很快，因为缓冲区是预先填充的。

是否有一种 SQL Server 模式（即SET NOEXEC ON）会导致 SQL Server 不执行任何实际的数据修改，不使用任何锁，而是用所需的数据填充缓冲区？例如

或者

我们网站的一部分要求向用户询问 20 个关于他们自己的多项选择题（“个人资料”）。网站的这一部分将被经常查看，并且偶尔会更新。该网站预计会产生大量流量，因此正在考虑尝试并为性能问题做准备。

我可以看到将其存储在数据库中的 3 种方法是：

1. 为每个问题创建 1 个表，每个表都有 QuestionID 和 Answer，然后是 CustomerInfo 表来存储配置文件数据，外键映射到问题。

2. Question、Question_Type 和 Answers 表。把所有东西都塞进这些结构里。我在这里特别关心的是更新配置文件所需的 20 个左右的插入。这是否会在高流量时对性能造成影响？

3. 非规范化的单个表，每个问题一个字段，将答案代码硬编码在 HTML 和/或 C# 对象中。

我倾向于#2或#3。你认为最好的解决方案是什么？

我注意到大约 150 万个输入值发生了一个有趣的性能变化。有人可以给我一个很好的解释为什么会这样吗？

表很简单。它由 (bigint, bigint, bigint, bool, varbinary(max)) 我在前三个 bigint 上有一个 pk 聚集索引。我只插入布尔值“true”作为数据 varbinary(max)。

从那时起，性能似乎相当稳定。

图例：Y（时间以毫秒为单位）| X（插入 10K）

我也对图表上的恒定相对较小（有时非常大）的峰值感到好奇。

峰值之前的实际执行计划。

图例：
我要插入的表： TSMDataTable
1. BigInt DataNodeID - fk
2. BigInt TS - 主时间戳
3. BigInt CTS - 修改时间戳
4. 位：ICT - 记录最后插入的值（提高读取性能）
5. 数据：数据
布尔值当前时间戳保持

环境
这是当地的。
它不共享任何资源。
它是固定大小的数据库（足够所以它不会扩展）。
（计算机，4 核，8GB，7200rps，Win 7）。
（Sql Server 2008 R2 DC，处理器关联（核心 1,2），3GB，）

多少碎片是坏的？扫描密度有多低才算过低？扫描密度有多低是坏的？

我有一个具有以下索引密度和碎片级别的表：

您可以看到我刚刚进行了碎片整理TransactionEntries17，这就是为什么它的扫描密度如此之高，而它的碎片如此之低的原因。

但是 12% 的扫描密度是不是太低了？48% 的碎片率高得可怕吗？

删除行（需要索引扫描）时出现性能问题。索引碎片是70000 页索引上的巨大闪烁红色警报，还是可能但不太可能的原因？

从 SQL Server BOL：

扫描密度 [最佳计数：实际计数]

是一个百分比。它是Best Count与Actual Count的比率。如果一切都是连续的，则该值为 100；如果该值小于 100，则存在一些碎片。

如果所有内容都是连续链接的，则最佳计数是范围更改的理想数量。实际计数是范围更改的实际数量。

逻辑碎片

通过扫描索引的叶页返回的乱序页的百分比。这个数字与堆无关。乱序页是指分配给索引的下一个物理页不是当前叶页中的下一页指针所指向的页。

但是没有关于什么水平的碎片太高，应该降低的指导。也没有任何关于什么扫描密度太低的指导，应该增加。

如果我们从存储过程中提取多个表而不是每个表中的过程，它将如何影响 Sql Server 的性能？

我们有一个包含大约 40 个不同（每个大约 1-5GB）数据库的 SQL 服务器。服务器是一个 8 核 2.3G CPU 和 32G 内存。27Gig 固定到 SQL Server。CPU 利用率几乎总是接近 100%，内存消耗约为 95%。这里的问题是 CPU 一直接近 100% 并试图了解原因。

我已经运行了一个初始检查，以查看哪个数据库通过使用这个脚本导致了高 CPU，但我无法详细证实真正消耗 CPU 的内容。顶部查询（来自所有数据库）只需大约 4 秒即可完成。IO 也不是瓶颈。

记忆会是这里的罪魁祸首吗？我检查了内存拆分，并且 OBJECT CACHE 占用了分配给 SQL Server 的大约 80% 的内存 (27G)。我希望这是正常的，只要涉及到很多 SP。运行分析器，我确实看到了很多重新编译，但主要是由于“临时表更改”、“延迟编译”等，并且不清楚这些重新编译是否是由于内存压力导致计划被抛出缓存的结果

欣赏任何想法。

困境：

我即将在 MS SQL Server（2012 开发版）上执行数据填充。数据基于生产数据。数量约为 4TB（约 2.5 亿个项目）。

目的：

测试全文搜索和常规索引的性能。目标数量应该是大约 3 亿个项目，每个项目大约 500K。

问题：

我应该做些什么来加快我应该担心的过程或后果？

前任。

1. 关闭统计？
2. 我应该为每笔交易而不是单笔交易批量插入 1k 个项目吗？
3. 简单的恢复模式？
4. 日志截断？

重要的：

我将使用 2k 个生产项目的样本来创建每个将插入数据库的随机项目。我将使用在 c# 中生成的近乎独特的样本。这将是一张桌子：

我正在尝试监视我的 SQL Server 上的锁定持续时间，但 Duration 列是空白的。如何使用 Profiler 进行监控？