1).序列/自增
数据库序列（Sequence）的核心工作是生成一组唯一的、递增的数字（或字符），通常用于为数据库表的主键或唯一标识符提供可靠的、自动生成的数值。它在许多数据库管理系统（如 PostgreSQL、Oracle、DB2）中是一个独立于表的标准对象，有些数据库则采用自增列的方式来实现（如MySQL、SQL Server)。序列的主要工作职责：一是提供唯一性保证，这是序列最核心的任务，其通过内部机制（通常是一个计数器），保证每次调用返回的值在当前序列的上下文中是唯一的；二是顺序性生成，序列生成的数字默认是连续递增（或递减）的，尽管在分布式或高并发场景下可能会出现间隔，但总体上保证数值是单调递增的；三是高效分配机制，序列提供了一种机制来快速分配唯一值，避免了在应用层生成主键的锁竞争和协调复杂性；四是独立于事务，序列值的生成通常不依赖于具体的事务提交与否。一旦被调用并获得一个值，即使该事务随后回滚，这个值通常也不会被回滚或重用，这确保了值的唯一性不会因事务失败而受到影响（但也意味着序列值可能有“空洞”）。
在分布式数据库中使用序列的核心挑战在于：如何在保证全局唯一性的前提下，解决单点故障、性能瓶颈、顺序性与“空洞”、复杂性等问题。例如，如果数据库采用单个序列生成器，则很容易成为性能瓶颈和单点故障。通常在分布式数据库中避免采用单一中心点，可采用上述分布式策略（内置分布式序列、分段分配、Snowflake、UUID）或使用高可用的中央协调服务集群（如 etcd），确保序列生成机制本身具有容错能力。在性能方面则推荐采用预取缓存或其他分布式方案，后者如分段分配、Snowflake、UUID等方式本质上具有更高的扩展性和并发性能。在具体使用上则优先选择并使用好分布式数据库内置的主键或序列生成机制。如果内置机制不满足需求或需要自研，则应仔细权衡分段分配、Snowflake类算法、UUID等方案的优缺点（唯一性、有序性、长度、性能、复杂度），特别注意避免单点故障和缓解性能瓶颈（如缓存），并在涉及时间戳的方案中严格保障时钟同步。明确业务对“连续无空洞”的真正需求，通常空洞是可接受的。
2).存储过程
在分布式数据库中使用存储过程，相比单机数据库引入了更多复杂性和需要特别注意的问题，核心挑战在于如何管理分布式环境下的数据一致性、事务、性能和复杂性。在一致性和事务方面，分布式事务因存在网络开销大，性能差等问题，需在强一致性（延迟高、阻塞风险）和弱/最终一致性（设计复杂）之间权衡选择。在性能方面，分布式环境下存在网络延迟、序列化开销、协调开销、全局锁等都可能成为新瓶颈，此外数据分布情况下，跨分片访问昂贵，也会对性能造成较大影响。在复杂性方面，分片键设计、分布式事务监控、跨节点部署/更新、异常调试困难会加大使用复杂性。
总之，在分布式数据库中使用存储过程，首先考虑其必要性。建议尽可能将复杂的业务逻辑放在应用层处理，利用其更强大的计算、状态管理和容错能力。如果必须使用，也应遵循精简逻辑，避免复杂业务规则，聚焦核心数据操作。深入理解你所使用的特定分布式数据库关于存储过程执行模型、事务支持、分片策略和容错机制的细节，严格遵守其最佳实践。
3).触发器
在分布式数据库中使用触发器相比单机数据库存在更多风险和复杂性，其核心挑战在于 "被动触发行为的分布式传播与状态管理"。一方面，分布式环境下触发器会存在修改其他分片数据的情况，此时会触发隐式的跨分片事务或分布式查询，性能极差且易出错。如果有级联情况，则情况会更为复杂且难以调试。
因此，在分布式数据库中，使用触发器需要极度谨慎，甚至极力避免。避免使用是第一选择： 强烈建议重构业务逻辑，将触发器的功能（如数据同步、审计、复杂校验、级联更新）移至应用层显式实现。 应用层拥有对分布式事务、重试、幂等性和错误处理的完全控制能力。其次，如果必须使用，也应遵循触发器逻辑百分百只操作修改所在同一个分片键分区内的数据。严格禁止在触发器内执行任何可能导致访问或修改其他分片的操作。
4).约束-主键
在分布式数据库中，主键的设计不再仅仅是保证唯一性和提供索引效率，它直接决定了数据的物理分布、查询性能、事务效率和可扩展性。与单机数据库相比，复杂性显著增加。一方面，在分布式数据库中，主键与分片键存在强关联，两者可以不同，但主键必须包含分片键的所有列。其背后的原因是因为分布式数据库通过主键必须包含分区键的约束，使得数据库能够通过分片键快速定位到具体分片，并在该分片内验证主键唯一性。而且，分片键一旦选定，不会轻易修改，更改通常是代价极高的操作。此外，分布式数据库还需考虑热点问题，如通过单一或少量分片承载过高负载（写入/读取），导致集群性能瓶颈，因而应摒弃单调递增主键在范围分片的使用，后者会导致所有新数据都写入最后一个分片（或按范围分片时的末尾范围），造成严重写入热点。通常建议选择全局唯一但有高散列性的字段作为主键为上。
5).约束-外键
在分布式数据库中使用和设计外键相比单机数据库存在本质性差异和重大挑战。核心矛盾在于 "分布式环境难以高效实现跨节点/分片的强一致性与原子性约束"。单机库中，外键验证是本地操作（检查同一实例中的关联表），开销可控。在分布式中，外键引用的主表和被引用表很可能存储在不同节点/分片上。这就存在跨分片查询验证问题，通常需要向父表所在的分片发送远程查询或事务请求。每次约束检查都可能引入显著的网络往返延迟，严重拖慢写入性能（尤其是高频插入或批量导入）。高效的约束检查通常需要父表的唯一键（主键） 在所有节点上有全局索引，这意味着插入父表本身也需要进行跨节点的全局唯一性检查，而维护全局索引的代价很高。同样，外键约束涉及修改多个表（或多个分片），需要保证原子性。分布式数据库中，即使单次操作只修改子表的一行，如果该行引用了父表在不同分片上的键，该操作也会升级为跨分片事务，如产生级联操作则更是一场灾难。
在分布式数据库中，极其不推荐使用传统的外键约束，除非业务场景极其简单且数据库明确支持并能保证性能可接受。首选方案是在业务逻辑层（应用代码）显式地、原子性地管理数据的插入、更新、删除顺序和验证关联关系。避免数据库隐式开销。可灵活选择弱一致性模型。如一定要在库内实现，则可考虑应考虑共位设计，即父表和子表使用相同的分片键，则它们通常存储在同一分片上。此时在同一分片内执行操作，约束检查变为本地操作，性能大幅提升。因此如果必须使用分布式数据库的外键，务必进行充分的性能测试、设置严格约束、禁用级联操作，并深刻理解特定数据库的实现机制和限制。分布式系统的核心优势在于可扩展性和分区容忍性。外键约束（尤其是强制强一致性的外键）在很大程度上与这些优势背道而驰，谨慎评估其必要性是所有分布式数据库设计的必修课。
6).约束-唯一
在分布式数据库中设计和使用唯一约束面临的核心挑战是 “如何在数据分散存储的背景下高效实现全局唯一性验证”。与单机唯一性检查仅需本地查找不同，分布式数据库中唯一键值可能分布在任意节点上，验证需跨节点通信 和全局状态协调。这不可避免会受到网络延迟的影响，并进而影响吞吐量，想象下在高并发或大批量写入中，唯一性检查所带来的性能损耗是巨大的。一般要求唯一约束列必须包含分片键，这样只需在本地分片验证唯一性（高效单片操作），否则就需要引入全局索引来维护唯一性，但后者也面临高昂的维护成本。
在分布式数据库中，唯一性约束优先考虑在应用层实现，这样可避免这一高昂成本的操作。如必须在数据库中执行，可通过绑定分片键的方式将其转换为本地操作，降低开销；拒绝可能的跨分片唯一性约束。
7).全局索引
分布式数据库中，有本地索引与全局索引的区别。本地索引是指与主表分片一一对应，绑定在一起；全局索引则是独立于主表分片，可拥有自己的分片策略，可以理解为“另一张表”。全局索引，主要是用于加速非分片键查询的核心机制，但其设计与使用存在显著挑战。与本地索引的本质差异在于：数据位置分散性、网络通信开销、跨节点事务成本。全局索引因为需要跨节点更新索引条目（远程写入），不可避免地引入了分布式事务来保证原子性，进而导致写入延迟加大，高并发场景全局索引成为瓶颈。
是使用中，分布式数据库优选使用本地索引，或者通过分片键的冗余设计将原本需要全局索引的转换为本地索引。此外也可以在允许的情况下，采用异步索引机制或干脆使用外部索引引擎来避免此部分开销。
8).分区
在分布式数据库中，有两个容易混淆的概念就是“分片”和“分区”，很多数据库甚至就是不区分的。一般来说，分布式数据库中的分片，是指数据库依据用户设置的分片规则或系统内置规则将表的数据分布到多个节点上，以实现负载均衡和高并发处理能力。而分区则是一种逻辑概念，即在 SQL 层面定义 Range、List、Hash 等分区策略，从而进一步优化查询性能、管理大表数据、支持按时间归档等场景。分区概念之前在如Oracle数据库中，其定义更像现在的分片概念，是一种物理存储上的划分，只不过不是分布在不同节点，而是在一个节点的不同存储区域（段）。因此这部分还要看不同数据库的实现原理是什么，没有统一之规。
9).分片
分布式数据库的核心在于数据分片，支持拆分方式越多、数据拆分越均衡对未来等运行效率越有帮助。这里重点关注下数据拆分的自动与手工。随着分布式数据库被越来越多的用户所使用，如何降低用户选择使用分布式的门槛成为关键。一个核心问题就是是否能实现数据的自动拆分，而不需要人工介入。这里重点对比下两种策略
