分布式数据库复杂 SQL 优化经验能否结合示例详细讲讲？

不同的分布式数据库，可能有不同的处理方法，以下仅以我行实施的td为例。
td以mysql为基础，对其进行改造，并在其之上设计代理proxy，代理主要功能有路由、抽取、缓存、汇聚等。
td核心为分表键shardkey，一个表拆分为若干分区，分散至各数据节点，记录根据分表键的hash值按固定规则分配，落到对应数据库节点。
所以，对于单表的查询，如果条件中带有shardkey并指定值，那么代理就能明确知道数据所在的数据库节点，可以智能路由至对应节点查询，效率就会高。如果没有指定shardkey值，代理只能将sql分发至所有节点，并将查询结果在代理汇集，效率相对低，并占用更多计算资源。
多表关联，差异更大。如果关联的两表有shardkey互等，那么关联记录必然都落在同一个数据库节点，代理将sql分发至各节点查询，并汇聚结果即可。如果关联条件没有shardkey互等，那么关联数据就不会落在同一数据库节点，数据库节点并不能互相数据访问查询，只能由代理将关联表的所有记录抽取至代理服务器，再执行语句，效率就极差。
此外还设有全局表，单表等形式的表，方便特定条件的关联查询。
分片表和全局表的关联，任何情况无需拉表，因为全局表每个数据库节点有全量数据。
回到最初的sql优化，如果理解了以上设计原理，那么语句的优化方法就不难分析设计了。
如帐户类信息表，关联查询多以帐户关联，那么可以设这些表的分表键为帐号字段。但如果增加客户信息的关联查询，那么以上方式就不合适了，但优化方式是使关联数据落于同一节点，那么可以所有帐户信息表增加客户号字段冗余，并以客户号为分表键即可。即使以帐号相笔为关联条件，也可再增加客户号关联条件。
所以td的优化，更多的是表的设计，分表键的设计的优化，语句只是配合。
复杂的关联查询，永远无法统一分表键的情况，将一个语句分成两个或多个即可。
具体的sql及示例就不再列举了。