标签: sqlperformance

我有一个大表(大约1000万条记录),其中包含几个键到其他较小的表中.键在每个较小的表中都是唯一的,但在大表中则不是.我想根据键匹配从一个较小的表中向大表中添加一列,但我不确定"正确"的方法.我有一个有效的解决方案,但它需要相当长的时间(认为可能是不可避免的),并且通常不认为这是最佳的方式.这就是我所拥有的:

CREATE TABLE new_big_table LIKE big_table;
ALTER TABLE new_big_table ADD(new_column TINYINT NOT NULL);
INSERT INTO new_big_table SELECT big_table.*, smaller_table.my_column
  FROM big_table JOIN smaller_table ON big_table.key1 = smaller_table.key1
  AND big_table.key2 = smaller_table.key2;

这可以完成工作,但它真的闻起来像我做错了.似乎至少我不需要创建表的副本来完成这项工作.有没有更直接(更有效？)的方式呢？

值得一提的是,这是针对家中的个人爱好项目,所以我可以自由地占用机器的所有资源(因为我是唯一使用它的人).因此,如果有做这样的事情的任何直接的性能优化技巧,我会很感激他们(我与这个实验在Amazon EC2实例,因为它应该是快了很多,并有比我的个人桌面更多内存) .

SELECT Trade.TradeId, Trade.Type, Trade.Symbol, Trade.TradeDate, 
       SUM(TradeLine.Notional) / 1000 AS Expr1
FROM   Trade INNER JOIN
             TradeLine ON Trade.TradeId = TradeLine.TradeId
WHERE  (TradeLine.Id IN
                      (SELECT     PairOffId
                        FROM          TradeLine AS TradeLine_1
                        WHERE      (TradeDate <= '2011-05-11')
                        GROUP BY PairOffId
                        HAVING      (SUM(Notional) <> 0)))
GROUP BY Trade.TradeId, Trade.Type, Trade.Symbol, Trade.TradeDate
ORDER BY Trade.Type, Trade.TradeDate

当表开始增长时,我担心WHERE子句中IN的性能.有没有人对这种查询有更好的策略？子查询返回的记录数比TradeLine表中的记录数慢得多.TradeLine表本身以10 /天的速度增长.

谢谢.

编辑:我使用了将子查询从WHERE移动到FROM的想法.我投票支持了这个新查询的所有答案.

   SELECT Trade.TradeId, Trade.Type, Trade.Symbol, Trade.TradeDate,   
          PairOff.Notional / 1000 AS Expr1
   FROM         Trade INNER JOIN
                  TradeLine ON Trade.TradeId = TradeLine.TradeId INNER JOIN
                      (SELECT     PairOffId, SUM(Notional) AS Notional
                        FROM …

我最近才意识到您现在可以在SQL Server中索引视图(请参阅http://technet.microsoft.com/en-us/library/cc917715.aspx).我现在正试图弄清楚当我从一个索引视图的查询中获得更好的性能与存储过程中的同一查询时,它的执行路径被缓存了吗？

举个例子如下:

SELECT colA, colB, sum(colC), sum(colD), colE
FROM myTable
WHERE colFDate < '9/30/2011'
GROUP BY colA, colB, colE

每次运行时日期都会不同,所以如果这是一个视图,我不会WHERE在视图中包含它,而是将其作为我对视图的选择的一部分.如果它是存储过程,则日期将是参数.请注意,表中大约有300,000行.其中200,000个符合where条款和日期.在小组之后将返回10,000.

如果这是一个索引视图,我是否应该期望获得更好的性能而不是有机会缓存​​执行路径的存储过程？或者proc会更快吗？或者差异可以忽略不计？我知道我们可以说"只是尝试两种方式",但有太多因素可能会错误地偏向结果导致我得出错误的结论,所以我想听到更多关于它背后的理论以及预期的结果是什么.

谢谢!

sys.dm_db_missing_index_group_stats的文档使用术语"用户查询"和"系统查询",但它没有定义这些含义.例如:

• user_seeks:"由用户查询引起的搜索次数,该组中的推荐索引可能已被用于."
• system_seeks:"由系统查询引起的搜索次数,例如自动统计信息查询,该组中的推荐索引可能已被用于."

基于在System查询中使用该术语的方式来确定数据库中权限的完整(包括从AD ROLES继承)的视图？,我假设系统查询是针对系统表的查询.然后,用户查询必须是针对用户表的查询.

有没有人对这两个术语的定义有更权威的来源？我问,因为我正在使用sys.dm_db_missing_index_group_stats的结果,并考虑如何在决定是否应用索引时正确权衡avg_user_impact与avg_system_impact.

我有一个存储过程具有以下代码:

BEGIN TRY
--BEGIN TRANSACTION @TranName

    DECLARE @ID int

    INSERT INTO [dbo].[a] ([Comment],[Type_Id],[CreatedBy])
    VALUES ('test',1,2)

    SET @ID = SCOPE_IDENTITY()

    INSERT INTO [dbo].[b] ([Can_ID],[Com_ID],[Cal_ID],[CreatedBy])
    VALUES (1,@ID,null,2)

    UPDATE c SET LastUpdated = GETDATE(), LastUpdatedBy = 2 WHERE b.id = @ID

    --COMMIT TRANSACTION @TranName

    SELECT * from [View] where a.id=@ID
    END TRY
    BEGIN CATCH
--ROLLBACK TRANSACTION @TranName
END CATCH

单独运行的每个语句(现在都是)运行得很快.但是,当我们从Transaction的代码段中删除注释时,脚本运行时间从1秒增加到超过2分钟.

系统已经运行了很长一段时间了,之前这不是问题,我一直在尝试搜索有关SQL Server如何处理事务的文档,以防万一有可能影响SQL性能的事情而且这是唯一的事情.我想到的是事务日志......但理想情况下,这些单独的语句也可以在单个事务中运行,任何想法？

我有一个性能查询最近的商店:

我们有一张表格,其中包含一个国家/地区约50,000条记录(商店/销售点位置).

每条记录都有location"地理"类型的列

[LOCATION_geo] [geography]

同样为了性能,我使用这种语法在该位置列上创建了一个SPATIAL INDEX

CREATE SPATIAL INDEX [LOCATION_geoIndex] 
ON [dbo].[StoreLocations] ([LOCATION_geo])
USING GEOGRAPHY_GRID 
WITH (
GRIDS =(LEVEL_1 = MEDIUM,LEVEL_2 = MEDIUM,LEVEL_3 = MEDIUM,LEVEL_4 = MEDIUM), 
CELLS_PER_OBJECT = 16, PAD_INDEX  = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO

我有一个存储过程来返回用户当前位置最近的1000商店.

USE [CompanyDB]
GO
SET STATISTICS TIME ON;  
GO  
declare @point geography;
    set @point = geography::Point(49.2471855, -123.1078987, 4326);

    SELECT top (1000) [id]
          ,[Location_Name]
          ,[LOCATION_geo]from [MYDB].[dbo].[StoreLocations]
        where [LOCATION_geo].STDistance(@point) <= 10000 …

我有以下查询：

DECLARE @application_number CHAR(8)= '37832904';
SELECT
    la.LEASE_NUMBER AS lease_number,
    la.[LEASE_APPLICATION] AS application_number,
    tnu.[FOLLOWUP_CODE] AS note_type_code -- catch codes not in codes table
FROM [dbo].[lease_applications] la
LEFT JOIN [dbo].tickler_notes_uniq tnu ON tnu.[ACCOUNT_NUMBER] = la.[ACCOUNT_NUMBER]
WHERE la.LEASE_APPLICATION = @application_number
      OR @application_number IS NULL;



SELECT
    la.LEASE_NUMBER AS lease_number,
    la.[LEASE_APPLICATION] AS application_number,
    tnu.[FOLLOWUP_CODE] AS note_type_code -- catch codes not in codes table
FROM [dbo].[lease_applications] la
LEFT JOIN [dbo].tickler_notes_uniq tnu ON tnu.[ACCOUNT_NUMBER] = la.[ACCOUNT_NUMBER]
WHERE la.LEASE_APPLICATION = @application_number; 

这两个查询之间的唯一区别是，我添加了检查该变量是否为NULL的检查。

这些查询的执行计划是：

您可以在此处找到图形化计划

问题是。为什么计划如此不同？

更新： …

我有两张看起来几乎相同的桌子.当我从其中任何一个中选择时,我的逻辑读取大约为8.000-10.000次读取.但当我内心加入它们时,我得到了大约380.000个逻辑读取.

我使用MS SQL 2012.

我遇到问题的查询如下所示:

SELECT ac.ID AS AccountID
    ,ab.Balance
    ,abc.BalanceInAccountCurrency
FROM dbo.Dates d
INNER JOIN dbo.Accounts ac ON d.[Date] BETWEEN ac.CreationDate AND ac.ClosureDate
INNER JOIN dbo.AccountBalances ab ON ab.AccountID  = ac.ID AND d.[Date] BETWEEN ab.CreationDate  AND ab.ClosureDate
INNER JOIN dbo.AccountBalancesInAccountCurrency abc ON abc.AccountID = ac.ID AND d.[Date] BETWEEN abc.CreationDate AND abc.ClosureDate
WHERE d.[Date] = DATEFROMPARTS(2017,06,20);

当我只加入AccountBalances时:

SELECT ac.ID AS AccountID
      ,ab.Balance
FROM dbo.Dates d
INNER JOIN dbo.Accounts ac ON d.[Date] BETWEEN ac.CreationDate AND ac.ClosureDate
INNER JOIN dbo.AccountBalances ab ON …

我们在开发过程中遇到了一个奇怪的问题，正在寻找有关SELECT INTO临时表上的自死锁问题的解释。

我们有一个例程将一些相当复杂的 JSON 文档转换为表格形式。我们目前正在使用 来完成此任务OPENJSON，通常效果很好。

这种转变是在触发器的背景下发生的。当向表中插入一行或多行时，会生成一组 JSON 文档，将其存储在单个变量中，并传递到以下例程中。它看起来像这样：

SELECT 
a.[ID],
b.[Some stuff here...]
INTO #MyTempTable
FROM OPENJSON(@MyJSONDocuments)
WITH (
    ID VARCHAR(40),
    nestedDocument NVARCHAR(MAX) AS JSON) a
CROSS APPLY OPENJSON(nestedDocument ,'$') b

当我们在 SSMS 中运行它时，它工作得很好。临时表已生成并填充，没有问题。当我们将其移至触发器并仅将一行插入基础表（即@MyJSONDocuments单个文档的数组）时，它也可以正常工作。当我们插入两行或更多行，并且@MyJSONDocuments数组中包含多个文档时，我们会遇到可怕的情况：

Transaction (Process ID x) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

当我们将SELECT INTO语句包装在 SSMS 中的 aBEGIN TRAN / COMMIT …

如果两个事务尝试同时修改同一行会发生什么？通常，一旦该行被修改，另一个事务就会等待，直到第一个事务执行提交或回滚。但是，如果他们完全在同一时刻发送更新请求怎么办？