> ## Documentation Index > Fetch the complete documentation index at: https://docs.pawsql.com/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > PawSQL 是一个产品：Cloud 是公网部署形态，Engine / Optimizer / Auditor / Advisor / Patroller 是同一产品的组件与交付形态，不是彼此独立的产品。 / PawSQL is a single product: Cloud is the public deployment form, while Engine / Optimizer / Auditor / Advisor / Patroller are components and delivery forms of the same product, not separate products. > 术语以站内术语表为准：SQL 审核对应英文 SQL Review，查询重写对应 Query Rewrite，索引推荐对应 Index Recommendation；英文内容统一用 Review，不用 Audit。 / Use the site glossary for terminology: 审核 is SQL Review, 重写 is Query Rewrite, 索引推荐 is Index Recommendation; English content uses Review, never Audit. > 引用能力范围或版本支持时以对应页面为准；标注 unknown、或 status 非 published 的内容表示尚未经产品核实，不应作为事实引用。 / Cite capability scope and version support from the corresponding page; content marked unknown, or with a status other than published, is not yet product-verified and must not be cited as fact. # Distributed SQL Optimization > Optimize distributed SQL using distribution keys, cross-shard join analysis, data movement, replicated tables, and global/local index strategies. PawSQL Distributed SQL Optimization targets performance problems that are specific to distributed databases by analyzing data distribution, cross-node movement, join paths, distribution keys, and index strategies. Unlike traditional single-node databases, distributed SQL performance depends not only on access paths, but also on where data is located and whether computation can be pushed down to the nodes that own the data. ## Overview In a distributed database, a SQL statement may be logically correct and still perform poorly because of inefficient data distribution. Common problems include: * Join columns that do not align with distribution keys * Large Shuffle / Redistribute operations between nodes * Small tables that are not replicated * Predicates that are not pushed down * Data skew caused by poor distribution-key selection * Inefficient use of global or local indexes PawSQL analyzes both SQL structure and distribution metadata. ```mermaid theme={null} flowchart LR A["SQL"] --> B["Metadata & Distribution"] B --> C["Distributed Analysis"] C --> D["Rewrite / Index / Distribution"] D --> E["Optimized Plan"] ``` ## Why Distributed SQL Needs Specialized Optimization Traditional SQL optimization focuses on: * Indexes * Join algorithms * Scan types * Predicate pushdown * Aggregation and sorting Distributed databases add another set of questions: * Which node owns the data? * Can the join be completed locally? * Must data move between nodes? * Which side is suitable for broadcast? * Does the distribution key match the dominant access pattern? * Is data heavily skewed? As a result, SQL that is efficient on a single-node database may be inefficient in a distributed environment. ## Key Capabilities ### Distribution key analysis Evaluate whether table distribution keys align with common filter conditions, join predicates, and access patterns. Typical issues include: * Frequently joined tables using unrelated distribution keys * Filters that do not benefit from the distribution strategy * Low-cardinality distribution keys * Hot partitions or node-level skew ### Cross-shard join detection Identify joins that require data to cross shards or nodes. For large business tables, cross-shard joins can introduce: * Network transfer * Shuffle * Intermediate-result explosion * Coordinator pressure PawSQL can further analyze potential optimization paths. ### Data movement analysis Identify execution-plan operators such as: * Redistribute * Broadcast * Exchange * Motion * Shuffle and determine whether some of that movement can be avoided. ### Replicated table recommendation For relatively small tables that are frequently joined, such as configuration, dimension, or parameter tables, PawSQL can evaluate whether replicated or broadcast-table designs are more appropriate. Potential benefits include: * Fewer cross-node joins * Lower network overhead * Better join pushdown ### Predicate and join pushdown Analyze whether filters and joins can be pushed closer to the data nodes to reduce intermediate row volume. ### Global and local index analysis For databases that support global and local indexes, PawSQL can evaluate: * Index coverage * Partition / shard access paths * Global-index maintenance cost * Whether local indexes satisfy the query pattern ## Common Optimization Strategies ```mermaid theme={null} flowchart LR A["Align Distribution Keys
Keep frequent joins local whenever possible."] B["Reduce Data Movement
Use pushdown and rewrites to reduce Shuffle and Redistribute."] C["Use Replicated Tables
Reduce cross-node joins for frequently accessed small tables."] D["Rewrite Cross-shard SQL
Change distributed execution behavior using equivalent SQL forms."] E["Optimize Index Strategy
Choose access paths using global and local indexes."] F["Control Data Skew
Avoid hot shards and uneven node utilization."] ``` ## Example Suppose two large distributed tables use different distribution keys: ```text theme={null} orders DISTRIBUTED BY customer_id payments DISTRIBUTED BY payment_id ``` SQL: ```sql theme={null} SELECT * FROM orders o JOIN payments p ON o.customer_id = p.customer_id; ``` Because the two tables are distributed differently, the database may need to redistribute one side before completing the join. Possible optimization strategies include: 1. Changing the distribution key 2. Reducing the joined data set using filters 3. Broadcasting the smaller side 4. Rewriting or decomposing the SQL to reduce data movement 5. Introducing an additional replica or replicated table The correct strategy depends on data volume, database capabilities, and the business data model. ## Supported Scenarios Distributed SQL Optimization applies to distributed database environments such as: * TDSQL PostgreSQL * TDSQLx-MySQL * OceanBase * GaussDB * openGauss * PolarDB-X * GoldenDB * Greenplum See [Supported Databases](/en/getting-started/supported-databases) for detailed capability coverage. ## Related Capabilities ## Related Use Cases