标签: query-performance

我很好奇以下哪一项会更有效率？
我一直对使用有点谨慎,IN因为我相信SQL Server会将结果集转化为一个大的IF声明.对于大的结果集,这可能导致性能不佳.对于小结果集,我不确定是否更可取.对于大型结果集,EXISTS效率会不会更高？

WHERE EXISTS (SELECT * FROM Base WHERE bx.BoxID = Base.BoxID AND [Rank] = 2)

与

WHERE bx.BoxID IN (SELECT BoxID FROM Base WHERE [Rank = 2])

我正在努力绕过Django的ORM.我想要做的是在我的表格中的字段中获取不同值的列表....相当于以下之一:

SELECT DISTINCT myfieldname FROM mytable

(或者)

SELECT myfieldname FROM mytable GROUP BY myfieldname

在使用原始sql之前,我至少喜欢用Django方式做.例如,使用表格:

id,街道,城市

1,赫尔大街

2,其他街,赫尔

3,Bibble Way,莱斯特

4,另一种方式,莱斯特

5,高街,Londidium

我想得到:

船体,莱斯特,Londidium.

我最近发现并修复了我正在处理的网站中的一个错误,导致表中数百万个重复的数据行即使没有它们也会非常大(仍然是数百万).我可以很容易地找到这些重复的行,并可以运行单个删除查询来终止它们.问题是尝试一次性删除这么多行会长时间锁定表,如果可能的话我想避免这种情况.我可以看到摆脱这些行的唯一方法,而不是取下网站(通过锁定表):

1. 编写一个脚本,在循环中执行数千个较小的删除查询.这理论上会解决锁定表问题,因为其他查询将能够进入队列并在删除之间运行.但它仍然会在数据库上加载相当多的负载,并且需要很长时间才能运行.
2. 重命名表并重新创建现有表(它现在将为空).然后在重命名的表上进行清理.重命名新表,将旧表命名并将新行合并到重命名的表中.这需要采取相当多的步骤,但应该以最小的中断完成工作.这里唯一棘手的部分是所讨论的表格是一个报表,所以一旦它重新命名,而空的一个放在它的位置,所有历史报告都会消失,直到我把它放回原位.此外,由于存储的数据类型,合并过程可能会有点痛苦.总的来说,这是我现在可能的选择.

我只是想知道是否有其他人之前有这个问题,如果是这样,你如何处理它而不取下网站,并希望,如果有任何中断用户？如果我使用2号或类似的方法,我可以安排这些东西在深夜运行并在第二天早上进行合并,并且让用户提前知道,这不是什么大问题.我只是想看看是否有人有更好或更简单的方法来进行清理.

我有一个varchar字段(20)

执行此查询时,它很快(使用索引查找):

SELECT * FROM [dbo].[phone] WHERE phone = '5554474477'

但这个很慢(使用索引扫描).

SELECT * FROM [dbo].[phone] WHERE phone = N'5554474477'

我猜测如果我将字段更改为nvarchar,那么它将使用Index Seek.

我正在尝试在我维护的Web应用程序中调试SQL超时的来源.我有C#代码的源代码,所以我确切地知道正在运行什么代码.我已经将应用程序调试到执行超时的SQL代码的行,并且我在SQL分析器中观察运行的查询.

当此查询从Web执行时,它会在30秒后超时.但是,当我完全按照Profiler中显示的方式剪切/粘贴查询时,我将其放入SSMS并运行它,它几乎立即返回.我已经跟踪了ARITHABORT在Web正在使用的连接中设置为OFF的问题(也就是说,如果我在SSMS会话中关闭ARITHABORT,它会运行很长时间,如果我将其重新打开,那么它会运行很快).但是,阅读ARITHABORT的描述,它似乎并不适用......我只做一个简单的SELECT,并且根本没有执行任何算法......只有一个带有WHERE条件的INNER JOIN:

为什么ARITHABORT OFF会在此上下文中导致此行为？有什么办法可以改变SSMS对该连接的ARITHABORT设置吗？我正在使用SQL Server 2008.

这是一个关于SQL Server 2008 R2的问题

到目前为止,我不是DBA.我是一名java开发人员,必须不时编写SQL.(主要嵌入代码中).我想知道我在这里做错了什么,如果是的话,我可以做些什么来避免它再次发生.

Q1:

SELECT something FROM (SELECT * FROM T1 WHERE condition1) JOIN ...

Q1有14个连接

Q2与Q1相同,但有一个例外.(SELECT*FROM T1 WHERE condition1)之前执行,并存储在临时表中.

这不是相关的子查询.

Q2:

SELECT * INTO #tempTable FROM T1 WHERE condition1
SELECT something FROM #tempTable  JOIN ...

再次,14加入.

现在让我感到困惑的是,Q1花了> 2分钟(尝试了几次,以避免缓存发挥作用),而Q2(两个查询合并)花了2秒!是什么赋予了？

我正在尝试提高运行速度非常慢的查询的性能.完成实际执行计划后 ; 我发现Clustered Index Seek占82%.有什么方法可以改善Index Seek的表现吗？下面是执行计划中的问题索引查找的图像以及它正在使用的索引和表.

替代文字http://img340.imageshack.us/img340/1346/seek.png

指数:

/****** Object:  Index [IX_Stu]    Script Date: 12/28/2009 11:11:43 ******/
CREATE CLUSTERED INDEX [IX_Stu] ON [dbo].[stu] 
(
 [StuKey] ASC
)WITH (PAD_INDEX  = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF) ON [PRIMARY]

表(为简洁起见省略了一些列):

CREATE TABLE [dbo].[stu](
 [StuCertKey] [int] IDENTITY(1,1) NOT NULL,
 [StuKey] [int] NULL
 CONSTRAINT [PK_Stu] PRIMARY KEY NONCLUSTERED 
(
 [StuCertKey] ASC
)WITH (PAD_INDEX  = OFF, IGNORE_DUP_KEY = OFF, FILLFACTOR = …

在我们的产品中,我们有一个通用的搜索引擎,并试图优化搜索性能.查询中使用的许多表都允许空值.我们应该重新设计我们的表以禁止空值进行优化吗？

我们的产品上都运行Oracle和MS SQL Server.

我已经认识到这一概念AsNoTracking(),DetectChanges()以及AutoDetectChangesEnabled最近.据我所知,当使用Entity Framework从数据库中获取记录时AsNoTracking(),实体框架不会跟踪这些记录的任何更改,在这种情况下更新获取记录的任何属性都将失败.

我的问题是,如果以这种方式获取记录,它是否也会导致禁用对DetectChanges()的自动调用,或者是否必须通过设置显式完成:

Context.Configuration.AutoDetectChangesEnabled = false;

另请告诉我,如果在为了只读的目的而严格获取数据时执行这两个操作,它会产生什么影响(在性能方面):

Context.Configuration.AutoDetectChangesEnabled = false;
Context.Set<T>().AsNoTracking();

我们有以下数据

 IF OBJECT_ID('dbo.LogTable', 'U') IS NOT NULL  DROP TABLE dbo.LogTable

 SELECT TOP 100000 DATEADD(day, ( ABS(CHECKSUM(NEWID())) % 65530 ), 0) datesent 
 INTO [LogTable]
 FROM    sys.sysobjects
 CROSS JOIN sys.all_columns

我想计算行数,去年行数和最近十年行数.这可以使用条件聚合查询或使用子查询来实现,如下所示

-- conditional aggregation query
SELECT
    COUNT(*) AS all_cnt,
    SUM(CASE WHEN datesent > DATEADD(year,-1,GETDATE())
             THEN 1 ELSE 0 END) AS last_year_cnt,
    SUM(CASE WHEN datesent > DATEADD(year,-10,GETDATE())
             THEN 1 ELSE 0 END) AS last_ten_year_cnt
FROM LogTable


-- subqueries
SELECT
(
    SELECT count(*) FROM LogTable 
) all_cnt, 
(
    SELECT count(*) FROM LogTable WHERE datesent …