DDL statement execution method and apparatus
By introducing transaction management lock information during the execution of DDL statements, the problem of inconsistent execution of DDL statements in distributed databases is solved, effective lock control and concurrent processing are achieved, and execution efficiency is improved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING OCEANBASE TECHNOLOGY CO LTD
- Filing Date
- 2023-04-27
- Publication Date
- 2026-05-15
AI Technical Summary
Distributed databases lack a complete locking mechanism when executing DDL statements, which makes it impossible to keep the execution of DDL statements consistent with the control of locks, and makes it impossible to effectively coordinate the execution of multiple DDL statements. Furthermore, traditional methods result in low efficiency in concurrent execution.
By initiating transactions during the execution of DDL statements, recording the target lock information corresponding to the DDL statements, and deleting the target lock information after the transaction is successfully committed, a robust lock management mechanism is provided to ensure the consistency between lock operations and transaction states.
It achieves consistent execution of DDL statements and effective lock control, enabling the concurrent processing of multiple DDL statements and improving execution efficiency and flexibility.
Smart Images
Figure CN116501812B_ABST
Abstract
Description
Technical Field
[0001] This specification relates to the field of database technology, and more particularly to a method and apparatus for executing DDL statements. Background Technology
[0002] With the development of computer technology, distributed databases have been widely used in various fields. However, when executing DDL statements, distributed databases in related technologies lack a complete locking mechanism, making it impossible to maintain consistency between the execution of DDL statements and the distributed database's control over locks, thus hindering the effective coordination of the execution of multiple DDL statements. Summary of the Invention
[0003] In view of the above, one or more embodiments of this specification provide a method and apparatus for executing DDL statements.
[0004] To achieve the above objectives, one or more embodiments of this specification provide the following technical solutions:
[0005] According to a first aspect of one or more embodiments of this specification, a method for executing DDL statements is provided, comprising:
[0006] In response to an execution request for a Data Definition Language (DDL) statement, a transaction is started. The transaction is used to execute the DDL statement.
[0007] Within a transaction, the target lock information corresponding to the DDL statement is recorded. The target lock information is used to indicate the parameters of the locks that the DDL statement adds to the database object during execution.
[0008] In response to a successful transaction commit, the target lock information is deleted to complete the execution of the DDL statement.
[0009] According to a second aspect of one or more embodiments of this specification, a DDL statement execution apparatus is provided, comprising:
[0010] The Start module is used to start a transaction in response to an execution request for a Data Definition Language (DDL) statement. The transaction is used to execute the DDL statement.
[0011] The recording module is used to record the target lock information corresponding to the DDL statement within a transaction. The target lock information is used to indicate the parameters of the lock added to the database object during the execution of the DDL statement.
[0012] The delete module is used to delete the target lock information in response to a successful transaction commit, thus completing the execution of the DDL statement.
[0013] According to a third aspect of one or more embodiments of this specification, an electronic device is provided, comprising:
[0014] processor;
[0015] Memory used to store processor-executable instructions;
[0016] The processor implements the method described in the first aspect by running executable instructions.
[0017] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method as described in the first aspect.
[0018] The DDL statement execution method provided in this manual initiates a transaction in response to an execution request for a Data Definition Language (DDL) statement. Within the transaction, it records the target lock information corresponding to the DDL statement. Finally, upon successful transaction commit, it deletes the target lock information, thus completing the DDL statement execution. This solution integrates lock operations during DDL statement execution into the transaction, providing a robust lock management mechanism. This ensures consistency between DDL statement execution and lock control, enabling the coordination of concurrent processing of multiple DDL statements. Attached Figure Description
[0019] Figure 1 This is a flowchart illustrating a DDL statement execution method provided in an exemplary embodiment.
[0020] Figure 2 This is a schematic diagram illustrating the execution process of a DDL statement as provided in an exemplary embodiment.
[0021] Figure 3 This is a schematic diagram illustrating the execution process of another DDL statement provided in an exemplary embodiment.
[0022] Figure 4 This is a schematic diagram of the structure of a device provided in an exemplary embodiment.
[0023] Figure 5 This is a schematic diagram of the structure of a DDL statement execution device provided in an exemplary embodiment. Detailed Implementation
[0024] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.
[0025] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.
[0026] To facilitate understanding, the terms used in this instruction manual will be explained first.
[0027] Data Definition Language (DDL) is used to define database objects such as databases, tables, columns, and indexes. By executing DDL statements, operations such as creating indexes in tables and adding new columns to tables can be performed.
[0028] Locks are one of the methods used for concurrency control in databases. During the execution of database statements (such as DDL statements), locks can be added to the objects on which they are applied, thereby avoiding conflicts with other operations in the database. The conflict behavior between locks depends on the lock mode. Common lock modes in databases include shared locks (SHARE, S), exclusive locks (EXCLUSIVE, X), row-level shared locks (ROW SHARE, RS), and row-level exclusive locks (ROW EXCLUSIVE, RX).
[0029] The conflict relationships between the various lock modes are shown in Table 1 below:
[0030] Table 1. Conflict relationships between different locking modes
[0031]
[0032]
[0033] In Table 1, lock modes that conflict with each other cannot be applied to the same database object by different database statements. For example, when a DDL statement is used to modify the attributes of a specified table in the database, the DDL statement can add an exclusive lock on that specified table. In this case, since the exclusive lock is in conflict with any lock mode, other database statements besides this DDL statement cannot add any lock mode to that specified table again. That is, before the exclusive lock is released, other statements in the database cannot operate on that specified table.
[0034] Because distributed databases do not have a complete locking mechanism when executing DDL statements, the execution of DDL statements cannot be kept consistent with the distributed database's control over locks, thus making it impossible to effectively coordinate the execution of multiple DDL statements.
[0035] In related technologies, to ensure that DDL statements in distributed databases can be executed correctly, a DDL queue approach is usually adopted. That is, according to the type of DDL statement, it is added to a designated queue, and each queue processes the DDL statements in order. Therefore, although this approach can ensure that DDL statements are executed correctly, it also causes DDL statements in the same queue to be unable to be executed concurrently, resulting in low execution efficiency.
[0036] Furthermore, since distributed databases have multiple nodes, the execution of DDL statements may involve tables or partitions on multiple nodes. Therefore, the locking mechanism of DDL statements in traditional single-machine databases cannot be applied to distributed databases.
[0037] In view of this, the solution provided in this specification initiates a transaction in response to an execution request for a Data Definition Language (DDL) statement, then records the target lock information corresponding to the DDL statement within the transaction, and finally deletes the target lock information in response to a successful transaction commit, thereby completing the execution of the DDL statement. The solution provided in this specification integrates lock operations during DDL statement execution into the transaction, providing a robust lock management mechanism that ensures consistency between DDL statement execution and lock control, thus enabling the coordination of concurrent processing of multiple DDL statements.
[0038] The following will describe the exemplary implementation method in detail with reference to the accompanying drawings and embodiments.
[0039] First, this specification provides a method for executing DDL statements, which can be executed by any electronic device.
[0040] Figure 1 This is a flowchart illustrating a DDL statement execution method provided in an exemplary embodiment, such as... Figure 1 As shown in the embodiments of this specification, the DDL statement execution method includes the following steps.
[0041] S101, in response to an execution request for a DDL statement, initiate a transaction, which is used to execute the DDL statement.
[0042] It should be noted that a transaction comprises a series of operations on the database, which are either all executed or none are executed; it is an indivisible unit of work. In distributed databases, the tables or partitions involved in a transaction may be located on the same node or on different nodes; this specification does not impose any restrictions on this.
[0043] The transactions in the embodiments of this specification include a series of operations for executing DDL statements, such as locking and unlocking operations of the database objects on which the DDL statements act, and recording operations of target lock information.
[0044] S102, Record the target lock information corresponding to the DDL statement within the transaction. The target lock information is used to indicate the parameters of the lock added to the database object during the execution of the DDL statement.
[0045] It should be noted that the database object can be a table or partition in a database, and this disclosure does not limit this. For example, when using DDL statements to create a local index on a table, it is necessary to add a shared lock to the table and row-level exclusive locks to all partitions of the table.
[0046] In some embodiments, target lock information may include one or more of transaction identifier, DDL identifier, lock mode, and lock state.
[0047] The transaction identifier is used to indicate the transaction used to record the target lock information. The transaction identifier is assigned by the database when a transaction is started. For example, if the target lock information is recorded within transaction A, then the transaction identifier of the target lock information is the transaction identifier of transaction A.
[0048] A DDL identifier is used to indicate the DDL statement corresponding to the target lock information, and it can be obtained before the transaction begins. For example, DDL identifiers are unique; the DDL identifier corresponding to the same DDL statement is the same.
[0049] Lock mode refers to the lock mode added to a database object by a DDL statement. As mentioned earlier, based on the requirements of the DDL statement, lock modes can be divided into shared locks, exclusive locks, row-level shared locks, and row-level exclusive locks.
[0050] A lock can be in a pending lock state, a locked state, or a pending unlock state. The pending lock state indicates that the database object affected by the DDL statement is not yet locked, but has been reserved for locking. The locked state indicates that the database object affected by the DDL statement is already locked. The pending unlock state indicates that the lock on the database object affected by the DDL statement has not yet been released, but has been reserved for release.
[0051] For example, target lock information is recorded in a pre-configured lock record set, which is mapped to database objects. This lock record set can be maintained by a lock service within the database. The lock service can detect the identifier of a database object, allowing the database object affected by a DDL statement to be mapped to the corresponding lock record set. This enables modification or viewing of all lock information related to the database object within that lock record set.
[0052] In some embodiments, target lock information can be recorded in the form of tuples. For example, target lock information can be a four-tuple including transaction identifier, DDL identifier, lock mode, and lock state. By adding this four-tuple to a pre-configured lock record set, the recording operation of target lock information can be realized.
[0053] It should be noted that the recording operations for the target lock information are performed within the transaction to ensure consistency between the target lock information and the transaction state. This avoids situations where locks on database objects are not released after the transaction is committed, or locks on database objects are released before the transaction is committed.
[0054] S103, in response to a successful transaction commit, remove the target lock information to complete the execution of the DDL statement.
[0055] It should be noted that after a transaction is successfully committed, the target lock information can be deleted, thereby releasing the lock on the database object affected by the DDL statement to prevent it from affecting the execution of other statements in the database.
[0056] The embodiments in this specification integrate the locking mechanism of DDL statements into transactions, ensuring the consistency between the lock state and the transaction state. That is, locks are added when a transaction starts and released after the transaction is committed, thus providing a complete lock management scheme and reducing conflicts and errors in the execution of DDL statements.
[0057] In some embodiments, prior to S102, the validity of the target lock information can be verified based on the lock record set. If the target lock information is invalid, the transaction is rolled back to terminate the execution of the DDL statement.
[0058] The verification method for the target lock information can be as follows: traverse all lock information in the lock record set. If there is lock information in the lock record set that conflicts with the lock mode of the target lock information and has a different transaction identifier, then the target lock information is invalid.
[0059] It should be noted that when transaction identifiers are the same but lock modes conflict, the conflicting lock modes can be merged or the lock can be upgraded, and the target lock information remains valid.
[0060] In some embodiments, there can be multiple transactions, which are chained together to execute DDL statements. In this case, the target lock information corresponding to the DDL statement can be recorded in the first transaction among the multiple transactions. The lock state of the target lock information is a pending lock state, which is used to indicate that the database object to be locked by the DDL statement is about to be locked. This prevents other operations in the database from preemptively locking the database object during the locking process, thus preventing the DDL statement from being unable to lock the database object.
[0061] For example, if the first transaction in a set of transactions commits successfully, the lock status of the target lock information is changed to the locked state, thus indicating that the lock corresponding to the DDL statement is effective; otherwise, the DDL statement cannot be executed.
[0062] In some embodiments, where there are multiple transactions that are chained together, the lock status of the target lock can be queried during the execution of the last transaction. If the target lock is in a locked state, its lock status is changed to a pending unlock state to avoid conflicts between subsequent unlock operations on the database object affected by DDL statements and other lock operations on that database object. If the target lock is in a state other than locked, it means that the target lock is still occupied. In this case, it can be waited for to become locked before being changed to a pending unlock state to avoid unlocking failure or premature unlocking before the transaction ends.
[0063] The target lock information can be queried using DDL identifiers. By obtaining the DDL identifier corresponding to the DDL statement, the target lock information can be retrieved based on the DDL identifier, thus obtaining the lock state recorded in the target lock information.
[0064] For example, when the lock status of the target lock information is pending unlocking, the target lock information can be deleted in response to the successful commit of the last transaction among multiple transactions, thereby releasing the lock on the database object on which the DDL statement is applied, so as not to affect the execution of other statements in the database.
[0065] For example, if the last transaction in a set of transactions fails to commit, the lock status of the target lock information is changed to a locked state to prevent the lock from being released prematurely before the transaction corresponding to the DDL statement is committed.
[0066] The DDL statement execution methods provided in this manual integrate locks during DDL statement execution with transactions, thus achieving flexibility, transactionality, and high availability. For example, the solution provided in this manual can flexibly meet the concurrency requirements between DDL statements. When creating a local index, a shared lock needs to be added to the main table, and row-level exclusive locks need to be added to all partitions of the main table. Since shared locks do not conflict with each other, and row-level exclusive locks do not conflict with each other, the method provided in this manual can concurrently execute multiple index creation tasks on the same table.
[0067] The above describes the execution methods of DDL statements provided in this manual. For ease of understanding, the following will combine... Figure 2 and Figure 3 The lock handling methods for DDL statements in a single transaction and DDL statements in multiple transactions are introduced separately.
[0068] Figure 2 This is a schematic diagram of the execution process of a DDL statement provided in an exemplary embodiment. The DDL statement can be executed within a transaction that modifies database metadata.
[0069] Please refer to Figure 2 In this embodiment, upon receiving a DDL statement, a transaction corresponding to the DDL statement is first initiated. Then, during the execution of the transaction, the lock information corresponding to the DDL statement is recorded. Finally, after the transaction is committed, the lock information is deleted.
[0070] Specifically, lock information can be recorded in the following ways:
[0071] (1) Add a lock to the database object affected by the DDL statement by specifying the lock mode.
[0072] (2) Verify whether the added lock conflicts with other locks in the lock record set.
[0073] If there is a lock information in the lock record set that conflicts with the lock mode and the added lock, and the transaction identifier is different from the transaction identifier of the current transaction, then the lock information of the lock added in step (1) is invalid and the DDL statement cannot be executed.
[0074] If the lock information added in step (1) is valid, then the valid lock information is recorded in the lock record set.
[0075] Figure 3 This is a schematic diagram illustrating the execution process of another DDL statement provided in an exemplary embodiment. This DDL statement requires execution through multiple transactions that modify database metadata, wherein the multiple transactions are concatenated (e.g., Figure 3 (Transactions A, B, and C in the context of the transaction).
[0076] Please refer to Figure 3 In this embodiment, the execution of the DDL statement requires three transactions: Transaction A, Transaction B, and Transaction C. Upon receiving the DDL statement, Transaction A is initiated first, and lock information containing the pending lock status is recorded within Transaction A. Subsequently, after Transaction A is committed, the pending lock status in the lock information is changed to a locked status. Next, Transaction B is executed and committed. Finally, when Transaction C (the last transaction corresponding to the DDL statement) is executed, the locked status in the lock information is changed to a pending unlock status, and after Transaction C is successfully committed, the lock information is deleted.
[0077] Specifically, the lock information containing the state to be locked can be recorded in the following ways:
[0078] (1) For the database object affected by the DDL statement, a lock is added by specifying the lock mode and DDL identifier. The DDL identifier is used to indicate the lifecycle of the added lock, that is, the added lock will last until the transaction corresponding to the DDL statement ends.
[0079] (2) Verify whether the added lock conflicts with other locks in the lock record set.
[0080] If there is a lock information in the lock record set that conflicts with the lock mode and the added lock, and the transaction identifier is different from the transaction identifier of the current transaction, then the lock information of the lock added in step (1) is invalid and the DDL statement cannot be executed.
[0081] If the lock information added in step (1) is valid, then the valid lock information is recorded in the lock record set.
[0082] One way to change the locked status in lock information to an unlocked status is as follows:
[0083] (1) For the database object affected by the DDL statement, release the lock by specifying the lock mode and DDL identifier.
[0084] (2) Search for the lock information corresponding to the specified lock mode and DDL identifier in the lock record set. If the state of the lock information is not all locked, return and retry; otherwise, change the locked state in the lock information to the unlocking state.
[0085] Figure 4 This is a schematic diagram of the structure of a device provided in an exemplary embodiment. Please refer to... Figure 4 At the hardware level, the device includes a processor 402, an internal bus 404, a network interface 406, memory 408, and non-volatile memory 410, and may also include other hardware required for business operations. One or more embodiments of this specification can be implemented in software, such as the processor 402 reading the corresponding computer program from the non-volatile memory 410 into memory 408 and then running it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.
[0086] Please refer to Figure 5 , Figure 5 A DDL statement execution device 500 is provided, which can be applied to, for example Figure 4 The device shown is used to implement the technical solution of this specification. The DDL statement execution device 500 may include:
[0087] The initiation module 501 is used to initiate a transaction in response to an execution request for a Data Definition Language (DDL) statement. The transaction is used to execute the DDL statement.
[0088] The recording module 502 is used to record the target lock information corresponding to the DDL statement within a transaction. The target lock information is used to indicate the parameters of the lock added to the database object during the execution of the DDL statement.
[0089] The deletion module 503 is used to delete the target lock information in response to a successful transaction commit, thereby completing the execution of the DDL statement.
[0090] In some embodiments, the target lock information includes a lock state. When there are multiple transactions that are concatenated, the recording module 502 is further configured to: record the target lock information corresponding to the DDL statement within the first transaction of the multiple transactions, wherein the lock state of the target lock information is a pending lock state.
[0091] In some embodiments, the recording module 502 is further configured to: if the first transaction among multiple transactions is successfully committed, modify the lock state of the target lock information to a locked state.
[0092] In some embodiments, the target lock information includes a lock state. When there are multiple transactions that are concatenated, the deletion module 503 is further configured to: query the lock state of the target lock information during the execution of the last transaction among the multiple transactions; if the lock state of the target lock information is a locked state, then modify the lock state of the target lock information to a pending unlock state.
[0093] In some embodiments, the deletion module 503 is further configured to: delete the target lock information in response to the successful commit of the last transaction among multiple transactions when the lock state of the target lock information is in an unlocking state.
[0094] In some embodiments, the target lock information further includes a DDL identifier, which corresponds to a DDL statement. The deletion module 503 is also configured to: during the execution of the last transaction among multiple transactions, query the lock status of the target lock information based on the DDL identifier corresponding to the DDL statement.
[0095] In some embodiments, the deletion module 503 is further configured to: if the last transaction among multiple transactions fails to commit, modify the lock state of the target lock information to a locked state.
[0096] In some embodiments, target lock information is recorded in a pre-configured lock record set, which has a mapping relationship with database objects.
[0097] In some embodiments, the DDL statement execution device 500 further includes a verification module (not shown in the figure) for verifying whether the target lock information is valid based on the lock record set; if the target lock information is invalid, the transaction is rolled back to terminate the execution of the DDL statement.
[0098] In some embodiments, the target lock information includes a transaction identifier and a lock mode. The transaction identifier indicates the transaction used to record the target lock information, and the lock mode includes one of shared lock, exclusive lock, row-level shared lock, and row-level exclusive lock. The verification module is further configured to: traverse all lock information in the lock record set; if there is lock information in the lock record set that conflicts with the lock mode of the target lock information and has a different transaction identifier, then the target lock information is invalid.
[0099] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.
[0100] In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.
[0101] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.
[0102] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.
[0103] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0104] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.
[0105] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this specification. The singular forms “a,” “described,” and “the” used in one or more embodiments of this specification and in the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more associated listed items.
[0106] It should be understood that although the terms first, second, third, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of one or more embodiments of this specification, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "in response to a determination," or "when," or "in the event of a determination."
[0107] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the protection scope of one or more embodiments of this specification.
Claims
1. A method for executing DDL statements, comprising: In response to an execution request for a Data Definition Language (DDL) statement, a transaction is initiated, the transaction being used to execute the DDL statement; Within the transaction, the target lock information corresponding to the DDL statement is recorded. The target lock information is used to indicate the parameters of the lock added to the database object during the execution of the DDL statement. In response to the successful commit of the transaction, the target lock information is deleted to complete the execution of the DDL statement; The target lock information includes a lock state; when there are multiple transactions and they are connected in series, recording the target lock information corresponding to the DDL statement within the transaction includes: recording the target lock information corresponding to the DDL statement within the first transaction among the multiple transactions, wherein the lock state of the target lock information is a pending lock state; the method further includes: if the first transaction among the multiple transactions is successfully committed, then modifying the lock state of the target lock information to a locked state.
2. The method according to claim 1, wherein the target lock information includes the lock state; When the number of transactions is multiple and the transactions are concatenated, the method further includes: During the execution of the last transaction among the plurality of transactions, the lock status of the target lock information is queried; If the lock status of the target lock information is locked, then the lock status of the target lock information is changed to unlocking.
3. The method according to claim 2, wherein deleting the target lock information in response to a successful transaction commit includes: If the lock status of the target lock information is pending unlocking, the target lock information is deleted in response to the successful commit of the last transaction among the plurality of transactions.
4. The method according to claim 2, wherein the target lock information further includes a DDL identifier, and the DDL identifier corresponds to the DDL statement; During the execution of the last transaction among the plurality of transactions, querying the lock status of the target lock information includes: During the execution of the last transaction among the plurality of transactions, the lock status of the target lock information is queried based on the DDL identifier corresponding to the DDL statement.
5. The method according to claim 3, further comprising: If the last transaction among the multiple transactions fails to commit, the lock status of the target lock information is modified to a locked state.
6. The method according to claim 1, wherein the target lock information is recorded in a pre-configured lock record set, and the lock record set has a mapping relationship with the database object.
7. The method according to claim 6, before recording the target lock information corresponding to the DDL statement within the transaction, the method further includes: Based on the lock record set, verify whether the target lock information is valid; If the target lock information is invalid, the transaction is rolled back to terminate the execution of the DDL statement.
8. The method according to claim 7, wherein the target lock information includes a transaction identifier and a lock mode, the transaction identifier being used to indicate the transaction used to record the target lock information, and the lock mode including one of a shared lock, an exclusive lock, a row-level shared lock, and a row-level exclusive lock; The step of verifying the validity of the target lock information based on the lock record set includes: Traverse all lock information in the lock record set. If there is lock information in the lock record set that conflicts with the lock mode of the target lock information and has a different transaction identifier, then the target lock information is invalid.
9. A DDL statement execution device, comprising: The initiation module is used to initiate a transaction in response to an execution request for a Data Definition Language (DDL) statement, the transaction being used to execute the DDL statement; The recording module is used to record the target lock information corresponding to the DDL statement within the transaction. The target lock information is used to indicate the parameters of the lock added to the database object during the execution of the DDL statement. The deletion module is used to delete the target lock information in response to the successful commit of the transaction, so as to complete the execution of the DDL statement; The target lock information includes a lock state; when there are multiple transactions and they are connected in series, recording the target lock information corresponding to the DDL statement within the transaction includes: recording the target lock information corresponding to the DDL statement within the first transaction among the multiple transactions, wherein the lock state of the target lock information is a pending lock state; the recording module is further configured to modify the lock state of the target lock information to a locked state if the first transaction among the multiple transactions is successfully committed.
10. An electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1 to 8 by executing the executable instructions.
11. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1 to 8.