enhencement: supplement the comment for SchemaActionType

dbms/src/TiDB/Schema/SchemaBuilder.cpp

@@ -370,7 +370,15 @@ void SchemaBuilder<Getter, NameMapper>::applyAlterPhysicalTable(DBInfoPtr db_inf
         const auto & schema_change = schema_changes[i];
         /// Update column infos by applying schema change in this step.
         schema_change.second(orig_table_info);
-        /// Update schema version aggressively for the sake of correctness.
+        /// Update schema version aggressively for the sake of correctness（for read part).
+        /// In read action, we will use table_info.schema_version(storage_version) and TiDBSchemaSyncer.cur_version(global_version) to compare with query_version, to decide whether we can read under this query_version, or we need to make the schema newer.
+        /// In our comparison logic, we only serve the query when the query schema version meet the criterion: storage_version <= query_version <= global_version(The more detail info you can refer the comments in DAGStorageInterpreter::getAndLockStorages.)
+        /// And when apply multi diffs here, we only update global_version when all diffs have been applied.
+        /// So the global_version may be less than the actual "global_version" of the local schema in the process of applying schema changes.
+        /// And if we don't update the storage_version ahead of time, we may meet the following case when apply multiple diffs: storage_version <= global_version < actual "global_version".
+        /// If we receive a query with the same version as global_version, we can have the following scenario: storage_version <= global_version == query_version < actual "global_version".
+        /// And because storage_version <= global_version == query_version meet the criterion of serving the query, the query will be served. But query_version < actual "global_version" indicates that we use a newer schema to server an older query which may cause some inconsistency issue.
+        /// So we update storage_version aggressively to prevent the above scenario happens.
         orig_table_info.schema_version = target_version;
         auto alter_lock = storage->lockForAlter(getThreadName());
         storage->alterFromTiDB(

dbms/src/TiDB/Schema/SchemaGetter.h

@@ -28,6 +28,7 @@
 
 namespace DB
 {
+// The enum results are completely the same as the DDL Action listed in the "parser/model/ddl.go" of TiDB codebase, which must be keeping in sync.
 enum class SchemaActionType : Int8
 {
     None = 0,