SQL Server 2012从小表中删除非常慢
手机用户2502913375 发布于 2023-01-18 19:30我有一张711记录表.
这是表格:
USE [wynparts_aspdnsf]
GO
/****** Object: Table [dbo].[WR_SPL_PreCompiledLists] Script Date: 3/10/2014 5:06:36 PM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[WR_SPL_PreCompiledLists](
[Penta_Nbr] [numeric](15, 0) NOT NULL,
[ListType] [nvarchar](50) NOT NULL,
[ListData] [xml] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
有些ListData可能会变得很大.
我正在尝试运行如下DELETE语句:
DELETE FROM WR_SPL_PreCompiledLists WHERE Penta_Nbr = 48855
在较大的记录上执行此操作需要4分钟或更长时间.我的查询计划很简单,只有4个步骤.使用此命令仅删除3条记录.没有触发器或任何东西.
执行计划:
为什么这不会花不到一秒钟？我该怎么做才能让它更快？
UPDATE
我正在检查下面的答案,并收到了这个,我真的不明白.
TEXT session_id request_id start_time status command sql_handle statement_start_offset statement_end_offset plan_handle database_id user_id connection_id blocking_session_id wait_type wait_time last_wait_type wait_resource open_transaction_count open_resultset_count transaction_id context_info percent_complete estimated_completion_time cpu_time total_elapsed_time scheduler_id task_address reads writes logical_reads text_size language date_format date_first quoted_identifier arithabort ansi_null_dflt_on ansi_defaults ansi_warnings ansi_padding ansi_nulls concat_null_yields_null transaction_isolation_level lock_timeout deadlock_priority row_count prev_error nest_level granted_query_memory executing_managed_code group_id query_hash query_plan_hash ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------- ----------- ----------------------- ------------------------------ -------------------------------- ---------------------------------------------------------------------------------------------------------------------------------- ---------------------- -------------------- ---------------------------------------------------------------------------------------------------------------------------------- ----------- ----------- ------------------------------------ ------------------- ------------------------------------------------------------ ----------- ------------------------------------------------------------ ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------- -------------------- -------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ---------------- ------------------------- ----------- ------------------ ------------ ------------------ -------------------- -------------------- -------------------- ----------- -------------------------------------------------------------------------------------------------------------------------------- ----------- ---------- ----------------- ---------- ----------------- ------------- ------------- ------------ ---------- ----------------------- --------------------------- ------------ ----------------- -------------------- ----------- ----------- -------------------- ---------------------- ----------- ------------------ ------------------ SELECT sqltext.TEXT, req.* FROM sys.dm_exec_requests req CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS sqltext 59 0 2014-03-11 08:02:36.890 running SELECT 0x02000000BD1AA61696485297D5100F2547B979F25F10C2830000000000000000000000000000000000000000 0 -1 0x06000500BD1AA616F09E44FE0000000001000000000000000000000000000000000000000000000000000000 5 1 BAD34569-6E35-4945-8F9F-E1C46F3CF791 0 NULL 0 MISCELLANEOUS 0 1 19335541 0x 0 0 0 0 1 0x00000000C20ED498 0 0 0 2147483647 us_english mdy 7 1 1 1 0 1 1 1 1 2 -1 0 2 0 0 0 0 1 0x4AC3E94A42400E47 0xB94AAAF5F1DB9778 (@1 int)DELETE [WR_SPL_PreCompiledLists] WHERE [Penta_Nbr]=@1 62 0 2014-03-11 08:02:12.820 suspended DELETE 0x0200000015ABE50126BD79096518C75D9209AA1B9DC3DBF60000000000000000000000000000000000000000 16 -1 0x0600050015ABE501409D44FE0000000001000000000000000000000000000000000000000000000000000000 5 1 70353187-2595-4D08-9F9C-E608E6FACEA6 0 PAGEIOLATCH_EX 13 PAGEIOLATCH_EX 5:1:1047189 2 1 19335431 0x 0 0 156 24064 1 0x00000000C20ED0C8 4863 14 20863 2147483647 us_english mdy 7 1 1 1 0 1 1 1 1 2 -1 0 0 0 0 0 0 1 0x418A7DF29AF7A9A0 0x9230291B34359B04 (2 row(s) affected)
更新2
我使用以下命令并确定没有其他表具有对此表的外键引用: SELECT OBJECT_NAME(R.CONSTID) FROM SYSREFERENCES R WHERE R.RKEYID = OBJECT_ID('WR_SPL_PreCompiledLists')
解析度
我在Penta_Nbr和ListType的主键上有一个索引(它是一个多字段主键).事实证明,这个索引对于仅通过Penta_Nbr删除记录没有用.在Penta_Nbr上创建另一个索引修复了我的性能问题.此删除操作现在不到1秒.
-
这可能是由多种因素造成的.主要的两个是锁和等待.
开始执行命令,然后在新的查询窗口中执行以下查询:
SELECT sqltext.TEXT, req.* FROM sys.dm_exec_requests req CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS sqltext
这将返回当前正在运行的查询的列表(这是稍微修改的Pinal Dave查询).
接下来,查看第一列并选择包含查询的行.以下是您需要查看的一些列:
status:如果它正在运行,那很好.如果它被暂停,那么看看其余的
blocking_session_id:如果另一个会话/查询阻止您执行(锁定问题),则此列将包含Id.您可以使用它
EXEC sp_who2来获取有关阻止会话的图片.wait_type:如果没有可用的阻塞会话,则查询正在等待某事.本专栏将告诉您它是什么.有关等待类型的更多详细信息,请访问此处
wait_time:如果这个问题太严重了.该值以毫秒为单位.等待时间很短,特别是在PAGEIOLATCH等待类型(访问物理文件).
last_wait_type:指示最后一个等待类型是否不同.这对于分析查询是否因同一原因而被阻止运行非常有帮助.
您可以浏览其余列并尝试了解这些值.这是一个完整的描述.
如果存在阻塞会话,只需尝试使用以下命令将其终止:
KILL blocking_session_id --replace by the actual Id, usually > 50
编辑:
我能够从您发回的结果中提取相关的行/列:
TEXT session_id status command blocking_session_id wait_type wait_time last_wait_type wait_resource reads writes logical_reads ----------------------------------------------------------------- ---------- ------------ ---------- ------------------- ------------------- ----------- ---------------- ---------------- -------- -------- ---------------- (@1 int)DELETE [WR_SPL_PreCompiledLists] WHERE [Penta_Nbr]=@1 62 suspended DELETE 0 PAGEIOLATCH_EX 13 PAGEIOLATCH_EX 5:1:1047189 4863 14 20863
如果你按照我之前提到的分析:
该状态是
suspended该blocking_session_id是
0,这意味着没有锁问题该wait_type是
PAGEIOLATCH_EX.您的查询正在等待从物理磁盘上读取数据,然后在其上运行过滤器(WHERE Penta_Nbr = 48855).该WAIT_TIME(每资源)为低,这意味着你的数据在很多页(总运行时间/ WAIT_TIME)分开.
该last_wait_type是相同的- >那是你的问题!
什么是
PAGEIOLATCH_EX？我从RedGate那里找到了一篇很好的文章:
http://documentation.red-gate.com/display/SM4/PAGEIOLATCH_EX
我真的怀疑表中的XML数据很大.我的建议是
Penta_Nbr如果您还没有索引,请创建索引运行磁盘碎片整理或文件碎片整理
2023-01-18 19:32 回答
时尚摄影师阿强_331
京公网安备 11010802041100号