由 dawei 不合理索引设计是性能下滑的元凶。缺少WHERE条件字段的索引、过度创建冗余索引、忽略INCLUDE列优化，都会拖慢查询并增加写入开销。建议定期用sys.dm_db_missing_index_视图识别缺失索引，并结合执行计划验证索引有效性。
自增长主键遇上大量DELETE后未重建，极易引发页拆分和碎片飙升。尤其是GUID作为聚集索引时，随机插入导致物理存储严重碎裂。务必定期检查sys.dm_db_index_physical_stats碎片率，超过30%且索引页数超1000时应重建。
事务中长时间持有锁却未及时提交或回滚，轻则阻塞业务请求，重则引发连锁超时。避免在事务内调用外部API、等待用户输入或执行耗时计算。所有BEGIN TRAN必须配对出现，推荐启用XACT_ABORT ON提升异常安全性。
备份未验证=没备份。仅执行BACKUP DATABASE不等于数据真正可恢复。每周至少一次还原测试到隔离环境，检查日志链连续性、STOPAT精度及文件路径兼容性，同时确认备份压缩与加密密钥留存完整。
AI模拟效果图，仅供参考
tempdb配置不当会成为系统瓶颈。多数据文件数量≠逻辑CPU核心数，而应为8~12个（≤8核时取核数，>8核时从8起步再根据争用情况调优），且初始大小需统一、启用TF 1118避免分配冲突。
误用SELECT 不仅增加网络与内存负担，更可能因表结构变更导致应用解析失败。所有查询须显式列出字段，视图与存储过程中亦需严格限定列集，禁用通配符投影。
自动更新统计信息关闭或频率过低，会导致执行计划陈旧。尤其在大表增量导入后，SQL Server可能仍沿用旧分布直方图。确保AUTO_UPDATE_STATISTICS和AUTO_CREATE_STATISTICS处于ON状态。
错误处理裸奔：未捕获错误号、忽略@@ERROR或TRY…CATCH中遗漏RAISERROR/THROW重抛，致使上游无法感知故障。存储过程必须用TRY CATCH封装，并将关键错误信息写入日志表或Event Log。
MAXDOP配置一刀切：OLTP系统设为0（启用所有处理器）常引发并行反效果。建议OLTP场景设为8以内，数据仓库类负载再动态调整；务必结合sp_configure ‘cost threshold for parallelism’综合评估。
忽略死锁图分析，仅靠日志报警就重启服务。死锁不可怕，重复发生才危险。开启trace flag 1222或扩展事件捕捉死锁XML，聚焦资源类型、参与语句、索引顺序，针对性调整访问模式或加覆盖索引。
安全补丁长期拖延，已知漏洞如CVE-2022-23221、CVE-2023-29360曾致远程代码执行。建立补丁基线策略，测试环境先行验证，生产窗口内48小时内完成关键更新。
监控盲区埋隐患：只盯CPU/内存，忽视PAGEIOLATCH_等待、WRITELOG高占比、tempdb版本存储增长等隐性信号。部署免费工具如sp_WhoIsActive + SentryOne Free Dashboard，设置阈值告警。