删除架构元素时，架构更改过程为：公共 -> 只写 -> 只删除 ->重组 ->不存在。
如果要删除的元素是 table，则此过程仅对表的架构信息进行操作，不会影响数据。因此，数据是一致的。
然而，从"公共"到"只写"的过程似乎不是原子的。在此过程中，不能先在某些节点上查询此表，然后再在所有节点上查询此表。同样，在将"只写"切换为"只删除"的过程中，不能向部分节点插入数据，逐渐不能向所有节点插入数据。在这两种情况下都存在短暂的不一致。
如果是这样，在设计基于业务模型的 TiDB 时，我是否应该考虑短暂的不一致？
没有必要考虑不一致问题。
在集群中执行 DDL 时，不同 TiDB 节点在某个时间点最多有两种模式状态。所以在从"公有"到"只写"的变更过程完成之前，集群中的一些节点仍然是公的，有些已经是只写的。