前陣子我集中對一套業(yè)務系統(tǒng)做了幾輪數據庫巡檢翻筆記本時發(fā)現當天用到的SQL Server命令其實可以組成一份相當完整的排查清單。從會話狀態(tài)到索引碎片從等待統(tǒng)計到死鎖現場基本覆蓋了日常運維里最常遇到的那幾類問題。這篇就把當天真正動手敲過、并且驗證有效的命令逐條寫出來每條附帶我當時的判斷邏輯和踩過的坑想直接拿去用的朋友照著復制即可。1. 這批命令的整理背景慢查詢和阻塞告警逼出來的清單那段時間生產環(huán)境頻繁報出兩類問題一是某些頁面接口響應突然變慢二是早上九點半左右偶發(fā)超時告警。我最初也是靠經驗逐個排查執(zhí)行計劃、索引、鎖挨個看效率不高。后面實在覺得不行干脆把高頻用到的排查命令統(tǒng)一整理成一份腳本文件命名成“巡檢腳本.sql”塞進常用工具目錄里。之后只要系統(tǒng)再報警我第一件事就是跑一遍這套命令從全局指標到細節(jié)語句一條龍過完基本十分鐘內能定位到方向。這套命令挑選的標準很簡單一條命令對應一類常見問題。比如連接數異常對應會話視圖慢查詢對應語句統(tǒng)計鎖等待對應阻塞查詢空間緊張對應數據庫文件大小。每一條都要能直接給出可判斷的指標而不是給一堆原始數據讓讀者自己猜。適用版本方面我本地的環(huán)境是SQL Server 2019和2022下面寫的系統(tǒng)視圖和命令在2016及以上版本都可以跑老版本2008 R2部分視圖字段略有差異使用時要留意。另外提一句我整理的這些命令多數是只讀查詢不會修改數據跑起來相對安全。但涉及DBCC、重建索引和備份那幾條必須在維護窗口或低峰期操作千萬別在業(yè)務高峰期直接對生產庫執(zhí)行重建索引這個后面細說。2. 數據庫健康巡檢命令先看整體狀態(tài)再追細節(jié)很多朋友排查問題時習慣直接揪著某條慢SQL去優(yōu)化我的習慣是反過來——先看一眼服務器和數據庫整體狀態(tài)。因為很多時候單個語句慢只是表象背后是連接數堆積或日志文件膨脹在拖累全局。開場先跑這幾條相當于給數據庫做個體檢。2.1 會話與連接狀態(tài)快速判斷當前有沒有“堵車”判斷數據庫“堵不堵”第一條命令是查當前會話和連接數SELECT session_id, status, login_name, host_name, program_name, login_time, last_request_start_time, last_request_end_time FROM sys.dm_exec_sessions WHERE is_user_process 1 ORDER BY last_request_start_time;這條命令會把所有用戶會話列出來我主要看兩件事一是有沒有大量會話長時間處于running或sleeping狀態(tài)二是last_request_start_time和last_request_end_time間隔是不是異常大。如果某個會話的開始時間和結束時間差了好幾秒甚至幾十秒大概率這個會話對應的請求出現了阻塞或者執(zhí)行計劃有問題。再配合查詢具體請求狀態(tài)SELECT session_id, start_time, status, command, wait_type, wait_time, blocking_session_id FROM sys.dm_exec_requests WHERE session_id 50;wait_type是重點常見的有LCK_M_S共享鎖等待、LCK_M_X排他鎖等待、PAGEIOLATCH_SH磁盤IO等待、CXPACKET并行查詢等待?？吹絯ait_type是鎖等待時就得繼續(xù)查阻塞鏈這個我放到后面專門講?？吹絇AGEIOLATCH_SH這類IO等待占大頭就要考慮是不是內存不足或磁盤性能瓶頸而不是盲目加索引。2.2 數據庫文件和日志狀態(tài)預防磁盤被寫滿巡檢時必須看的還有數據庫文件大小和剩余空間。生產環(huán)境最常見的事故之一就是日志文件瘋狂增長把磁盤塞滿導致數據庫進入只讀狀態(tài)。我用的語句是SELECT db.name AS database_name, mf.type_desc AS file_type, mf.name AS logical_name, mf.physical_name, mf.size * 8 / 1024 AS size_mb, mf.growth * 8 / 1024 AS growth_mb, mf.is_percent_growth, CAST(mf.size * 8.0 / 1024 / 1024 AS DECIMAL(10,2)) AS size_gb, CAST(FILEPROPERTY(mf.name, SpaceUsed) * 8.0 / 1024 / 1024 AS DECIMAL(10,2)) AS used_gb FROM sys.databases db JOIN sys.master_files mf ON db.database_id mf.database_id WHERE db.database_id 4 ORDER BY size_gb DESC;這里算出每個文件的邏輯名、物理路徑、總大小、已用空間一眼看到剩余空間。有個容易忽略的點growth字段如果是按百分比增長大型數據庫擴容時可能瞬間分配很大空間引起IO抖動。建議核心業(yè)務庫的數據文件和日志文件都改成固定大小增長比如每次增長2GB或4GB避免頻繁自動擴張帶來的性能波動。2.3 活動事務檢查清理日志失敗的常見原因還有一條我經常用的DBCC命令DBCC OPENTRAN(數據庫名);這條的作用是查看當前數據庫中最早的活動事務。如果日志備份一直失敗或者日志文件無法收縮多半是有長事務沒有提交。跑完這條如果看到類似“最早的活動事務”信息就能定位到具體的事務開始時間和SPID。記得有一次某張業(yè)務表被一條未提交的UPDATE鎖住外部程序一直在等鎖日志也越漲越大就是靠DBCC OPENTRAN找到事務源頭然后和業(yè)務側確認后手動回滾才解除的。3. 性能排查命令從等待統(tǒng)計中揪出真正的瓶頸數據庫變慢往往不是單一語句的問題而是某個環(huán)節(jié)成為了瓶頸。我比較依賴等待統(tǒng)計來定位因為等待統(tǒng)計是SQL Server自己記錄的“卡在哪”的數據比我們猜要準確得多。有個很形象的類比醫(yī)院急診室護士會記錄每個病人的等待原因和等待時間等待統(tǒng)計就是數據庫的“候診記錄表”。3.1 等待類型匯總先看整體等待分布SELECT wait_type, wait_time_ms / 1000.0 AS wait_time_sec, waiting_tasks_count, signal_wait_time_ms / 1000.0 AS signal_wait_sec, (wait_time_ms - signal_wait_time_ms) / 1000.0 AS resource_wait_sec, wait_time_ms * 100.0 / SUM(wait_time_ms) OVER() AS wait_percent FROM sys.dm_os_wait_stats WHERE wait_type NOT IN ( BROKER_EVENTHANDLER, BROKER_RECEIVE_WAITFOR, BROKER_TASK_STOP, BROKER_TO_FLUSH, BROKER_TRANSMITTER, CHECKPOINT_QUEUE, CHKPT, CLR_AUTO_EVENT, CLR_MANUAL_EVENT, CLR_SEMAPHORE, DBMIRROR_DBM_EVENT, DBMIRROR_EVENTS_QUEUE, DBMIRROR_WORKER_QUEUE, DBMIRRORING_CMD, DIRTY_PAGE_SCAN, DISPATCHER_QUEUE_SEMAPHORE, EXECSYNC, FSAGENT, FT_IFTS_SCHEDULER_IDLE_WAIT, FT_IFTSHC_MUTEX, HADR_CLUSAPI_CALL, HADR_NOTIFICATION_DEQUEUE, HADR_TIMER_TASK, HADR_WORK_QUEUE, KSOURCE_WAKEUP, LAZYWRITER_SLEEP, LOGMGR_QUEUE, MEMORY_ALLOCATION_EXT, ON_TASK_WAIT, PREEMPTIVE_OS_LIBRARYOPS, PREEMPTIVE_OS_COUNTOPS, PREEMPTIVE_OS_CRYPTOPS, PREEMPTIVE_OS_QUERYMDN, PREEMPTIVE_OS_TXITPROC, REQUEST_FOR_DEADLOCK_SEARCH, RESOURCE_QUEUE, SLEEP_BPOOL, SLEEP_BUFFERPOOL, SLEEP_DBSTARTUP, SLEEP_DCOMSTARTUP, SLEEP_MASTERDBREADY, SLEEP_MASTERMDREADY, SLEEP_MASTERUPGRADED, SLEEP_MSDBSTARTUP, SLEEP_SYSTEMTASK, SLEEP_TASK, SLEEP_TEMPDBSTARTUP, SNI_HTTP_ACCEPT, SP_SERVER_DIAGNOSTICS_SLEEP, SQLTRACE_BUFFER_FLUSH, SQLTRACE_INCREMENTAL_FLUSH, SQLTRACE_WAIT_ENTRIES, WAIT_FOR_RESULTS, WAITFOR, WAITFOR_TASKSHUTDOWN, WHILE_TEMP, XE_BUFFERMGR_ALLOC, XE_DISPATCHER_WAIT, XE_DISPATCHER_JOIN, XE_MODULEMGR_CALLNOTIFICATION, XE_LOGGER_TICK, XE_TIMER_EVENT ) AND waiting_tasks_count 0 ORDER BY wait_time_ms DESC;這里我排除了大量自循環(huán)等待類型——比如SLEEP_TASK、WAITFOR這類屬于空閑等待如果不過濾掉它們會占掉大部分統(tǒng)計容易誤導判斷?？唇Y果時我主要關注三塊排名靠前的是PAGEIOLATCH_*說明磁盤IO壓力大LCK_*說明存在鎖阻塞CXPACKET說明并行查詢等待較多。每種等待的應對思路完全不同不能盲目加索引或加內存。3.2 最耗時查詢排行直接找出“罪魁禍首”等待統(tǒng)計確認了方向后下一步就是把最慢的語句找出來。我用的是執(zhí)行計劃緩存中的統(tǒng)計信息SELECT TOP 10 qs.total_elapsed_time / qs.execution_count AS avg_elapsed_ms, qs.total_worker_time / qs.execution_count AS avg_cpu_ms, qs.total_logical_reads / qs.execution_count AS avg_logical_reads, qs.execution_count, qs.total_elapsed_time, qs.total_logical_reads, qs.creation_time, SUBSTRING(st.text, (qs.statement_start_offset / 2) 1, ((CASE qs.statement_end_offset WHEN -1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END - qs.statement_start_offset) / 2) 1) AS statement_text, qs.plan_handle FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st ORDER BY avg_elapsed_ms DESC;這條能列出平均耗時最長、平均CPU最多、邏輯讀取最多的語句。我通常按平均邏輯讀取排序再看耗時因為邏輯讀太高的語句往往意味著全表掃描或索引缺失。得到plan_handle之后還可以進一步查看該語句的完整執(zhí)行計劃SELECT query_plan FROM sys.dm_exec_query_plan(0x06000600...); -- 填入實際的 plan_handle注意query_plan返回的是XML格式在SSMS中點擊即可看到圖形化執(zhí)行計劃。這里有個隱藏坑執(zhí)行計劃緩存是動態(tài)的實例重啟或內存壓力大時舊的統(tǒng)計會被清掉。所以如果系統(tǒng)已經重啟過或者跑了很長時間sys.dm_exec_query_stats里只能看到緩存中的語句。想完整記錄歷史語句還是得提前開擴展事件或第三方監(jiān)控不能只靠這一個視圖。3.3 缺失索引提示參考但不要無腦加SQL Server提供一個很實用的動態(tài)管理視圖可以直接告訴你“它覺得哪里缺索引”SELECT migs.avg_total_user_cost * migs.avg_user_impact AS improvement_score, migs.avg_user_impact, migs.avg_total_user_cost, mid.database_id, mid.object_id, mid.statement AS table_name, mid.equality_columns, mid.inequality_columns, mid.included_columns, CREATE INDEX [IX_ OBJECT_NAME(mid.object_id, mid.database_id) _ REPLACE(REPLACE(REPLACE(ISNULL(mid.equality_columns, ), , , _), [, ), ], ) CASE WHEN mid.inequality_columns IS NOT NULL THEN _ REPLACE(REPLACE(REPLACE(mid.inequality_columns, , , _), [, ), ], ) ELSE END ] ON mid.statement ( ISNULL(mid.equality_columns, ) CASE WHEN mid.equality_columns IS NOT NULL AND mid.inequality_columns IS NOT NULL THEN , ELSE END ISNULL(mid.inequality_columns, ) ) CASE WHEN mid.included_columns IS NOT NULL THEN INCLUDE ( mid.included_columns ) ELSE END ; AS create_index_statement FROM sys.dm_db_missing_index_details mid JOIN sys.dm_db_missing_index_group_stats migs ON migs.group_handle mid.index_group_handle WHERE mid.database_id DB_ID() ORDER BY improvement_score DESC;這個視圖會直接拼出建議的CREATE INDEX語句看起來非常方便但我要提醒一句缺失索引建議只是基于成本評估的“建議”不是“必須執(zhí)行”。我在實際中見過不少案例按提示加索引后單條查詢快了不少但整個表的寫入變慢甚至因為索引過多導致日志增長和存儲膨脹。我的習慣是先人工判斷這個缺失索引對應的查詢是否高頻涉及的列是否在WHERE和JOIN條件中出現選擇性是否夠好再加一個INCLUDE的列是否能讓查詢覆蓋。一條查詢如果只跑一次就算預測收益99%也不值得加索引。4. 索引維護命令碎片檢測與重建/重組的完整決策鏈索引維護是SQL Server日常運維里繞不開的話題但也是被誤解較多的。很多人只知道定期重建索引卻不問為什么重建、碎片到什么程度才需要重建。這里把完整的命令決策鏈寫出來。4.1 碎片詳情查詢重建之前先看看數據執(zhí)行如下語句查看某個數據庫所有索引的碎片情況SELECT OBJECT_NAME(ps.object_id) AS table_name, i.name AS index_name, ps.index_type_desc, ps.page_count, ps.avg_fragmentation_in_percent, ps.avg_page_space_used_in_percent, ps.record_count, ps.ghost_record_count FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, SAMPLED) ps JOIN sys.indexes i ON ps.object_id i.object_id AND ps.index_id i.index_id WHERE ps.avg_fragmentation_in_percent 5 AND ps.page_count 100 AND ps.index_type_desc HEAP ORDER BY ps.avg_fragmentation_in_percent DESC;重點看兩列avg_fragmentation_in_percent代表碎片率avg_page_space_used_in_percent代表頁面填充率。碎片率只是表面指標頁面填充率過低說明頁內空間浪費嚴重即使碎片率不高也需要關注。這里我踩過一個大坑SAMPLED模式只采樣部分頁面掃描大表很快但結果可能不夠準確。小表或者碎片極不均勻的表用SAMPLED可能漏掉某些碎片區(qū)。更準確的是DETAILED模式但DETAILED會掃描全部頁面大表耗時很長必須在維護窗口執(zhí)行。所以我的做法是日常巡檢用SAMPLED快速看維護日再針對重點大表用DETAILED做最終確認。4.2 重建與重組的選擇按碎片率分檔處理查到碎片后按以下規(guī)則處理比較穩(wěn)妥碎片率低于5%不需要處理哪怕索引會繼續(xù)膨脹。碎片率在5%到30%之間執(zhí)行重組ALTER INDEX ... REORGANIZE這個是邏輯整理不重建物理結構不會產生大量日志。碎片率大于30%執(zhí)行重建ALTER INDEX ... REBUILD物理上重新分配頁產生日志較多。對應命令分別是-- 重組單個索引 ALTER INDEX [IX_表名_列名] ON [dbo].[表名] REORGANIZE; -- 重建單個索引 ALTER INDEX [IX_表名_列名] ON [dbo].[表名] REBUILD; -- 重建表上所有索引 ALTER INDEX ALL ON [dbo].[表名] REBUILD WITH (FILLFACTOR 90, ONLINE ON);如果生產環(huán)境是企業(yè)版重建索引時可以帶ONLINE ON這樣表在重建期間仍然可讀寫業(yè)務影響小很多標準版不支持在線重建通常只能選擇在維護窗口操作。另外重建大表索引前一定要預估好日志空間。曾經有人在幾小時內跑完重建結果日志文件把磁盤塞爆最后數據庫進入只讀。更穩(wěn)妥的做法是對核心大表在重建前先備份數據庫或者把數據庫恢復模式臨時改成簡單模式僅限于非關鍵庫并且要評估數據安全。4.3 填充因子與其他參數別讓索引維護白忙活FILLFACTOR是索引頁的填充百分比它直接影響后續(xù)碎片產生的速度。默認值是0等價于100%即索引頁盡可能填滿。對于頻繁插入的表建議設置成90左右預留一部分空間給后續(xù)插入避免頁分裂導致碎片快速增加對于基本只讀的表可以保持默認這樣索引更緊湊查詢IO更少。還有一個點容易被忽略——重建索引之后對應的統(tǒng)計信息也會自動更新。所以通常不需要再單獨執(zhí)行UPDATE STATISTICS。但如果某個查詢的執(zhí)行計劃一直不穩(wěn)定另當別論。5. 阻塞與死鎖排查命令還原現場而不是只看到結果數據庫阻塞和死鎖是運維中最頭疼的問題之一。難點在于死鎖發(fā)生那一刻就結束了等你去查的時候現場已經沒了。所以阻塞查詢要“實時”跑死鎖追蹤要“提前開”。以下是我排查這類問題時實際用到的命令組合。5.1 實時阻塞鏈查詢從等待者找到源頭sp_who2是老一代DBA常用命令勝在簡單EXEC sp_who2;但sp_who2返回的信息不夠結構化也不方便過濾。我現在更常用這樣一條查詢能直接看到阻塞者和被阻塞者的關系SELECT r.session_id AS blocked_session_id, r.blocking_session_id AS blocking_session_id, r.wait_type, r.wait_time / 1000.0 AS wait_time_sec, r.status, t.text AS blocked_sql_text, b.text AS blocking_sql_text, es.host_name, es.login_name, es.program_name FROM sys.dm_exec_requests r LEFT JOIN sys.dm_exec_connections rc ON r.session_id rc.session_id LEFT JOIN sys.dm_exec_connections bc ON r.blocking_session_id bc.session_id CROSS APPLY sys.dm_exec_sql_text(rc.most_recent_sql_handle) t CROSS APPLY sys.dm_exec_sql_text(bc.most_recent_sql_handle) b JOIN sys.dm_exec_sessions es ON r.session_id es.session_id WHERE r.blocking_session_id 0 AND r.blocking_session_id IS NOT NULL;這條查詢把阻塞者和被阻塞者兩邊的SQL文本都列出來一眼就能看出是哪條語句鎖住了什么資源。有一次排查超時告警跑完后發(fā)現阻塞源頭是一個長事務里的UPDATE語句一直在更新某大表的同一批記錄。往下一查發(fā)現更新條件字段上沒有索引每次更新都在全表掃描持有大量鎖不釋放后面所有涉及該表的操作全被擋在門外。后續(xù)在該字段上補了索引再配合業(yè)務側縮短事務時間問題才徹底解決。5.2 歷史死鎖追蹤提前開啟跟蹤標記死鎖不像阻塞可以現場看到更多時候需要我們翻歷史記錄。SQL Server默認會記錄死鎖相關信息但信息比較簡略。我建議在實例層面開啟跟蹤標記1222和1204這樣死鎖發(fā)生時會把完整的資源和語句寫到錯誤日志里DBCC TRACEON(1222, -1); DBCC TRACEON(1204, -1);開啟后查看錯誤日志中的死鎖信息EXEC sp_readerrorlog 0, 1, deadlock;日志里會顯示類似“deadlock victim”的字樣以及涉及的資源、進程ID和SQL語句。如果還嫌不夠直觀可以開擴展事件來捕獲xml_deadlock_report事件保存死鎖圖形文件用SSMS打開直接看環(huán)形依賴關系。我個人在生產環(huán)境更推薦擴展事件方式因為它能保存完整的死鎖圖XML排查效率比看文本日志高很多。5.3 鎖粒度和隔離級別理解比命令本身更重要排查鎖問題到深處必須理解隔離級別的影響。很多時候不是語句寫錯了而是隔離級別設置不合理導致鎖持有時間過長。比如默認的READ COMMITTED下讀操作只加共享鎖讀完即釋放但如果改成REPEATABLE READ或SERIALIZABLE讀鎖會一直持有到事務結束極易造成阻塞放大。-- 查看當前會話隔離級別 SELECT CASE transaction_isolation_level WHEN 0 THEN Unspecified WHEN 1 THEN READ UNCOMMITTED WHEN 2 THEN READ COMMITTED WHEN 3 THEN REPEATABLE READ WHEN 4 THEN SERIALIZABLE WHEN 5 THEN SNAPSHOT ELSE UNKNOWN END AS isolation_level FROM sys.dm_exec_sessions WHERE session_id SPID;針對某些報表類查詢如果允許臟讀可以按語句級別加WITH (NOLOCK)提示把讀鎖徹底去掉但這要業(yè)務側接受可能出現的中途被修改的數據。對核心交易邏輯不建議用NOLOCK來繞過鎖問題正確做法是優(yōu)化事務粒度、減少鎖持有時間或者開啟READ COMMITTED SNAPSHOTRCSI讓讀操作走行版本快照。6. 備份與完整性校驗命令出事后才做的操作其實最需要提前演練備份算是SQL Server命令里最基礎也最不能出錯的部分。我發(fā)現很多團隊的備份腳本是“能跑就行”但從沒做過恢復演練真到出問題時才發(fā)現備份文件損壞或恢復鏈斷裂。這里分享的是我實際使用的備份與校驗命令組合。6.1 全量備份與差異備份參數不是隨便填的全量備份最常用的一條BACKUP DATABASE [數據庫名] TO DISK ND:\Backup\數據庫名_20260120.bak WITH INIT, NAME N數據庫名-全量備份, COMPRESSION, CHECKSUM, STATS 10;幾個關鍵參數說明一下。INIT表示覆蓋同名文件如果不用INIT而且目標文件已存在備份會追加到文件里容易造成文件字節(jié)數增長且不可讀。COMPRESSION啟用備份壓縮能顯著減小備份體積但也更消耗CPU資源——如果服務器CPU本身已經長期高位可以改成MAXTRANSFERSIZE調優(yōu)而不是啟用壓縮。CHECKSUM在校驗備份時非常關鍵它會在備份過程中計算校驗和RESTORE VERIFYONLY時就能檢查數據頁是否有損壞。差異備份的命令類似BACKUP DATABASE [數據庫名] TO DISK ND:\Backup\數據庫名_20260120_diff.bak WITH DIFFERENTIAL, INIT, NAME N數據庫名-差異備份, CHECKSUM;需要強調差異備份是基于上一次全量備份的增量。如果全量備份被覆蓋或刪除中間所有差異備份都失效。所以備份文件的保留策略必須嚴格比如保留最近7天每日全量再加上當天所有差異備份不要手動去刪中間文件。6.2 事務日志備份恢復時間點的關鍵對恢復模式為FULL的數據庫必須定期備份事務日志BACKUP LOG [數據庫名] TO DISK ND:\Backup\數據庫名_20260120_log.trn WITH INIT, CHECKSUM;日志備份做得好才能把數據庫恢復到任意時間點?，F實中我看到不少情況是全量備份和差異備份都有但日志備份頻率過低甚至一天才一次。如果數據庫在下午兩點宕機日志備份最后一次是早上六點中間的數據就只能丟。核心交易庫建議日志備份間隔控制在15分鐘以內備份文件不大成本主要是IO開銷和時間精度。6.3 恢復校驗備份的真正考驗是能不能恢復備份完不等于萬事大吉我用一條命令驗證備份文件完整性RESTORE VERIFYONLY FROM DISK ND:\Backup\數據庫名_20260120.bak WITH CHECKSUM;這條只校驗備份集完整性不實際恢復數據速度快可作為日常監(jiān)控任務的一部分。但需要說明VERIFYONLY不能完全代替真正的恢復演練。我自己的做法是每季度至少做一次完整的RESTORE DATABASE到隔離環(huán)境的演練確認備份文件能正?；謴筒⑶覒萌罩炬満竽艿玫狡谕麜r間點。偶爾遇到備份文件在校驗時報CHECKSUM錯誤的情況就是因為備份過程中磁盤IO異?；蛭募軗p這種時候必須盡快定位物理磁盤問題重新做備份不能繼續(xù)往這個文件上追加任何數據。6.4 數據庫完整性檢查DBCC CHECKDB的正確打開方式除了備份我還把DBCC CHECKDB納入月度維護計劃。它檢查數據庫邏輯和物理完整性能發(fā)現頁損壞、分配錯誤、邏輯一致性等問題DBCC CHECKDB([數據庫名]) WITH NO_INFOMSGS, ALL_ERRORMSGS, PHYSICAL_ONLY;大多數情況下生產庫我建議用PHYSICAL_ONLY模式因為它只檢查物理結構不檢查所有邏輯約束耗時比完整檢查短很多。維護窗口充足時再跑不帶PHYSICAL_ONLY的完整檢查。還有一個實際建議CHECKDB也是CPU和IO密集操作盡量不要和索引重建、全量備份安排在同一時間段執(zhí)行免得互相搶資源。7. 把命令整理成自己的巡檢清單多跑幾遍你也有手感最后分享一個我自己堅持的習慣。上面這些命令不是每次都需要全部跑一遍我的做法是分為日常巡檢、周度巡檢、月度維護三檔對應不同頻率和深度。日常巡檢每天早上一遍跑會話狀態(tài)查詢、數據庫文件大小、DBCC OPENTRAN、備份是否成功。十分鐘內完成腳本里加好時間戳和狀態(tài)高亮異常時直接標紅。周度巡檢加跑等待類型匯總、碎片率抽樣、最耗時查詢排行用于發(fā)現性能退化趨勢。月度維護跑CHECKDB、索引重組或重建、季度恢復演練、完整死鎖日志分析。把這些命令組合到一起后你會發(fā)現數據庫問題大多是漸變的——日志文件在悄悄變大某條語句的邏輯讀在逐步上升等待類型占比在慢慢偏移。只看某一天的快照很難發(fā)現問題持續(xù)按固定頻率采集并對比才能抓住趨勢。關于這些命令本身我再補充一個建議新建一個專門的查詢腳本文件把每條命令都寫好注釋和排序條件別到用的時候臨時打開SSMS手敲。人總是會記憶模糊的尤其凌晨被叫起來處理故障時一份固化的巡檢腳本比什么都可靠。我?guī)状瘟璩颗挪閱栴}能十分鐘定位靠的就是這份提前寫好的腳本以及平時養(yǎng)成的固定執(zhí)行節(jié)奏。