SQL Server 的杀毒软件可以排除哪些文件夹？
针对工作负载的排除与不设防护的主机是两种不同决定。把例外限定在已证实的交互上，并保留其余管控。
在数据库评审中，两句话常被混用，含义却大不相同。一句说某个工作负载需要某项例外；另一句说主机不再需要端点防护。前者是有边界的工程决定，后者是无人负责的风险。把两者分开就是任务的全部，而它从服务器实际做什么开始。
两句听起来相似的话
例外会指明某个路径、进程或文件类型，并给出理由。而放弃则是把某项管控从机器上撤掉，转而为此给出理由。两者可能带来相近的性能数字，安全姿态却完全不同。
数据库服务器不适合被放弃，因为它保存着其他一切所依赖的数据。它也不适合套用桌面级策略，因为扫描数据库保持打开的文件会引发桌面环境永远不会遇到的问题。诚实的立场居于中间，而且必须论证而不是假定。评审应当记录的正是这套论证。
比较例外与放弃
把两个选项并排放到四点上看：什么仍然受保护、什么会暴露、决定归谁所有、由哪些证据支撑。
有边界的例外让主机其余部分保持原有防护，把决定留在具名负责人手中，并以可复现的症状为依据。放弃则撤掉一切防护，通常以机器未暴露这一主张为依据。该主张必须经得起服务器实际角色的检验，因为文件共享、链接服务器、代理作业和管理性文件传输都会造成防火墙永远看不到的暴露面。下表中的比较只有一列能在负责人变更后仍然成立，因为它记录了什么被决定以及为什么。
| Point | Scoped exception | Blanket exclusion |
|---|---|---|
| Coverage | Only the named paths or processes | The whole host |
| Evidence needed | A reproduced interaction | An argument about exposure |
| Owner | A named reviewer with a date | Usually nobody |
| Behaviour after an update | Reviewed again | Silently inherited |
把例外限定在已证实的交互上
从症状出发，而不是从清单出发。文件访问冲突、资源压力与慢查询在日志中表现不同，也应导向不同的修正。在开启防护的情况下复现症状，然后确定涉及的精确路径或进程。
常见的候选是数据库文件、日志文件、备份和全文目录文件，而Microsoft 关于杀毒软件与 SQL Server 的指引仍是已部署版本与安全产品的参照。不要照抄另一台服务器的清单，也不要假定一个服务名涵盖所有已安装组件。应当提出的是能处理已证实交互的最小例外。任何更大的范围都需要各自的论证。
Get-MpPreference | Select-Object -ExpandProperty ExclusionPath
Get-MpComputerStatus | Select-Object AntivirusEnabled, RealTimeProtectionEnabled对照服务器角色复核这份清单，因为为一次事件添加的例外往往会永久留下。每条记录旁的一句简短备注，就足以让下一次审计成为可能。
保留网络与身份管控
端点例外并不说明谁可以访问数据库。防火墙策略仍应限制哪些来源能打开 SQL 或管理会话，应用账户也仍应限定这些会话可以做什么。
VPN 属于同一场讨论，却常被误用作理由。限制访问路径并不能验证经它传入的文件、脚本或查询。加密隧道对网络传感器同样不透明，所以传感器提供的可见性并不等于主机代理提供的可见性。这是两条不同的证据流，谁也替代不了谁。补丁管理、可信管理工具和经过测试的恢复路径，仍是各自有人负责的独立职责。角色卫生也在此列：无关的浏览、下载和文件共享任务应远离数据库主机，除非其负责人明确接受。
先测试这次变更，再承担责任
用有代表性的工作负载和真正重要的安全检查来测试，然后比较稳定性、吞吐量和持续防护，而不只是原先那个错误。
Get-MpThreatDetection | Sort-Object InitialDetectionTime -Descending | Select-Object -First 5
Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 20保留受支持的退路和一位在组件或产品更新后复核该例外的负责人，因为为某一个构建写下的例外，可能比它存在的理由活得更久。把范围、理由和复核日期记在与服务器构建记录相同的地方。没有这些，下一位复核者继承的只是一份没有论证的清单。例外的正当性，只在理由仍然成立时才成立。