preface
This article will take a preliminary look at how the ShardingSphere execution engine works
How to understand an execution engine
First of all, let’s take a look at the official documentation
The target
We know that the execution engine is designed to make efficient use of the valuable resource of database connections, but how does that work?
scenario
Let’s start with a few scenes:
In the case of partition table, a SQL query may fall on multiple partition tables during the actual execution, so it leads to the problem of allocation of join number:
- For each sub-table query, a join is allocated, which is the most efficient;
- However, assuming that there are 100 sub-tables, 100 connections are required, which greatly increases the overhead of database connection count;
- If only one connection is allocated to handle the query operations of the 100 sub-tables, it needs to be executed sequentially and the results of each execution need to be loaded into memory.
Connection mode
Based on the above scenario, ShardingSphere provides two connection modes:
Memory limited mode
There is no limit on the number of database connections. If you operate on 10 sub-tables, 10 database connections are allocated
This mode is suitable for a small number of connections
Connection restriction mode
Strictly control the number of database connections, assuming that the operation of 100 sub-tables, only 1 database connection is allocated, the operation of sub-tables, serial processing
Automatic selection
As mentioned above, the execution engine automatically selects the appropriate connection mode for different scenarios when it is actually working, based on the following formula:
