Transaction data management method and device, equipment, storage medium and program product

Abstract

The embodiment of the invention provides a transaction data management method and device, equipment, a storage medium and a program product, and relates to the field of database management. The method comprises the steps of determining a statement feature value of a first SQL statement, wherein the statement feature value comprises at least one of an operation type, an access object identifier and a grammar feature; under the condition that the target transaction is successfully submitted, a target transaction feature identifier corresponding to the target transaction is determined according to the statement feature values of the SQL statements, the transaction corresponding to the SQL statements is the target transaction, and the first SQL statement is any one SQL statement in the SQL statements; and binding the target transaction feature identifier and target transaction statistical data corresponding to the target transaction, and storing the target transaction statistical data in a storage space, wherein the target transaction statistical data comprises at least one of a transaction identifier, submission time and client information. According to the method provided by the invention, the transaction data management capability is improved.

Description

Technical Field

[0001] This application relates to the field of database management, and more particularly to a transaction data management method, apparatus, device, storage medium, and program product. Background Technology

[0002] In modern distributed database systems, transactions are the core mechanism for ensuring data consistency and integrity. As enterprise database applications become increasingly complex (such as financial transactions, e-commerce order processing, and IoT device data collection), the demand for granular monitoring, security auditing, and resource governance of the transaction execution process is growing.

[0003] However, existing implementations have poor capabilities in managing transaction data. Summary of the Invention

[0004] This application provides a transaction data management method, apparatus, device, storage medium, and program product to solve the technical problem of poor transaction data management capabilities.

[0005] In a first aspect, this application provides a transaction data management method, comprising: determining statement feature values ​​of a first structured query language (SQL) statement, wherein the statement feature values ​​include at least one of operation type, access object identifier, and syntax features;

[0006] If the target transaction is successfully committed, the target transaction feature identifier is determined based on the multiple statement feature values ​​of multiple SQL statements. The transaction corresponding to the multiple SQL statements is the target transaction, and the first SQL statement is any one of the multiple SQL statements.

[0007] Bind the target transaction feature identifier and the target transaction statistics corresponding to the target transaction to the storage space. The target transaction statistics include at least one of the following: transaction identifier, commit time, and client information.

[0008] In one possible implementation of the first aspect, the target transaction feature identifier corresponding to the target transaction is determined based on multiple statement feature values ​​of multiple SQL statements, including:

[0009] Perform aggregate hashing on multiple statement feature values ​​to obtain the target transaction feature identifier; or,

[0010] Bitmap structured encoding is performed on multiple statement feature values ​​to obtain the target transaction feature identifier.

[0011] In one possible implementation of the first aspect, the method further includes:

[0012] Bind the statement characteristic value of the first SQL statement and the statistical data of the first SQL statement, and store them in the storage space.

[0013] In one possible implementation of the first aspect, the method further includes:

[0014] Retrieve target transaction statistics from the storage space.

[0015] In one possible implementation of the first aspect, multiple statement feature values ​​are stored in a cache space, and the method further includes:

[0016] If the target transaction fails to commit, discard the multiple statement feature values ​​corresponding to the target transaction in the cache space.

[0017] In one possible implementation of the first aspect, determining the statement characteristic value of the first SQL statement includes:

[0018] Determine the statement characteristics of the first SQL statement by using a database executor hook; or,

[0019] Determine the statement characteristics of the first SQL statement by parsing its log; or,

[0020] The query plan analysis determines the statement characteristics of the first SQL statement.

[0021] In one possible implementation of the first aspect, determining the statement characteristic value of the first SQL statement includes:

[0022] The feature weight configuration is determined based on the context information of the target transaction. The feature weight configuration is used to indicate the weights for feature extraction for operation type, data object identity and / or syntax features.

[0023] The statement feature value of the first SQL statement is determined based on the feature weight configuration.

[0024] In one possible implementation of the first aspect, determining the statement characteristic value of the first SQL statement includes:

[0025] The first SQL statement is processed by low-level object mapping and encoding. The low-level object mapping process maps the low-level object identifier of the first SQL statement to the target data object identifier, and the encoding process converts the syntax tree structure of the first SQL statement into the target syntax feature encoding.

[0026] The statement characteristic value of the first SQL statement is determined based on the first SQL statement after the underlying object mapping processing and encoding processing.

[0027] Secondly, this application provides a transaction data management device, comprising:

[0028] The first determining module is used to determine the statement feature value of the first SQL statement. The statement feature value includes at least one of operation type, access object identifier and syntax feature.

[0029] The second determining module is used to determine the target transaction feature identifier corresponding to the target transaction based on the multiple statement feature values ​​of multiple SQL statements when the target transaction is successfully committed. The transaction corresponding to the multiple SQL statements is the target transaction, and the multiple SQL statements include the first SQL statement. The storage module is used to bind the target transaction feature identifier and the target transaction statistics corresponding to the target transaction and store them in the storage space. The target transaction statistics include at least one of the following: transaction identifier, commit time, and client information.

[0030] Thirdly, this application provides an electronic device, comprising: a processor; a memory communicatively connected to the processor; the memory storing computer-executable instructions; and the processor executing the computer-executable instructions stored in the memory to implement the method of any one of the first aspects.

[0031] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method of any one of the first aspects.

[0032] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method of any one of the first aspects.

[0033] The transaction data management method, apparatus, device, storage medium, and product provided in this application enhance the management capabilities of transaction data by dynamically collecting SQL behavior characteristics and generating transaction feature identifiers (TFIDs). This solves the problems of existing technologies regarding transaction statistical consistency, semantic identification, and cross-database compatibility, achieving a semantic upgrade in transaction behavior analysis and automated policy response. The TFID can automatically label the business intent (e.g., "payment transaction") or risk attributes (e.g., "cross-sensitive table write operation") of a transaction, improving observability granularity. Furthermore, based on the bitmap encoding of the TFID, it can support real-time matching of feature combinations (e.g., "long transaction + large-scale deletion"), thereby triggering strategies such as security auditing and resource scheduling. Moreover, the TFID generation mechanism does not depend on a specific database kernel and can be adapted to mainstream databases such as MySQL and Oracle through plugins, proxies, or log consumption. Simultaneously, feature collection and aggregation are completed in memory, and the TFID is calculated only once when the transaction is successfully committed, having minimal impact on transaction execution performance. The TFID is only generated upon successful transaction commit, avoiding statistical pollution and ensuring that policy decisions are based on valid transaction data. Attached Figure Description

[0034] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0035] Figure 1 A schematic diagram illustrating a scenario for a transaction data management method provided in an embodiment of this application;

[0036] Figure 2 A flowchart illustrating a transaction data management method provided in an embodiment of this application;

[0037] Figure 3 A flowchart illustrating another transaction data management method provided in an embodiment of this application;

[0038] Figure 4 This is a schematic diagram of the structure of a transaction data management device provided in an embodiment of this application;

[0039] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0040] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0041] 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 numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0042] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0043] The technical terms used in the embodiments of this application are explained below:

[0044] I. Transaction.

[0045] In modern database systems, a transaction refers to a group of database operations executed as a logical unit of work. These operations either all complete successfully and take effect permanently, or they are all not executed (rolled back) to ensure that the database always maintains a consistent and reliable state.

[0046] The main purpose of transactions is to maintain the integrity and consistency of data in complex environments such as concurrent access and system failures.

[0047] All operations within a transaction are treated as an indivisible whole: either all are executed or none are executed. Even if an error occurs or the system crashes during execution, the executed parts will be undone (rolled back).

[0048] Transactions must transform a database from one consistent state to another. For example, in a money transfer operation, the total amount should remain unchanged before and after the transaction.

[0049] Multiple concurrent transactions do not interfere with each other. Each transaction executes as if it has exclusive access to system resources, even if they run concurrently. Different isolation levels (such as Read Uncommitted, Repeatable Read, and Serializable) provide different levels of isolation guarantees.

[0050] Once a transaction is successfully committed, its modifications to the database are permanent, and the data will not be lost even if the system subsequently fails (such as a power outage or crash). This is typically achieved through writing to a log (such as WAL, Write-Ahead Logging).

[0051] A transaction can include the following complete phases:

[0052] 1. Transaction Initiation Phase.

[0053] During this phase, the database system assigns a unique transaction identifier (XID) to the new transaction and initializes the transaction context according to the specified isolation level, including the snapshot view, concurrency control structure, and log sequence number. This phase marks the beginning of the transaction's lifecycle; all subsequent operations are performed within this transaction context, maintaining logical isolation from external concurrent transactions.

[0054] 2. Statement Execution Phase.

[0055] During this phase, transactions execute user-submitted data manipulation statements (such as SQL) sequentially. The system completes logical processing through query parsing, optimization, and execution engines, generating dirty pages in the buffer pool. Simultaneously, to support atomicity and Multi-Version Concurrency Control (MVCC), the system records corresponding undo logs; if data modifications are involved, redo logs are also generated and cached in the log buffer. All state changes during this phase are only visible to the current transaction and are not yet persisted.

[0056] 3. Log Persistence Phase.

[0057] Following the Write-Ahead Logging (WAL) protocol, the system forcibly flushes the redo logs related to the transaction to persistent storage before committing. This operation ensures that even in the event of a system crash, the modifications of committed transactions can still be reconstructed through recovery mechanisms, thus meeting durability requirements. This stage is a crucial guarantee for a transaction to move from "logical completion" to "physical reliability."

[0058] 4. Transaction Commit Phase.

[0059] When a client issues a COMMIT command, the system marks the transaction status as "committed" and writes a commit record to the transaction log. Subsequently, all locks held by the transaction are released, making the changes visible to other concurrent transactions (depending on the isolation level). At this point, the transaction satisfies atomicity and consistency, and its effects are considered permanent and irreversible by the database.

[0060] 5. Transaction Rollback Phase.

[0061] If an error, constraint violation, or client call to ROLLBACK occurs during statement execution, the system will enter the rollback phase. In this phase, the DBMS uses the Before-Image recorded in the Undo Log to perform a reverse compensation operation, undoing each effective modification one by one until the initial state of the transaction is reached. Simultaneously, all acquired locks and memory resources are released, and the transaction status is marked as "Aborted." This mechanism strictly guarantees the atomicity of transactions—that is, "all-or-nothing" semantics.

[0062] 6. Resource Cleanup Phase

[0063] After a transaction is committed, the system enters an asynchronous cleanup process: dirty pages are gradually flushed to disk by the background checkpoint mechanism; undo log versions no longer required by active transactions are reclaimed; and transaction metadata (such as XIDs and memory descriptors) are released. Although this stage does not affect the logical completion of the transaction, it is crucial for the long-term stability of the system, storage efficiency, and garbage collection.

[0064] Figure 1 This is a schematic diagram illustrating a scenario where the transaction data management method of this application is applied. For example... Figure 1 As shown, users can send transaction-related operation commands to the database through a client, and the database can respond to the transaction-related operation commands and execute the corresponding operations. The transaction data management device can manage the relevant data generated when the database executes the transaction-related operation commands, so as to realize the transaction data management method provided in this application embodiment.

[0065] In modern distributed database systems, transactions are the core mechanism for ensuring data consistency and integrity. As enterprise database applications become increasingly complex (such as financial transactions, e-commerce order processing, and IoT device data collection), the demand for granular monitoring, security auditing, and resource governance of the transaction execution process is growing.

[0066] However, existing implementations have poor management capabilities for transaction data.

[0067] For example, existing databases generally provide statement-level statistics, such as PostgreSQL's pg_stat_statements extension or MySQL's Performance Schema. These mechanisms can record metrics such as the number of times each SQL statement is executed, its execution time, the number of rows returned, and the shared cache hit rate, and aggregate them by statement text hash.

[0068] However, the statistical granularity of existing databases is "single SQL statement", which cannot reflect the complete behavior of a transaction; it does not distinguish whether the statement belongs to a COMMIT or ROLLBACK transaction; and it lacks the ability to automatically identify the overall business intent of the transaction (such as "payment" or "registration") or risk attributes (such as "high-risk write" or "cross-sensitive table").

[0069] The transaction data management method, apparatus, equipment, storage medium, and program products provided in this application are intended to solve the above-mentioned technical problems of the prior art.

[0070] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0071] Figure 2 This is a flowchart illustrating a transaction data management method provided in an embodiment of this application, as shown below. Figure 2 As shown, the method includes:

[0072] S201. The electronic device determines the statement characteristic value of the first SQL statement, the statement characteristic value including at least one of operation type, access object identifier and syntax characteristics.

[0073] During the execution of a target transaction, the electronic device can determine the statement feature value (SFV) of each SQL statement corresponding to the target transaction. The SFV includes at least one of the following: operation type, access object identifier, and syntax feature. The SQL statement corresponding to the target transaction includes the first SQL statement.

[0074] The transaction execution process refers to the complete lifecycle of a transaction in the database, from its inception to its commit or rollback. For example, the entire process of a financial payment transaction from the user initiating a request to its final commit.

[0075] This SQL statement is a standardized query language instruction used to manipulate data in a database. For example: UPDATE accounts SET balance=1000 WHERE user_id=1, instructs the balance field of the record in the accounts table where user_id is equal to 1 to be changed to 1000.

[0076] The statement feature value is a structured descriptive unit of the behavioral characteristics of an SQL statement, which may include operation type, access object identifier, and syntax features. For example: {operation:"UPDATE",object_hash:"table_accounts_123",syntax_hash:"hash_abc"} indicates that the operation type of this SQL statement is update (UPDATE), table_accounts_123 is a unique identifier (hash or encoding) of the data object being operated on (such as a table or view) after normalization, and hash_abc is the hash value calculated after normalizing the SQL.

[0077] The operation type of the statement can be SELECT, INSERT, UPDATE, DELETE, DDL, etc.; the identifier of the accessed data object can be a hash of the table name, column name, schema name, etc.; the syntax features of the statement can be the hash value of the syntax tree structure generated by the statement parsing, etc., and the specifics are not limited here.

[0078] S202. When the target transaction is successfully committed, the electronic device determines the target transaction feature identifier corresponding to the target transaction based on the multiple statement feature values ​​of multiple SQL statements. The transaction corresponding to the multiple SQL statements is the target transaction, and the first SQL statement is any one of the multiple SQL statements.

[0079] In other words, if the target transaction is successfully committed, the electronic system can determine the target transaction feature identifier based on the multiple statement feature values ​​of the multiple SQL statements corresponding to the target transaction.

[0080] The transaction feature identifier is a unique identifier generated by aggregating the feature values ​​of all statements within the target transaction, and can be used to describe the characteristics of transaction behavior. For example, it can be a 64-bit encoded value generated by hash calculation, such as transaction feature identifier tfid=hash(SFV1+SFV2+...+SFVn).

[0081] For example, such as Figure 3 As shown, the electronic device can determine the corresponding transaction feature identifier based on the statement feature values ​​of all SQL statements from SQL statement 1 to SQL statement n.

[0082] S203. The electronic device binds the target transaction feature identifier and the target transaction statistics corresponding to the target transaction to the storage space. The target transaction statistics include at least one of the following: transaction identifier, commit time, and client information.

[0083] The transaction statistics can be metadata recorded when the target transaction is committed, which may include information such as transaction ID, commit time, and client information. For example: {xid:12345,commit_time:"2023-10-01T12:00:00Z",client_ip:"192.168.1.1"}.

[0084] This client information refers to the identifier of the client initiating the transaction, such as its IP address or username. For example, client information could be client_ip=192.168.1.1.

[0085] The total execution time can be the total time taken from the start of a transaction to its commit.

[0086] In addition, transaction statistics can include other data such as memory usage when the target transaction is committed; there are no specific limitations here.

[0087] This possible implementation solves the problems of scattered storage of transaction features and decoupling of statistics from the final state of transactions in existing technologies by extracting the semantic features of SQL statements and generating transaction-level identifiers. The behavioral characteristics (such as operation type and accessed objects) of each SQL statement in the target transaction are recorded in real time; the generation of transaction feature identifiers aggregates the scattered SFVs into a unified identifier, and a strong binding mechanism ensures that the transaction feature identifier is only generated when the transaction is successfully committed, avoiding invalid data residue. This achieves semantic solidification of transaction behavior features, enabling operations personnel to quickly locate high-risk transactions (such as cross-sensitive table write operations) and distinguish between read-only and write transactions using TFIDs, and supports feature-based policy responses (such as security audit alerts and resource quota restrictions).

[0088] In some embodiments, the electronic device determines the statement characteristic value of the first SQL statement, which may specifically include:

[0089] The electronic device performs low-level object mapping and encoding processing on the first SQL statement. The low-level object mapping processing maps the low-level object identifier of the first SQL statement to the target data object identifier, and the encoding processing converts the syntax tree structure of the first SQL statement into the target syntax feature encoding. Then, the statement feature value of the first SQL statement is determined based on the first SQL statement after the low-level object mapping and encoding processing.

[0090] For example, during the process of determining the statement feature value of the first SQL statement by an electronic device, the underlying object identifiers (such as table name OID and syntax tree structure) of different databases (such as MySQL and Oracle) can be converted into unified data object identifiers and syntax feature codes through a mapping layer. For example, the table name hash of MySQL and the table OID of Oracle are both mapped to the unified field object_id, and the syntax tree structure is converted into standardized codes.

[0091] The underlying object identifier is a database-specific table name, column name, or OID identifier. For example, MySQL uses table name hashes and Oracle uses table OIDs.

[0092] This standardized syntax feature encoding converts the SQL syntax tree structure into a common encoding format. For example, it converts the syntax tree of SELECT * FROM users into a fixed field {type: "SELECT", table: "users"}.

[0093] In this possible implementation, cross-database feature mapping eliminates the impact of underlying implementation differences on feature identifier consistency. For example, in a hybrid cloud architecture, even if a transaction is executed across MySQL and Oracle instances, its target transaction feature identifier can still reflect the same business characteristics (such as "cross-sensitive table write operations") through unified encoding, thereby supporting cross-database transaction behavior comparison and governance.

[0094] In some embodiments, the electronic device performs low-level object mapping processing on the first SQL statement, which may specifically include:

[0095] Electronic devices can call the corresponding mapping rules through the database adapter and output the mapping results as standardized feature value fields.

[0096] In other words, electronic devices can call the corresponding mapping rules based on the current database type (such as MySQL or Oracle) to convert the underlying object identifiers (such as table name OID, syntax tree structure) into standardized feature value fields.

[0097] For example, MySQL table names are encoded using SHA-256 hashes, while Oracle table OIDs are converted to fixed-length numeric values. This step, through the coordinated work of adapters and mapping rules, ensures the universality of feature identifiers across heterogeneous database environments.

[0098] This database adapter is a module adapted for different database types and can be used to invoke mapping rules. For example, the MySQL adapter invokes table name hash rules, while the Oracle adapter invokes OID mapping rules.

[0099] This standardized feature value field is a feature value storage field with a uniform format. For example, {object_id: "table_accounts_123", database_type: "MySQL"}.

[0100] This possible implementation enhances the flexibility and compatibility of cross-database mapping by invoking rules through the database adapter. For example, in a multi-cloud database environment, the adapter can dynamically select mapping rules based on the database type, ensuring that the TFID remains consistent across instance transactions, thereby supporting collaborative operation and maintenance analysis.

[0101] In some embodiments, the electronic device determines the statement characteristic value of the first SQL statement, which may specifically include:

[0102] The electronic device determines the statement characteristic value of the first SQL statement through a database executor hook; or,

[0103] The electronic device determines the statement characteristic value of the first SQL statement by parsing the log of the first SQL statement; or,

[0104] Electronic devices determine the statement characteristics of the first SQL statement through query plan analysis.

[0105] For example, before collecting the target statement's feature values, the electronic device captures the execution context of the first SQL statement in real time through an executor hook or a log parsing module. For instance, PostgreSQL obtains the syntax tree structure after SQL parsing through an ExecutorStart hook, and MySQL extracts the operation type and access object through a binlog parsing module.

[0106] Here, the executor hook refers to a callback function inserted by the database kernel during the SQL execution phase, which can be used to capture context information about the executed SQL statement. For example, PostgreSQL's ExecutorStart Hook.

[0107] Parsing the log of the first SQL statement refers to extracting the behavioral characteristics of the first SQL statement by parsing database logs (such as WAL logs). For example, this can be done using MySQL's binlog parsing module.

[0108] In this possible implementation, the real-time issue of feature value extraction is addressed through an execution context capture mechanism. For example, in a high-concurrency financial trading system, executor hooks can ensure that the feature values ​​of each SQL statement are captured immediately during execution, avoiding data loss due to latency. This technique significantly improves the completeness of feature value collection and system response efficiency.

[0109] In some embodiments, the electronic device determines the statement characteristic value of the first SQL statement, which may specifically include:

[0110] The electronic device determines the feature weight configuration based on the context information of the target transaction. The feature weight configuration is used to indicate the weight of feature extraction for operation type, data object identity and / or syntax features; then, the statement feature value of the first SQL statement is determined based on the feature weight configuration.

[0111] The context information consists of environment parameters at the time the target transaction is started, such as the client IP, application name, or transaction level. For example, if the target transaction originates from the "Payment" business module, the context information would include the application name "PaymentService".

[0112] This feature weight configuration is the different weight configuration for features of different dimensions when the electronic device determines the statement feature value of the first SQL statement. For example, payment transactions will preferentially extract the features of "sensitive table identifier" and "write operation".

[0113] For example, when a target transaction starts, the electronic device can dynamically configure the weight dimensions of feature extraction by analyzing client context information (such as application name and client IP). For instance, if the transaction comes from the "payment" business module, the "sensitive table identifier" and "write operation" features are extracted first; if the transaction is a "query" type, the "access mode" and "data volume" features are extracted first.

[0114] In this possible implementation, the business relevance of feature identifiers is improved through scenario-aware feature weight allocation. Dynamically configuring weight dimensions reduces redundant feature collection; for example, in payment transactions, "sensitive table identifiers" are extracted first, avoiding irrelevant fields (such as "query count") from interfering with the semantic capabilities of identifiers. This design reduces the computational overhead of feature aggregation while enhancing the adaptability of TFID to business scenarios, such as accurately marking "high-risk write operations" in financial transactions.

[0115] In some embodiments, the electronic device determines the target transaction feature identifier corresponding to the target transaction based on multiple statement feature values ​​of multiple SQL statements, which may specifically include:

[0116] The electronic device performs aggregate hashing on multiple statement feature values ​​to obtain the target transaction feature identifier; or,

[0117] Bitmap structured encoding is performed on multiple statement feature values ​​to obtain the target transaction feature identifier.

[0118] In addition, multiple statement feature values ​​can be processed in other ways to obtain the target transaction feature identifier. For example, multiple statement feature values ​​can be encoded using a Type-Length-Value (TLV) structure for data storage, but the specifics are not limited here.

[0119] During transaction execution, electronic devices can aggregate all Statement Feature Values ​​(SFVs) of the target transaction into a fixed-length Transaction Feature Identifier (TFID) using a hash algorithm (such as SHA-256).

[0120] Features can also be encoded using bitmap or TLV formats, for example, mapping the operation type "UPDATE" to a specific bit in a bitmap, or encoding the data object identifier as a TLV field.

[0121] This hash algorithm maps data of arbitrary length to a fixed-length output. For example, the SHA-256 algorithm can convert the feature values ​​of an SQL statement into a 64-bit hash value.

[0122] This bitmap uses binary bits to represent features, supporting fast bitwise operation matching. For example, a "write operation" can be mapped to the first bit of the bitmap (00000001).

[0123] The TLV format is an encoding method that stores data in a type-length-value structure. For example: {type: "operation", length: 4, value: "UPDATE"}.

[0124] In this possible implementation, hash algorithms and compact coding mechanisms improve the storage efficiency and scalability of transaction feature identifiers. Hash algorithms aggregate scattered statement feature values ​​into fixed-length identifiers, reducing storage and indexing overhead; bitmap or TLV formats support fast feature combination matching (such as "write operation + sensitive table"), enhancing the semantic meaning of identifiers. For example, in financial trading scenarios, TFID can quickly determine whether a transaction involves high-risk write operations through bitmaps, thereby supporting real-time risk control strategy responses.

[0125] In some embodiments, the electronic device may also store statistical data of SQL statements; therefore, the method further includes the following steps:

[0126] S204. The electronic device binds the statement characteristic value of the first SQL statement and the statistical data of the first SQL statement to the storage space.

[0127] After determining the statement feature value of the first SQL statement, the electronic device can also convert the statement feature value into a corresponding identifier, and bind the identifier of the statement feature value together with the statistical data of the first SQL statement and store it in the storage space.

[0128] In this embodiment, all SFVs belonging to the same transaction are temporarily accumulated in a transaction feature buffer (cache space). This buffer exists throughout the transaction's lifecycle, is maintained only in memory, and is not persisted.

[0129] In some embodiments, when a target transaction begins, the electronic device can create and initialize a list of statement feature values ​​for the target transaction. This list of statement feature values ​​can be used to store the statement feature values ​​of the SQL statements corresponding to the target transaction.

[0130] For example, such as Figure 3 As shown, the electronic device can store the statement characteristic values ​​of each SQL statement from SQL statement 1 to SQL statement n, as well as the statistical data of the first SQL statement, into the storage space.

[0131] In some embodiments, the electronic device can query stored target transaction statistics; therefore, the method further includes the following steps:

[0132] S205. The electronic device obtains the target transaction statistics data in the storage space.

[0133] For example, an electronic device can send a target transaction feature identifier to the device corresponding to the storage space, and then receive target transaction statistics from the device corresponding to the storage space.

[0134] For example, electronic devices can provide the ability to query transaction feature identifiers externally through system views or built-in functions. For instance, after a transaction feature identifier is generated, the electronic device can provide query capabilities externally through system views (such as committed_transaction_stats) or built-in functions (such as tfid_has_flag). For example, operations personnel can query the TFID of a specific transaction through a view and filter transactions containing the feature of "sensitive table + write operation" through functions. This step is implemented through the database interface module, supporting feature-based policy responses (such as security auditing and resource allocation).

[0135] The system view is a predefined query interface in the database used to display transaction characteristic identifiers and target transaction statistics. The committed_transaction_stats view contains fields such as tfid, xid, and commit_time.

[0136] This built-in function is a predefined function provided by the database for manipulating transaction characteristic identifiers and target transaction statistics. For example, the `tfid_has_flag(tfid_value, "write")` function determines whether a transaction contains write operation characteristics.

[0137] In this possible implementation, the operability and scalability of transaction feature identifiers are achieved through the query capabilities of system views and built-in functions. For example, operations and maintenance personnel can use the `tfid_has_flag` function to filter high-risk transactions in real time, thereby supporting automated policy responses (such as anomaly detection and cost allocation), significantly improving the observability and governance efficiency of the database.

[0138] In some embodiments, multiple statement feature values ​​can be stored in a cache space, and the method further includes:

[0139] S206. In the event that the target transaction fails to commit, i.e., the target transaction is rolled back, the electronic device discards multiple statement feature values ​​corresponding to the target transaction in the cache space.

[0140] If the electronic device detects that the transaction has been successfully committed, it binds the target transaction feature identifier with the transaction statistics and stores them persistently; if the target transaction fails to commit, i.e. the target transaction is rolled back, it directly discards the multiple statement feature values ​​corresponding to the target transaction in the cache space and does not generate the target transaction feature identifier corresponding to the target transaction.

[0141] In this context, transaction rollback refers to the undoing of a transaction due to an anomaly or manual intervention during its execution. For example, a financial transaction might trigger a rollback due to risk control rules.

[0142] The multiple statement characteristic values ​​in this cache space can be a data structure in memory that temporarily stores transaction characteristic values. For example, it could be a list of SFVs accumulated during transaction execution.

[0143] In this possible implementation, a transaction rollback compensation mechanism ensures strong consistency between statistical data and the final state of the transaction. For example, in financial transaction scenarios, a ROLLBACK transaction will not retain invalid characteristics, avoiding misjudgment as a "high-risk payment" transaction, thereby improving the accuracy of security audits and the efficiency of resource governance.

[0144] In this embodiment, by dynamically collecting SQL behavior characteristics and generating Transaction Feature Identifiers (TFIDs), the problems of transaction statistical consistency, semantic identification, and cross-database compatibility in existing technologies are solved, realizing the semantic upgrade of transaction behavior analysis and automated policy response. The TFID can automatically label the business intent of a transaction (such as "payment transaction") or risk attributes (such as "cross-sensitive table write operation"), improving the granularity of observability. Furthermore, based on the bitmap encoding of the TFID, it can support real-time matching of feature combinations (such as "long transaction + large-scale deletion"), thereby triggering strategies such as security auditing and resource scheduling. Moreover, the TFID generation mechanism does not depend on a specific database kernel and can be adapted to mainstream databases such as MySQL and Oracle through plugins, proxies, or log consumption. Simultaneously, feature collection and aggregation are completed in memory, and the TFID is calculated only once when the transaction is successfully committed, having minimal impact on transaction execution performance. The TFID is only generated during COMMIT, avoiding statistical pollution and ensuring that policy decisions are based on valid transaction data.

[0145] Figure 4 This is a schematic diagram of the structure of a transaction data management device provided in an embodiment of this application, as shown below. Figure 4 As shown, the transaction data management device 400 provided in this embodiment includes, in some embodiments:

[0146] The first determining module 401 is used to determine the statement feature value of the first SQL statement. The statement feature value includes at least one of operation type, access object identifier and syntax feature.

[0147] The second determining module 402 is used to determine the target transaction feature identifier corresponding to the target transaction based on the multiple statement feature values ​​of multiple SQL statements when the target transaction is successfully committed. The transaction corresponding to the multiple SQL statements is the target transaction, and the first SQL statement is any one of the multiple SQL statements.

[0148] Storage module 403 is used to bind the target transaction feature identifier and the target transaction statistics corresponding to the target transaction and store them in the storage space. The target transaction statistics include at least one of the following: transaction identifier, commit time, and client information.

[0149] In one possible implementation, the second determining module 402 is specifically used to: perform aggregate hashing on multiple statement feature values ​​to obtain a target transaction feature identifier; or, perform bitmap structured encoding on multiple statement feature values ​​to obtain a target transaction feature identifier.

[0150] In one possible implementation, the storage module 403 is further used to: bind the statement feature value of the first SQL statement and the statistical data of the first SQL statement, and store them in the storage space.

[0151] In one possible implementation, the transaction data management device 400 further includes:

[0152] The acquisition module 404 is used to acquire target transaction statistics data in the storage space.

[0153] In one possible implementation, multiple statement feature values ​​are stored in a cache space, and the transaction data management device 400 further includes:

[0154] The discard module 405 is used to discard multiple statement feature values ​​corresponding to the target transaction in the cache space if the target transaction fails to commit.

[0155] In one possible implementation, the first determining module 401 is specifically used to: determine the statement characteristic value of the first SQL statement by means of the database executor hook; or, determine the statement characteristic value of the first SQL statement by means of parsing the log of the first SQL statement; or, determine the statement characteristic value of the first SQL statement by means of query plan analysis.

[0156] In one possible implementation, the first determining module 401 is specifically used to: determine the feature weight configuration based on the context information of the target transaction, wherein the feature weight configuration is used to indicate the weights for feature extraction of operation type, data object identifier and / or syntax features; and determine the statement feature value of the first SQL statement based on the feature weight configuration.

[0157] In one possible implementation, the first determining module 401 is specifically used to: perform low-level object mapping processing and encoding processing on the first SQL statement, wherein the low-level object mapping processing maps the low-level object identifier of the first SQL statement to the target data object identifier, and the encoding processing converts the syntax tree structure of the first SQL statement into the target syntax feature encoding; and determine the statement feature value of the first SQL statement based on the first SQL statement after the low-level object mapping processing and encoding processing.

[0158] The transaction data management device provided in this embodiment can execute the methods implemented in the above method embodiments. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0159] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 5As shown, the electronic device 50 may include a memory 501 and a processor 502. Optionally, the electronic device may also include a transceiver 503, wherein the memory 501 and the processor 502 communicate with each other; for example, the memory 501, the processor 502 and the transceiver 503 may communicate via a communication bus 504, the memory 501 is used to store a computer program, and the processor 502 executes the computer program to implement the method of the above embodiments.

[0160] Optionally, the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps in the method embodiments disclosed in this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0161] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the methods in any of the above method embodiments.

[0162] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods in any of the above method embodiments.

[0163] All or part of the steps in the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a readable memory. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned memory (storage medium) includes: read-only memory (ROM), RAM, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof.

[0164] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0165] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0166] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0167] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations.

[0168] In this application, the term "comprising" and its variations can refer to non-limiting inclusion; the term "or" and its variations can refer to "and / or". The terms "first", "second", etc., in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0169] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0170] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0171] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0172] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0173] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0174] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0175] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0176] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0177] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A transaction data management method, characterized in that, The method includes: Determine the statement feature value of the first SQL statement, wherein the statement feature value includes at least one of operation type, access object identifier and syntax feature; If the target transaction is successfully committed, the target transaction feature identifier is determined based on the multiple statement feature values ​​of multiple SQL statements. The transaction corresponding to the multiple SQL statements is the target transaction, and the first SQL statement is any one of the multiple SQL statements. The target transaction feature identifier and the target transaction statistics corresponding to the target transaction are bound and stored in the storage space. The target transaction statistics include at least one of the following: transaction identifier, commit time, and client information.

2. The method according to claim 1, characterized in that, The step of determining the target transaction feature identifier corresponding to the target transaction based on multiple statement feature values ​​of multiple SQL statements includes: The target transaction feature identifier is obtained by performing aggregate hashing on the multiple statement feature values; or, The target transaction feature identifier is obtained by performing bitmap structured encoding on the multiple statement feature values.

3. The method according to claim 1, characterized in that, The method further includes: The statement feature value of the first SQL statement and the statistical data of the first SQL statement are bound and stored in the storage space.

4. The method according to claim 3, characterized in that, The method further includes: Obtain the target transaction statistics data in the storage space.

5. The method according to claim 1, characterized in that, The multiple statement feature values ​​are stored in a cache space, and the method further includes: If the target transaction fails to commit, discard the multiple statement feature values ​​corresponding to the target transaction in the cache space.

6. The method according to claim 1, characterized in that, The determination of the statement feature value of the first SQL statement includes: The statement characteristic value of the first SQL statement is determined by hooking the database executor; or, The statement characteristic value of the first SQL statement is determined by parsing the log of the first SQL statement; or, The statement characteristic values ​​of the first SQL statement are determined through query plan analysis.

7. The method according to claim 1, characterized in that, The determination of the statement feature value of the first SQL statement includes: The feature weight configuration is determined based on the context information of the target transaction. The feature weight configuration is used to indicate the weights for feature extraction of operation type, data object identifier and / or syntax features. The statement feature value of the first SQL statement is determined based on the feature weight configuration.

8. The method according to claim 1, characterized in that, The determination of the statement feature value of the first SQL statement includes: The first SQL statement is subjected to low-level object mapping processing and encoding processing. The low-level object mapping processing is to map the low-level object identifier of the first SQL statement to the target data object identifier. The encoding processing is to convert the syntax tree structure of the first SQL statement into the target syntax feature encoding. The statement feature value of the first SQL statement is determined based on the first SQL statement after the underlying object mapping processing and encoding processing.

9. A transaction data management device, characterized in that, The transaction data management device includes: The first determining module is used to determine the statement feature value of the first SQL statement, wherein the statement feature value includes at least one of operation type, access object identifier and syntax feature; The second determining module is used to determine the target transaction feature identifier corresponding to the target transaction based on multiple statement feature values ​​of multiple SQL statements when the target transaction is successfully committed. The transaction corresponding to the multiple SQL statements is the target transaction, and the multiple SQL statements include the first SQL statement. The storage module is used to bind the target transaction feature identifier and the target transaction statistics corresponding to the target transaction and store them in the storage space. The target transaction statistics include at least one of the following: transaction identifier, commit time, and client information.

10. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 8.

Images