Strategy for customizing table division according to service code based on Spring and Mybatis

Abstract

The invention discloses a Spring and Mybatis-based self-defined table division strategy according to a service code, and relates to the technical field of relational number libraries, the strategy comprises a table division client and a table division server, the table division client comprises a CodeShard Aop table division section, a CodeShard Interceptor table division interceptor and a CodeTableShard table division context; and the sub-table server side comprises a code-hard-service sub-table service, and the sub-table server side comprises a code-hard-service sub-table service. According to the method, table division is carried out according to the service code, tables which are related to the code and need to be subjected to table division are uniformly partitioned, which sub-table the data exists can be self-defined, the table division condition of the data can be dynamically adjusted, the data related to the service code can be locked in the adjusting process, in addition, the database division condition is supported, the data are dispersed into a plurality of tables, and the table division efficiency is improved. The data volume of a single table is reduced, so that the data query and operation performance is improved, the index of the database can be more effectively utilized, the index efficiency is improved, and the data retrieval speed is increased.

Description

Technical Field

[0001] The present invention relates to the technical field of relational databases, and in particular to a self-defined table partitioning strategy based on Spring and Mybatis according to business codes. Background Art

[0002] For relational databases such as MySQL and Oracle, when the amount of data in a single table increases to a certain extent, the query of the table will become slower and slower. At this time, you should consider splitting the table, that is, spreading the data of a table into multiple tables.

[0003] At present, the solutions on the market generally set a table partitioning rule for a certain table, such as partitioning by time, putting the data of 2017 in table xxx into table xxx_2017, and the data of 2018 into table xxx_2018... There has always been a difficult problem in this way of partitioning, that is, the data of the table is related. When the data of a table without partitions and a table with partitions need to be associated for paging query, deletion, modification and other operations. Such solutions cannot meet the requirements. Some solutions can partially meet the requirements, such as only meeting the requirements of modification and deletion. However, it is also necessary to make relatively large changes to the original code: for example, the original Mybatis plug-in method cannot be used, and a new method with the same function must be added to replace the unusable method to place the parameters or annotations used for partitioning.

[0004] Currently, no effective solution has been proposed for the problems in the related technologies. Summary of the invention

[0005] In view of the problems in the related art, the present invention proposes a customized table partitioning strategy based on Spring and Mybatis according to business code to overcome the above technical problems existing in the existing related art.

[0006] The technical solution of the present invention is achieved in this way:

[0007] A custom table partitioning strategy based on Spring and Mybatis according to business code, including: table partitioning client and table partitioning server, wherein;

[0008] The table sharding client includes: CodeShardAop table sharding aspect, CodeShardInterceptor table sharding interceptor and CodeTableShard table sharding context;

[0009] The table sharding service end includes: code-shard-service table sharding service, wherein;

[0010] The CodeShardInterceptor table interceptor is represented as a Mybatis plug-in, configured into the project, and called through the Mybatis job;

[0011] The code-shard-service table service is used to configure the service management table, which is responsible for maintaining the application status of the business code and partitions, and synchronizing the status to Redis. The service management table includes: a partition code table shard_code and a data migration configuration table data_move_config.

[0012] Further, configuring the CodeShardInterceptor table interceptor includes the following steps:

[0013] Intercept all SQL requests in the app and obtain businessCode from the table sharding tool CodeTableShard;

[0014] If the data is obtained, the shardCode corresponding to the businessCode is obtained from Redis according to the businessCode, and then the shard table name is replaced by the SQL to be executed.

[0015] Furthermore, the Mybatis job call includes the following steps:

[0016] Get the business type to be divided into tables from the configuration file;

[0017] Send a request to code-shard-service through the network using the business type as a parameter;

[0018] code-shard-service will return which shard tables correspond to each business type and determine the returned data structure, including: marking a table that only exists in one business type, and its CodeShardInterceptor shard table interceptor will return the corresponding data object and store it in the shardWorkerMap attribute.

[0019] Furthermore, the code-shard-service table sharding service includes: table sharding information acquisition and table sharding management.

[0020] Furthermore, the sub-table information acquisition includes: configuring two network interfaces, respectively used to obtain a sub-table name list, and querying all sub-table names under the business type from the data migration configuration table data_move_config according to the business type and returning and obtaining the partition number.

[0021] Furthermore, the shard table management configures two network interfaces, which are respectively used to create a partition number corresponding to the business code, store the transmitted parameters in the shard_code table, and migrate the data of a certain business code to a new partition.

[0022] Beneficial effects of the present invention:

[0023] The present invention is based on Spring and Mybatis to customize the sub-table strategy according to the business code, through the plug-in CodeShardInterceptor sub-table interceptor of Mybatis, the configuration is configured into the project, and is called by Mybatis work, and the code-shard-service sub-table service is used to configure the service management table, which is responsible for maintaining the application of the business code and the partition, and the situation is synchronized to Redis, the sub-table strategy is customized according to the business code, the sub-table is carried out according to the business code, the table that needs to be sub-tableed related to the code is uniformly partitioned, and which sub-table the data exists in can be customized. The sub-table situation of the data can be dynamically adjusted, and the adjustment process will lock the data related to the business code and prevent operation. In addition, the situation of supporting sub-libraries, such as order and payinfo tables in library 1, and attendance tables in library 2, the data is dispersed into multiple tables, the data volume of a single table is reduced, thereby improving the query and operation performance of the data, and the index of the database can be more effectively utilized, the efficiency of the index is improved, and the retrieval speed of the data is accelerated. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0025] Figure 1 This is a principle block diagram of a custom table partitioning strategy based on Spring and Mybatis according to a business code according to an embodiment of the present invention;

[0026] Figure 2 It is a call flow chart after calling a method of the Dao layer based on a custom table partitioning strategy according to business code in Spring and Mybatis according to an embodiment of the present invention;

[0027] Figure 3 It is a flowchart of a replaceTableName method for customizing a table partitioning strategy based on Spring and Mybatis according to an embodiment of the present invention;

[0028] Figure 4 This is a schematic diagram of an interface implementation process of a custom table partitioning strategy based on Spring and Mybatis according to an embodiment of the present invention;

[0029] Figure 5 The present invention is a schematic diagram of a calling relationship of a customized table partitioning strategy based on Spring and Mybatis according to a business code according to an embodiment of the present invention. DETAILED DESCRIPTION

[0030] The following will be combined with the accompanying drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field belong to the scope of protection of the present invention.

[0031] According to an embodiment of the present invention, a custom table partitioning strategy based on Spring and Mybatis according to business code is provided.

[0032] like Figure 1-Figure 5 As shown, according to an embodiment of the present invention, a custom table partitioning strategy based on Spring and Mybatis according to business code includes: a table partitioning client and a table partitioning server, wherein;

[0033] The table sharding client includes: CodeShardAop table sharding aspect, CodeShardInterceptor table sharding interceptor and CodeTableShard table sharding context;

[0034] The table sharding service end includes: code-shard-service table sharding service, wherein;

[0035] CodeShardAop table-splitting aspect is an aspect for the annotation: "@CodeShard", which is configured into the project. The annotation @CodeShard is provided by the present invention. All methods marked with @CodeShard will enter this aspect when called, and will return to this aspect first after the method ends. Therefore, this aspect can uniformly process methods marked with @CodeShard before and after calling. CodeShardInterceptor is provided by the present invention. It is a plug-in of mybatis and is configured into the project. It can modify the sql to be executed.

[0036] This technical solution, such as Figure 2As shown, when the hello method in the example is called, hello is a method in the service layer. The hello method will call the dao layer method: world1Dao.select, world2Dao.get. The sql of these two methods must be processed in separate tables. First, mark @CodeShard on the service. Then set the businessCode (business code) before calling the first dao layer method. The first parameter in setCode specifies what business it is, and the second parameter specifies the business code of the business. In this example, the first parameter specifies the "schoolCode" business, and the second parameter sets the value of schoolCode. In this way, the original Dao layer method does not need to be changed to achieve the purpose of passing the business code. At the same time, because the dao layer method does not need to be changed, the native methods of the third-party plug-ins of mybatis can also be divided into tables, such as selectAll, selectCount, selectOne, selectByExample, etc. of tk.mybatis.

[0037] Specifically, the following steps are included:

[0038] The CodeShardAop table-sharding aspect first checks whether there is business code information in CodeTableShard. If there is, it records the information and clears CodeTableShard. The reason for doing this is to prevent the information in the caller's CodeTableShard from being overwritten by the callee's business code information when a method annotated with @CodeShard calls another method annotated with @CodeShard.

[0039] After the setCode method of CodeTableShard is called in the hello method, CodeTableShard will record the current business code information. The advantage of using CodeTableShard to pass sub-table information is that there is no need to modify the original dao layer method (current solutions on the market all require modifying the dao layer method by adding method parameters to pass the business code information for sub-tables).

[0040] When calling CodeShardInterceptor, CodeShardInterceptorr will intercept all SQL requests in the app and obtain the businessCode from CodeTableShard. If the businessCode is obtained, try to obtain the corresponding shardCode from redis based on the businessCode. If the shardCode cannot be obtained from redis, get the shardCode from the sharding service. Then replace the sql to be executed with the sharding table name, such as replacing the sql: select*from order where... with select*from order_code_1where... The benefit of doing this: as long as one of redis and the sharding service exists, the sharding operation process will continue, ensuring high availability.

[0041] Finally, when the hello method is executed, the CodeShardAop table-sharding aspect will clear the business code information in the current CodeTableShard and set the business code information recorded in step 1 back to CodeTableShard.

[0042] Among them, CodeShardInterceptor table interceptor is represented as a Mybatis plug-in and is configured into the project. Specifically, the following steps are included:

[0043] Intercept all SQL requests in the app and obtain the businessCode from the table shard context tool CodeTableShard.

[0044] If the query is obtained, the shardCode (partition code) corresponding to the businessCode is obtained from Redis according to the businessCode, and then the sql to be executed is replaced with the shard table name. Specifically, if the sql is: select * from order where..., it is replaced with select * from order_code_1 where...

[0045] In this technical solution, CodeShardInterceptor is a Mybatis interceptor, which implements the Interceptor interface provided by Mybatis. It is configured in the project by the configuration file, and Mybatis will call it when working.

[0046] Specifically, the project calls the CodeShardInterceptor table interceptor at startup, including the following steps:

[0047] Get the business type to be divided into tables from the configuration file, such as schoolCode and mchId;

[0048] Send a request to code-shard-service through the network using the business type as a parameter;

[0049] code-shard-service will return which shards correspond to each business type. The returned data structure is as follows: {"schoolCode":["pay","order"],"mchid":["pay_merchant","parnter"]}.

[0050] Among them, a table is marked to exist only in one business type, and its CodeShardInterceptor table interceptor will return and convert it into the corresponding data object and store it in the shardWorkerMap attribute.

[0051] CodeShardInterceptor has two main functions. Take the business type of schoolCode as an example: First, when schoolCode=123 is adjusted from zone 1 to another zone, all SQLs related to table pay and table order and only related to schoolCode=123 are intercepted. In other words, even if the table pay and table order are in the SQL to be executed, the data to be operated has nothing to do with schoolCode=123 and will not be affected. The advantage of this is that during the data migration process, only users with schoolCode=123 will be affected, and users of other schools will not be affected. The scope of impact is minimized. The intercepted SQL will not be executed and will return to the user "the system is busy". Secondly, replace the table names in the SQL: pay and order with table names with partition numbers, such as: pay_code_1, order_code_1.

[0052] In addition, the partition number process: the present invention provides the business implementer with a table partition context tool: CodeTableShard. Before the business implementer calls a certain dao layer method, he calls the setCode(CodeShardModel model, String code) method of CodeTableShard. The first parameter is the business type, "schoolCode" is passed here, and the second parameter is the business code, "123" is passed here. When the dao layer method is called, the call eventually returns to the CodeShardInterceptor table partition interceptor. The CodeShardInterceptor table partition interceptor will retrieve the value set by the business implementer through the CodeTableShard get method and obtain the corresponding partition number from Redis based on the value.

[0053] In this technical solution, the two functions of CodeShardInterceptor are both in the processing of the replaceTableName method. The flowchart of the replaceTableName method is as follows: Figure 3 shown.

[0054] In addition, the code-shard-service table service is responsible for maintaining the application status of the business code and partitions, and synchronizing the status to Redis, wherein the service management table is configured, and the service management table includes: the partition code table shard_code and the data migration configuration table data_move_config.

[0055] The partition code table shard_code mainly has the following fields:

[0056] business_code: business code;

[0057] shard_code: partition code;

[0058] mode_code: business type, such as 'SchoolCode';

[0059] is_locked: whether it is locked: 0 no, 1 yes; default value: 0;

[0060] Specifically, the is_locked field: when the data related to a business_code needs to be migrated to a partition, this field will be set to 1 first, and then set back to 0 after the data is migrated.

[0061] Among them, the data migration configuration table data_move_config mainly has the following fields:

[0062] mode_code: business type, such as 'SchoolCode';

[0063] table_name: sub-table name;

[0064] move_sql: the sql used to migrate the table data;

[0065] move_jdbc_config: the database configuration used when migrating the table data;

[0066] This technical solution, code-shard-service, provides two types of services: shard information acquisition and shard management.

[0067] Specifically, the acquisition of sub-table information includes two network interfaces:

[0068] First, get the list of sub-table names; pass in the business type, return the array of sub-table names; interface implementation: query all sub-table names under the business type from the data migration configuration table data_move_config according to the business type and return them.

[0069] Second, get the partition number; pass parameters: business type, business code, return: partition number;

[0070] Specifically, Figure 4 As shown, the interface implementation includes the following steps:

[0071] Get business type and business code;

[0072] Using business type + business code as key, try to get the area code from Redis, where:

[0073] If yes, return the area code and end;

[0074] If not, look up the area code from the partition code table shard_code based on the business type and business code, where:

[0075] If not, report an exception, and prompt: the business code is not in the partition code table;

[0076] If yes, check whether the value of is_locked in the record is 1, where:

[0077] If the value of is_locked is not 1, the partition code is used as the value;

[0078] If the value of is_locked is 1, the value is "LOCKED:" + partition code;

[0079] Use business type + business code as key, store it in redis with value as value, and return the value as partition number.

[0080] In this technical solution, after obtaining the partition number, the CodeShardInterceptor table interceptor must first check whether the partition number starts with "LOCKED:". If so, it means that the data of the business code is being migrated to the partition.

[0081] Specifically, sub-table management includes two network interfaces:

[0082] First, create the partition number corresponding to the business code; pass parameters: business type, business code, partition number; requirement: the business implementer must call this interface to create the partition number corresponding to the business code when the business code is created, otherwise the CodeShardInterceptor table interceptor will report an error when obtaining the partition number corresponding to the business code;

[0083] Interface implementation: Store the passed parameters in the shard_code table.

[0084] Second, migrate the data of a certain business code to a new partition; pass parameters: business type, business code, target partition.

[0085] Interface implementation includes the following steps:

[0086] The business type + business code is used as the key, and "LOCKED:" + the current partition number is used as the value and stored in Redis;

[0087] For the records corresponding to the business type and business code in the shard_code table, is_locked is set to 1;

[0088] Query all records under the business code in the data_move_config table, and then execute each one: connect to the database with the configuration of move_jdbc_config, execute SQL with the current partition and target partition as parameters of move_sql, and migrate data;

[0089] After data migration is completed, the is_locked value of the record corresponding to the business type and business code in the shard_code table is set to 0;

[0090] First, store the business type + business code as the key and the target partition number as the value in Redis.

[0091] In addition, when applying, the entire data migration is divided into six parts. Two scheduled tasks: table migration task and table data migration. Four execution modules: table migration task processing module, data migration preprocessing module, data migration processing module and data migration execution module. The calling relationship between them is as follows: Figure 5 As shown, the details are as follows:

[0092] The specific table migration tasks are as follows:

[0093] 1. First, take out the first task (named Task A here) from codeshard_movedata_task. If it is empty, it means there is no migration task at present, so end the current task. If it is not empty, go to the next step;

[0094] 2. Try to obtain the cloth lock, the lock is marked as: moveTaskLock. If the acquisition fails, it means that there is already a node processing the first task, and the current task ends. If the acquisition is successful, go to the next step;

[0095] 3. Get the status value in task A. If status == 0 (the task is pending), call the shard migration task processing module to process the task. If the processing result is no (indicating that the task processing failed), end the current task. If it is true, go to the next step. If status == 0, use the mode_code and business_code of the current task as the query conditions to query the shard_code table. If the value of the field is_lock is 1, it means that the business_code is being processed by other nodes. End the current task. If it is not 1 (that is, 0), it means that the current task has been processed. Delete the current task from codeshard_movedata_task.

[0096] Go to the next step;

[0097] 4. Take the remaining tasks, traverse each task, and adjust the table migration task processing module to process each task;

[0098] 5. Release the moveTaskLock lock;

[0099] 6. End.

[0100] The shard migration task processing module receives a single record in the codeshard_movedata_task table as a parameter, as follows:

[0101] 1. Set the record status of the currently pending task in the codeshard_movedata_task table to 1 (marking that the task is being processed);

[0102] 2. Call the data migration preprocessing module with the task mode_code, business_code and target_shard_code as parameters to process data migration. If the processed program has an exception, set the status of the current task in the table codeshard_movedata_task to 2 (marking that the task is processing an exception) and return No. Otherwise, proceed to the next step;

[0103] 3. At this step, it means that the migration task has been successfully processed, and the current task is deleted from codeshard_movedata_task. Return true;

[0104] The data migration preprocessing module receives mode_code, business_code, and target_shard_code as parameters, as follows:

[0105] 1. First use the mode_code parameter to find out how many business tables there are under the business (here, get the table name array);

[0106] 2. Use mode_code and business_code as parameters to query the shard_code table. If the target_shard_code in the table is equal to the target_shard_code passed when calling this module (indicating that the data has been or is being migrated to the target partition number) or the is_lock in the table is 1 (indicating that the data is being migrated), then end the current call. Otherwise, proceed to the next step.

[0107] 3. Start database transaction;

[0108] 3.1 Update the records found in the shard_code table in step 2: is_locked = 1, target_shard_code = parameter target_shard_code, update condition: is_locked == 0, id = id of the corresponding record;

[0109] 3.2 Use the table name array obtained in step 1, the businessCode parameter, the modelCode parameter, and the ID of the record found in the shard_code table in step 2 as parameters, and insert them into the data migration table codeshard_tables in batches (one table name and one data item);

[0110] 3.3 Parameter modelCode + parameter businessCode are used as the key, and the shard_code obtained from the "LOCKED" + shard_code table is used as the value and cached in redis;

[0111] Close the transaction. If any exception occurs in the middle, roll back the transaction and throw the exception. This ensures that the three steps either succeed or fail together;

[0112] 4. Call the data migration processing module with the id in the shard_code table, the parameter mode_code, the parameter business_code, the shard_code in the shard_code table, and the parameter target_shard_code as parameters;

[0113] 5. End.

[0114] The data migration processing module receives the id, mode_code, business_code, source_shard_code and target_shard_code in the shard_code table as parameters, as follows:

[0115] 1. Use "CODE_SHARD_PROCESS_TABLE:" + mode_code + business_code as the key to try to obtain the distributed lock. If the acquisition is successful, proceed to the next step. If the acquisition fails, it means that the business_code is already being processed by other nodes, and the current call is terminated directly;

[0116] 2. Find the list of table information to be processed in the codeshard_tables table under the conditions of codeshard_tables.code_id = id in the shard_code table and codeshard_tables.status = 0. If the result is 0, it means that the data related to business_code has been migrated and unlocked (set the value of "LOCKED" + shard_code in 3.3 of the data migration preprocessing module to shard_code, where the value of shard_code is equal to target_shard_code. And set is_lock = 0 for the corresponding record in the shard_code table), and end. Otherwise, proceed to the next step;

[0117] 3. The information list found in the codeshard_tables table includes table_name and mode_code. Pass the list and the parameters source_shard_code and target_shard_code to the data migration execution module to execute data migration;

[0118] 4. Set the status of the data in the codeshard_tables table that meets the conditions codeshard_tables.code_id = id in the shard_code table and codeshard_tables.status = 0 to 1, which means migration is complete;

[0119] 5. Unlock (same as unlocking in the second step), and you are done.

[0120] The data migration execution module receives the information list found in the codeshard_tables table and source_shard_code and target_shard_code as parameters. Each data in the list has table_name, mode_code and break_point_condition information, as follows:

[0121] 1. Put each piece of information in the list into a thread for execution;

[0122] 1.1 Use table_name and mode_code to find move_url from the data_move_config table, and then enter the loop;

[0123] 1.2 Use move_url as the communication address and call the business-side interface to migrate data. The business side needs to implement the migration interface, and input parameters: business_code (business code), target_shard_code (partition number to which the business code is to be migrated) and sqlCondition (sql condition for migrating data. If the break_point_condition field in the current information is not empty, the value of this field is passed as the sqlCondition parameter, otherwise it is passed empty); return: processStatus (data processing status: 0. in progress, 1. completed), breakCondition (sql condition for the next batch of data migration after the current batch is processed);

[0124] 1.3 If the returned processStatus == 1, it means that the data of the current table has been migrated, and the loop ends and goes to step 1.5. Otherwise, go to the next step;

[0125] 1.4 Use the returned breakCondition as the next sqlCondition and repeat step 1.2;

[0126] 1.5 Set the status in the record corresponding to this information in codeshard_tables to 1, which means the migration is complete.

[0127] 2. Wait for all threads to complete execution and end.

[0128] Among them, the sub-table data migration task mainly handles the tasks that are interrupted during the migration process. It is also possible to call and compete with the sub-table migration task. The details are as follows:

[0129] 1. Query all records in the shard_code table where is_lock == 1;

[0130] 2. Based on the information of each record, call the data migration preprocessing module to process the data migration task;

[0131] 3. End.

[0132] In summary, with the help of the above technical solution of the present invention, the following effects can be achieved:

[0133] 1. Improve performance: Split tables by business code, and uniformly partition tables related to the code, and you can customize which table the data is stored in. The data splitting can be adjusted dynamically, and the adjustment process will lock the data related to the business code and prevent operations. In addition, it supports split databases, such as order and payinfo tables in database 1, and attendance table in database 2. Spread data into multiple tables to reduce the amount of data in a single table, thereby improving data query and operation performance, making more effective use of database indexes, improving index efficiency, and speeding up data retrieval.

[0134] 2. Easy to expand: The sub-tables based on business codes can be flexibly adjusted, making it easy to add more sub-tables to adapt to the continuous increase in data volume. Data management is more convenient. Sub-tables based on business codes facilitate the management and maintenance of specific business data, while reducing the risk of single point failures.

[0135] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. After considering the disclosure of the specification and the examples, those skilled in the art will easily think of other embodiments of the present disclosure. This application is intended to cover any modification, use or adaptation of the present disclosure, which follows the general principles of the present disclosure and includes common knowledge or customary technical means in the art that are not disclosed in the present disclosure. The specification and the examples are only regarded as exemplary, and the true scope and spirit of the present disclosure are indicated by the claims.

[0136] It should be understood that the present disclosure is not limited to the exact structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A custom table partitioning strategy based on Spring and Mybatis according to business code, characterized in that: include: The table splitting client and table splitting server include: The table sharding client includes: CodeShardAop table sharding aspect, CodeShardInterceptor table sharding interceptor and CodeTableShard table sharding context; The table sharding service end includes: code-shard-service table sharding service, wherein; The CodeShardInterceptor table interceptor is represented as a Mybatis plug-in, configured into the project, and called through the Mybatis job; The code-shard-service table service is used to configure the service management table, which is responsible for maintaining the application status of the business code and partitions, and synchronizing the status to Redis. The service management table includes: a partition code table shard_code and a data migration configuration table data_move_config.

2. According to claim 1, the custom table partitioning strategy based on Spring and Mybatis according to business code is characterized in that: Configuring the CodeShardInterceptor table interceptor includes the following steps: Intercept all SQL requests in the app and obtain businessCode from the table sharding tool CodeTableShard; If the data is obtained, the shardCode corresponding to the businessCode is obtained from Redis according to the businessCode, and then the shard table name is replaced by the SQL to be executed.

3. According to claim 2, the custom table partitioning strategy based on Spring and Mybatis according to business code is characterized in that: The Mybatis job call includes the following steps: Get the business type to be divided into tables from the configuration file; Send a request to code-shard-service through the network using the business type as a parameter; code-shard-service will return which shard tables correspond to each business type and determine the returned data structure, including: marking a table that only exists in one business type, and its CodeShardInterceptor shard table interceptor will return the corresponding data object and store it in the shardWorkerMap attribute.

4. According to claim 1, the custom table partitioning strategy based on Spring and Mybatis according to business code is characterized in that: The code-shard-service table sharding service includes: table sharding information acquisition and table sharding management.

5. According to claim 4, the custom table partitioning strategy based on Spring and Mybatis according to business code is characterized in that: The sub-table information acquisition includes: configuring two network interfaces, respectively used to obtain a sub-table name list, and querying all sub-table names under the business type from the data migration configuration table data_move_config according to the business type and returning and obtaining the partition number.

6. According to claim 4, the custom table partitioning strategy based on Spring and Mybatis according to business code is characterized in that: The shard table management configures two network interfaces, which are respectively used to create a partition number corresponding to the business code, store the transmitted parameters in the shard_code table, and migrate the data of a certain business code to a new partition.

Images