分布式SQL的“分布透明”指用户无需关心数据物理位置，系统自动完成分片定位、结果合并与故障恢复。其核心是协调器解析SQL后，经优化、分发、聚合四步执行，并依赖分片、复制和元数据服务支撑。
分布式SQL不是把单机SQL简单拆到多台机器上，而是让SQL查询能跨多个节点自动协调执行，同时保持ACID事务、强一致性和标准SQL接口。核心在于“分布透明”——用户写一条普通SQL，系统自动处理数据在哪、怎么合并、出错怎么恢复。
什么是分布式SQL的“分布透明”
用户不需要关心数据物理存储位置。比如执行 SELECT * FROM orders WHERE user_id = 123，系统会自动定位user_id=123的数据可能落在哪个分片（shard）、哪个节点，拉取结果并合并返回。这背后依赖元数据服务、分片路由和分布式执行引擎。
- 分片（Sharding）：按规则（如哈希、范围）把大表拆到不同节点，避免单点瓶颈
- 复制（Replication）：每个分片通常有多个副本，保障高可用和读扩展
- 协调器（Coordinator）：接收SQL，生成分布式执行计划，调度任务到各节点
分布式SQL查询怎么执行
一条SQL进来后，系统经历解析→优化→分发→执行→聚合四步。例如执行 SELECT COUNT(*) FROM users GROUP BY region：
- 解析：识别语法、表名、聚合字段
- 优化：判断region是否为分片键；若是，可下推到各节点本地COUNT+GROUP BY；若不是，则需全量扫描再汇总
- 分发：把子任务发给对应节点（如region='华东'的数据在node-2，就只发给它）
- 聚合：协调器收集各节点中间结果，做最终合并（如SUM COUNT）
关键点：不是所有SQL都适合分布式执行。JOIN、子查询、ORDER BY LIMIT等操作容易引发跨节点数据移动，影响性能。
常见分布式SQL系统对比要点
选型时重点关注一致性模型、SQL兼容度、扩展方式和运维成本：
- CockroachDB：强一致性（Raft共识），PostgreSQL兼容度高，自动分片+弹性扩缩容
- TiDB：MySQL协议，HTAP架构支持实时分析，依赖PD组件做全局时间戳和调度
- YugabyteDB：兼容PostgreSQL/Redis，基于DocDB存储层，适合混合负载
- 注意：传统分库分表中间件（如ShardingSphere）不算真正分布式SQL，它不管理存储，事务和复杂查询能力受限
初学者避坑提醒
刚上手容易忽略底层约束：
- 主键或唯一键必须包含分片键，否则无法定位数据
- 跨分片JOIN默认低效，优先考虑冗余字段或应用层组装
- 全局序列（如自增ID）需用UUID、雪花算法或数据库提供的分布式序列函数
- 事务范围越大，协调开销越高；尽量控制在单分片内完成
基本上就这些。理解“分布透明”和“执行下推”两个关键词，就能抓住分布式SQL的本质。不复杂但容易忽略细节。
