TiDB handles the SQL statement using the
schema of the time and supports online asynchronous DDL change. A DML statement and a DDL statement might be executed at the same time and you must ensure that each statement is executed using the same
schema. Therefore, when the DML operation meets the ongoing DDL operation, the
Information schema is changed error might be reported. Some improvements have been made to prevent too many error reportings during the DML operation.
Now, there are still a few causes for this error reporting:
- Cause 1: Some tables involved in the DML operation are the same tables involved in the ongoing DDL operation. To check the ongoing DDL operations, use the
ADMIN SHOW DDLstatement.
- Cause 2: The DML operation goes on for a long time. During this period, many DDL statements have been executed, which causes more than 1024
schemaversion changes. You can modify this default value by modifying the
- Cause 3: The TiDB server that accepts the DML request is not able to load
schema informationfor a long time (possibly caused by the connection failure between TiDB and PD or TiKV). During this period, many DDL statements have been executed, which causes more than 100
- Cause 4: After TiDB restarts and before the first DDL operation is executed, the DML operation is executed and then encounters the first DDL operation (which means before the first DDL operation is executed, the transaction corresponding to the DML is started. And after the first
schemaversion of the DDL is changed, the transaction corresponding to the DML is committed), this DML operation reports this error.
In the preceding causes, only Cause 1 is related to tables. Cause 1 and Cause 2 do not impact the application, as the related DML operations retry after failure. For cause 3, you need to check the network between TiDB and TiKV/PD.
- Currently, TiDB does not cache all the
- For each DDL operation, the number of
schemaversion changes is the same with the number of corresponding
schema stateversion changes.
- Different DDL operations cause different number of
schemaversion changes. For example, the
CREATE TABLEstatement causes one
schemaversion change while the
ADD COLUMNstatement causes four.