# TiDB Server

+ Handling client connections
+ Parsing and compiling SQL statements
+ Relational and KV data transformation
+ SQL statements execution
+ Online DDL execution
+ Garbage collection (GC)

```
ID                Role    Host        Ports        OS/Arch       Status   ~!@Data Dir@!~    Deploy Dir
--                ----    ----        -----        -------       ------   --------    ----------
...
10.0.0.158:4000   tidb    10.0.0.158  4000/10080   linux/x86_64  Up       ~!@-@!~           /tidb-deploy/tidb-4000
...
```

![`smart`](TiDBServerSimple_aa_001_20220506.png)

------------------------------------------------------------------------
TiDB server itself is only responsible for the SQL computing engine and does not store data, so TiDB server is stateless. When facing a large number of concurrent connections, we can achieve load balancing by adding TiDB servers to improve the concurrent processing capability.

Handling client connections
- Users are authenticated by username and password, and the connected users can be authorized hereafter. These tasks are mainly done by the Protocol Layer module.

Parsing and compiling SQL statements
- After receiving to the SQL statement, TiDB server parses and compiles it. During the compilation process, it optimizes and generates an execution plan. These tasks are done by the Parser and Compiler modules.

Relational and KV data transformation
- Since data is stored on TiKV in the form of key-value (KV), there is a big difference between relational data (tables, indexes, and rows) and KV structures. TiDB is responsible for converting between relational data and KV storage.

SQL statements execution
- According to the compiled execution plan, it is executed on TiKV in batches. The data is read by the `Executor` module and the `DistSQL` module, and the transaction related operations are completed by the `Transaction` module and the `KV` module.

Execution of online DDL
- In TiDB, DDL operations do not lock tables. They are done by the `Schema Load` module, the `Worker` module, and the `Start Job` module. TiDB uses the online asynchronous schema change algorithm to support changing metadata objects. When a transaction is executed, it obtains the corresponding metadata snapshot at the transaction start. If the metadata is changed during a transaction, to ensure data consistency, TiDB returns an `Information schema is changed error` and the transaction fails to commit. In another training course: `TiDB SQL for Developers`, you can get more information about online DDL and how to deal with this situation to keep your DDL and DML running smoothly at the same time. Or, you can just simply watch this video on `YouTube PingCAP Learning` channel - `https://www.youtube.com/watch?v=d8jAtSzI6GY`.   

Garbage collection
- The `GC` module is responsible for recovering space from old versions that have expired, and this portion will be explained in the TiKV related chapters.