none
关于insert和update异常缓慢的问题 RRS feed

  • 问题

  • 通过监控日志发现有部分非常简单的insert和update语句执行时间非常长。例如:

    XXX 数据量200万,有200列!!,索引有40多个!!,并且部分索引的include非常多。GUID是主键索引

    经测试单独执行非常快,我也不清楚当时这行数据执行为什么会这么缓慢

    --执行了15秒

    update XXX set [CollectionState] = 3, [BuyerPayAmount] = 278.00, [ModifyGuid] = '9624181f-1d57-4a1b-9435-3ba0560d8d94', [ModifyBy] = 'dsd', [ModifyDate] = '2019/12/24 15:05:04', [ModifyAccount] = 'hk016' where [Guid] = '9de44f9f-69cd-44cd-8482-59ea9e935971'

    --执行了20秒

    insert into xxx (...) values (...);

    我想请教的是如果排除锁表的情况下,如果一个表的列和索引都非常多,会不会发生严重的行迁移现象,导致执行时间异常缓慢,案例中的情况还有什么情况会导致执行非常慢。

    2019年12月25日 5:27

答案

全部回复

  • Depends on which column you use as clustered index, guid is not good clustered index candidate. 
    2019年12月25日 18:32
  • Depends on which column you use as clustered index, guid is not good clustered index candidate. 
         GUID is PK,but its NONCLUSTERED
    2019年12月26日 1:42
  • Hi database_noob,

    我建议你用执行计划看下,语句执行这么长时间,时间都花在哪里?你可以参考以下这篇文章来看执行计划。 请参考SQL Server执行计划 解析。

    还有建议删除一些不用的非聚集索引来节省资源,减少开销,提高性能。 你可以运行以下语句来查看索引的使用情况。 Index id>2表示非聚集索引。

    select i.name, object_name(s.object_id) tblname,s.database_id,s.object_id,s.index_id,s.user_seeks,s.user_scans,s.user_lookups,s.user_updates
    from sys.dm_db_index_usage_stats s
           inner join sys.indexes i
                  on i.object_id = s.object_id and i.index_id = s.index_id
    where s.database_id = db_id() --and i.object_id = object_id(N'dbo.TestTable', N'U')
             and object_name(s.object_id) not like 'sys%'
    order by s.user_updates desc


    如果User_seeks,user_scans,user_lookups非常低,但是user_updates非常高,这意味着索引占用了过多的系统资源,则需要删除它。

    Best regards,
    Cathy 


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to  MSDN Support, feel free to contact MSDNFSF@microsoft.com

    2019年12月26日 3:14
  • 既然你自己已经验证了单独执行快,那么就是锁的问题了
    2019年12月26日 5:47
  • 既然你自己已经验证了单独执行快,那么就是锁的问题了

         查询DMV:dm_db_index_operational_stats  的XXX表分析出确实有严重的行锁现象,只要由一个ModifyDate上面的索引导致,下面是具体的数值

       row_lock_count = 615735614

       row_lock_wait_count  =  12002

       row_lock_wait_in_ms =   152486392

    但是语句非常简单,按照row_lock_wait_in_ms/row_lock_wait_count 算出平均每次等待都要12秒左右的时间

       update XXX set  ...., [ModifyDate] = '2019/12/24 15:05:04'  where [Guid] = '9de44f9f-69cd-44cd-8482-59ea9e935971'

    对于我来说这个ModifyDate索引因业务需要不能去除,想了解下这种简单的语句会产生如果多的锁,如何避免出现这种情况。

        

    2019年12月26日 8:35
  • Did you see blocking? Maybe update statement is waiting for lock.
    2019年12月26日 22:16