Distributed SQL: Architecture, Tradeoffs & Tests

What Is Distributed SQL?什么是分布式SQL？

Place this specific workflow in context with the federated queries and data virtualization guide, which connects the definitions, alternatives, validation steps, and related implementation guides.

可通过联邦查询与数据虚拟化指南理解本专题在整体流程中的位置；该指南串联了定义、替代方案、验证步骤与相关实施文章。

Distributed SQL is a relational database architecture that presents one logical SQL database while distributing data, replicas, query work and transactions across multiple nodes. Applications keep relational tables, schemas and SQL, while the database coordinates placement, routing, replication, concurrency and recovery.

分布式SQL是一种关系数据库架构：它对外呈现一个逻辑SQL数据库，同时把数据、副本、查询工作和事务分布到多个节点。应用继续使用关系表、Schema与SQL，由数据库协调数据位置、路由、复制、并发与恢复。

The definition is a category boundary, not a shared feature checklist. One product may expose a PostgreSQL wire protocol, another a MySQL-compatible interface, and another its own SQL dialect. Supported data types, extensions, constraints, indexes, isolation levels, geographic controls and transaction paths differ. Treat every compatibility or resilience claim as a hypothesis to prove with the exact edition and version.

这个定义只是类别边界，不是所有产品共享的功能清单。某个产品可能提供PostgreSQL线协议，另一个提供MySQL兼容接口，还有产品使用自己的SQL方言。受支持的数据类型、扩展、约束、索引、隔离级别、地域控制和事务路径都可能不同。任何兼容性或韧性声明都应视为需要针对准确版本和版本档次验证的假设。

Quick test: ask whether one schema and transaction contract owns the data across nodes. If independent source systems retain separate schemas and lifecycles and only share a query layer, you are closer to a distributed SQL query engine or federation—not a Distributed SQL database.

快速判断：确认跨节点数据是否由一个Schema和事务契约管理。如果独立来源仍保留各自Schema与生命周期，只共享查询层，那么它更接近分布式SQL查询引擎或联邦，而不是分布式SQL数据库。

How Distributed SQL Architecture Processes a Request分布式SQL架构如何处理请求

A client reaches a SQL endpoint.客户端访问SQL端点。
A driver, proxy or load balancer authenticates the session and selects an available SQL node. Wire compatibility does not by itself guarantee identical session settings, errors or failover behavior.
驱动、代理或负载均衡器验证会话并选择可用SQL节点。线协议兼容本身不保证会话设置、错误或故障转移行为完全相同。
The SQL layer parses, plans and authorizes.SQL层执行解析、规划与授权。
The node resolves catalogs, tables, indexes, privileges and statistics, then builds an execution plan. Some work remains local; other work becomes requests to distributed storage ranges or tablets.
节点解析目录、表、索引、权限与统计信息，然后生成执行计划。部分工作保留在本地，其他工作转为对分布式存储Range或Tablet的请求。
Metadata routes each key or span.元数据路由每个键或键范围。
A partition map identifies the responsible replica group. Point lookups may target one group; joins, scans or secondary-index access can touch many groups.
分区映射识别负责的副本组。点查可能只访问一个组；连接、扫描或二级索引访问可能涉及多个组。
Replica protocols protect each partition.副本协议保护每个分区。
A leader, leaseholder or another coordinator orders reads and writes according to the product's consistency model. A quorum or different agreement rule may be required before acknowledging a write.
Leader、Leaseholder或其他协调者依据产品一致性模型排列读写。确认写入前可能需要Quorum或其他一致规则。
The transaction layer resolves one outcome.事务层解析唯一结果。
For multi-key work, the system coordinates timestamps, locks or intents, conflict detection and atomic commit. The client still needs documented handling for retries, serialization failures and ambiguous timeouts.
对于多键工作，系统协调时间戳、锁或Intent、冲突检测与原子提交。客户端仍需按照文档处理重试、序列化失败与结果不明的超时。

Official architectures expose different names and protocols. CockroachDB documents SQL, transaction, distribution, replication and storage layers; YugabyteDB documents query and storage layers with tablets; TiDB documents SQL, placement/metadata and key-value storage components. These examples explain patterns, not one mandatory stack.

官方架构使用不同名称与协议。CockroachDB文档描述SQL、事务、分布、复制与存储层；YugabyteDB描述查询和存储层及Tablet；TiDB描述SQL、位置/元数据与键值存储组件。这些示例用于解释模式，不代表唯一强制技术栈。

Partitioning, Replication and Data Locality分区、复制与数据就近性

Distributed SQL systems commonly map relational rows and indexes into smaller key ranges, shards or tablets, then replicate each unit across failure domains. Range-based placement can support ordered scans but can hotspot on monotonically increasing keys. Hash distribution spreads keys more evenly but can make range access and locality harder. Product-managed splitting reduces manual shard operations; it does not remove the need for a workload-aware primary key.

分布式SQL系统通常把关系行与索引映射为更小的键范围、Shard或Tablet，再把每个单元复制到多个故障域。范围位置有利于有序扫描，但单调递增键可能形成热点；哈希分布更均匀，却可能增加范围访问与就近性的难度。产品托管拆分减少手工分片运维，但不会消除按工作负载设计主键的必要性。

Distribution key分布键

Test cardinality, write concentration, tenant size, time growth and query predicates. A key that balances rows may still concentrate transactions.

测试基数、写入集中度、租户规模、时间增长与查询条件。能均衡行的键仍可能集中事务。

Replica placement副本位置

Count independent failure domains, not just replicas. Confirm leaders, voters, read replicas, quorum loss and degraded behavior.

应计算独立故障域，而不只是副本数。确认Leader、投票副本、只读副本、Quorum丢失与降级行为。

Locality policy就近策略

Place common reads and writes near their users while respecting durability and residency rules. Verify data at rest and data in transit separately.

在满足持久性与驻留规则的同时，把常见读写放到用户附近。分别验证静态数据与传输中数据。

Google Cloud's Spanner schema design guidance warns that a monotonically changing first key part can concentrate high-rate inserts. TiDB's placement documentation also states that placement policies govern where data rests but do not guarantee that internal traffic remains in one region. Those are product-specific facts that illustrate why “regional” needs precise acceptance tests.

Google Cloud的Spanner Schema设计指南指出，首个键部分单调变化会集中高频插入。TiDB的位置文档也说明，位置策略控制静态数据位置，但不保证内部流量只留在一个地域。这些是特定产品事实，用来说明“区域化”必须具有准确验收测试。

Distributed Transactions, Isolation and Unknown Outcomes分布式事务、隔离与结果不明

ACID is not one latency number or one universal implementation. Ask which isolation levels are supported, whether the default differs from the source database, which anomalies are prevented, when conflicts are detected, and whether the client must retry. A transaction that stays inside one range can use a shorter path than a transaction spanning several ranges, indexes or tables. Cross-shard correctness is valuable precisely because coordination is real work.

ACID不是一个延迟数字，也不是统一实现。应确认支持哪些隔离级别、默认值是否与来源数据库不同、能防止哪些异常、何时检测冲突，以及客户端是否必须重试。留在一个Range内的事务通常比跨多个Range、索引或表的事务路径更短。跨分片正确性之所以有价值，正因为协调是真实工作。

CockroachDB documents transactions that can span ranges and tables and notes that serializable execution can require retries. YugabyteDB documents provisional records and a transaction-status path for multi-tablet transactions. TiDB documents optimistic and pessimistic transaction modes and compatibility differences around snapshots and constraint timing. Do not generalize any one protocol to the whole category.

CockroachDB文档说明事务可以跨Range和表，并指出Serializable执行可能要求重试；YugabyteDB说明多Tablet事务中的临时记录与事务状态路径；TiDB说明乐观和悲观事务模式，以及快照与约束时机方面的兼容差异。不能把某个协议概括为整个类别的统一行为。

Ambiguous timeout: if a client loses the response during commit, the write may have committed even though the client saw an error. Use a stable request or business key, bounded retry rules and a result lookup. Never turn every timeout into a blind duplicate write.

结果不明的超时：如果客户端在提交期间丢失响应，即使看到错误，写入也可能已经提交。应使用稳定请求键或业务键、有边界的重试规则与结果查询，不能把每次超时都变成盲目重复写入。

When Distributed SQL Fits—and When It Does Not分布式SQL何时适用，何时不适用

Good candidate较合适

An operational workload needs relational constraints and multi-row transactions, has measured write or storage limits, needs node/zone tolerance, and can model common operations with bounded locality.

运营工作负载需要关系约束和多行事务，存在实测写入或存储限制，需要容忍节点/可用区故障，并能让常见操作保持有界就近。

Conditional candidate有条件适用

Multi-region access, tenant placement or elastic capacity matters, but compatibility, latency and operating ownership still require a proof of concept using representative failures.

跨地域访问、租户位置或弹性容量很重要，但兼容性、延迟与运维责任仍需通过代表性故障PoC证明。

Poor candidate较不适用

The database is small and stable, one primary already meets objectives, the team cannot operate distributed failures, or the workload is an analytical federation better served without changing system-of-record ownership.

数据库小且稳定，一个Primary已满足目标，团队无法运维分布式故障，或工作负载只是分析联邦且无需改变记录系统所有权。

Do not distribute because a forecast sounds large. Establish a measured constraint: write contention, storage headroom, recovery time, maintenance availability, regional latency or a residency rule. Then compare simpler alternatives such as vertical scaling, read replicas, partitioning inside the current database, caching, archiving or a separate analytic path. Distribution adds network dependence, partial failure and repair work even when a service manages much of it.

不要因为预测数字看起来很大就实施分布。先建立实测约束：写争用、存储余量、恢复时间、维护可用性、区域延迟或驻留规则。再比较更简单的替代方案，例如纵向扩展、只读副本、现有数据库内部Partition、缓存、归档或独立分析路径。即使服务托管大量工作，分布仍会增加网络依赖、部分故障和修复工作。

Where InfiniSynapse Fits in a Distributed SQL EvaluationInfiniSynapse在分布式SQL评估中的位置

InfiniSynapse's public website describes direct connections to supported databases and multi-source joint analysis. Within an approved environment, that scope can help inspect representative connected data or reconcile bounded analytical results during an evaluation. The public page does not establish InfiniSynapse as a Distributed SQL database, SQL compatibility layer, migration engine, shard router, optimizer, replica manager, consensus service, transaction coordinator, failover manager or backup system.

InfiniSynapse官网描述了对受支持数据库的直接连接与多源联合分析。在获批环境中，这一范围可用于评估期间检查代表性已连接数据或核对有边界的分析结果。公开页面并未证明InfiniSynapse是分布式SQL数据库、SQL兼容层、迁移引擎、分片路由器、优化器、副本管理器、共识服务、事务协调器、故障转移管理器或备份系统。

Keep schema ownership, placement, constraints, transactions, access control, encryption, backups, recovery and operations in the responsible database platform. Before connected analysis, prepare approved endpoints, supported connection details, permitted schemas, primary or business keys, grain, representative queries, expected filters, observation time and a known reconciliation sample.

Schema所有权、数据位置、约束、事务、访问控制、加密、备份、恢复与运维应保留在负责的数据库平台中。进行已连接分析前，请准备获批端点、受支持的连接信息、允许访问的Schema、主键或业务键、粒度、代表性查询、预期过滤、观察时间与已知核对样本。

Inspect representative data across approved connections跨获批连接检查代表性数据

When those controls and inputs are ready, use the InfiniSynapse Web App for supported connected-source analysis and bounded result reconciliation. It does not create, migrate or operate the Distributed SQL database.

当这些控制与输入准备就绪后，可使用InfiniSynapse Web App执行受支持的已连接来源分析与有边界结果核对。它不会创建、迁移或运行分布式SQL数据库。

Analyze connected data分析已连接数据

Distributed SQL FAQ分布式SQL常见问题

What is Distributed SQL?

什么是分布式SQL？

Distributed SQL is a relational database architecture that presents one logical SQL database while distributing data, replicas, query work and transactions across multiple nodes. The category preserves relational concepts, but exact SQL syntax, driver, data type, constraint, index, isolation and transaction compatibility varies by product and version.

分布式SQL是一种关系数据库架构：它对外呈现一个逻辑SQL数据库，同时把数据、副本、查询工作和事务分布到多个节点。该类别保留关系概念，但准确的SQL语法、驱动、数据类型、约束、索引、隔离和事务兼容性会因产品与版本而异。

How is Distributed SQL different from a distributed database?

分布式SQL与分布式数据库有什么区别？

A distributed database is the broader category: it can use relational, document, key-value, wide-column or graph models. Distributed SQL is the relational subset centered on SQL, schemas and transactions. Every Distributed SQL database is distributed, but not every distributed database is Distributed SQL.

分布式数据库是更广的类别，可以采用关系、文档、键值、宽列或图模型。分布式SQL是以SQL、Schema和事务为核心的关系型子集。每个分布式SQL数据库都是分布式数据库，但并非每个分布式数据库都是分布式SQL。

Is Distributed SQL the same as sharding?

分布式SQL等同于分片吗？

No. Sharding partitions rows or key ranges across machines. Distributed SQL may automate partitioning, routing, replication and cross-shard transactions behind one SQL interface. A manually sharded set of independent SQL databases can expose SQL without providing the same single-database schema, transaction or operating contract.

不等同。分片把行或键范围分布到不同机器。分布式SQL可在一个SQL接口背后自动执行分区、路由、复制和跨分片事务。一组手工分片的独立SQL数据库虽然也能提供SQL，却未必拥有相同的单数据库Schema、事务或运维契约。

Is Distributed SQL better than NoSQL?

分布式SQL一定优于NoSQL吗？

Neither category is universally better. Distributed SQL is useful when relational modeling, joins, constraints and multi-row transactions are central. A NoSQL model can be a better fit for specialized access patterns, flexible documents or an existing ecosystem. Compare application invariants, query shapes, latency, scale, failure behavior and operating cost.

两类方案都不存在普遍优势。关系建模、连接、约束和多行事务是核心需求时，分布式SQL通常适用；对于专用访问模式、灵活文档或既有生态，NoSQL模型可能更合适。应比较应用不变量、查询形状、延迟、规模、故障行为和运维成本。

Does PostgreSQL or MySQL compatibility mean every application will migrate unchanged?

兼容PostgreSQL或MySQL是否意味着应用可以完全不改就迁移？

No. Compatibility labels can refer to wire protocol, syntax or selected features. Verify drivers, extensions, data types, collations, sequences, generated values, constraints, indexes, locking, isolation, stored code, DDL, error codes, query plans and operational tools against the exact product version.

不是。兼容标签可能只指线协议、语法或部分功能。必须针对准确产品版本验证驱动、扩展、数据类型、排序规则、序列、生成值、约束、索引、锁、隔离、存储代码、DDL、错误码、查询计划和运维工具。

Why can cross-shard transactions be slower?

为什么跨分片事务可能更慢？

A transaction that touches several ranges or tablets needs more network communication, conflict checks and commit coordination than a local operation. The actual protocol and cost are product-specific. Good key design and locality can keep common transactions bounded, but correctness should not be traded away without an explicit application design.

涉及多个Range或Tablet的事务通常比本地操作需要更多网络通信、冲突检查与提交协调。准确协议和成本因产品而异。良好的键设计与就近性可以约束常见事务范围，但不能在没有明确应用设计的情况下牺牲正确性。

How should a Distributed SQL database be tested before production?

分布式SQL数据库上线前应如何测试？

Replay representative queries and transactions; verify results, constraints and isolation; measure single-shard and cross-shard latency; test skew, hotspots, retries, connection failover, node and zone loss, rebalancing, schema changes, backup and restore. Define pass conditions from business invariants, latency objectives and recovery objectives.

应回放代表性查询与事务，验证结果、约束和隔离，测量单分片与跨分片延迟，并测试倾斜、热点、重试、连接故障转移、节点和可用区丢失、再平衡、Schema变化、备份与恢复。通过条件应来自业务不变量、延迟目标和恢复目标。

Official and Primary Sources官方与第一方来源

These documents describe specific products and versions, not one universal Distributed SQL standard. Verify current edition, license, topology, APIs, drivers, SQL and schema features, isolation, consistency, transaction limits, locality, backup, quotas, support and deprecation terms for the exact candidate.

这些文档描述的是特定产品与版本，而不是统一分布式SQL标准。必须针对准确候选验证当前版本档次、许可、拓扑、API、驱动、SQL与Schema功能、隔离、一致性、事务限制、就近性、备份、配额、支持与弃用条款。