A risk control index SQL pre-online performance detection method

Abstract

The application relates to the technical field of database performance detection, and discloses a risk control index SQL pre-online performance detection method, which comprises the following steps: a risk control index SQL is parsed into an abstract syntax tree through an Apache Calcite parser, and TableScan nodes of a database type are traversed and screened out; a filtering condition is extracted for each node, matched with index information in system metadata, and an EXPLAIN command is spliced to obtain a database execution plan, actual index usage and estimated scan row numbers are extracted; combined index matching results, keys and rows are jointly judged to obtain single-node detection results; finally, according to the detection results of all nodes, a final online judgment result of the risk control index SQL is output; so that the problem that the development online efficiency of the risk control index is reduced due to the manual detection depending on expert experience in the prior art is solved.

Description

Technical Field

[0001] This invention relates to the field of database performance testing technology, specifically to a method for testing the performance of risk control indicators (SQL) before they go live. Background Technology

[0002] Risk control indicators are the core elements for risk identification, risk quantification and risk management. With the booming development of third-party data and the increasing demand for refined risk control business, the construction logic of risk control indicators has gradually evolved from a single proprietary data dimension to a hybrid real-time indicator model that deeply integrates proprietary database data and third-party data.

[0003] The proprietary data mainly consists of user behavior details and transaction data stored in relational databases such as MySQL. This type of data is characterized by its large volume and high query frequency, which places stringent requirements on the query performance of risk control indicator SQL. It is generally required in the industry that risk control indicator SQL must hit the data table index and control the number of rows scanned during execution, so as to avoid database query lag and risk control decision delay caused by full table scans and large number of row scans, and ensure the real-time performance and stability of risk control business.

[0004] To ensure the execution performance of risk control indicator SQL after its deployment, current technologies typically conduct performance testing after the risk control indicator development is completed but before its official launch. However, the current performance testing model still has significant technical shortcomings, specifically: Firstly, the development of risk control indicators is mostly completed in non-production testing environments. Due to limitations in hardware resources, data anonymization, and data volume, the testing environment cannot simulate the real data volume and distribution of the online production environment. It is difficult to obtain accurate performance data of risk control indicator SQL in real application scenarios, which greatly reduces the reference value of performance testing. Secondly, due to the lack of standardized and automated performance testing methods, the performance evaluation and online review of risk control indicator SQL rely heavily on the expert experience of developers. Developers rely on their experience to judge whether the SQL has performance risks such as index misses or excessive number of rows scanned. This manual judgment method not only fails to achieve systematic and comprehensive detection of the execution logic of risk control indicator SQL, but also easily leads to inconsistent review standards due to differences in personal experience, resulting in some risk control indicator SQL with potential performance risks entering the production environment. Third, existing detection methods do not achieve structured parsing of SQL execution logic and joint analysis of the actual database execution plan. Relying solely on manual superficial judgment of SQL statements, they cannot accurately identify the actual performance of database scanning nodes during SQL execution, making it difficult to fundamentally avoid performance problems caused by inefficient queries. Summary of the Invention

[0005] The present invention aims to provide a method for performance testing of risk control indicators before they go live, in order to solve the problem that the existing technology relies on manual testing based on expert experience, which reduces the development and deployment efficiency of risk control indicators.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: a method for performance testing of risk control indicators SQL before deployment, comprising: S1. Upon receiving the application to launch the risk control indicator SQL, initiate the slow SQL automated detection process. S2. The risk control indicator SQL is parsed using the Apache Calcite parser to generate an abstract syntax tree (AST) that preserves the SQL execution logic and node relationships. S3. Traverse the abstract syntax tree (AST), extract all TableScan nodes, filter out non-database type scan nodes, and obtain the set of database table scan nodes to be detected. S4. Perform the single-table performance test process sequentially on each TableScan node in the database table scan node set until all nodes have been tested. S5. Extract the SQL filter conditions of the current TableScan node, match the filter conditions with the data table metadata-index information pre-saved by the system, determine whether the filter conditions hit the existing index of the data table, and obtain the index metadata matching result. S6. Concatenate the SQL statement corresponding to the current TableScan node with the EXPLAIN command, submit it to the database instance to which the data table corresponding to the node belongs for execution, obtain the detailed execution plan returned by the database, and extract the index field keys actually used and the estimated scan row number field rows from the execution plan; S7. Combine the index metadata matching results, the keys field, and the rows field to make a joint judgment to obtain the detection result of the current TableScan node. The detection result includes pass, prohibition from going online, and manual verification. S8. Based on the detection results of all TableScan nodes, output the final online determination result of the risk control indicator SQL.

[0007] The principle and advantages of this solution are as follows: In practical applications, this solution relies on the Apache Calcite parser and database execution plan analysis to build a fully automated risk control indicator SQL performance detection system. First, the risk control indicator SQL is parsed into an abstract syntax tree to achieve accurate extraction of database scanning nodes. Then, index metadata matching and actual execution plan analysis are performed on each node. Finally, the detection results are output through joint judgment of quantitative indicators, which systematically solves the defects of the existing detection mode from a technical perspective.

[0008] This solution does not rely on the dataset of the test environment. It directly obtains the real execution plan by executing the EXPLAIN command through the database instance. The extracted fields such as keys and rows can accurately reflect the execution performance of SQL in the actual database, making the test results close to the online real application scenario. This solution transforms human experience into standardized automatic detection and judgment rules. Through fixed node extraction, index matching, execution plan analysis, and joint judgment processes, it achieves undifferentiated and standardized detection of all risk control indicator SQL, completely eliminating reliance on personal experience and ensuring the consistency and sustainability of audit standards. This solution uses Calcite parsing to generate an abstract syntax tree, which can deeply decompose the SQL execution logic, accurately filter TableScan nodes for all database types, and achieve targeted detection of core nodes with performance risks, avoiding superficial judgments of SQL execution logic by manual detection. This solution automates the entire process from node extraction to result output, enabling a systematic and comprehensive performance scan of risk control indicator SQL without human intervention. This significantly improves the development and deployment efficiency of risk control indicators and reduces the team's labor and management costs. This solution combines the matching results of the index metadata at the syntax tree level with the quantitative indicators of the actual execution plan returned by the database to make a joint judgment. It replaces subjective judgment with a data-driven approach, making performance risk assessment more accurate and reliable. It avoids database performance problems caused by inefficient queries from the root, and ensures the real-time performance and stability of risk control business.

[0009] Preferably, as an improvement, in step S7, the rule for the joint determination is: If the index metadata matches successfully and the keys field is not empty, the current TableScan node is considered to have passed the test. If the index metadata matches successfully, the keys field is empty, and the value of the rows field is less than 1000, the current TableScan node is considered to have passed the test. If the index metadata fails to match and the keys field is empty, the current TableScan node is prohibited from going online.

[0010] The beneficial effects of this improvement are: by combining the index matching results, actual index usage, and the number of rows scanned, it can strictly control high-risk scenarios where the index is not hit and there is no actual index usage, while also taking into account low-performance risk scenarios where the index is successfully matched but not actually used and is a small table scan. This achieves refined and differentiated judgment of performance risks, avoids the reduction in development efficiency caused by over-detection, and also eliminates online performance problems caused by missed detections.

[0011] Preferably, as an improvement, in S7, except for two cases of passing the detection and one case of prohibiting online access, all other boundary scenarios determine that the current TableScan node is manually checked; The boundary scenarios include situations where the index metadata match fails but the keys field is not empty, and situations where the index metadata match succeeds but the keys field is empty and the value of the rows field is greater than or equal to 1000.

[0012] The beneficial effects of this improvement are: by clearly defining the scope of the boundary scenarios and uniformly determining them as manual verification, the efficiency of automated detection is preserved, while the limitations of automated rules in determining special scenarios are made up for, thus avoiding misjudgments caused by the rigidity of automated rules. By marking the manual verification as "potentially a minor check," the detection system can make special marks for scenarios that cannot be accurately determined automatically, guiding technical personnel to intervene in the review in a targeted manner. While ensuring the accuracy of the detection, this approach minimizes the scope and cost of manual intervention, achieving the optimal detection mode with automated detection as the main method and manual verification as a supplement.

[0013] Preferably, as an improvement, in S8, the output rule for the final online determination result is as follows: If all TableScan nodes in the database table scanning node set pass the test, the risk control indicator SQL is deemed to have no performance risk and is allowed to go online. If any TableScan node in the database table scan node set has a detection result of "prohibited from going online", it is directly determined that the risk control indicator SQL is prohibited from going online. If the detection result of the TableScan node in the database table scanning node set is manually verified, and there is no node whose detection result is prohibited from going online, it is necessary to wait for the manual review result before determining whether the risk control indicator SQL is allowed to go online.

[0014] The beneficial effects of this improvement are as follows: The final online decision-making rules establish the detection principle of "only allowing if all passes, rejecting if any is prohibited, and requiring manual review," which achieves strict control over the overall performance risk of risk control indicator SQL. For scenarios with multiple TableScan nodes, the method of detecting each node and aggregating the results ensures that only SQL with no performance risk nodes is allowed to go online, thus fundamentally avoiding the problem of low overall risk control indicator execution efficiency caused by the performance problem of a single node. At the same time, for SQL with manual review nodes but no prohibited nodes, the method of "manual review before judgment" is adopted, which balances the rigor and flexibility of detection and avoids the impact of individual boundary scenarios on the overall online efficiency of risk control indicators.

[0015] Preferably, as an improvement, in step S3, the instance field of the TableScan node is used to distinguish between database-type and non-database-type scan nodes.

[0016] The benefits of this improvement are as follows: By using the instance field of the TableScan node as the distinguishing criterion, a simple, efficient, and quantifiable standard is provided for filtering database-type and non-database-type scan nodes. No manual intervention is required to parse node attributes, achieving automated and accurate filtering of node types. This method can quickly filter out non-database nodes that do not pose a database performance risk, reduce ineffective performance testing processes, significantly improve overall testing efficiency, and avoid bias in judgment results caused by false detection of non-database nodes, ensuring the accuracy of the set of nodes to be tested.

[0017] Preferably, as an improvement, in step S5, the data table metadata-index information is stored in the system metadata database, and the metadata database pre-stores the mapping relationship between each database table and its index.

[0018] The benefits of this improvement are as follows: Data table metadata and index information are uniformly stored in the system metadata database, and the mapping relationship between tables and indexes is pre-stored. This eliminates the need for real-time access to the business database to query index information during the index matching process, improving the execution efficiency of index matching and avoiding resource consumption caused by frequent access to the business database. Simultaneously, the centralized storage mode of the metadata database facilitates unified management, updating, and maintenance of table and index information, ensuring that the information used for index matching is always accurate and up-to-date. This guarantees the reliability of the index metadata matching results from the data source level, laying a precise data foundation for subsequent joint judgment.

[0019] Preferably, as an improvement, in step S2, the Abstract Syntax Tree (AST) includes a hierarchical relationship of aggregation nodes, condition judgment nodes, table association nodes, projection nodes, and TableScan nodes, which is used to completely restore the execution logic of the risk control indicator SQL.

[0020] The beneficial effects of this improvement are as follows: Aggregation nodes are used to identify the aggregation calculation logic of SQL, such as summation and counting, clarifying the core calculation rules of risk control indicators; Condition judgment nodes are used to identify the condition filtering logic of SQL, clarifying the judgment criteria for data filtering; Table association nodes are used to identify the association relationship between multiple tables, clarifying the association dimension and association method of data; Projection nodes are used to identify the field selection logic of SQL, clarifying the data table fields to be extracted; TableScan nodes are used to identify the data scanning source of SQL and are the core nodes for performance testing.

[0021] By reconstructing the complete hierarchical relationship including aggregation nodes, condition judgment nodes, table association nodes, projection nodes, and TableScan nodes through Abstract Syntax Tree (AST), the execution logic of risk control indicator SQL can be structured and refined, allowing the system to clearly identify the execution order, data source, calculation logic, and relationships of SQL, avoiding superficial and fragmented analysis of SQL execution logic.

[0022] Preferably, as an improvement, in step S6, the detailed execution plan further includes id, select_type, table, type, and Extra fields, whereby the Extra field is used to identify whether a covering index is used and whether there is a table lookup operation.

[0023] The beneficial effects of this improvement are as follows: `id` is used to identify the execution order of SQL queries, providing feedback on the execution priority of multi-clause SQL queries and avoiding performance analysis biases caused by misjudgments in execution order; `select_type` is used to identify the query type, such as `SIMPLE` for simple queries and `JOIN` for join queries, providing feedback on the query complexity of SQL and offering scenario references for performance risk assessment; `table` is used to identify the database table corresponding to the execution plan, ensuring accurate correspondence between the detection results and the TableScan nodes to be detected, and avoiding table name matching errors; `type` is used to identify the database query access type, such as `index` for indexed queries and `all` for full table scans, providing intuitive feedback on the query efficiency level of SQL and assisting in verifying the authenticity of the `keys` field; `Extra` is used to identify additional information about the database query execution, providing feedback on the quality of index usage—when using a covering index and without table lookups, index usage efficiency is higher, further refining the dimensions of performance risk assessment.

[0024] Extracting fields such as id, select_type, table, type, and Extra from the detailed execution plan allows for a multi-dimensional and comprehensive reconstruction of the actual execution details of SQL in the database. This not only provides core quantitative indicators such as keys and rows for performance testing but also assists in verifying the accuracy of the execution plan through other fields, making performance risk assessment more comprehensive and accurate.

[0025] Preferably, as an improvement, the risk control indicator SQL includes a hybrid real-time indicator SQL that combines proprietary database data with external data, wherein the external data includes in-memory external user tag data.

[0026] The beneficial effects of this improvement are: for the characteristics of multi-source data fusion in hybrid real-time indicator SQL, this method can accurately distinguish the scanning nodes corresponding to the data in the proprietary database and the scanning nodes corresponding to the external data, and realize targeted performance testing. This fills the technical gap in performance testing of hybrid real-time risk control indicator SQL before its launch, and makes this method more practically valuable and industry-adaptable.

[0027] Preferably, as an improvement, the non-database type scanning node includes a memory table scanning node, and the database instance is a relational database instance, including a MySQL database instance. Attached Figure Description

[0028] Figure 1 This is a flowchart of an embodiment of the present invention. Detailed Implementation

[0029] The following detailed description illustrates the specific implementation method: Example The basics are as follows: Figure 1 As shown, a method for performance testing of risk control metrics SQL before deployment includes: S1. When a system receives an application to go online based on a risk control indicator SQL, it initiates an automated slow SQL detection process.

[0030] S2. The Apache Calcite parser is used to parse the SQL of the risk control indicators to generate the corresponding abstract syntax tree (AST), which fully preserves the execution logic and node relationships of the SQL.

[0031] S3. Traverse the abstract syntax tree to accurately find and extract all TableScan nodes, i.e., database scan nodes, filter out non-database scan nodes, such as memory table nodes, and obtain the set of database table scan nodes to be detected.

[0032] S4. For each TableScan node after filtering, execute the single-table performance test process sequentially until all nodes have been tested.

[0033] S5. Extract the SQL filter conditions of the current TableScan node, match them with the data table metadata - index information saved in advance by the system, and determine whether the filter conditions hit the existing index of the data table.

[0034] S6. Concatenate the SQL statement corresponding to the current TableScan node with the EXPLAIN command, submit it to the database instance to which the table belongs for execution, obtain the detailed execution plan returned by the database, and extract the core fields of the index keys actually used and the estimated number of rows scanned in the plan.

[0035] S7 combines the index metadata matching results from S5 with the core fields of the execution plan from S6 for a joint judgment. The judgment rule is a three-branch logic; the node passes the test only if the "pass" condition is met; otherwise, it triggers "prohibit online" or "manual verification." The test passed includes: The index metadata matched successfully and the execution plan's keys field is not empty; Or the index metadata match is successful, the keys field is empty, but the execution plan rows field is <1000; The following conditions are prohibited from being implemented: index metadata matching fails and the execution plan keys field is empty; Manual verification is required for boundary scenarios that do not fall into the two categories mentioned above, such as when a match fails but the keys are not empty. These scenarios should be marked as "possibly a smaller table" and manual verification should be recommended.

[0036] S8. If all TableScan nodes pass the test, the system determines that the SQL for this risk control indicator has no performance risk and allows it to go online. If any node triggers "prohibit online", then the indicator will be prohibited from going online. If there is a "manual verification" node, you need to wait for the manual review results before determining whether to allow it to go online.

[0037] For example, in an application environment of a method for performance testing of the risk control indicator's SQL before deployment, the core logic of the risk control indicator to be tested is: The core user data (inner_table) in the proprietary MySQL database is associated with the memory-based external user label data (outer_data). Values ​​under different scenarios are aggregated through conditional judgment, and finally, the quantitative indicator exact_label is output.

[0038] The original SQL to be tested is: SELECT SUM(CASE WHEN t2.some_flag = 'a' THEN t1.value_1 ELSE t1.value_2 END)AS exact_label FROM inner_db.inner_table t1 LEFT JOIN outer_data t2 ON t1.one_id = t2.one_id AND t1.product = 'product_a'; / *inner_db.inner_table is a custom MySQL database table, abbreviated as t1; outer_data is an in-memory external tag table, abbreviated as t2; * / *The two tables are linked by the user's unique identifier one_id, and the product dimension of t1 is limited to product_a; *Based on the value of the external label t2.some_flag, sum or aggregate the value_1 or value_2 field of t1, and finally output the metric exact_label. * / S1. Start detection; When the SQL for the risk control indicator is submitted for deployment, the system triggers an automated slow SQL detection process based on Calcite, and the SQL to be detected is passed to the calcite_slow_sql_detect main function.

[0039] S2 and SQL are parsed into an Abstract Syntax Tree (AST); The system calls the Calcite parser to parse the above SQL, generating a structured abstract syntax tree (AST). The core node hierarchy is as follows: aggregateNode(sum): identifier=exact_label -- Aggregate node (summation calculation) basicCall(Case): op="=" value=lateral('a') then1=t$1.value_1 else=t$1.value_2-- Condition judgment node JoinNode: where=t$1.one_id,t$2.one_id -- Table join node project: one_id, value_1, value_2 -- Projection node (select fields) `tableScan: instance=mysql database=inner_db table=inner_table filter=['product', 'product_a']` -- Database scan node project: one_id, some_flag -- Projection node (selection field) tableScan:instance=memory database=default table=outer_data -- Memory table scan node S3, Filter database scan nodes; Iterate through all TableScan nodes in the AST and filter out only database-type nodes based on the instance field: Only the inner_db.inner_table scan node with instance=mysql is retained, while the outer_data node with instance=memory is filtered out. There is no database performance risk for in-memory tables. The set of nodes to be detected: table_scan_nodes = [TableScanNode(inner_db.inner_table, filter=['product', 'product_a'])].

[0040] S4. Initialize the single-table detection loop; The set of nodes to be tested contains only one database scan node. The system starts a single-table performance test on this node by calling the single_table_detect function.

[0041] S5. Extract the filtering criteria and perform index metadata matching; Extract the filter criteria; extract the filter criteria as product = 'product_a' from this TableScan node. Metadata matching: The system queries the index information of inner_db.inner_table in the metadata database and confirms that the table has an index idx_product for the product field. Therefore, the index metadata matching result is index_match = True.

[0042] S6. Obtain the actual execution plan from the database; The generated node SQL, the original execution SQL corresponding to this TableScan node is: SELECT one_id, value_1, value_2 FROM inner_db.inner_table WHEREproduct = 'product_a'; The EXPLAIN command for concatenation is: EXPLAIN SELECT one_id, value_1, value_2 FROM inner_db.inner_tableWHERE product = 'product_a'; After executing and extracting the core fields, and submitting them to the MySQL database for execution, the core information of the returned execution plan is shown in Table 1 below: Table 1 Returned Execution Plan Information Table Fields value illustrate id 1 Query execution order select_type SIMPLE Simple queries, without complex structures table inner_table The database table corresponding to the execution plan is inner_table partitions (NULL) The table is not partitioned, or the query does not hit any partitions. type index The database accesses data using an index full scan. possible_keys (NULL) The list of indexes that could be used to optimize queries is empty. key idx_product The index actually used (not empty) key_len 12 The index key is 12 bytes long. ref (NULL) No constants or column references that match the indexed column. rows 30 Estimated number of scan lines filtered 10.00 After filtering based on conditions, the remaining rows that meet the criteria represent 10% of the total number of rows scanned. Extra Using index Using a covering index, no table lookup operation is required. Extraction results: keys=idx_product (not empty), rows=30.

[0043] S7. Multi-dimensional quantitative judgment of detection results Substitute into the core judgment formula:

[0044] Given: M=True indicates a successful index match, K=True indicates keys are not empty; Decision: The condition M∩K is satisfied, therefore the detection result of this node is P=1 (passed).

[0045] S8. Output the final online result. The TableScan node set to be tested contains only one node that has passed the test, with no prohibited or manually checked nodes. Substitute this into the final deployment formula:

[0046] Judgment: Satisfied The system will eventually output "Allowed to go live", meaning the risk control indicator SQL can be officially launched.

[0047] The core of this solution lies in using Apache Calcite in conjunction with the held metadata to automatically identify relevant databases and tables, thereby managing the system to access the database to obtain execution plans, intelligently analyzing the execution plans, and prohibiting inefficient and performance-risk indicators from entering.

[0048] By integrating the Apache Calcite parser and the database EXPLAIN command, a fully automated execution plan analysis and verification process has been built. This enables a systematic and comprehensive performance scan of all risk control indicator SQL queries before code deployment, transforming passive, incidental risk discovery into a proactive and mandatory detection process.

[0049] This innovative approach combines "syntax tree index matching results" with "actual database execution plan" for joint analysis, and introduces quantitative metrics such as keys (index usage) and rows (number of rows scanned) as decision-making criteria. This data-driven analysis method, based on real database feedback, avoids subjective assumptions, making performance risk assessment more accurate and reliable.

[0050] Transforming expert experience into repeatable, rule-based automated logical judgments effectively reduces the team's over-reliance on individual experience and ensures the consistency and sustainability of review standards.

[0051] The above descriptions are merely embodiments of the present invention, and common knowledge such as specific technical solutions and / or characteristics are not described in detail here. It should be noted that those skilled in the art can make various modifications and improvements without departing from the technical solutions of the present invention, and these should also be considered within the scope of protection of the present invention. These modifications and improvements will not affect the effectiveness of the implementation of the present invention or the practicality of the patent. The scope of protection claimed in this application should be determined by the content of its claims, and the specific embodiments described in the specification can be used to interpret the content of the claims.

Claims

1. A method for performance testing of risk control indicators SQL before deployment, characterized in that, include: S1. Upon receiving the application to launch the risk control indicator SQL, initiate the slow SQL automated detection process. S2. The risk control indicator SQL is parsed using the Apache Calcite parser to generate an abstract syntax tree (AST) that preserves the SQL execution logic and node relationships. S3. Traverse the abstract syntax tree (AST), extract all TableScan nodes, filter out non-database type scan nodes, and obtain the set of database table scan nodes to be detected. S4. Perform the single-table performance test process sequentially on each TableScan node in the database table scan node set until all nodes have been tested. S5. Extract the SQL filter conditions of the current TableScan node, match the filter conditions with the data table metadata-index information pre-saved by the system, determine whether the filter conditions hit the existing index of the data table, and obtain the index metadata matching result. S6. Concatenate the SQL statement corresponding to the current TableScan node with the EXPLAIN command, submit it to the database instance to which the data table corresponding to the node belongs for execution, obtain the detailed execution plan returned by the database, and extract the index field keys actually used and the estimated scan row number field rows from the execution plan; S7. Combine the index metadata matching results, the keys field, and the rows field to make a joint judgment to obtain the detection result of the current TableScan node. The detection result includes pass, prohibition from going online, and manual verification. S8. Based on the detection results of all TableScan nodes, output the final online determination result of the risk control indicator SQL.

2. The method for performance testing of risk control indicators SQL before deployment according to claim 1, characterized in that, In S7, the rule for the joint determination is: If the index metadata matches successfully and the keys field is not empty, the current TableScan node is considered to have passed the test. If the index metadata matches successfully, the keys field is empty, and the value of the rows field is less than 1000, the current TableScan node is considered to have passed the test. If the index metadata fails to match and the keys field is empty, the current TableScan node is prohibited from going online.

3. The method for performance testing of risk control indicators SQL before deployment according to claim 2, characterized in that, In S7, except for two cases where the detection passes and one case where the online access is prohibited, all other boundary scenarios determine that the current TableScan node is manually checked. The boundary scenarios include situations where the index metadata match fails but the keys field is not empty, and situations where the index metadata match succeeds but the keys field is empty and the value of the rows field is greater than or equal to 1000.

4. The method for performance testing of risk control indicators SQL before deployment according to claim 3, characterized in that, In S8, the output rule for the final online determination result is as follows: If all TableScan nodes in the database table scanning node set pass the test, the risk control indicator SQL is deemed to have no performance risk and is allowed to go online. If any TableScan node in the database table scan node set has a detection result of "prohibited from going online", it is directly determined that the risk control indicator SQL is prohibited from going online. If the detection result of the TableScan node in the database table scanning node set is manually verified, and there is no node whose detection result is prohibited from going online, it is necessary to wait for the manual review result before determining whether the risk control indicator SQL is allowed to go online.

5. The method for performance testing of risk control indicators SQL before deployment according to claim 4, characterized in that: In S3, the instance field of the TableScan node is used to distinguish between database type and non-database type scan nodes.

6. The method for performance testing of risk control indicators SQL before deployment according to claim 5, characterized in that: In step S5, the data table metadata-index information is stored in the system metadata database, and the metadata database pre-stores the mapping relationship between each database table and its index.

7. The method for performance testing of risk control indicators before SQL deployment according to claim 6, characterized in that: In S2, the Abstract Syntax Tree (AST) includes a hierarchical relationship of aggregation nodes, condition judgment nodes, table association nodes, projection nodes, and TableScan nodes, which is used to fully restore the execution logic of the risk control indicator SQL.

8. The method for performance testing of risk control indicators SQL before deployment according to claim 7, characterized in that: In S6, the detailed execution plan also includes id, select_type, table, type, and Extra fields. The Extra field is used to identify whether a covering index is used and whether there is a table lookup operation.

9. The method for performance testing of risk control indicators SQL before deployment according to claim 8, characterized in that: The risk control indicator SQL includes a hybrid real-time indicator SQL that combines proprietary database data with external data, and the external data includes in-memory external user tag data.

10. The method for performance testing of risk control indicators SQL before deployment according to claim 9, characterized in that: The non-database type scanning nodes include memory table scanning nodes, and the database instances are relational database instances, including MySQL database instances.

Images