Questions tagged «sql-server»

所有版本的Microsoft SQL Server（非MySQL）。还请添加特定于版本的标记，例如sql-server-2016，因为它通常与问题相关。

3
索引对更新列不在索引中的更新语句的影响
我经常看到人们说索引变慢update，delete并且insert。这用作一揽子声明，就好像它是绝对的一样。 在调整数据库以提高性能的同时，我不断遇到这种情况，这种情况似乎在逻辑上对我来说与该规则相矛盾，而且我在任何地方都找不到其他方式可以说或解释的人。 在SQL Server中，并且我相信/假定将使用大多数其他DBMS，您的索引是根据您指定的特定列创建的。插入和删除将始终影响整个行，因此没有办法不会影响索引，但是更新似乎更加独特，它们可以专门影响某些列。 如果我有未包含在任何索引中的列并更新了它们，它们是否会因为我在该表中的其他列上有索引而放慢了速度？ 例如，在我的User表中，我有一个或两个索引，主键是Identity / Auto Increment列，外键列上可能还有另一个。 如果我更新没有索引直接在其上的列（例如说他们的电话号码或地址），由于在任何一种情况下我在该表的其他列上都有索引，此更新是否会变慢？我要更新的列不在索引中，因此从逻辑上讲，不应更新索引，不是吗？如果有的话，如果我使用WHERE子句中的索引，我认为它们会加快速度。
3
为什么SQL Server会忽略索引？
我有一个表，CustPassMaster其中有16列，其中一个是CustNum varchar(8)，并且创建了一个index IX_dbo_CustPassMaster_CustNum。当我运行SELECT语句时： SELECT * FROM dbo.CustPassMaster WHERE CustNum = '12345678' 它完全忽略索引。这让我感到困惑，因为我还有另一个表，CustDataMaster其中包含更多列（55），其中一个是CustNum varchar(8)。我IX_dbo_CustDataMaster_CustNum在此表的此列（）上创建了一个索引，并使用了几乎相同的查询： SELECT * FROM dbo.CustDataMaster WHERE CustNum = '12345678' 它使用我创建的索引。 这背后有什么具体的理由吗？为什么要使用from的索引CustDataMaster，而不使用from的索引CustPassMaster？是由于列数少吗？ 第一个查询返回66行。对于第二个，返回1行。 另外，还要注意：CustPassMaster具有4991条记录和CustDataMaster5376条记录。这可能是忽略索引的原因吗？CustPassMaster也有具有相同CustNum值的重复记录。这是另一个因素吗？ 我将此主张基于两个查询的实际执行计划结果。 这是DDL CustPassMaster（具有未使用的索引的DDL ）： CREATE TABLE dbo.CustPassMaster( [CustNum] [varchar](8) NOT NULL, [Username] [char](15) NOT NULL, [Password] [char](15) NOT NULL, /* more columns here */ [VBTerminator] …
3
数据库灾难预防
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 我的数据库大于250GB。我使用第三方工具进行计划的备份。 计划数据库备份是保护SQL Server数据库免受损坏的最佳方法吗？还是可以推荐其他东西？
1
删除未使用的索引-评估意外的危险
根据DMV统计数据，我们有一个非常大的数据库，其中包含数百个未使用的索引，自从服务器在7月最后一次重新启动以来，该索引一直在累积。我们的一名DBA做出了以下警告性声明，这对我来说没有意义： 在删除索引之前，我们需要确定它是否不执行唯一性约束，因为查询优化器可能需要该索引存在。 每当创建索引时，都会在SQL Server中创建与该索引相关的统计信息。查询可能未使用索引，但可能正在使用其统计信息。因此，我们可能会遇到这样的情况：在删除索引之后，特定的查询性能会变得很差。SQL Server不保留统计信息的使用情况统计信息。尽管我们在数据库上启用了“自动创建统计信息”功能，但是我不知道在查询优化器创建丢失的统计信息之前必须在内部满足哪些所有参数。 关于＃1，在我看来，SQL Server实际上会在完成插入/更新之前对索引进行一次搜索以确定唯一性，因此，该索引不会显示为未使用。 关于＃2，这真的有可能吗？ 顺便说一句，当我说不使用索引时，我的意思是没有搜寻也没有扫描。
16 sql-server  index 
3
创建多级层次结构，其中每个节点具有随机数量的子级
我需要创建一些涉及层次结构的测试数据。我可以简化并做几个CROSS JOINs，但这将使我的结构完全统一/没有任何变化。这不仅看起来很乏味，而且测试数据的缺乏变化有时掩盖了原本会发现的问题。因此，我想生成遵循以下规则的非统一层次结构： 3级深 1级随机是5-20个节点 级别2是1-10个节点，级别1的每个节点随机 级别3是1-5个节点，级别2的每个节点随机 所有分支的深度将为3级。此时，深度均匀是可以的。 在任何给定级别上，子节点的名称都可以重叠（即，子节点的名称在同一级别的所有节点上不必唯一）。 术语“随机”在此定义为伪随机，而不是唯一随机的。需要提到这一点，因为术语“随机”通常用于表示“不会产生重复项的给定集合的随机排序”。我接受random = random，如果第1级每个节点的子代数分别只有4、7和8，即使跨越第1级20个节点，每个节点的潜在散布为1-10个子代，那很好，因为那是随机的。 即使使用嵌套WHILE循环可以很容易地做到这一点，但首选还是要找到一种基于集合的方法。一般而言，生成测试数据并没有生产代码所具有的效率要求，但是针对基于集合的方法进行射击可能会更具教育意义，并且在将来找到基于集合的问题解决方法时会有所帮助。因此，WHILE循环不排除循环，只有在不可能使用基于集合的方法时才可以使用循环。 基于集合=理想情况下是单个查询，而不考虑CTE，APPLY等。因此，使用现有或内联数字表就可以了。使用WHILE / CURSOR /过程方法将不起作用。我想将数据的部分存储到临时表或表变量中就好了，只要这些操作都是基于集合的，没有循环即可。但是，话虽如此，除非可以证明多查询方法实际上更好，否则单查询方法可能比多查询更受青睐。还请记住，“更好”的构成通常是主观的;-)。还请记住，前一句中“通常”的使用也是主观的。 任何版本的SQL Server（我想是2005年及更高版本）都可以。 只有纯T-SQL：没有这些愚蠢的SQLCLR东西！至少在生成数据方面。创建目录和文件将使用SQLCLR完成。但是在这里，我只是专注于生成所创建内容的价值。 T-SQL多语句TVF被认为是过程性的，而不是基于集合的，即使在外部它们掩盖了集合中的过程方法。有时候这是绝对合适的。这不是那个时候之一。同样，也不允许使用T-SQL标量函数，这不仅是因为它们也是过程性的，而且查询优化器有时会缓存其值并重复该值，以使输出结果与预期不符。 T-SQL内联TVF（又名iTVF）是基于集合的okey-dokey，并且实际上与使用相同[ CROSS | OUTER ] APPLY，后者如上所述是可以的。 重复执行查询应产生与先前运行几乎不同的结果。 更新说明1：最终结果集应表示为Level3的每个不同节点都有一行，其完整路径从Level1开始。这意味着Level1和Level2值将必须在一个或多个行上重复，除非只有一个Level2节点仅包含一个Level3节点。 澄清更新2：每个节点都有一个非常好的首选项，每个节点都有一个名称或标签，而不仅仅是一个数字。这将使生成的测试数据更加有意义和现实。 我不确定这个附加信息是否重要，但是如果万一有助于了解某些情况，测试数据将与我对以下问题的回答有关： 将XML文件导入SQL Server 2012 尽管此时不相关，但是生成此层次结构的最终目标是创建一个目录结构来测试递归文件系统方法。级别1和2将是目录，级别3将最终成为文件名。我搜索了一下（在这里和通过Google），但只发现了一个参考，以生成随机层次结构： Linux：创建随机目录/文件层次结构 这个问题（在StackOverflow上）实际上在期望结果方面非常接近，因为它还试图创建用于测试的目录结构。但是，这个问题（以及答案）的重点是Linux / Unix shell脚本，而不是我们所生活的基于集合的世界。 现在，我知道了如何生成随机数据，并且已经在创建文件的内容，以便它们也可以显示变化。这里最棘手的部分是每个集合中元素的数量是随机的，而不是特定的字段。并且，每个节点内的元素数量必须与同一级别上的其他节点随机。 示例层次结构 Level 1 Level 3 |---- A | |-- 1 …
4
删除表字段后声明磁盘空间
我正在运行sql 2008 r2，并且数据库在过去3年中运行良好且运行迅速，直到大约3个月前，我们在非常活跃和使用过的表上添加了ntext字段。现在，由于此表的巨大扩展空间，我们开始摆脱服务器空间。 我读到收缩，我们不想失去db的索引，因为它的工作速度已经快了很多年了，我们也不想让碎片化花费。 我们决定删除该字段及其所有值： 是否可以删除ntext字段及其所有值并释放空间，而又不删除索引，不缩小索引，不降低数据库性能？ 我附上数据库大小查询输出，以显示最近5个月的大小扩展。
9
WHERE子句的替代方法
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，使它成为数据库管理员Stack Exchange 的主题。 4年前关闭。 有没有办法只SELECT使用一列中具有某些数据的行而不使用WHERE？ 例如，如果我有这个： SELECT * FROM Users WHERE town = 'Townsville' 有没有一种方法可以WHERE在SELECT语句中实现该子句？ 就像是 SELECT *, town('Townsville') FROM Users 这是一个奇怪的问题，但这是我的同龄人问的一个问题
16 sql-server 
3
带有子查询的大表更新缓慢
对于SourceTable具有> 15MM的记录和Bad_Phrase具有> 3K的记录，以下查询需要将近10个小时才能在SQL Server 2005 SP4上运行。 UPDATE [SourceTable] SET Bad_Count= ( SELECT COUNT(*) FROM Bad_Phrase WHERE [SourceTable].Name like '%'+Bad_Phrase.PHRASE+'%' ) 用英语来说，此查询计算的是Bad_Phrase中列出的，是字段Name中的子字符串的不同短语的数量，SourceTable然后将结果放入字段中Bad_Count。 我想要一些有关如何使此查询运行得更快的建议。
2
为什么在联接谓词强制嵌套循环中引用变量？
我碰到这个问题最近，无法在网上找到的任何讨论。 下面的查询 DECLARE @S VARCHAR(1) = ''; WITH T AS (SELECT name + @S AS name2, * FROM master..spt_values) SELECT * FROM T T1 INNER JOIN T T2 ON T1.name2 = T2.name2; 始终获得嵌套循环计划 尝试通过INNER HASH JOIN或INNER MERGE JOIN提示强制问题会产生以下错误。 由于此查询中定义的提示，查询处理器无法生成查询计划。重新提交查询而不指定任何提示，也无需使用SET FORCEPLAN。 我发现了一种允许使用散列或合并联接的解决方法-将变量包装在一个聚合中。生成的计划的成本大大降低（19.2025比0.261987） DECLARE @S2 VARCHAR(1) = ''; WITH T AS (SELECT …
2
可视化SQL Server扩展事件数据
最近，我一直在探索在SQL Server中使用扩展事件来帮助我进行基准测试和优化各种查询。到目前为止，要查看事件数据，我一直在使用SSMS中的“观看实时数据”功能。 我遇到的问题是，实时事件功能似乎使用了内部缓冲区，这意味着有时我需要多次执行查询才能使其信息显示在窗口中。因此，我有一个两部分的问题要问： 有没有办法解决将延迟显示在实时供稿中的这种延迟？（我正在本地数据库上执行此操作，因此性能不是问题） 实时供稿是否是可视化扩展事件数据的最佳方法？SSMS中是否有另一个工具可以更好地适应我的用例？ 更新 根据要求，这里是会议： CREATE EVENT SESSION [Simple Query Benchmarking] ON SERVER ADD EVENT sqlserver.sql_batch_completed(SET collect_batch_text=(1) ACTION(sqlserver.query_hash,sqlserver.query_plan_hash,sqlserver.sql_text) WHERE ([package0].[equal_boolean]([sqlserver].[is_system],(0)) AND [package0].[greater_than_uint64]([duration],(1000)))) ADD TARGET package0.ring_buffer WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=1 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=ON,STARTUP_STATE=OFF) GO
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.