- 识别硬件和软件故障，调整超时，并防止镜像中的误报。
- 修复降低性能的模式：N+1、WHERE 函数和缺失索引。
- 避免 SQL 错误（语法、顺序、别名）和不良设计实践（PK、规范化）。
- 实施 KEDB 以快速透明地解决重复发生的事件。
我们的目标是让您带着清晰的行动指南离开：了解这些问题出现的原因、如何检测它们以及应该采取哪些措施。您将找到关于SQL Server（镜像）硬件和软件错误、性能瓶颈模式、常见查询编写错误、经典建模/开发陷阱以及如何使用结构良好的键控错误数据库 (KEDB) 来记录和解决重复事件的 ITIL/ITSM 方法的详细指南。
硬件错误：迹象、原因和反应时间
物理故障通常会很快显现出来，因为其他系统组件会向数据库引擎发出警报。发生这种情况时，服务器会立即收到硬件错误报告，但有时会因网络或 I/O 定时器而导致通知延迟。
常见原因包括连接中断或电缆损坏、网卡故障、路由器或防火墙变更、终端重新配置、存储事务日志的驱动器丢失，或进程/操作系统错误。这些问题如果影响到日志磁盘或网络，可能会导致从连接断开到数据库复制或镜像严重中断等各种问题。
请注意，某些网络组件和特定 I/O 子系统会应用自身的内部超时机制。这些超时机制独立于数据库，可能会延迟故障检测，从而延长实际故障发生到引擎感知到故障之间的时间间隔。
为了更好地了解“线路”上发生的情况，可以询问网络团队在诸如DNS 中断、网线断开、防火墙端口阻塞、监听该端口的应用程序崩溃、服务器名称更改或重启等常见事件发生期间，端口接收到的消息有哪些。这份症状清单有助于在服务突然停止时加快诊断速度。
软件错误和超时：何时修复以及如何避免误报
软件故障不会自行发出警报：如果没有监控机制，服务器可能会无限期地保持空闲状态。因此，在数据库镜像等场景中，会定期向实例发送 ping 请求，如果在约定的时间内没有收到任何信号，则认为发生了问题。
导致这些等待时间的条件包括网络错误（TCP 超时、数据包损坏、丢失或顺序错误）、操作系统/服务器/数据库无响应、Windows 级过期以及资源不足：磁盘或 CPU 饱和、事务日志 100%、内存或线程不足。
如果遇到这种情况，您可以选择增加超时时间、降低负载或升级硬件来应对需求。超时时间设置过短会导致误报；设置过长则会延迟对实际故障的响应。
SQL Server镜像中的ping/超时机制
为了保持每个连接的活跃状态，每个实例都会以固定的时间间隔发送 ping 包。如果在超时时间窗口（加上发送时间）内收到 ping 包，则认为通信处于活动状态，并将计时器重置。如果在该时间间隔内没有收到 ping 包，则认为超时已过，连接将被关闭，并根据角色和运行模式处理该事件。
即使另一台服务器运行正常，超时也会被视为故障。如果配置的超时值对于环境的正常延迟来说过短，则会出现“虚假”错误。因此，建议超时时间不要低于 10 秒。
在高性能模式下，超时时间始终为10 秒；这通常足以避免误报。在高安全模式下，默认值也为 10 秒，但可以配置；如果网络速度较慢，请在此模式下将其调整为 10 秒或更长。
如果需要更改此设置，请记住，此修改仅适用于高安全级别会话。您可以根据您的版本和策略，通过引擎管理界面或使用 T-SQL 查看和修改此设置。
出现错误时服务器如何响应
如果发生任何类型的错误，实例会根据其角色（主实例/见证实例/辅助实例）、运行模式和连接状态采取相应的措施。如果某个伙伴实例丢失，其行为会因当前是否处于高性能模式或高安全模式（且有见证实例）而有所不同，因此记录每个会话的运行模式至关重要，以便预测停机时间和切换情况。
SQL 中的性能杀手模式（以及如何修复它们）
有四种非常常见的“错误做法”会不必要地增加延迟。这些错误很容易发现，避免它们可以从一开始就节省 CPU、I/O 和数据库访问资源。
循环内的查询：每次迭代都执行查询（经典的 N+1 循环）会增加调用次数和延迟。使用 UNION 或 IN一次性检索所有数据，或者使用批量查询。使用已加载到内存中的数据结构来处理代码中的逻辑。
加载过多数据——检索你不会使用的列和行——就像用大锤砸核桃一样。应该筛选数据库，只选择必要的数据，在适当的时候使用分页，除非有明确的理由，否则避免使用 SELECT *。
WHERE 子句中的函数：对列应用 LOWER()、DATE() 或其他函数通常会阻止索引的使用。最好在不转换列的情况下进行比较：先预处理数据或转换字面值。例如，使用日期/时间列按日期范围进行筛选，而无需将其包装在函数中。
缺少索引：如果用于筛选或连接的列没有索引，就相当于要求执行全表扫描。定期检查应用程序的筛选/连接操作，并创建相应的索引（必要时创建复合索引）。平衡：索引过多会增加写入性能。
编写 SQL 时的典型错误：语法、顺序和歧义
大多数初学者（甚至一些经验丰富的用户）犯的错误都与语法和SQL 注入有关。数据库无法理解你的请求，因此会报错。使用带有文本高亮功能的编辑器会有所帮助，但了解常见的陷阱可以加快处理速度。
拼写错误：FROM、WHERE 子句或表/列名拼写错误很常见。错误信息通常会指出解析器出错的地方。使用带有高亮显示和自动补全功能的编辑器；如果某个关键字没有高亮显示，则需要引起注意。
括号和引号：缺少括号或引号会造成难以察觉的问题。请记住运算符优先级（AND/OR），并用括号将文本分组。在文本字面量中，请转义内部引号或交替使用单引号和双引号，以避免字符串断裂（例如，O'Reilly）。
SELECT 语句顺序无效：正确的顺序是SELECT → FROM → WHERE → GROUP BY → HAVING → ORDER BY。更改 ORDER BY 或 HAVING 的顺序会导致错误。请记住这个顺序，或者准备一份速查表。
省略表别名：在自连接或两个表存在同名列时，会收到“列名不明确”的错误。请使用简短、清晰的别名，并使用 `alias.column` 引用列。这样做还能提高 SQL 代码的可读性。
区分大小写或特殊名称：如果您坚持使用区分大小写或区分空格的名称，则需要根据搜索引擎的不同，使用双引号将其括起来。最好避免使用这些名称；否则，引用时请保持一致。
数据库开发中常见的错误
除了编写查询语句之外，还有一些设计决策会对中长期产生影响。以下列举了五个常见的开发错误，以及如何采取正确的措施来保护代码的完整性和可维护性。
过度使用存储过程：它们固然有用，但有了现代 ORM 和访问层，您不再需要将所有逻辑都放在其中。存储过程需要维护和版本控制成本；仅在必要时创建用于数据访问的存储过程，而不是用于应用程序业务逻辑。
避免使用主键：将唯一性委托给视图、存储过程或应用程序会增加复杂性和错误率。在所有表中定义真正的主键，并在适当的地方使用唯一键；这将防止事后去重和脆弱的查询。
硬删除而非软删除：物理删除数据会使审计和恢复变得复杂，尤其是在发生“糟糕，我搞砸了”的情况时。对于许多用例，可以添加一个活动/非活动（软删除）标志，并将其从查询中排除。物理删除仅用于受控清理。
已知错误数据库 (KEDB)：它是什么以及为什么它对你来说是个好主意
在实际运营中，并非所有问题都能立即解决。由于资源有限、系统复杂或需要保障业务连续性等原因，临时解决方案（权宜之计）在所难免。KEDB 是一个存储库，用于记录所有已知错误、错误原因（如有）以及相应的临时或永久解决方案。
它是 ITIL 框架的一部分，并与问题管理和知识管理相辅相成。当重复出现类似事件时，团队会查阅知识库数据库 (KEDB)，应用已验证的解决方案，从而减少停机时间，而无需从头开始。
用户获益：更快的故障解决速度、更少的故障中断和更可预测的结果。IT 部门获益：提高效率（无需重复造轮子）、即使人员流动也能保留知识，以及用于持续改进的数据。利益相关者获益：提高透明度、基于充分信息的产能/风险决策和成本节约。
如何逐步实施有效的KEDB
1）明确范围和目标：确定包含哪些故障（软件、硬件、网络或特定领域），如何对故障进行分类，以及要实现的目标（例如，缩短平均修复时间、提高满意度等）。优先考虑关键系统和服务，并使范围与业务目标和服务级别协议 (SLA) 保持一致。
指导性问题：它是否涵盖所有内容，还是我们应该从影响最大的问题入手？我们的主要目标是缩短解决问题的时间，还是也希望发现预防的模式？
2) 收集并记录：与事件/问题管理团队合作，收集尚未记录的重复出现错误和有效的临时解决方案。使用包含以下字段的简单模板：描述、根本原因（如果已知）、临时/永久解决方案、影响、日期和备注。
提示：使用清晰的语言，采取可操作的步骤，进行有用的分类，链接相关事件，并在有新进展时更新条目。
3) 选择工具：您需要强大的搜索、分类/标签功能、项目间链接、可扩展性、报告功能，以及与 ITSM 平台集成的能力。优先考虑用户友好的界面以鼓励用户采用；考虑使用 AI 驱动的搜索和可自定义的工作流程。
4）培训团队：教他们如何高效地记录文档、高效地搜索信息并保持文档质量。培训内容包括结合真实案例的实践练习、快速指南、视频、导师指导以及定期复习课程。鼓励反馈以改进流程。
5) 维护和改进：明确职责、关键绩效指标 (KPI) 和审核周期（关键问题每月审核一次，其他问题每季度审核一次）。建立新条目的同行评审机制，每次问题出现后持续更新文档，并建立用户和支持团队的反馈渠道。
6）推广使用：开展内部宣传活动，表彰贡献最大的员工，并促进各部门（网络、软件、硬件）之间的协作。将 KEDB 融入服务文化，使其成为用户查找信息的首选平台。
KEDB 与知识库（KDB）：主要区别
KEDB 专注于已知故障及其解决方案（临时或永久），与问题和事件管理紧密相关。它通常与 ITSM 集成，其主要受众是负责解决事件的技术团队。
KEDB 的内容远不止于此：它涵盖了最佳实践、流程、配置数据、帮助文章等等。其维护工作也更为广泛，除了技术文章之外，还需要修订流程和最佳实践。简而言之：KEDB 是“当此操作失败时，执行其他操作”这一概念的专门子集。
如您所见，数据库的稳定性和性能不仅取决于编写良好的 SQL 语句、进行智能建模以及组织运维知识，还取决于对物理和逻辑故障（及其检测时间）的理解。如果您能纠正这四种性能模式，避免常见的语法错误，采用强主键和合理的规范化设计，并搭建一个实时数据库管理系统 (KEDB)，即使出现故障，您也能拥有一个速度更快、更可预测且更易于操作的平台。
