none
困扰多时的查询语句超时问题 RRS feed

  • 问题

  • 一句select语句,逻辑上一点都不复杂,4-5个表连接,还使用了一些自定义函数。在ASP.net中调用,多数时间都很正常。但是经过一段不确定的时间使用后,就会出现调用超时错误,而且并非所有调用者都出问题,仅仅是其中一个表的一个筛选ID(业务中的部门ID)为特定值时发生,也就是说只有这个部门调用才会超时;

    令人无法想通的是,当发生超时时,在管理器中运行这个select语句,参数写死(出问题的部门ID),完全没有任何问题;

    还有更绝的!在管理器中运行这个select语句后,asp.net中的超时问题完全解决!实在想不通!

    2012年11月6日 5:46

答案

  • 建下面的INDEX看看,

    /****** Object:  Index [NonClusteredIndex-20121122-135301]    Script Date: 11/22/2012 1:54:25 PM ******/
    CREATE NONCLUSTERED INDEX [NonClusteredIndex-20121122-135301] ON [dbo].[SYS_RestWare]
    (
     [uRest] ASC,
     [uWare] ASC,
     [nQTYHigh] ASC,
     [nQTYLow] ASC,
     [nMinApplyQTY] ASC
    )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
    GO

    CREATE NONCLUSTERED INDEX [NonClusteredIndex-20121122-135301SYS_RestWare] ON [dbo].[SYS_WareProvider]
    (--uWare,uSerial,uProvider,nOrderKey
     [uWare] ASC,
     [uSerial] ASC,
     [uProvider] ASC,
     [nOrderKey] ASC
    )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
    GO

    CREATE NONCLUSTERED INDEX [NonClusteredIndex-20121122-135301SYS_WareProviderRest] ON [dbo].[SYS_WareProviderRest]
    (--uWare,uSerial,uProvider,nOrderKey
     [uRest] ASC,
     [uWareProvider] ASC
    )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
    GO


    Please click the Mark as Answer button if a post solves your problem!


    2012年11月22日 5:28
  • 我找到原因了,是索引的问题;


    大其心,可容天下之物; 虚其心,可受天下之善;

    2012年11月25日 6:18

全部回复

  • 参数写死,是一个确定值,查夜优化器可以选择确定的执行计划,所属执行计划不一定使用和参数是一样的(你可以对比计划执行计划来确定)

    至于执行一次可以解决超时问题,这个一方面可能是缓存,执行一次之后,数据已经缓存到内存了,而未执行之前的,需要的一些数据可能不在缓存,需要从磁盘加载,这样花费的时间多一些,另外,也有可能是执行计划已经缓存了,减少了编译的时间,你可以通过 SET STATISTICS IO ON;SET STATISTICS TIME ON; 来查看执行的 I/O, 编译的执行时间

    2012年11月6日 7:53
  • 我认为不是缓存的关系,因为重启sql server也能解决问题,这就和缓存无关了!

    而且在管理器中运行这个select语句用时不超过1秒,而asp.net里面是超时,至少30秒以上才会超时吧,编译不可能要那么多时间啊!

    2012年11月6日 9:06
  • 不奇怪,缓存只是其中的一种可能。你可以在asp.net代码中连续执行2次相同的代码,看一下2次执行的速度是否同意慢,来判断是否是数据或者执行计划的缓存问题。
    根据你上面的阐述,很有可能是执行计划造成的。
    你的asp.net里T-SQL估计是关系引擎在生成计划的时候无法嗅探到具体的参数值生成不佳的计划造成的。

    如果你是SQL SERVER为 2005或之后,建议你在你的ASP.NET中的T-SQL语句后面加上option(recompile) 来试一下是否会变快, 假设你的T-SQL为select * from tb1 where col1 = @p,则改为最下面的。

    select * from tb1 where col1 = @p option(recompile)

    当然最好拿你执行的快的时候跟慢到时候的执行计划发上来。

    2012年11月6日 12:00
  • Sounds parameter sniffing to me. By the way, what are sql connection settings on client side? We found that query maybe slow if client set arithabort on.
    2012年11月6日 14:19
  • 重新编译执行计划就可以解决吗?

    关注一下  


    给我写信: QQ我:点击这里给我发消息

    2012年11月6日 15:05
  • 重新编译执行的目的就是解决参数嗅探问题。但会牺牲掉计划的重用。
    2012年11月6日 15:07
  • There's better way then recompile to handle parameter sniffing.
    2012年11月6日 15:34
  • 据我所知还有一个OPTIMIZE FOR,不知道是否还有其他的选项。不过假如对于那个特定部门ID使用OPTIMIZE FOR的话,那对于其他的非特定部门ID不知道是否会产生影响。
    2012年11月6日 16:14
  • Replacing parameters with local variables is another option.
    2012年11月6日 16:25
  • 已经在相关语句中加上了 option(recompile),要过一段时间,看看还会不会出现超时


    • 已编辑 ninax 2012年11月7日 1:41
    2012年11月7日 1:40
  • 你可以尝试在函数中创建一个变量,然后这个变量的值=参数的值,操作的时候使用变量的值,这样的执行计划不会是最好的,但是应该不会出现超时的状况。
    2012年11月8日 1:33
  • 你可以尝试在函数中创建一个变量,然后这个变量的值=参数的值,操作的时候使用变量的值,这样的执行计划不会是最好的,但是应该不会出现超时的状况。

    这个是什么道理呢?
    2012年11月9日 1:26
  • 道理跟你在查询器中直接用参数值查询一个样,这个时候参数的值在编译器编译的时候是确定的,这样关系引擎能根据具体的参数值跟statistics选择较好的计划。
    2012年11月9日 1:29
  • 已经在相关语句中加上了 option(recompile),要过一段时间,看看还会不会出现超时



    今天,老问题又出现了。虽然已经加上了option(recompile),但是还是不能解决这个问题!
    2012年11月16日 5:26
  • 你可以尝试在函数中创建一个变量,然后这个变量的值=参数的值,操作的时候使用变量的值,这样的执行计划不会是最好的,但是应该不会出现超时的状况。

    我会再试试这个办法,然后看一段时间等待结果……
    2012年11月16日 5:28
  • 其实你没有必要过一段时间再等待结果,你可以立马测试,立马给出结果,如果有性能问题,就给相关的PLAN跟 io 的statistics,否则你能确定过段时间出问题的还是原来的语句吗?

    如果你能确定,那你可以给出相关的出问题的T-SQL语句跟计划,我们可以仔细的给你分析。



    Please click the Mark as Answer button if a post solves your problem!





    2012年11月16日 5:42
  • 现在没有任何性能问题啊?

    从程序之外的任何地方运行这个sql语句都没碰到过性能问题,即使程序运行时超时,外面运行也是正常的

    不知道如何去测试


    • 已编辑 ninax 2012年11月16日 5:56
    2012年11月16日 5:55
  • 现在没有任何性能问题啊?

    从程序之外的任何地方运行这个sql语句都没碰到过性能问题

    不知道如何去测试

    1,你的意思是说,平时这个语句都没有性能问题,只是偶尔会出现,是这样吗?

    2,你是怎么判断现在又出问题超时问题的语句就是原来对其写法调整过的语句?  而不是其他新出问题的语句?



    Please click the Mark as Answer button if a post solves your problem!

    2012年11月16日 6:07
  • 1.是这样的

    2.在vs里单步执行,确认

    2012年11月16日 6:12
  • 1.是这样的

    2.在vs里单步执行,确认

    如果每次调试都同样的参数值,每次在vs里单步执行都超时,还是偶尔超时?  也就是你能否再次调试那个超时的T-SQL语句,并且让它再次超时?

    .

    目前最简单的方法就是增加commandTimeout的值,默认为30, 你可以设置为100,或者更大的值,如果你想从根本上解决问题。

    必须给出T-SQL语句,超时时候的参数值,及其相关的计划。

    Please click the Mark as Answer button if a post solves your problem!




    2012年11月16日 6:21
  • 超时和是否调试没有关系,不管是运行还是调试,都是偶尔超时,但是一旦发生超时,如果不采取相关行动,他就始终会在程序里超时,但也仅针对这个特定的查询ID超时,而其他ID不超时。上面说的相关行动就是重启sql server或者在外部运行超时的sql语句。

    增加commandTimeout的值也试过,加到过90,依然超时。

    具体语句是这样的

    declare @RestID uniqueidentifier, @AppSerial uniqueidentifier, @Category uniqueidentifier
    set @RestID='16fff8bf-bce9-413e-bd7e-53447675fd4d'
    set @AppSerial='5ADE73CA-BD1C-464F-8A15-5845FB3FCF9E'
    set @Category='5C5E5D5F-1252-4FC9-A7B1-5FC3AD6CD37F'

    SELECT   SYS_CodeWare.uSerial, dbo.fn_getStoLastDayQTY(SYS_CodeWare.uSerial, dbo.fn_SYS_getMainStorage(@RestID))
                    AS LastDayQTY, dbo.fn_getStorageQTY(SYS_CodeWare.uSerial, dbo.fn_SYS_getMainStorage(@RestID))
                    AS StorageQTY, dbo.fn_getOnWayQTY(SYS_CodeWare.uSerial, dbo.fn_SYS_getMainStorage(@RestID)) AS OnWayQTY,
                    dbo.fn_getTodayUsedQTY(SYS_CodeWare.uSerial, dbo.fn_SYS_getMainStorage(@RestID)) AS TodayUsedQTY,
                    dbo.fn_getStoAndOnwayQTY(SYS_CodeWare.uSerial, dbo.fn_SYS_getMainStorage(@RestID)) AS StoAndOnwayQTY,
                    dbo.fn_CalcQTY(SYS_CodeWare.uSerial, dbo.fn_SYS_getMainStorage(@RestID)) AS CalcQTY,
                    dbo.fn_getDefaultProvider(@RestID, SYS_CodeWare.uSerial) AS DefaultProvider, Pur_PurchaseApplyDetail.nApplyQTY,
                    Pur_PurchaseApplyDetail.cApplyRemark, SYS_CodeWare.cWareNumber, SYS_CodeWare.cWareName,
                    SYS_CodeWare.cMnemonicCode, SYS_CodeWare.cUnit, Pur_PurchaseApplyDetail.uSerial AS AppDetailSerial,
                    SYS_RestWare.nQTYHigh, SYS_RestWare.nQTYLow, SYS_RestWare.nMinApplyQTY,
                    Pur_PurchaseApplyDetail.dModifyDate, Pur_PurchaseApplyDetail.nActualityQTY, Pur_PurchaseApplyDetail.bPCAudit,
                    Pur_PurchaseApplyDetail.dPCAuditDate, Pur_PurchaseApplyDetail.uPCAuditor,
                    Pur_PurchaseApplyDetail.cPCAuditRemark, Pur_PurchaseApplyDetail.uPCAudit,
                    Pur_PurchaseApplyDetail.uProvider
    FROM      SYS_RestWare INNER JOIN
                    SYS_CodeWare INNER JOIN
                    SYS_CodeWare AS 大类 ON SYS_CodeWare.uCategory = 大类.uSerial ON
                    SYS_RestWare.uWare = SYS_CodeWare.uSerial LEFT OUTER JOIN
                    Pur_PurchaseApply INNER JOIN
                    Pur_PurchaseApplyDetail ON Pur_PurchaseApply.uSerial = Pur_PurchaseApplyDetail.uPurchaseApply AND
                    Pur_PurchaseApply.uSerial = @AppSerial ON SYS_CodeWare.uSerial = Pur_PurchaseApplyDetail.uWare
    WHERE   (SYS_CodeWare.bAudit = 1) AND (SYS_CodeWare.bDisabled = 0) AND (SYS_CodeWare.bActived = 1) AND
                    (SYS_CodeWare.bPurchase = 1) AND (SYS_CodeWare.bCategoryWare = 1) AND
                    (SYS_CodeWare.uCategory = @Category) AND (SYS_RestWare.uRest = @RestID)
    ORDER BY 大类.nfOrderKey, SYS_CodeWare.nfOrderKey, SYS_CodeWare.cWareName

    这个是在外部运行的,在程序里的就是去掉前面那些赋值的语句的select

    关键是@RestID,就只有这个RestID会出现超时,其他的都不会。我不知道如何在程序发生超时是得到它的执行计划,因为在管理器中一运行就不超时了!

    2012年11月16日 8:14
  • 你好,这个问题我在ORACALE技术嘉年华大会上听嘉宾提到过类似的问题,就是说系统其它用户操作都很正常,唯独某个特定用户一段时间后系统就超时,最终问题在于索引,请检查下索引是否有重复列引用在多个索引中,根据用户id 的统计信息,有可能个别用户产生了其它执行计划,并且碎片也是要关注的地方。
    2012年11月16日 12:30
  • 我碰到过一回,查到最后发现索引问题,我把SQL语句强制指定索引,定期维护索引,后来一直没出现

    More: blog.csdn.net/happyflystone

    2012年11月16日 15:14
  • 你好,这个问题我在ORACALE技术嘉年华大会上听嘉宾提到过类似的问题,就是说系统其它用户操作都很正常,唯独某个特定用户一段时间后系统就超时,最终问题在于索引,请检查下索引是否有重复列引用在多个索引中,根据用户id 的统计信息,有可能个别用户产生了其它执行计划,并且碎片也是要关注的地方。
    我碰到过一回,查到最后发现索引问题,我把SQL语句强制指定索引,定期维护索引,后来一直没出现

    More: blog.csdn.net/happyflystone

    碰到这种问题我第一检查的就是索引,而且特意为此查询做了优化,也没有发觉有不同;在发生超时时,重新整理生成索引以消除碎片,但是没有效果,依然超时。

    • 已编辑 ninax 2012年11月17日 1:05
    2012年11月17日 1:03
  • 我也遇到相似的问题,系统调用一个存储过程“A”;系统刚上线的时候,一切正常;大概运行6个月;有时候调用A很正常;有时候系统提示超时;

    慢慢的,我发现是其中一个参数的问题,如果不传这个参数;一切正常;如果传了此参数;大多数时候正常;

    在异常时, 如果我在本地调试,连接本地数据库;正常;连接服务器数据库;系统提示超时;

    过几天,同样的参数;又在本地调试,连接远程数据库;正常(偶而)

    存储过程如下:

    SET ANSI_NULLS ON
    GO
    SET QUOTED_IDENTIFIER ON
    GO
    ALTER PROC [dbo].[TC_GetTreaDetails]
        (
          @StoreTreasuryId UNIQUEIDENTIFIER ,
          @ProductCode VARCHAR(50) ,
          @IIndex TINYINT ,
          @STime DATETIME ,
          @ETime DATETIME
        )
    AS 
        SET NOCOUNT ON ;
        SET @ETime = CONVERT(DATE, @ETime)
        SET @STime = CONVERT(DATE, @STime)
        DECLARE @TreasuryName VARCHAR(50)
        SELECT  @TreasuryName = TreasuryName
        FROM    dbo.Ease_StoreTreasury
        WHERE   StoreTreasuryId = @StoreTreasuryId
        IF @TreasuryName IS NULL 
            RETURN ;
        SELECT  b.IIndex ,
                b.IPoing ,
                c.ProductCode ,
                c.ProductSP ,
                c.ProductWeight ,
                c.ProductMCode ,
                c.ProductName ,
                CONVERT(DATE, B.ITime) 'ITime'
        INTO    #TC1
        FROM    dbo.Ease_Tpro a
                INNER JOIN dbo.Ease_TproDetails b ON a.IID = b.IID
                INNER JOIN dbo.Ease_Product c ON a.ProductID = c.ProductID
        WHERE   a.StoreTreasuryId = @StoreTreasuryId
                AND c.ProductCode LIKE '' + @ProductCode + '%'
                AND a.STime BETWEEN @STime AND @ETime
                AND b.IPoing IS NOT NULL
        CREATE NONCLUSTERED INDEX IX_ITime_0 ON #TC1(IIndex)
    	
        IF @IIndex <> 255 
            DELETE  FROM #TC1
            WHERE   IIndex <> @IIndex
        ------------------------------------------------------------------------
        SELECT  @TreasuryName ,
                ProductMCode ,
                ProductCode ,
                ProductSP ,
                ProductWeight ,
                IPoing ,
                ITime ,
                CASE WHEN IIndex = 0 THEN '初始化'
                     WHEN IIndex = 1 THEN '物流入库'
                     WHEN IIndex = 2 THEN '物流出库'
                     WHEN IIndex = 3 THEN '配料'
                     WHEN IIndex = 4 THEN '收银交易'
                     WHEN IIndex = 5 THEN '冻结'
                     WHEN IIndex IS NULL THEN '未知交易'
                     ELSE '其它'
                END ,
                ProductName
        FROM    #TC1
        
        ------------------------------------------------------------------------
        DROP TABLE #TC1


    大其心,可容天下之物; 虚其心,可受天下之善;

    2012年11月17日 13:43
  • 超时和是否调试没有关系,不管是运行还是调试,都是偶尔超时,但是一旦发生超时,如果不采取相关行动,他就始终会在程序里超时,但也仅针对这个特定的查询ID超时,而其他ID不超时。上面说的相关行动就是重启sql server或者在外部运行超时的sql语句。

            关键是@RestID,就只有这个RestID会出现超时,其他的都不会。我不知道如何在程序发生超时是得到它的执行计划,因为在管理器中一运行就不超时了!

    超时和是否调试当然没有关系啦。你提到“针对这个特定的查询ID超时,而其他ID不超时”,我需要的就是这个特定的ID呢,因为你没有使用SQL trace等,如果你不在VS里单步调试,你怎么能确定就是某个特定的ID才会导致超时呢? 并且这也就是我说的没有必要过段时间来验证,而是可以立即去验证的原因。

    既然是特定的@RestID出问题,并且管理器中一运行就不超时了,那问题应该就不了,大不了硬来呗,把VS中的T-SQL代码用query-hint硬绑成跟管理器中的计划一样呗。不过为了找出真正的原因,我希望你能提供如下东西,分析一下真正的原因,以防止再有其他特殊的@RestID再次造成这样的异常。

    1),“我不知道如何在程序发生超时是得到它的执行计划”

    首先在你VS里的程序中添加如下代码,然后得到它的SPID,

       SqlCommand cmd = new SqlCommand(“ select @@spid”,con);
       spid= (Int32)cmd.ExecuteScalar();

    在运行至你超时的代码之前,打开SQL profiler,

        1在SQL profiler行过滤器中SPID设置为你在VS中取得上值。

        2选择show all events,在performance中选择 showplan all , showplan xml 跟showplan statistics profile

        3 把 CommandTimeout 设置为0, CommandTimeout = 0;

    上面设置完毕后执行VS中的代码,执行10分钟,

    如果已经执行完毕。

    用SQL profiler把 showplan all , showplan xml 跟showplan statistics profil的数据原封不动的贴上来。

    如果没有执行完毕,把 showplan all , showplan xml 贴上来,并且运行下面的语句,把结果集帖上来。

     select * from   [sys].[dm_os_waiting_tasks] where session_id=spid (此处的值为前面VS里得到的SPID)and blocking_session_id is not null

    2),fn_SYS_getMainStorage 跟fn_getDefaultProvider的内容(2个函数都用到了@RestID,我需要知道里面到底做了什么。)

    3),SYS_RestWare,SYS_CodeWare,Pur_PurchaseApply ,Pur_PurchaseApplyDetail 4个表的scheme(不仅要表的scheme,而且还要包含INDEX的scheme),你可以在SSMS中tool\option\SQL server object explorer\Scripting\table and view options\script indexes 设置为TRUE,这样你导出的时候就会包含INDEX的scheme.

    4), 你在管理器中需要运行如下代码,并且把把表头为 Rows Executes StmtText StmtId NodeId 。。。。。的那个结果集 ,跟消息那个TAB的如SQL Server parse and compile。。。相关统计信息完整的贴上来。

    注意,你需要运行2次下面的代码,一次用一般的@RestID,另一此为那个特殊在VS里超时的@RestID。并且把2次不同的结果集产生的记录条数发上来。

       set statistics profile on
       go
       set statistics io on
       go
         set statistics time on
       go

         --此处为你在管理器中运行的T-SQL语句。

      set statistics time off
       go
     set statistics io off
       go
     set statistics profile off
     go

    5), 需要下面4个结果集的值

     select @@version

    select count(*)  from SYS_RestWare

    select count(*)  from SYS_RestWare.uRest = @RestID -- 此为一般的不超时的@RestID

    select count(*)  from SYS_RestWare.uRest = @RestID--此为特殊的超时的@RestID



    Please click the Mark as Answer button if a post solves your problem!


    2012年11月19日 5:49
  • @lfofiug

    你可以把你几个表相关的scheme跟INDEX的scheme都发上来,来做进一步的分析。 



    Please click the Mark as Answer button if a post solves your problem!

    2012年11月19日 5:57
  • 1)现在没有发生超时,所以我得不到超时的执行计划,一般可能2星期左右会发生超时,要等发生了才能得到。而不超时的时候,每一种ID的计划都完全相同

    后面几条内容都准备好了,贴出来好像太长了,我压缩了一个包放在了网上:sql内容 ,请下载一下。


    • 已编辑 ninax 2012年11月20日 2:05
    2012年11月20日 2:04
  • 1)现在没有发生超时,所以我得不到超时的执行计划,一般可能2星期左右会发生超时,要等发生了才能得到。而不超时的时候,每一种ID的计划都完全相同

    后面几条内容都准备好了,贴出来好像太长了,我压缩了一个包放在了网上:sql内容 ,请下载一下。


    所以我上面才问你“如果每次调试都同样的参数值,每次在vs里单步执行都超时,还是偶尔超时?” ,如果你还是不能得到超时时候的计划的话,你给出的信息可能会有点问题,我暂且你看一下。

    既然这样的话,那很可能是你那个超时的T-SQL语句在执行的时候被其他的session blocked了,
    如果再次发现长时间无法执行完毕这样的情况,你可以用我上面提到的 select * from   [sys].[dm_os_waiting_tasks] where session_id=spid (此处的值为前面VS里得到的SPID)and blocking_session_id is not null 来检查。



    Please click the Mark as Answer button if a post solves your problem!



    2012年11月20日 2:10
  • 肯定没有被其他进程阻塞的情况,我检查过
    • 已编辑 ninax 2012年11月20日 2:22
    2012年11月20日 2:22
  • 你给的表格,能不能把 Rows Executes StmtText StmtId NodeId Parent PhysicalOp  等计划的列头给出来啊,有些数字我都对不上号啊。

    另外我建议你建以下三个INDEX,尤其是SYS_RestWare.uRest

    SYS_RestWare.uRest
    SYS_WareProviderRest.uRest
    SYS_Code.uSerial



    Please click the Mark as Answer button if a post solves your problem!



    2012年11月20日 2:40
  • 你给的表格,能不能把 Rows Executes StmtText StmtId NodeId Parent PhysicalOp  等计划的列头给出来啊,有些数字我都对不上号啊。

    另外我建议你建以下三个INDEX,尤其是SYS_RestWare.uRest

    SYS_RestWare.uRest
    SYS_WareProviderRest.uRest
    SYS_Code.uSerial


    表格头加上了,请那个文件重新下载一下。

    索引的话,sys_Code.uSerial就是主键,另两个uRest都有索引,但不是单独的,和另一些字段的组合索引,组合的不能用?

    2012年11月20日 5:14
  • 当然啦,uRest一定要放在第一位才会对你的那个例子有效!所以才让你再建新的INDEX。


    Please click the Mark as Answer button if a post solves your problem!

    2012年11月20日 5:16
  • 你给的表格,能不能把 Rows Executes StmtText StmtId NodeId Parent PhysicalOp  计划的列头给出来啊,有些数字我都对不上号啊。

    另外我建议你建以下三个INDEX,尤其是SYS_RestWare.uRest

    SYS_RestWare.uRest
    SYS_WareProviderRest.uRest
    SYS_Code.uSerial


    表格头加上了,请那个文件重新下载一下。

    索引的话,sys_Code.uSerial就是主键,另两个uRest都有索引,但不是单独的,和另一些字段的组合索引,组合的不能用?

    要你给出一个带表头的完整的执行计划很难,第一次表头漏了,现在给出的列少了很多,而且列头跟内容还对错了。。。。

    这个应该不难啊,如果在SSMS中,右键选择 copy with header ,黏贴;如果在SQL PROFILER,那全部选择,黏贴。,就行啦,



    Please click the Mark as Answer button if a post solves your problem!

    2012年11月20日 6:07
  • 我是用“将结果保存到文件”来保存执行结果的,如果列少了,那一定是微软的bug……

    现在我把结果输出为文本,然后复制黏贴了,请烦再下载看看是不是对。

    还有,我用excel打开看的话是对的很齐的


    • 已编辑 ninax 2012年11月22日 3:30
    2012年11月22日 3:26
  • 建下面的INDEX看看,

    /****** Object:  Index [NonClusteredIndex-20121122-135301]    Script Date: 11/22/2012 1:54:25 PM ******/
    CREATE NONCLUSTERED INDEX [NonClusteredIndex-20121122-135301] ON [dbo].[SYS_RestWare]
    (
     [uRest] ASC,
     [uWare] ASC,
     [nQTYHigh] ASC,
     [nQTYLow] ASC,
     [nMinApplyQTY] ASC
    )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
    GO

    CREATE NONCLUSTERED INDEX [NonClusteredIndex-20121122-135301SYS_RestWare] ON [dbo].[SYS_WareProvider]
    (--uWare,uSerial,uProvider,nOrderKey
     [uWare] ASC,
     [uSerial] ASC,
     [uProvider] ASC,
     [nOrderKey] ASC
    )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
    GO

    CREATE NONCLUSTERED INDEX [NonClusteredIndex-20121122-135301SYS_WareProviderRest] ON [dbo].[SYS_WareProviderRest]
    (--uWare,uSerial,uProvider,nOrderKey
     [uRest] ASC,
     [uWareProvider] ASC
    )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
    GO


    Please click the Mark as Answer button if a post solves your problem!


    2012年11月22日 5:28
  • 索引加上了,等过几个星期看看是否还会有超时

    谢谢!

    2012年11月22日 6:39
  • 我找到原因了,是索引的问题;


    大其心,可容天下之物; 虚其心,可受天下之善;

    2012年11月25日 6:18