A graph database storage procedure parameter constantization optimization method and device

Abstract

The application discloses a kind of graph database storage procedure parameter constantization optimization method and device, belong to graph database management technical field, which method includes: receiving the storage procedure call request containing calling parameter;Before logical planning starts, the actual value of calling parameter is obtained, and the actual value is stored in the storage area accessible in query optimization stage;The storage procedure body is logically planned, and the initial execution plan containing the variable expression corresponding to calling parameter is generated;In query optimization stage, the actual value is read from the storage area, and the variable expression in the initial execution plan is replaced with the constant expression corresponding to the actual value, to generate the execution plan after constantization;The execution plan after constantization is optimized and executed.This application can generate a highly customized, efficient execution plan, thereby significantly improving the execution efficiency of storage procedure.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of graph database management, and particularly relates to a graph database storage procedure parameter constant optimization method and device. BACKGROUND

[0002] In a graph database system, a storage procedure as a core feature allows users to define complex query logic in advance and improve development efficiency and application performance through repeated calls. The existing mainstream graph database systems generally use an interpretive execution mode when processing storage procedure calls, that is, each call needs to go through five stages of syntax analysis (parsing the storage procedure body into an abstract syntax tree), semantic verification (verifying the semantic correctness of the syntax tree), logical planning (generating a logical execution plan), query optimization (applying various optimization rules to improve the execution plan), and physical execution (converting the optimized plan into physical operators and executing them).

[0003] However, this traditional implementation has significant technical defects and performance bottlenecks:

[0004] First, the parameter processing efficiency is low. When a storage procedure is called, although the caller has explicitly provided the specific values of all parameters, in the existing implementation architecture, these parameters are still represented as variable expression types in the execution plan. This design causes dynamic lookup in the runtime context through variable names every time the parameters are accessed during execution; expression calculations related to the parameters cannot be completed in the planning stage and must be delayed until the execution stage; and the optimizer loses the opportunity for deep optimization because it cannot obtain the specific values of the parameters.

[0005] Second, the optimizer's capabilities are limited. Because the parameters are represented as variables rather than actual constants, the query optimizer faces significant functional limitations when processing the storage procedure body: it cannot implement constant folding optimization for expressions containing parameters; it cannot build an efficient index scan path because most index selection rules require the right side of the filter condition to be a constant value to take effect, and the variable form of the parameters causes the optimizer to only select a full table scan, which is an inefficient access method; it cannot effectively implement predicate pushdown optimization, making it difficult to push filter conditions containing parameters to the storage layer for execution; and the statistics module cannot accurately estimate the result set cardinality based on the specific values of the parameters, further affecting the quality of optimization decisions.

[0006] Third, there is significant repeated computation overhead. For the same parameter that is referenced multiple times in a storage procedure, the existing implementation mechanism causes repeated evaluation of parameter expressions, repeated lookup operations for the same parameter, and unnecessary type checking and conversion overhead, resulting in waste of computing resources.

[0007] Fourthly, there is a concept complexity problem in the code structure. The existing implementation marks the parameters as "constant variables" in the symbol table, which is contradictory in concept: variables and constants belong to two different semantic concepts, and the mixed definition of "constant variables" confuses the nature of the boundary between the two; this special type of variable needs to be differentiated in multiple modules of the system, increasing the complexity and maintenance cost of the code, and reducing the readability and maintainability of the system.

[0008] Fifthly, the comprehensive performance is significantly affected. The cumulative effect of the above problems causes the actual execution performance of the stored procedure to be much lower than the expected level, which is specifically manifested as: for parameterized point query scenarios, the performance degradation caused by the inability to use indexes can reach several times or even dozens of times; for complex stored procedures, the cumulative optimization loss can cause performance differences of orders of magnitude; the execution efficiency of the stored procedure is lower than that of the equivalent ad hoc query, which is contrary to the original design intention of the stored procedure to improve performance.

[0009] In summary, the existing technology lacks an effective mechanism to fully utilize the priori information that the parameter value is known when the stored procedure is called, to realize more efficient query optimization and execution flow, which is also a key technical bottleneck restricting the performance improvement of the graph database stored procedure. SUMMARY

[0010] The purpose of the present application is to provide a graph database stored procedure parameter constant optimization method and device, to solve the problem that the existing graph database cannot generate the optimal execution plan when the stored procedure is called, because the query optimizer cannot obtain and utilize the specific value of the parameter, resulting in low execution performance of the stored procedure.

[0011] To achieve the above purpose, the following technical solutions are used in the present application:

[0012] A graph database stored procedure parameter constant optimization method according to the present application comprises the following steps:

[0013] Receiving a stored procedure call request containing a call parameter;

[0014] Before the logical planning starts, the actual value of the call parameter is obtained, and the actual value is stored in a storage area accessible during the query optimization phase;

[0015] Logical planning is performed on the stored procedure body to generate an initial execution plan containing a variable expression corresponding to the call parameter;

[0016] During the query optimization phase, the actual value is read from the storage area, and the variable expression in the initial execution plan is replaced with a constant expression corresponding to the actual value to generate a constant execution plan;

[0017] The optimized and executed constant plan is executed.

[0018] As a preferred, the acquiring the actual value of the call parameter comprises:

[0019] The call statement of the stored procedure call request is parsed, and an abstract syntax tree of the call statement is constructed;

[0020] The abstract syntax tree is traversed, and a parameter expression and its position information are extracted;

[0021] According to the parameter declaration order in the call statement, each parameter expression is bound to the corresponding formal parameter position;

[0022] Each parameter expression after binding is evaluated to obtain its actual value;

[0023] The parameter name, data type meta information and the actual value are encapsulated as a variable object.

[0024] As a preferred, the storage area is a context variable mapping table maintained by a request context;

[0025] The actual value is stored in the storage area, comprising:

[0026] Each parameter is registered in the context variable mapping table with the parameter name as the key and the corresponding variable object as the value.

[0027] As a preferred, before the logic planning of the stored procedure body, further comprising:

[0028] A symbol table is constructed for the stored procedure body;

[0029] In the symbol table, the call parameter is registered as a value variable symbol, wherein the value variable symbol is not associated with the actual value of the call parameter.

[0030] As a preferred, the replacing the variable expression in the initial execution plan with a constant expression corresponding to the actual value is realized by a constant optimization rule.

[0031] As a preferred, the execution of the constant optimization rule comprises the following steps:

[0032] The expression nodes in the initial execution plan are traversed;

[0033] The node of the type of bound variable expression is identified, and its variable name is extracted;

[0034] The context variable mapping table is searched with the variable name as the key;

[0035] When a matching variable object is found, a constant expression is created based on the actual value encapsulated by the variable object;

[0036] The bound variable expression node is replaced with the constant expression.

[0037] Preferably, the method further comprises:

[0038] When processing a stored procedure containing a subquery, the following steps are performed:

[0039] External variables referenced by the subquery are collected to form a set of relevant variables;

[0040] Variables that have been registered in the context variable mapping table are removed from the set of relevant variables;

[0041] An association operator is constructed for the remaining unregistered external variables.

[0042] Preferably, the optimization of the constantized execution plan comprises applying at least one of the following optimization rules:

[0043] Constant folding and simplification is performed on an operation condition containing the constant expression;

[0044] An index scan path is generated based on a filter condition composed of the constant expression;

[0045] A predicate containing the constant expression is pushed down to a storage layer;

[0046] Cardinality estimation and join order optimization are performed based on the specific value of the constant expression.

[0047] A graph database stored procedure parameter constantization optimization apparatus, comprising:

[0048] A receiving module configured to receive a stored procedure call request containing a call parameter;

[0049] A context management module configured to, before logical planning begins, obtain an actual value of the call parameter and store the actual value in a storage area accessible during a query optimization phase;

[0050] A logical planning module configured to perform logical planning on a stored procedure body to generate an initial execution plan containing a variable expression corresponding to the call parameter;

[0051] A rule rewriting module configured to, during the query optimization phase, read the actual value from the storage area and replace the variable expression in the initial execution plan with a constant expression corresponding to the actual value to generate a constantized execution plan;

[0052] An optimization execution module is configured to execute the constantized execution plan.

[0053] A computer readable storage medium storing a computer program, the computer program enabling a computer to implement the method for constantizing a graph database stored procedure parameter according to any one of the preceding embodiments when executed.

[0054] The present application has the following beneficial effects:

[0055] 1. The present application fundamentally solves the key technical bottleneck of the execution efficiency of a graph database stored procedure by innovative design at the architecture level. Compared with the prior art, the present application first achieves an order of magnitude improvement in query execution performance. By changing the stored procedure parameter from a variable lookup in the execution period to a constant use in the optimization period, the parameterized point query can fully utilize the index scan path, and the performance is improved by 10-100 times. For a complex stored procedure, the overall performance is improved by 5-50 times due to the elimination of repeated variable lookup and expression calculation overhead. This improvement makes the execution efficiency of the stored procedure comparable to that of the ad hoc query manually spliced, and even exceeds it in some scenarios.

[0056] 2. In terms of optimizer capability, the present application completely breaks through the dilemma that the optimizer cannot do anything for the stored procedure parameters in the traditional implementation. Through parameter constantization, all optimization rules based on constants such as index selection, constant folding, and predicate pushdown can take effect on the stored procedure parameters, and the statistical information module can also perform accurate cardinality estimation based on specific parameter values, thereby optimizing the join order and operator selection to produce an execution plan with higher quality. In system implementation, the present application discards the contradictory concept of “constant variable” in the original design, encapsulates the constantization logic as an independent optimization rule, and ensures the simplicity and maintainability of the code while maintaining good compatibility with the existing system.

[0057] 3. The present application also has excellent universality, is suitable for parameters of all data types, has no limitation on the complexity of the stored procedure body, and can be combined with other query optimization techniques to produce a synergistic effect. More importantly, all optimizations are completely transparent to the user, and significant performance benefits can be obtained without modifying the existing stored procedure definition and calling interface, truly realizing “zero-cost migration”. BRIEF DESCRIPTION OF DRAWINGS

[0058] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed in the embodiment or prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0059] Figure 1 is a flowchart of a graph database stored procedure parameter constantization optimization method provided by an embodiment of the present application.

[0060] Figure 2 is a flowchart of a method for obtaining an actual value of a calling parameter provided by an embodiment of the present application.

[0061] Figure 3 is a flowchart of a method for processing a subquery provided by an embodiment of the present application.

[0062] Figure 4 is a flowchart of an execution process of a constant optimization rule provided by an embodiment of the present application.

[0063] Figure 5 is a structural schematic diagram of a graph database stored procedure parameter constantization optimization apparatus provided by an embodiment of the present application.

[0064] Figure 6 is a schematic diagram of an electronic device for implementing a graph database stored procedure parameter constantization optimization method provided by an embodiment of the present application. DETAILED DESCRIPTION

[0065] In order to make the technical solutions of the present application clearer, the present application will be further described in detail below in combination with the drawings and specific embodiments. The terms "first", "second", etc. in the claims and the specification of the present application are used to distinguish similar objects, and do not necessarily describe a specific order or sequence. It should be understood that the terms used in this way can be interchanged as appropriate, which is only a distinguishing way used in the description of the embodiments of the present application to describe the objects with the same properties. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, so that the processes, methods, systems, products or devices containing a series of units do not have to be limited to those units, but can include other units not clearly listed or inherent to these processes, methods, products or devices.

[0066] Embodiment 1

[0067] As shown in Figure 1 , a graph database stored procedure parameter constantization optimization method includes steps S110-S150.

[0068] S110, receiving a stored procedure calling request containing a calling parameter;

[0069] In the present embodiment, receiving the stored procedure invocation request is the starting point of the entire optimization process. The graph database system implements reliable reception and preliminary processing of the invocation request through a multi-layer architecture. Specifically, it provides multiple access methods, such as client connection based on standard database connection protocols (such as JDBC, ODBC), RESTful API interface for web services, command line interactive interface, and direct calls between internal modules. These access methods collectively form a multi-channel request reception system that can adapt to invocation requirements in different scenarios.

[0070] At the same time, a complete stored procedure invocation request contains at least three key parts: stored procedure identification information (including name or unique identifier ID), a list of parameter expressions arranged in order, and related invocation context metadata. In actual invocation, the typical request expression takes the form of "CALL procedure_name(argument1, argument2,...)", where the parameters can be literal constants (such as the number 123, the string 'example'), variable references (such as $user_id), or complex expressions containing operations (such as $base_value+10).

[0071] S120, before the start of logical planning, obtaining the actual value of the invocation parameter and storing the actual value in a storage area accessible to the query optimization stage;

[0072] Before the start of logical planning, completing the acquisition and storage of the actual value of the parameter is the key step of the present embodiment. Through a carefully designed parameter processing flow, it is ensured that all invocation parameters have been evaluated and placed in an accessible storage area before the query optimizer starts working.

[0073] In some embodiments, as shown in Figure 2 the actual value of the invocation parameter is obtained, including:

[0074] S210, parsing the invocation statement of the stored procedure invocation request and constructing an abstract syntax tree of the invocation statement;

[0075] S220, traversing the abstract syntax tree to extract parameter expressions and their position information;

[0076] S230, according to the parameter declaration order in the invocation statement, binding each parameter expression with the corresponding formal parameter position;

[0077] S240, evaluating each parameter expression after binding to obtain its actual value;

[0078] S250, encapsulating the parameter name, data type meta-information, and actual value into a variable object.

[0079] After receiving the stored procedure invocation request, the syntax analyzer first performs lexical analysis and syntax analysis on the invocation statement, and constructs a complete abstract syntax tree accordingly. This tree structure can accurately reflect the syntax hierarchy of the invocation statement, in which the parameter expressions are accurately identified as important leaf nodes or sub-trees.

[0080] Then, the parameter extractor accesses each node of the abstract syntax tree using a depth-first traversal algorithm, and accurately extracts each parameter expression and its position information in the parameter list by identifying the characteristic syntax patterns of the parameter positions (such as comma-separated expressions within parentheses).

[0081] Next, the binder establishes a one-to-one mapping relationship between the parameter expressions and the formal parameter positions according to the declaration order of the parameters in the invocation statement. This operation strictly follows the parameter signature when the stored procedure is defined, ensuring that the actual parameters and the formal parameters are completely corresponding in position and quantity. For named parameter invocation, the system verifies the consistency of the parameter names through symbol table query; for positional parameter invocation, the mapping is directly established according to the declaration order.

[0082] Subsequently, the expression evaluator performs recursive evaluation calculation on each parameter expression that has completed binding. For literal constant expressions, the evaluator directly extracts the intrinsic value; for variable reference expressions, the system resolves the variable value by querying the current execution context; for complex operation expressions, the evaluator creates a temporary calculation environment and gradually calculates according to the operator priority until the final result is obtained. All evaluation operations are completed in an independent environment before the planning stage, ensuring that there is no side effect on subsequent query optimization.

[0083] After evaluation is completed, the system encapsulates the parameter information into a self-contained variable object (Variable), which uses a unified data structure and contains three core fields: parameter name string, data type meta-information structure body, and actual value. This encapsulation method not only maintains the semantic integrity of the parameters, but also provides convenience for subsequent storage and access.

[0084] Finally, the encapsulated variable object is registered in the context variable mapping table (contextVars) maintained by the request context (RequestContext) accessible to the query optimization phase. This context variable mapping table uses a hash table data structure, with parameter names as keys and variable objects as values, providing O(1) time complexity lookup performance. The context variable mapping table remains valid throughout the request lifecycle, ensuring that the query optimizer can quickly access the actual parameter values during the execution plan optimization process.

[0085] It should be noted that the life cycle of the context variable mapping table is bound to a single stored procedure call. Specifically, the context variable mapping table is created and populated at the beginning of the stored procedure call, and remains valid throughout the planning and optimization phase, while in the execution phase, the parameter values are passed through the interpreter's scope, and then automatically cleaned up at the end of the call. This design achieves the decoupling of optimization period constant replacement and execution period value transmission through precise life cycle management of the context variable mapping table, while maintaining the compatibility of the execution model and ensuring performance improvement.

[0086] In some embodiments, as shown in FIG. 1, when processing a stored procedure containing a subquery, the following steps are performed: Figure 3

[0087] S310, collect the external variables referenced by the subquery to form a set of related variables;

[0088] S320, remove variables that have been registered in the context variable mapping table from the set of related variables;

[0089] S330, construct an association operator for the remaining unregistered external variables after removal.

[0090] When the system parses the stored procedure, if a subquery statement is identified, it needs to distinguish between true related variables and context variables and perform differential processing. Specifically, the system first identifies all subqueries and collects all external variables referenced by each subquery to form a set of related variables. For example, when a subquery involves two external variables @cust_id and @prod_id, the system will include both @cust_id and @prod_id in the set. Then, the system checks the context variable mapping table and removes variables that have been registered in it from the set of related variables. The key to this operation is to identify variables that have been assigned a value and do not need to be dynamically transmitted, such as the scenario where @cust_id = 1001 is explicitly specified in the stored procedure. For the remaining unregistered variables, the system constructs an association (Apply) operator, which binds these variables as parameters to the subquery, thereby avoiding repeated parsing of the subquery each time the outer query is executed. This design enables the execution plan to dynamically adjust based on the actual state of the variables: when the variables are constantized, the subquery can be converted to a precomputed JOIN or materialized operation; when the variables still need to be dynamically bound, the necessary association logic is retained.

[0091] S130, logically plan the stored procedure body to generate an initial execution plan containing variable expressions corresponding to the call parameters;

[0092] In some embodiments, before logically planning the stored procedure body, the following steps are further included:

[0093] ​a symbol table is constructed for the stored procedure body;

[0094] In the symbol table, the call parameters are registered as value variable symbols, which are not associated with the actual values of the call parameters.

[0095] Before logical planning of the stored procedure body, the system also needs to perform a symbol table (SymbolTable) construction operation. This operation creates and initializes a symbol table structure corresponding to the current stored procedure body through the symbol table manager. As a core data structure in the compilation process, the symbol table is responsible for recording and managing all identifiers and their semantic attributes that appear in the stored procedure body. During the construction process, the system processes the parameter declaration part of the stored procedure header in turn, creating corresponding symbol table entries for each call parameter.

[0096] In the symbol registration process, the system adopts a specific parameter symbol registration strategy. For each call parameter, the symbol table manager calls the symbol creation interface to generate value variable symbols, which record the name, data type, scope, and other basic attributes of the parameter. However, more importantly, the symbol table deliberately maintains the separation of value variable symbols and actual parameter values during registration. In specific implementation, the "value binding" field in the symbol table entry is set to null or a special marker, explicitly indicating that the symbol has not been associated with any specific numerical value. This design ensures that the symbol only participates in type checking and syntax correctness verification during semantic verification, without performing value-related calculations or optimizations in advance.

[0097] After completing the symbol table construction, the system enters the logical planning phase. The query planner takes the abstract syntax tree and symbol table of the stored procedure body as input and begins the plan generation process. Specifically, the planner follows the top-down and step-by-step refinement principle, first parses the overall structure of the stored procedure body, identifies each query block and their related relationships. When processing expressions containing call parameters, the planner obtains the type information of the parameter symbols by querying the symbol table, ensures the correctness of the expression type, and creates corresponding binding variable expression (BindingVarTypedExpr) nodes. These binding variable expression nodes internally save references to the corresponding parameter symbols in the symbol table, but their specific numerical content remains unbound. The planner also converts the declarative semantics of the stored procedure body into a series of logical operators based on the query model of the graph database, including traversal operators, filter operators, projection operators, etc., and maintains the original form of the variable expressions in these operators.

[0098] The final generated initial execution plan is a complete logical execution tree, in which all the parts related to the calling parameters are in the form of bound variable expressions. The plan accurately reflects the query intent and data flow of the stored procedure body, while retaining the complete parameterization characteristics for the subsequent optimization stage. This design provides the necessary structural basis for the constant replacement of the query optimization stage while maintaining the correctness of the syntax and semantics.

[0099] In the query optimization stage, the actual values are read from the storage area, and the variable expressions in the initial execution plan are replaced with constant expressions corresponding to the actual values to generate a constant execution plan.

[0100] In the query optimization stage, the system first starts the constant optimization process, which is implemented through a special constant optimization rule (ConstVar2ConstantRule). The optimizer first receives the initial execution plan generated in the logical planning stage, which contains parameter expressions in the form of variables. The constant optimization rule is configured as an important optimization rule in the query optimizer rule set and is triggered when the optimizer performs algebraic transformation.

[0101] In some embodiments, as shown in FIG. 4, the execution of the constant optimization rule includes the following steps: Figure 4

[0102] S410, traverse the expression nodes in the initial execution plan;

[0103] S420, identify the node of the type of bound variable expression, and extract the variable name;

[0104] S430, use the variable name as the key to look up the context variable mapping table;

[0105] S440, when a matching variable object is found, create a constant expression based on the actual value encapsulated by the variable object;

[0106] S450, replace the bound variable expression node with the constant expression.

[0107] The optimizer uses a depth-first traversal algorithm to access all expression nodes in the initial execution plan tree, and maintains a node access stack to ensure that each expression node is accurately accessed and only accessed once.

[0108] ​During the traversal, the optimizer performs type detection on each expression node, and thus identifies the expression nodes whose types are marked as binding variables. For the identified binding variable expression (BindingVarTypedExpr) nodes, the optimizer accesses the internally stored variable name field, and extracts the full variable name string. The name is identical to the parameter name defined at the stored procedure.

[0109] After obtaining the variable name, the optimizer accesses the context variable mapping table in the current request context, and calls the hash table query interface to perform an exact match query in the context variable mapping table, using the extracted variable name as the lookup key.

[0110] When a matching variable object is found in the context variable mapping table, the optimizer extracts the encapsulated actual value from the variable object. According to the data type of the actual value and the type meta information in the variable object, the optimizer creates a corresponding constant expression (ConstTypedExpr) node. For basic data types, a corresponding literal constant expression is directly created; for complex data types, a constant expression containing serialized data is created.

[0111] After creating the constant expression, the optimizer performs an expression node replacement operation. This operation is implemented by modifying the reference of the parent node to the child node in the execution plan tree. The optimizer locates the position of the binding variable expression in the plan tree, and updates the reference of the parent node to the node as the newly created constant expression node. After the replacement is completed, the original binding variable expression node is removed from the execution plan tree.

[0112] Through the cyclic execution of the above steps, the optimizer can traverse and process all binding variable expressions corresponding to the call parameters in the initial execution plan, and generate a fully constantized execution plan. All parameter-related expressions in the plan have been replaced by specific constant values, providing an optimization basis for subsequent optimization rules such as constant folding, index selection, etc.

[0113] It should be noted that this constantization optimization rule only applies to the input parameters of the stored procedure, and does not process variables defined or modified by the SET statement inside the stored procedure body.

[0114] S150, optimize and execute the constantized execution plan.

[0115] After the constantization processing is completed, the parameters in the initial execution plan have been replaced by determined constant expressions. This conversion enables the optimizer to fully utilize the known constant information in the subsequent optimization process, and carry out more in-depth and targeted optimization, including but not limited to the following aspects:

[0116] (1) Constant folding and simplification of the operation condition containing constant expression, reducing the calculation overhead at runtime;

[0117] (2) Generating index scan path based on the filter condition composed of constant expression, improving data access efficiency;

[0118] (3) Pushing down the predicate containing constant expression to the storage layer, filtering irrelevant data as early as possible, reducing the data amount of upper layer processing;

[0119] (4) Performing cardinality estimation and join order optimization based on the specific value of constant expression, thereby generating a more optimal execution plan.

[0120] Finally, the optimized execution plan is converted into an executable structure composed of physical operators and executed. In this process, since the parameter access has been replaced by constant access, the execution stage does not need to perform runtime parameter lookup, and the execution efficiency is significantly improved.

[0121] It should be noted that in the interpreted execution mode, the parameters of the stored procedure involve two levels: the first is the planning optimization level, and the parameters are exposed to the optimizer through the context variable mapping table, so that the optimizer can perform constant replacement in the optimization stage; the second is the execution level, and the parameter variable object is injected into the current scope of the interpreter for value transmission in the actual execution stage. This design decouples the logical abstraction of the parameters from the value transmission, allowing the optimizer to perform deep optimization in advance to improve execution efficiency, while retaining the flexibility of the interpreted execution mode.

[0122] The embodiment "fixes" the parameter values known at the time of the stored procedure call to the query structure before the query optimization stage, so that the optimizer can see a query statement with all values explicitly specified, enabling it to fully apply a series of optimization methods such as constant folding, index selection, and accurate cardinality estimation, and finally generate a highly customized and efficient execution plan (especially an index scan plan), thereby significantly improving the execution efficiency of the stored procedure.

[0123] Actual measurements also show that the embodiment achieves an order of magnitude improvement in query execution performance. By converting the stored procedure parameters from variable lookup at the execution stage to constant use at the optimization stage, the parameterized point query can fully utilize the index scan path, with a performance improvement of 10-100 times. For complex stored procedures, the overall performance improvement can reach 5-50 times due to the elimination of repeated variable lookup and expression calculation overhead.

[0124] Embodiment 2

[0125] As shown in Figure 5 , a graph database stored procedure parameter constantization optimization apparatus comprises:

[0126] receive a stored procedure call request containing a call parameter;

[0127] a context management module, configured to obtain an actual value of the call parameter before a logical plan is started, and store the actual value in a storage area accessible in a query optimization stage;

[0128] a logical plan module, configured to perform logical planning on a stored procedure body to generate an initial execution plan containing a variable expression corresponding to the call parameter;

[0129] a rule rewriting module, configured to read the actual value from the storage area in the query optimization stage, and replace the variable expression in the initial execution plan with a constant expression corresponding to the actual value to generate a constantized execution plan;

[0130] an optimization execution module, configured to optimize and execute the constantized execution plan.

[0131] The embodiment is used to implement the method provided in the above embodiment, and has the beneficial effects corresponding to the method. Technical details not described in the embodiment can be referred to the method provided in all the foregoing embodiments.

[0132] Embodiment 3

[0133] As shown in Figure 6 An electronic device includes a memory 601 and a processor 602, the memory 601 is configured to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor 602 to implement a graph database stored procedure parameter constantization optimization method.

[0134] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the electronic device described above can refer to the corresponding process in the foregoing method embodiments, which will not be described here.

[0135] A computer readable storage medium storing a computer program, the computer program causes a computer to execute when realizing a graph database stored procedure parameter constantization optimization method as described above.

[0136] For example, the computer program can be divided into one or more modules / units, one or more modules / units are stored in the memory 601 and executed by the processor 602, and the I / O interface transmission of data is completed by the input interface 605 and the output interface 606, to complete the application, one or more modules / units can be a series of computer program instruction segments that can complete a specific function, the instruction segments are used to describe the execution process of the computer program in the computer device.

[0137] The computer device can be a desktop computer, a notebook computer, a palm computer, a cloud server, and the like. The computer device can include, but is not limited to, the memory 601 and the processor 602. It can be understood by those skilled in the art that the embodiments are merely examples of the computer device, and do not limit the computer device. The computer device can include more or fewer components, or combine certain components, or include different components, for example, the computer device can further include an inputter 607, a network access device, a bus, and the like.

[0138] The processor 602 can be a central processing unit (CPU), and can also be other general-purpose processors 602, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, and the like. The general-purpose processor 602 can be a microprocessor or the processor 602 can also be any conventional processor.

[0139] The memory 601 can be an internal storage unit of the computer device, for example, a hard disk or a memory of the computer device. The memory 601 can also be an external storage device of the computer device, for example, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, and the like. Further, the memory 601 can include both the internal storage unit and the external storage device of the computer device. The memory 601 is used to store computer programs and other programs and data required by the computer device. The memory 601 can also be used to temporarily store the outputter 608. The aforementioned storage medium includes a U disk, a mobile hard disk, a read-only memory (ROM) 603, a random access memory (RAM) 604, a disk or an optical disk, and the like.

[0140] The above embodiments only express several embodiments of the present application, and the description is more specific and detailed, but it cannot be understood as a limitation on the scope of the present application. It should be noted that for those skilled in the art, without departing from the concept of the present application, a number of modifications and improvements can be made, which are within the scope of the present application. Therefore, the protection scope of the present application should be subject to the appended claims.

Claims

1. A method for optimizing constant parameters in a graph database stored procedure, characterized in that, Includes the following steps: Receive stored procedure call requests containing call parameters; Before the logical planning begins, the actual value of the calling parameter is obtained and stored in a storage area accessible during the query optimization phase. Perform logical planning on the stored procedure body to generate an initial execution plan containing variable expressions corresponding to the call parameters; During the query optimization phase, the actual value is read from the storage area, and the variable expression in the initial execution plan is replaced with a constant expression corresponding to the actual value to generate a constant execution plan. The execution plan after constantization is optimized and then executed.

2. The method for constant optimization of stored procedure parameters in a graph database according to claim 1, characterized in that, Obtaining the actual value of the calling parameter includes: Parse the call statement of the stored procedure call request and construct an abstract syntax tree of the call statement; Traverse the abstract syntax tree to extract the parameter expressions and their position information; Based on the parameter declaration order in the calling statement, each parameter expression is bound to the corresponding formal parameter position; The actual value is obtained by evaluating each parameter expression after binding. The parameter name, data type metadata, and the actual value are encapsulated into a variable object.

3. The method for constant optimization of stored procedure parameters in a graph database according to claim 2, characterized in that, The storage area is a context variable mapping table maintained by the request context; Storing the actual value in the storage area includes: Each parameter is registered in the context variable mapping table, using the parameter name as the key and the corresponding variable object as the value.

4. The method for constant optimization of stored procedure parameters in a graph database according to claim 1, characterized in that, Before performing logical planning on the stored procedure body, the following is also included: Build a symbol table for the stored procedure body; In the symbol table, the calling parameter is registered as a value variable symbol, wherein the value variable symbol is not associated with the actual value of the calling parameter.

5. The method for constant optimization of stored procedure parameters in a graph database according to claim 3, characterized in that, The replacement of the variable expressions in the initial execution plan with constant expressions corresponding to the actual values ​​is achieved through constant optimization rules.

6. The method for constant optimization of stored procedure parameters in a graph database according to claim 5, characterized in that, The execution of the constant optimization rule includes the following steps: Iterate through the expression nodes in the initial execution plan; Identify nodes of type bind variable expression and extract their variable names; Use the variable name as the key to look up the context variable mapping table; When a matching variable object is found, a constant expression is created based on the actual value encapsulated by that variable object; Replace the bound variable expression node with the constant expression.

7. The method for constant optimization of stored procedure parameters in a graph database according to claim 3, characterized in that, The method further includes: When processing a stored procedure that contains a subquery, perform the following steps: Collect the external variables referenced by the subqueries to form a set of related variables; Remove variables that have been registered in the context variable mapping table from the set of related variables; Construct association operators for the remaining unregistered external variables after removal.

8. The method for constant optimization of stored procedure parameters in a graph database according to claim 1, characterized in that, Optimizing the constant-quantified execution plan includes applying at least one of the following optimization rules: The operation conditions containing the constant expression are folded and simplified using constant folding. Based on the filtering conditions composed of the constant expressions, an index scan path is generated; Push down the predicate containing the constant expression to the storage layer; Cardinality estimation and connection order optimization are performed based on the specific values ​​of the constant expressions.

9. A parameter constant optimization device for stored procedures in a graph database, characterized in that, include: The receiving module is used to receive stored procedure call requests containing call parameters; The context management module is used to obtain the actual value of the calling parameters before the logical planning begins, and store the actual value in a storage area accessible during the query optimization phase; The logic planning module is used to perform logical planning on the stored procedure body and generate an initial execution plan containing variable expressions corresponding to the call parameters; The rule rewriting module is used to read the actual value from the storage area during the query optimization phase and replace the variable expression in the initial execution plan with a constant expression corresponding to the actual value to generate a constant execution plan. The optimization execution module is used to optimize and execute the constantized execution plan.

10. A computer-readable storage medium storing a computer program, characterized in that, The computer program enables the computer to implement a graph database stored procedure parameter constant optimization method as described in any one of claims 1 to 8 when executed.

Images