DBLE Query Process: Simple and Complex Queries Overview

In the previous session we introduced basic splitting algorithms and configuration; this article now focuses on other DBLE features, particularly its query processing flow.

dble query flow diagram

Basic DML has been covered earlier; here we discuss complex queries, which include cross‑database distributed queries, aggregation functions, JOIN, UNION, sub‑queries, complex expressions, and views. DBLE supports all except correlated sub‑queries.

The processing starts from the client, passes through a NIO‑based network layer, then follows the MySQL protocol. DBLE fully supports the MySQL protocol, converting binary TCP packets into SQL statements for parsing.

1. Simple Query

A simple statement such as select * from table where id=? is routed to the appropriate data node, sent via the MySQL protocol to the backend MySQL pool, and the result is returned directly unless additional merging is required (e.g., select * from table where id in(1,2,3) which may involve multiple nodes and a simple merge).

2. Complex Query

Complex queries like JOIN and UNION are parsed into a query plan tree. For example, a JOIN between two tables forms a binary tree where leaf nodes represent base queries sent to MySQL, and parent nodes aggregate results using counters until the root node produces the final result, which is then wrapped back into the MySQL protocol.

An operational example demonstrates two tables: tb_mod (sharded by modulo 4 across four nodes) and jump_hash (sharded by consistent hash across two nodes). The example shows how data distribution differs between the two tables.

For further details, refer to the DBLE project repositories:

https://github.com/actiontech/dble https://github.com/actiontech/dble-docs-cn https://github.com/actiontech/dble-test-suite

Course inquiries and community links are provided at the end of the article.