mysql实际使用中的经典问题和解决方案
mysql实际使用中的经典问题和解决方案
- 可扩展性：并发量提升导致的TPC-C性能下降
- 使用线程池
- 不支持 hash join
- 大规模部署中MySQL半同步复制的挑战
- Raft
- 在组复制的默认模式下，跨数据中心的吞吐量与理论预期存在显著偏差
- 组复制：本地主机部署报告不可达
九个令人困惑的 MySQL 问题
- SysBench 读写测试展现超线性吞吐量增长：如果同时运行两个实例时的总吞吐量大致等于它们单独运行时的吞吐量之和，就代表线性关系。如果合并后的吞吐量超过这个总和，则表明存在超线性关系。
- 应用 PGO 后 TPC-C 吞吐量意外下降：PGO 在较低并发水平下显著提升了 MySQL 的吞吐量。然而，当并发数超过 150 时，整体吞吐量和峰值性能均呈现下降趋势。
- 线程池在可扩展性增强后对 MySQL 的负面影响：启用 Percona 线程池相比禁用时导致了吞吐量的显著下降。
- MySQL 8.0 中 TPC-C 吞吐量下降过快：TPC-C 吞吐量的下降速度远超预期，接近 50%的降幅。
- 可重复读意外优于读已提交：在 SysBench uniform 这样的低冲突测试中，MVCC ReadView 的开销是主要瓶颈，超过了锁开销。因此，可重复读（Repeatable Read）的性能优于读已提交（Read Committed）。相反，在 SysBench pareto 这样的高冲突测试中，锁开销成为主要瓶颈，导致读已提交的性能优于可重复读。
- 组复制吞吐量低于半同步复制：问题的根源在于组复制（Group Replication）采用的认证数据库机制，而半同步复制中并不存在这一机制。该机制涉及大量内存分配与释放操作，严重制约了吞吐量的提升。尽管无需进行 Paxos 日志持久化，但这一瓶颈抵消了组复制的优势。显然，认证数据库机制的实现构成了组复制面临的主要性能挑战。
- 改进后的组复制性能优于半同步复制：Group Replication 利用 Paxos 日志持久化，而半同步复制则依赖中继日志持久化。由于这些机制的不同，采用 Paxos 日志持久化的 Group Replication 展现出比半同步复制显著更优的性能。
- SysBench 无效果，TPC-C 表现良好：MySQL 8.0 通过解决全局锁存瓶颈并优化 InnoDB 中的锁调度，实现了可扩展性的提升。令人意外的是，在实现锁系统优化后，吞吐量反而下降了，这出乎意料。
- 禁用 NUMA 真的对 MySQL 有益吗：BIOS 中禁用 NUMA 后更有利的内存分配机制，尤其对 MySQL 主服务器等应用大有裨益。禁用 NUMA 是否也对 MySQL 从库回放有益呢？
如何有效解决软件问题
分析策略
- 心理策略：面对困难，尤其是那些看似复杂的问题时，保持自信至关重要。这些挑战可以成为激发个人潜能、提升解决问题能力的契机。
- 简化策略：当问题出现且重现原始条件非常复杂时，逐步简化复现环境至关重要。
- 模式发现策略：当问题反复出现时，往往能揭示其潜在特征，便于统计与之相关的模式和规律。这些数据有助于问题复现和推理判断。
- 提高可复现性的策略：重现问题的能力在解决复杂问题时往往至关重要。通过捕捉问题复现的特征来提高可重现性，是加速问题解决的关键。
- 寻找关键证据的策略：有时，直接揭示问题的特征颇具挑战性；这需要创造条件使问题充分显现。
逻辑思维
- 演绎推理：演绎推理涉及从前提中得出结论，通常以三段论的形式构建。三段论通常包括一个大前提、一个小前提和一个结论。
- 归纳推理：归纳推理从具体实例中推断出一般性结论。
- 溯因推理：溯因推理，又称反向推理，是指从观察到的事实中推导出最佳解释。这是一种在解决编程问题时广泛采用的方法，尤其当症状明显但根本原因尚不明确时。
- 归谬法：“归谬法”是一种通过展示命题的逻辑结论会导致荒谬或矛盾结果来反驳该命题的方法。此方法旨在证明某个陈述或假设必定为假，因为接受它将导致不合逻辑或不可接受的结果。这是一种常用的驳论方法，其特点在于“以退为进”的策略，即通过引入荒谬性来暴露推理中的缺陷。
解决问题的策略
- 平衡不同选项：一旦问题的根本原因被确定，通常会有多种选择方案，需要仔细权衡它们的优缺点。
- 分解问题：复杂问题往往伴随着多个关联问题，这些问题会严重干扰分析和判断。为了有效解决此类问题，关键在于消除这些干扰、简化问题，并降低误判风险。
- 通过探索寻找解决方案：当面对陌生问题或被过多细节压垮时，必须在探索的同时寻求解决方案。这种方法对解决复杂问题尤为有效。
- 寻求理论支持：这种方法能促进更深刻的理解，并在整个增强过程中保持思路清晰，确保全面掌握相关概念，避免偏离既定方向。
- 基于逻辑的测试：要评估新功能的性能改进潜力，必须从多个角度和环境进行严格的迭代测试与验证。可靠的结论能确保后续测试结果的可预测性。验证过程中发现的任何偏差都必须彻底调查，以识别潜在的干扰因素。
- 逻辑推理原则：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
221. ask for reasons before accepting a conclusion,
2. give an argument to support your conclusion,
3. design your reasons to imply the conclusion,
4. recognize the value of having more relevant information,
5. weigh the pros and cons,
6. consider the possible courses of action,
7. look at the consequences of these various courses of action,
8. evaluate the consequences,
9. consider the probabilities that those various consequences will actually occur,
10. delay making important decisions when practical,
11. assess what is said in light of the situation,
12. use your background knowledge and common sense in drawing conclusions,
13. remember that extraordinary statements require extraordinarily good evidence,
14. defer to the expert,
15. remember that firmer conclusions require better reasons,
16. be consistent in your own reasoning,
17. be on the lookout for inconsistency in the reasoning of yourself and others,
18. check to see whether explanations fit all the relevant facts,
19. you can make your opponent's explanation less believable by showing that there are
alternative explanations that haven't been ruled out,
20. stick to the subject,
21. don't draw a conclusion until you've gotten enough evidence.
逻辑推理：解决复杂问题的关键
许多复杂的软件问题源于信息和逻辑的混乱。要解决这些问题，关键在于通过精确的数据和系统化的推理来理清逻辑关系，从而追踪根本原因。掌握这种逻辑方法能显著提升程序员解决问题的能力。
虽然数据结构和算法是编程的核心，但解决编程问题不仅仅是对它们的熟悉或精通。它需要逻辑推理能力。因此，本章的内容构成了后续主题的基础。
常见问题解决框架
![[8fdf25878c4aff269ad26bc3002e7205.png]](https://misakatang.oss-cn-beijing.aliyuncs.com/blog_picture/8fdf25878c4aff269ad26bc3002e7205.png)
计算机科学基础
系统架构
SMP
在这种配置中，访问本地 L1 和 L2 缓存的速度极快，且与 NUMA 架构相比，CPU 切换的开销极小。SMP 架构在正常情况下通常支持中等吞吐量。然而，正是由于 SMP 无法有效扩展以满足更高的吞吐量需求，才推动了 NUMA 架构的发展。
NUMA
在多核系统日益普及的时代，内存层次结构正朝着非均匀分布式架构演进。非均匀内存架构（NUMA）系统相比对称多处理（SMP）架构具有更优的可扩展性，其特点是内存节点分布在系统各处。每个节点物理上邻近部分处理器核心，但所有节点的整个物理地址空间全局可见，使得核心既能本地访问内存也能远程访问。因此数据访问时间呈现非均匀性，具体时长取决于数据位置。若多个核心频繁远程访问大量数据，跨节点数据访问会因延迟和互连争用导致性能下降。通过采用 NUMA 感知的调度算法尽可能让线程与其所需数据就近部署，可有效缓解此类问题。![[73a26c9835141996aa0470f756f95344.png]](https://misakatang.oss-cn-beijing.aliyuncs.com/blog_picture/73a26c9835141996aa0470f756f95344.png)
MySQL 在实现线性可扩展性方面的困难源于多个因素，包括基于 MVCC ReadView 的 Read Committed 事务隔离机制。这涉及将全局 ReadView 复制到本地，导致线程间对全局 ReadView 更新的争用。此外，在 NUMA 环境中，频繁的跨 NUMA 节点访问是必要的，这进一步加剧了可扩展性的复杂性。
X86 架构
X86 采用了一种称为 CISC（复杂指令集计算）的复杂系统。它能够同时执行大量任务，但也使得处理器设计更为复杂且制造成本更高。
在 x86 架构下，每增加一个 NUMA 节点都会显著提升高并发吞吐量。这凸显了 x86 架构在有效管理 NUMA 节点间内存访问方面的强大性能表现，从而充分发挥其在高性能计算中的潜力。
ARM 架构
ARM 与 x86 处理器的主要区别在于它们的指令集：ARM 采用 RISC（精简指令集计算）架构，通过简化指令来提高速度和能源效率。
基于 ARM 架构的服务器以低功耗和成本效益著称，但与 x86 架构相比，其整体性能通常较低，且在内存访问可扩展性方面可能存在局限。
大量测试表明，与 ARM 相比，MySQL 在 x86 架构上展现出更好的可扩展性。
数据结构
数组
在 MySQL InnoDB 存储引擎中，MVCC ReadView 使用类似向量的数据结构来存储所有活跃事务的事务 ID。这种动态数组支持可变长度，能够适应活跃事务列表的大小变化。对于 Read Committed 事务隔离级别，每次读取操作都会使用自己的 ReadView。
从实践角度来看，利用固定长度数组能带来显著的性能优势。其稳定性避免了因内存重新分配导致的性能波动，而缓存友好性则进一步提升了效率。
链表
MySQL 通常使用标准库中的链表，这类链表通常实现为双向链表以便于插入和删除操作，但其查询性能往往较差。在主流的 NUMA 架构中，由于非连续的内存访问模式，链表在查询方面通常效率低下。因此，链表最适合作为辅助数据结构或适用于数据量较小的场景。
队列
在 MySQL 中，队列通常被封装以提供额外功能，例如同步队列和双端队列，以满足 FIFO 处理需求。例如，下面展示的入站成员使用同步队列存储 Group Replication 的应用数据包，作为与 Paxos 网络交互及中继日志磁盘写入相关数据的缓存。
堆
堆（Heaps）在需要频繁访问并移除最高或最低优先级元素，或频繁进行根节点的插入和删除操作时尤为实用。优先队列（Priority queues）常通过堆来实现，MySQL 中也采用了这一结构。例如，在 MySQL 8.0.34 中，数据结构 purge_pg_t（详见下文）利用标准库中的 priority_queue 高效查找最旧的事务 ID。
从数学角度看，堆数据结构具有理论树层级最少的平衡树结构。然而在现代架构中，它们存在显著缺陷。堆采用从根节点到叶节点的非顺序访问模式，这种模式对缓存不友好。这使得堆适用于相对较小的数据集，但随着数据规模扩大效率会降低。低效的缓存访问或许可以解释，为何基于堆的算法（如堆排序）尽管具备理论优势，其平均性能仍无法超越快速排序。
哈希表
传统哈希表的主要优势在于其快速的查询速度。然而，由于哈希槽中存储的内存指针较为分散，它们可能不太缓存友好。这种分散性会导致频繁访问操作时效率降低。为解决这一问题，出现了诸如 Google 的 Swiss Table 等解决方案，它们采用缓存友好且更高效的方法来加快比较和插入速度。然而，这类解决方案并不具有普适性，尤其不适合数据库使用场景。
红黑树
在计算机科学中，红黑树是一种自平衡的二叉搜索树，以高效存储和检索有序数据而闻名。红黑树中的每个节点都有一个额外的“颜色”位，通常为红色或黑色，这有助于维护树的平衡结构
B+树
B+树是一种多叉树，其特点是每个节点拥有大量子节点，包括根节点、内部节点和叶子节点。根节点可以是一个叶子节点，也可以是一个拥有两个或更多子节点的节点。
B+树在面向块的存储环境中表现出色，例如文件系统，这得益于其高扇出特性（通常每个节点包含约 100 或更多指针）。这种高扇出减少了定位元素所需的 I/O 操作次数，使得当数据无法全部装入内存而必须从磁盘读取时，B+树尤为高效。
混合数据结构
在各种应用场景中，依赖单一数据结构未必总能获得最佳性能。结合不同数据结构往往能带来显著提升。例如，MySQL 中的 MVCC ReadView 最初使用动态数组（vector）维护活跃事务列表，利用二分查找进行查询。但在高并发环境下，该列表可能过度膨胀，导致在 NUMA 环境中效率下降。为解决这一问题，采用了混合策略：将近期事务存储在静态数组中以快速访问，而长时间运行的事务则置于动态数组中。这种由多个变量管理的双数组策略提高了访问速度和效率。
算法
搜索算法
在计算机科学中，搜索算法旨在特定数据结构或搜索空间内定位信息。
MySQL 常用的搜索算法包括二分查找、红黑树查找、B+树查找和哈希查找。
排序算法
在计算机科学中，排序算法将列表中的元素按特定顺序排列，最常用的顺序是数值和字典序，可以是升序或降序。高效的排序对于优化其他算法的性能至关重要，例如搜索和合并算法，这些算法需要已排序的输入数据。
一般来说，使用排序算法时，关键在于应用的灵活性和缓存友好性。通过考量算法的复杂度，可以找到最适合的排序算法。
贪心算法
贪心算法遵循在每个阶段做出局部最优选择的启发式方法。虽然对于许多问题它通常不会产生最优解，但它可以在合理的时间内产生近似全局最优解的局部最优解。
基于 SQL 生成执行计划时最具挑战性的问题之一是选择连接顺序。目前，MySQL 的执行计划采用了一种简单的贪心算法来确定连接顺序，该算法在某些场景下表现良好。
动态规划
动态规划通过递归地将复杂问题分解为更简单的子问题来简化问题。若一个问题能通过最优地解决其子问题并合并它们的解来得到最优解，则该问题具有最优子结构。此外，如果子问题嵌套在更大的问题中且动态规划方法适用，那么大问题的值与子问题的值之间存在关联。应用动态规划的两个关键属性是最优子结构和重叠子问题。
在执行计划优化的背景下，MySQL 8.0 探索了使用动态规划算法来确定最优连接顺序。这种方法可以极大提升复杂连接的性能，尽管在当前实现中仍处于实验性阶段。
摊还分析
在计算机科学中，摊还分析是一种用于分析算法复杂度的方法，具体指执行算法所需消耗的资源（如时间或内存）量。进行摊还分析的动机在于，仅考虑最坏情况下的运行时间可能过于悲观。相反，摊还分析会对一系列操作中的运行时间进行平均化处理。
MySQL 曾因每隔 60 秒清理过期认证数据库信息而经历严重的性能波动。通过将清理策略重新设计为每 0.2 秒执行一次，性能波动降至毫秒(ms)级别，测试中已无法感知这些波动。改进后的 MySQL 版本通过采用分摊处理法来减少大幅波动，从而基本消除了性能骤降现象。
Paxos
在分布式系统中，面对任意故障时保持副本间的一致性数十年来一直是研究重点。虽然简单场景下可采用朴素解决方案，但这些方案通常无法提供通用解法。Paxos 协议族专为在不可靠或易出错的处理器间达成共识而设计，其核心在于使多个参与方对单一结果达成一致——当出现故障或通信问题时，这一任务将变得极具挑战性。Paxos 家族被公认为实现三副本及以上共识的唯一经过验证的解决方案，因其能解决 2F+1 个副本间达成共识的通用问题，同时容忍最多 F 个故障。这使得 Paxos 成为状态机复制(SMR)的基础组件，也是确保集群环境高可用性的最简算法之一。
操作系统
MySQL 主要部署在 Linux 操作系统上。为了保持专注，这里的讨论基于 Linux 操作系统环境下的场景。这包括 CPU 调度、进程和线程模型、分阶段模型、内存分配以及系统调用，所有这些都与 MySQL 性能密切相关。
CPU 调度
Linux 调度器作为一个多队列调度器运行，这意味着每个逻辑主机 CPU 都有自己的运行队列，其中包含等待执行的进程。每个虚拟 CPU 都被排队在这些运行队列之一中。将虚拟 CPU 从一个运行队列移动到另一个运行队列被称为 CPU 迁移。当估计的等待时间过长、当前运行队列已满或需要填充另一个运行队列时，调度器可能会决定迁移虚拟 CPU。
在同一调度域内迁移虚拟 CPU 的成本低于将其迁移到不同域，因为核心间的缓存距离更近。
理解 CPU 调度细节对诊断 MySQL 性能问题至关重要。一个关键问题是 Linux 的调度机制能否有效管理 MySQL 中的数千个并发线程。由于 MySQL 基于线程模型运行，评估 Linux 调度器如何处理如此大量的线程非常重要。
随着用户线程数量的增加，Linux 调度器难以有效管理 CPU 时间，频繁的上下文切换导致效率低下和性能下降。为解决这一问题，系统强制执行最小执行粒度，确保每个进程在被抢占前至少运行 100 微秒。这种方法最大限度地减少了短调度间隔带来的效率损失。完全公平调度器（CFS）利用这一最小粒度，防止可运行进程数量增长时产生过高的切换开销。
基于 CPU 调度原理，MySQL 实现了事务节流机制，例如限制进入 InnoDB 事务系统的线程数量。这确保了事务的并发性保持在可控范围内。过多线程进入 InnoDB 会导致锁存争用，显著降低效率。
进程模型
在构建并发数据库系统时，内存效率至关重要。MySQL 采用基于线程的模型，相比传统 PostgreSQL 基于进程的模型更具优势，特别是在高并发场景下。PostgreSQL 的模型可能导致更高的内存消耗，而 MySQL 的线程模型在处理大量并发连接时效率更高。
线程模型
基于线程模型的挑战：
- 缓存性能：基于线程的执行模型在多客户端情况下通常导致较差的缓存性能。
- 复杂性：现代数据库管理系统软件的单体设计导致系统复杂且难以维护。
基于线程的并发性的陷阱：： - 线程管理：针对不同工作负载，预分配的工作线程数量没有最优解。线程过多会浪费资源，而过少则会限制并发性。
- 上下文切换：操作期间的上下文切换可能导致大量工作集从缓存中被驱逐，当线程恢复时会造成延迟。
- 缓存利用率：轮询调度未考虑共享缓存内容带来的优势，导致效率低下。
分阶段模型
分阶段模型是一种特殊类型的线程模型，旨在最小化处理大量并发线程时的一些缺点。该模型将数据库系统分解为不同的模块，每个模块封装成自包含的阶段，并通过队列相互连接。通过同时解决硬件和软件方面的挑战，分阶段模型为传统 DBMS 设计的局限性提供了有效的解决方案。
分阶段模型在 MySQL 中被广泛用于二级回放、Group Replication 以及 MySQL 8.0 中 Redo 日志的改进等任务。然而，由于各种队列导致的响应时间增加，它并不适合处理用户请求。MySQL 主服务器优先考虑面向用户操作的低延迟和高吞吐量，而像二级回放这样不直接与用户交互的任务，则可以用更高的延迟换取高吞吐量。
内存分配
Linux 内存管理子系统负责管理虚拟内存、按需分页以及为内核结构和用户程序分配内存。内存热点通常源于不当的数据初始化，特别是在默认的首次接触策略下，这可能导致 NUMA 节点间内存分布不均。为了缓解这一问题，应在数据将被使用的计算分区中进行初始化。
对于 MySQL 应用而言，有效利用基于 NUMA 的内存分配至关重要。测试结果表明，针对 TPC-C 类型的工作负载，在 BIOS 层面禁用 NUMA 可以提升 MySQL 主服务器的吞吐量。这一改进源于该配置为 MySQL 主服务器及类似应用提供了更优的内存分配方案。
系统调用
传统上，系统调用的性能开销主要源于模式切换时间。这一时间包括在用户模式下执行系统调用指令、切换到内核模式，最终再返回用户模式。现代处理器将这种模式切换视为处理器异常处理，涉及清空用户模式流水线、将寄存器保存到内核栈、更改保护域，并将执行导向异常处理程序。此后，需要通过异常返回来恢复用户模式的执行。
编译原理
编译原理是一门关键的计算机科学课程，涵盖编译器构建的基本原理与方法。其内容包括语言与文法、词法分析、语法分析、语法制导翻译、中间代码生成、内存管理、代码优化以及目标代码生成等主题。课程的核心是有限状态机。
有限状态机
在 MySQL 中，FSM 在词法和语法分析以及组复制中扮演着关键角色。例如，在组复制中，FSM 帮助管理 Paxos 处理期间的决策，比如在内存分配失败时是继续处理还是报错退出。通常，如果某个状态无法继续处理，它会报错退出以防止拜占庭故障。
FSM（有限状态机）同样被应用于 TCP/IP 协议中以检测异常状态。例如，服务器端 TCP 连接中出现大量 CLOSE WAIT 状态，可能意味着许多连接未能正常关闭。
MySQL 解析器
MySQL 解析器采用 C/C++实现，利用 GNU Bison 和 Flex 进行 SQL 查询解析。Flex 负责生成词法单元，Bison 则处理语法解析。SQL 解析对 MySQL 代理的读写评估及将 SQL 转换为语法树等操作至关重要。
PGO
基于配置文件的优化（PGO）是一种编译器技术，它通过使用来自被插桩程序的测试运行的性能分析数据来提高程序性能。PGO 不依赖程序员提供的频率信息，而是利用配置文件数据来优化最终生成的代码，重点关注程序中频繁执行的区域。这种方法减少了对启发式方法的依赖，只要性能分析数据能准确代表典型使用场景，就能提高性能。
排队论
排队论是研究等待线或队列的数学理论，用于预测队列长度和等待时间。它广泛应用于计算机科学和信息技术领域。例如，在网络中，路由器和交换机依赖队列来管理数据包传输。通过应用排队论，设计者可以优化这些系统以实现响应性能和高资源利用率。虽然排队论并非专门用于提升软件性能，但它作为一种模型，通过考察物理和逻辑资源的利用情况来评估系统效率。根据排队论，几乎任何资源都可以被视为队列，瓶颈资源也可通过这种方式分析以更好地理解其特性。
单队列瓶颈
图中两个 Paxos 实例之间的网络延迟约为 10ms，与实际网络延迟相符。大量实例表明 Paxos 通信本质上是串行的。在网络延迟成为主导因素的场景中，它会形成单一队列瓶颈。因此，无论并发级别如何，改进版 Mencius 的吞吐量都受限于此网络延迟。
多队列瓶颈
一个复杂的程序通常涉及多个队列，除非某个队列占据主导地位，否则可能同时存在多个瓶颈。下图展示了一个基本服务器队列模型，包含单个 CPU 和两个磁盘。当 CPU 繁忙时，请求会排队；同样，访问磁盘时也会发生排队。在此模型中，可以应用排队论来计算服务器的吞吐量能力。
不同队列瓶颈间的相互影响
在多队列瓶颈的场景中，优化一个瓶颈并不一定会带来整体吞吐量的提升；甚至可能导致吞吐量下降。现实中的例子包括在高并发情况下，Profile-Guided Optimization (PGO) 导致吞吐量降低，就体现了这一现象。
资源利用率与响应时间的关系
根据排队理论，随着资源利用率的增加，平均响应时间也会增加，当利用率接近 100%时，平均响应时间急剧恶化。
如果资源耗尽，比如内存不足，机器的响应时间可能会变得非常慢。因此，控制资源利用率至关重要。根据排队理论，对于 MySQL OLTP 系统，要保持响应时间，需要将利用率控制在特定范围内。找到最佳利用率点对维持效率至关重要，这也是事务节流理论的基础。虽然排队理论并不能直接解决问题，但它为性能优化提供了指导，并加深了对系统性能的理解。
事务节流机制
为防止性能下降，控制资源使用至关重要。对于 MySQL OLTP 应用，由于存在多个锁存队列瓶颈和全局活动事务列表的复制，管理进入事务系统的并发是关键。
计算机网络
在学校里，网络课程往往教授的是理论，但通常不会教学生如何实际分析和解决网络问题。因此，当问题出现时，许多人感到迷茫，缺乏有效解决问题所需的逻辑思维能力。虽然网络知识可以随时学习，但要找到正确的解题方法需要大量实践。正确的方法能确保问题顺利解决，而错误的方向则会大大增加解决问题的难度。
FLP 不可能性理论
在一个具有潜在进程崩溃故障的完全异步消息传递分布式系统中，Fischer、Lynch 和 Paterson 于 1985 年提出的 FLP 不可能性结果证明，使用确定性算法实现共识是不可能的。然而，实践者常常忽视这一结果，因为实际系统通常表现出一定程度的同步性。FLP 结果所假设的最坏情况调度场景在实践中不太可能发生，除非是在智能拒绝服务攻击等对抗性情况下。
FLP 不可能定理在问题解决中极具价值，因为它突显了在网络中区分消息丢失与延迟的挑战。实践中，虽然消息延迟通常有界，但像 MySQL 这样的系统可能出现长时间延迟，导致难以判断节点信息是丢失还是暂时延迟。此类误判可能引发错误，例如组复制错误地将节点报告为不可达。
// TODO