# Execute Ddl Statement


![left](./student-guide/diagram/05-DDL-execution-01-01.png)
------------------------------------------------------------
TiDB databases support online DDL, that is, DDL operations do not lock tables, and DML statements do not block. Next, let's take a look at the modules required to execute DDL.

First, only one TiDB server is allowed to perform DDL operations for the entire TiDB database at the same time. There is a worker module in every TiDB server. This worker module is responsible for handling DDL operations. It will only be enabled if the current TiDB server role is owner.

If you have multiple TiDB Servers in your TiDB database, these TiDB Servers will rotate (by elect) to become the owner role at a fixed time. This time is called the term of office. When a TiDB Server is the owner role and is in the tenure, its worker model The block can handle DDL operations.

The current owner role information of the database is persisted in the PD. The woker module can check whether the TiDB server it is in is currently the ownere role. When the owner's term expires, the PD initiates and elects to select a new owner.

Secondly, in addition to the worker module, there is also a load schema module, which is used to load the latest schema information after the current TiDB Server becomes the ownere role. This ensures that the TiDB Server with the current owner role has the latest schema information.

Finally, the start job module is responsible for receiving DDL request and assigning IDs to DDL operations. Here, we call each DDL operation assigned an ID job.

In summary, the first part of DDL operations can be summarized as:
  - DDL statements are sent from the client to the TiDB Server, which parses (Parse) and compiles (Compile) to generate an execution plan. The process is the same as for DML statements. Please refer to the introduction of DML statements here.
  - The start job module encapsulates DDL operations and persists them in TiKV. After that, the start job will also do a job, which is to notify the worker module of the TiDB server where it is located to execute the job in TiKV, so the worker first judges whether the TiDB server it is in is the owner role, if it is executed, and if it is not, it abandons.
  - If the TiDB Server where the start job is located in the previous step is not the owner role, then we can only wait for the TiDB Server with the owner role in the TiDB database to periodically check for jobs that need to be executed in TiKV, and the job will be processed next.