Compute
Elastic Cloud Server
Huawei Cloud Flexus
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Cloud Phone Host
Huawei Cloud EulerOS
Networking
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
VPC Endpoint
Cloud Connect
Enterprise Router
Enterprise Switch
Global Accelerator
Management & Governance
Cloud Eye
Identity and Access Management
Cloud Trace Service
Resource Formation Service
Tag Management Service
Log Tank Service
Config
OneAccess
Resource Access Manager
Simple Message Notification
Application Performance Management
Application Operations Management
Organizations
Optimization Advisor
IAM Identity Center
Cloud Operations Center
Resource Governance Center
Migration
Server Migration Service
Object Storage Migration Service
Cloud Data Migration
Migration Center
Cloud Ecosystem
KooGallery
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP Filing
Support Plans
My Credentials
Customer Operation Capabilities
Partner Support Plans
Professional Services
Analytics
MapReduce Service
Data Lake Insight
CloudTable Service
Cloud Search Service
Data Lake Visualization
Data Ingestion Service
GaussDB(DWS)
DataArts Studio
Data Lake Factory
DataArts Lake Formation
IoT
IoT Device Access
Others
Product Pricing Details
System Permissions
Console Quick Start
Common FAQs
Instructions for Associating with a HUAWEI CLOUD Partner
Message Center
Security & Compliance
Security Technologies and Applications
Web Application Firewall
Host Security Service
Cloud Firewall
SecMaster
Anti-DDoS Service
Data Encryption Workshop
Database Security Service
Cloud Bastion Host
Data Security Center
Cloud Certificate Manager
Edge Security
Managed Threat Detection
Blockchain
Blockchain Service
Web3 Node Engine Service
Media Services
Media Processing Center
Video On Demand
Live
SparkRTC
MetaStudio
Storage
Object Storage Service
Elastic Volume Service
Cloud Backup and Recovery
Storage Disaster Recovery Service
Scalable File Service Turbo
Scalable File Service
Volume Backup Service
Cloud Server Backup Service
Data Express Service
Dedicated Distributed Storage Service
Containers
Cloud Container Engine
SoftWare Repository for Container
Application Service Mesh
Ubiquitous Cloud Native Service
Cloud Container Instance
Databases
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GeminiDB
GaussDB
Distributed Database Middleware
Database and Application Migration UGO
TaurusDB
Middleware
Distributed Cache Service
API Gateway
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
Multi-Site High Availability Service
EventGrid
Dedicated Cloud
Dedicated Computing Cluster
Business Applications
Workspace
ROMA Connect
Message & SMS
Domain Name Service
Edge Data Center Management
Meeting
AI
Face Recognition Service
Graph Engine Service
Content Moderation
Image Recognition
Optical Character Recognition
ModelArts
ImageSearch
Conversational Bot Service
Speech Interaction Service
Huawei HiLens
Video Intelligent Analysis Service
Developer Tools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Content Delivery & Edge Computing
Content Delivery Network
Intelligent EdgeFabric
CloudPond
Intelligent EdgeCloud
Solutions
SAP Cloud
High Performance Computing
Developer Services
ServiceStage
CodeArts
CodeArts PerfTest
CodeArts Req
CodeArts Pipeline
CodeArts Build
CodeArts Deploy
CodeArts Artifact
CodeArts TestPlan
CodeArts Check
CodeArts Repo
Cloud Application Engine
MacroVerse aPaaS
KooMessage
KooPhone
KooDrive
On this page

Show all

Best Practices of SQL Queries

Updated on 2024-05-07 GMT+08:00

Based on the SQL execution mechanism and a large number of practices, SQL statements can be optimized by following certain rules to enable the database to execute SQL statements more quickly and obtain correct results.

  • Replace UNION with UNION ALL.

    UNION eliminates duplicate rows while merging two result sets but UNION ALL merges the two result sets without deduplication. Therefore, replace UNION with UNION ALL if you are sure that the two result sets do not contain duplicate rows based on the service logic.

  • Add NOT NULL to the join columns.

    If there are many NULL values in the JOIN columns, you can add the filter criterion IS NOT NULL to filter data in advance to improve the JOIN efficiency.

  • Convert NOT IN to NOT EXISTS.

    nestloop anti join must be used to implement NOT IN, and hash anti join is required for NOT EXISTS. If no NULL value exists in the JOIN columns, NOT IN is equivalent to NOT EXISTS. Therefore, if you are sure that no NULL value exists, you can convert NOT IN to NOT EXISTS to generate hash join and to improve the query performance.

    The statements for creating a foreign table are as follows:

    DROP SCHEMA IF EXISTS no_in_to_no_exists_test CASCADE;
    CREATE SCHEMA no_in_to_no_exists_test;
    SET CURRENT_SCHEMA=no_in_to_no_exists_test;
    CREATE TABLE t1(c1 int, c2 int, c3 int);
    CREATE TABLE t2(d1 int, d2 int NOT NULL, d3 int);

    The statement for implementing the query using NOT IN is as follows:

    SELECT * FROM t1 WHERE  c1 NOT IN (SELECT d2 FROM t2);

    The plan is as follows:

    gaussdb=# EXPLAIN SELECT * FROM t1 WHERE  c1 NOT IN (SELECT d2 FROM t2);
                                       QUERY PLAN
    ----------------------------------------------------------------------------------
     Streaming (type: GATHER)  (cost=0.06..38.57 rows=3 width=12)
       Node/s: All datanodes
       ->  Nested Loop Anti Join  (cost=0.00..38.44 rows=3 width=12)
             Join Filter: ((t1.c1 = t2.d2) OR (t1.c1 IS NULL))
             ->  Seq Scan on t1  (cost=0.00..14.14 rows=30 width=12)
             ->  Materialize  (cost=0.00..18.08 rows=90 width=4)
                   ->  Streaming(type: BROADCAST)  (cost=0.00..17.93 rows=90 width=4)
                         Spawn on: All datanodes
                         ->  Seq Scan on t2  (cost=0.00..14.14 rows=30 width=4)
    (9 rows)

    Because there is no null value in the t2.d2 column (the t2.d2 column is NOT NULL in the table definition), the query can be equivalently modified as follows:

    1
    SELECT * FROM t1 WHERE  NOT EXISTS (SELECT * FROM t2 WHERE t1.c1=t2.d2);
    

    The generated plan is as follows:

    gaussdb=# EXPLAIN SELECT * FROM t1 WHERE  NOT EXISTS (SELECT * FROM t2 WHERE t1.c1=t2.d2);
                                      QUERY PLAN
    -------------------------------------------------------------------------------
     Streaming (type: GATHER)  (cost=14.38..29.99 rows=3 width=12)
       Node/s: All datanodes
       ->  Hash Right Anti Join  (cost=14.32..29.86 rows=3 width=12)
             Hash Cond: (t2.d2 = t1.c1)
             ->  Streaming(type: REDISTRIBUTE)  (cost=0.00..15.49 rows=30 width=4)
                   Spawn on: All datanodes
                   ->  Seq Scan on t2  (cost=0.00..14.14 rows=30 width=4)
             ->  Hash  (cost=14.14..14.14 rows=29 width=12)
                   ->  Seq Scan on t1  (cost=0.00..14.14 rows=30 width=12)
    (9 rows)

  • Use hashagg.

    If a plan involving groupAgg and SORT operations generated by the GROUP BY statement is poor in performance, you can set work_mem to a larger value to generate a hashagg plan, which does not require sorting and improves the performance.

  • Replace functions with CASE statements.

    The GaussDB performance greatly deteriorates if a large number of functions are called. In this case, you can modify the pushdown functions to CASE statements.

  • Do not use functions or expressions for indexes.

    Using functions or expressions for indexes stops indexing. Instead, it enables scanning on the full table.

  • Do not use != or <> operators, NULL, OR, or implicit parameter conversion in WHERE clauses.
  • Split complex SQL statements.

    You can split an SQL statement into several ones and save the execution result to a temporary table if the SQL statement is too complex to be tuned using the solutions above, including but not limited to the following scenarios:

    • The same subquery is involved in multiple SQL statements of a job and the subquery contains large amounts of data.
    • Incorrect plan cost causes a small hash bucket of subquery. For example, the actual number of rows is 10 million, but only 1000 rows are in hash bucket.
    • Functions such as substr and to_number cause incorrect measures for subqueries containing a large amount of data.
    • BROADCAST subqueries are performed on large tables in multi-DN environment.

For details about optimization, see Typical SQL Optimization Methods.

We use cookies to improve our site and your experience. By continuing to browse our site you accept our cookie policy. Find out more

Feedback

Feedback

Feedback

0/500

Selected Content

Submit selected content with the feedback