Server database time sequence subtable control method, device and storage medium

Abstract

The application discloses a kind of server database timing subtable control method, equipment and storage medium, it is related to database management technical field, the method comprises: in response to automatic subtable instruction, extract split table name, split type and split date corresponding to log table in subtable configuration file, construct subtable rule set in conjunction with subtable strategy;According to current system time and subtable rule set, table creation task is registered for the date to be split, and subtable running state data is obtained;Through the original log table name imported by business side, subtable running state data and current system time, corresponding date calculation logic is matched, and target subtable name is calculated;According to target subtable name, create subtable, and business log is written into routing mapping to subtable, and the target timing subtable of server database is obtained.The application solves the problem of low data operation efficiency by configuring subtable rule, automatic table creation and transparent routing mechanism, improves log query performance and operation and maintenance efficiency.

Description

Technical Field

[0001] This application relates to the field of database management technology, and in particular to a control method, device and storage medium for time-series table partitioning of a server database. Background Technology

[0002] In the context of game server log database management and operational data analysis, the ability to efficiently store, quickly query, and automatically manage massive amounts of log data directly affects the efficiency of game operation analysis, customer service response speed, and system stability.

[0003] In related technologies, game server log storage, querying, and operation and maintenance management are carried out by continuously accumulating data in a single table, combined with manual table partitioning, data migration, table structure synchronization, and the creation of new data tables. This method relies on manual database operation and maintenance to be completed item by item, and uses a fixed storage structure to carry log data. It is difficult to adapt to the game server operation scenario of rapid and continuous growth of log data and dynamic changes in business needs, resulting in low data operation efficiency.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a control method, device and storage medium for time-series table partitioning of server databases, which aims to solve the technical problem of low data operation efficiency.

[0006] To achieve the above objectives, this application proposes a control method for time-series table partitioning in a server database, the method comprising: In response to the automatic table partitioning command, extract the partition table name, partition type and partition date corresponding to the log table in the partitioning configuration file, and construct a set of partitioning rules in combination with the partitioning strategy; Register table creation tasks for the dates to be split according to the current system time and the set of table splitting rules, and obtain table splitting running status data; The target sub-table name is calculated by matching the date calculation logic of the sub-table corresponding to the original log table name with the original log table name, the sub-table running status data and the current system time. Create a partitioned table based on the target partitioned table name, and map the write route of the business log to the partitioned table to obtain the target time-series partitioned table of the server database.

[0007] In one embodiment, in response to the automatic table partitioning command, the original configuration file entries in the table partitioning configuration file are extracted line by line to obtain the original configuration line set; Parse each line of the original configuration line set field by field according to the preset delimiter, determine the split table name, split type and split date in sequence, and output the fieldized configuration entries; Convert the split date strings in the fieldized configuration entries into time values, remove the specified date-type configuration entries that are earlier than the current time and are not from the current day, and obtain the valid configuration entries; Based on the retrieval index key of the split table name, the valid configuration entries are grouped and aggregated according to the split type to construct the table splitting rule set.

[0008] In one embodiment, according to the splitting type, the log table splitting rule items of the table splitting rule set are divided into daily periodic table splitting items and specified date table splitting items, and a set of table splitting items to be created is obtained by classification. Based on the set of table items to be created and the current system time, the table items put into use on the day are selected, and the original table structure is verified and reused one by one to obtain the list of table items that have taken effect on the day. Based on the list of table sub-items that have taken effect on the current day and the set of table sub-items that are still to be created, register a fixed-interval cyclic table creation task for the daily periodic table sub-items, and register a table creation task for the corresponding time for the table sub-items of the specified date, so as to obtain a set of timed table creation tasks. Integrate the list of sub-tables that have taken effect on the same day with the set of scheduled table creation tasks, and generate the running status data of the sub-tables according to the time axis.

[0009] In one embodiment, based on the list of effective table segments for the day and the daily periodic table segments, the corresponding splitting start date is compared with the current system time, and the effective status and associated time node of each item are marked to obtain the daily table segment set; Effective table items are selected from the daily table set. By comparing the current system time with the table creation time of the day, the effective table items that have exceeded the table creation time of the day are split into tables for the next day, and the table effective status set is updated. Select the table items to be effective from the set of table effective statuses, and calculate the table creation time point one day before the start date of each item's split as the first table creation trigger point; Verify whether the current system time has exceeded the initial table creation trigger time and perform corresponding supplementary table creation to obtain the daily timed trigger parameter set; Based on the daily timed trigger parameter set, a cyclic table creation task with a fixed interval is registered for the daily table entries.

[0010] In one embodiment, based on the list of table segments that have taken effect on the current day and the table segment items for a specified date, the dates to be split in the table segment items for a specified date are compared with the current system time and divided into dates to be created on the current day and dates to be created in the future. Based on the effective pending date, the original table structure is used to create sub-tables, resulting in a detailed set of sub-tables added on that day. Based on the subdivision set, the future effective dates to be created are traversed, the creation time of the future effective dates to be created is calculated, and the corresponding original table structure is matched to obtain the set of future subdivision scheduled task parameters. Based on the set of parameters for the future table partitioning scheduled tasks, register the table creation task with the corresponding trigger time for the future date to be partitioned.

[0011] In one embodiment, based on the current system time, the original log table name passed by the business side is used as the retrieval key to verify the table running status data and obtain the table rule hit identifier. Based on the hit identifier of the table partitioning rule, the writing target parsing logic of the original log table name is branched to obtain candidate table names; The candidate table name is checked against the list of effective sub-tables in the sub-table running status data for existence. After confirming that the table item meets the table name standard, the target sub-table name is output.

[0012] In one embodiment, the write route branch is determined according to the hit identifier of the table partitioning rule, and a branch determination result including the missed branch parameters and the hit branch parameters is obtained. Based on the branch determination result of the missing branch parameters, the corresponding original log table name is marked as a missing candidate table name; Based on the branch determination result of the hit branch parameters, extract the split type identifier and the date rule information to be split corresponding to the original log table; The corresponding date matching and selection algorithm is invoked based on the splitting type identifier, and the effective base date corresponding to the splitting table is obtained by matching and calculating from the date rule information to be split in combination with the current system time; The effective reference date is converted into a date suffix in a continuous number format, and a target candidate table name is generated by concatenating the date suffix with the original table name according to a preset naming rule. The target table name is obtained by integrating the target candidate table name with the target candidate table name.

[0013] In one embodiment, the metadata of the original log table corresponding to the target partition table name is connected to the log database to verify the existence of the target partition table and obtain the table existence status identifier. Using the table existence identifier, non-existent target partition tables are created using the original log table as the same source template, thus obtaining physical partition table readiness information; Based on the physical table readiness information, the original table name in the business-side log writing instruction is replaced with the target table name, and a writing mapping relationship from logical table name to physical table is constructed to obtain the routing mapping effective status data. The business logs are written to the corresponding physical partition table based on the routing mapping status data to obtain the target time-series partition table in the server database.

[0014] In addition, to achieve the above objectives, this application also proposes a server database time-series partitioning device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the server database time-series partitioning control method described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the server database time-series table partitioning control method described above.

[0016] This application provides a control method for time-series table partitioning in a server database. The method involves extracting the partition table name, partition type, and partition date corresponding to the log table in the partition configuration file from an automatic partitioning command, constructing a partitioning rule set based on the partitioning strategy, registering a table creation task for the partition date according to the current system time and the partitioning rule set to obtain partition running status data, calculating the target partition table name by matching the original log table name, partition running status data, and the current system time with the date calculation logic corresponding to the partition type, and finally creating a shared-source structure partition table based on the target partition table name and mapping the business log write route to the corresponding partition table to obtain the target time-series partition table in the server database. This method solves the technical problems of existing server log databases, such as continuous expansion of single-table data leading to degraded query performance, cumbersome and error-prone manual partitioning operations, high coupling between partitioning rules and business code, and lack of an automatic table creation mechanism that easily leads to log write failures. It improves the automation level of log database partitioning operation and maintenance and the query response efficiency of log data, achieves zero intrusion of partitioning logic into the business layer, and ensures high availability of the log write link and accuracy of data sharding by time dimension.

[0017] In summary, this application solves the technical problem of low data operation efficiency by configuring table partitioning rules, automatically creating tables on a scheduled basis, and using a transparent routing mechanism. It improves log query performance and operation and maintenance efficiency, and achieves zero business intrusion and high write reliability. Attached Figure Description

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

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating the first embodiment of the control method for time-series table partitioning of the server database in this application; Figure 2 This is the architecture diagram for the automatic table partitioning in this application; Figure 3 This is a flowchart illustrating the fourth embodiment of the control method for time-series table partitioning of the server database in this application; Figure 4 This is a flowchart illustrating the fifth embodiment of the control method for time-series table partitioning of the server database in this application; Figure 5 This is a flowchart illustrating the seventh embodiment of the control method for time-series table partitioning of the server database in this application; Figure 6 This is a schematic diagram of the time-series table partitioning device for the server database in this application.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] In related technologies, game server log storage, querying, and operation and maintenance management are carried out by continuously accumulating data in a single table, combined with manual table partitioning, data migration, table structure synchronization, and the creation of new data tables. This method relies on manual database operation and maintenance to be completed item by item, and uses a fixed storage structure to carry log data. It is difficult to adapt to the game server operation scenario of rapid and continuous growth of log data and dynamic changes in business needs, resulting in low data operation efficiency.

[0024] This application provides a solution: First, in response to the automatic table partitioning command, the partitioning table name, partitioning type, and partitioning date corresponding to the log table in the partitioning configuration file are extracted. Combined with the partitioning strategy, a partitioning rule set is constructed. Then, according to the current system time and the partitioning rule set, a table creation task is registered for the date to be partitioned, and the partitioning running status data is obtained. Next, using the original log table name passed from the business side, the partitioning running status data, and the current system time, the date calculation logic corresponding to the partitioning type of the original log table name is matched to calculate the target partitioning table name. Finally, the partitioning table is created according to the target partitioning table name, and the write route of the business log is mapped to the partitioning table to obtain the target time-series partitioning table of the server database.

[0025] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or server database time-series partitioning device capable of performing the above functions. The following description uses a server database time-series partitioning device as an example to illustrate this embodiment and the subsequent embodiments.

[0026] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0027] This application provides a method for controlling time-series table partitioning in a server database, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the control method for time-series table partitioning of the server database in this application.

[0028] In this embodiment, the control method for time-series table partitioning of the server database includes steps S10 to S40: Step S10: Respond to the automatic table partitioning command, extract the partition table name, partition type and partition date corresponding to the log table in the partitioning configuration file, and construct a set of partitioning rules in combination with the partitioning strategy.

[0029] Automatic table partitioning commands are the core control commands that trigger the log table partitioning management process, initiating the entire execution chain from configuration parsing and rule generation to subsequent table creation scheduling. The partitioning configuration file is a declarative configuration carrier that stores log table partitioning rules, carrying partitioning parameters for each log table in the form of structured row records. For example, it includes the original log table name to be partitioned, partitioning mode type, partitioning effective date, and remarks. The partitioning rule set is in-memory structured rule data generated after parsing and verification, using the original log table name as the index key, storing the partitioning mode, a list of dates to be partitioned, and partitioning timestamps for each table. Partitioning strategies are partitioning granularity rules adapted to different log data growth characteristics, including daily periodic partitioning strategies and specified date partitioning strategies.

[0030] In this embodiment, the automatic table partitioning command can be triggered in five ways. First, service startup triggering: when the log database service process completes initialization loading, the system automatically generates and issues an automatic table partitioning command to load partitioning rules and add the necessary partitions for the day, ensuring that log writes are immediately available after service startup. Second, configuration change triggering: when an update to the partitioning configuration file is detected, the system automatically generates and issues an automatic table partitioning command to reload partitioning rules and synchronously update subsequent table creation tasks, ensuring that rule changes take effect immediately. Third, manual operation and maintenance triggering: operation and maintenance personnel initiate a partitioning rule reload request through the database management backend or enter a partitioning management execution command through the command-line tool. After receiving the request, the system generates and issues an automatic table partitioning command for rule refresh and addition operations under manual intervention. Fourth, scheduled inspection triggering: according to preset periodic scheduling rules, the system automatically generates and issues an automatic table partitioning command at a fixed time each day to verify the integrity of partitioning rules and the status of created tables, and repair any abnormally missing partitioning items. Fifthly, write exception triggering: when the log write link detects an exception error that the target table does not exist, the system automatically generates and issues an automatic table partitioning instruction to urgently rebuild the corresponding partition and correct the routing rules, so as to quickly restore the log write capability.

[0031] Once the database partitioning management module receives the automatic partitioning instruction, it begins to read the partitioning configuration file and extract the partitioning parameters.

[0032] For example, there are two methods for extracting parameters from the table partitioning configuration file. The first is full-line synchronous parsing. Before the formal start of table partitioning rule construction, all rows of the configuration file are read completely. Fields are split line by line according to a preset delimiter, and the original log table name, partitioning type identifier, and partitioning date string are extracted sequentially. The format of all fields is validated synchronously, and the extracted data is then output to the rule construction module. This method has a simple and stable parsing logic, is less prone to field omissions or parsing errors, and can provide comprehensive and reliable raw parameters for rule construction. It is suitable for common scenarios with small configuration file sizes and full-load reload. The second method is incremental differential asynchronous parsing. In the case of a command triggered by a configuration change, the set of table partitioning rules that are currently in effect in memory is read first, and then the updated configuration file is read. The differences between the old and new configurations are compared line by line. Field extraction and parsing are only performed on the newly added, modified, and deleted configuration lines, while the unchanged rule entries are retained. After parsing, the in-memory rule set is updated asynchronously. This method only handles the differential configurations and does not require repeated parsing of the full content, reducing the computational overhead of configuration reload. It is suitable for production scenarios where configurations are frequently fine-tuned and need to be smoothly implemented.

[0033] Once all the splitting parameters are obtained, a set of table partitioning rules can be constructed based on the following method.

[0034] In one optional approach, the system's preset table partitioning rule structure template is first retrieved. The field definitions and validation rules within the template are extracted. Then, all extracted partitioning parameters are grouped by the original log table name, and each group is populated into the corresponding template fields. Simultaneously, expiration date filtering is performed, removing partitioning entries with dates earlier than the current time but not from the current day. Finally, a structured set of table partitioning rules is generated. This method relies on preset templates for rule construction, offering intuitive logic, standardized validation, and fast execution, making it suitable for highly standardized table partitioning scenarios.

[0035] In another alternative approach, the extracted splitting parameters are first decomposed into multiple dimensions, extracting core parameters such as the original log table name, splitting type, and splitting date. Simultaneously, the current system time is time-series calibrated to generate a base timestamp for the current day and future time window thresholds. Then, based on the splitting type parameter, corresponding splitting cycle rules, date matching rules, and table creation trigger rules are generated. Based on the date parameter, a list of dates to be split and split timestamps are generated. These rules and markers are aggregated by log table name to generate complete rule entries for each table. Subsequently, all generated rule entries undergo validity checks, including verifying the validity of the splitting date format, whether the start date is later than the current time, and whether the splitting type for the same table is unique. All invalid rule entries are removed, and all valid rule entries are aggregated by table name index, ultimately generating a set of table partitioning rules. This method can flexibly generate personalized rules tailored to the characteristics of each log table, offering richer rule dimensions and higher adaptation accuracy. It can fully match the data growth rhythm of different log tables and improve the rationality of table partitioning granularity.

[0036] In an exemplary scheme for determining a set of table partitioning rules, a pre-set rule structure template is first loaded. This template contains two basic structures: daily periodic table partitioning rules and specified date table partitioning rules. Each structure is pre-configured with corresponding field validation rules and date filtering logic. Then, basic field parsing is performed, reading the extracted partitioning parameters line by line. Each line is validated to ensure the original log table name is valid, the partitioning type identifier is within the preset enumeration range, and the partitioning date string conforms to the preset format, removing invalid configuration lines with abnormal fields. Next, for the daily periodic type configuration, the partitioning start date is extracted and converted to a timestamp. The temporal validity of the start date is validated, generating the corresponding period marker to be partitioned and the initial value of the partitioned time. For the specified date type configuration, the original log table names are grouped and aggregated, compiling all partitioning dates of the same table into a list of dates to be partitioned, while filtering out expired and non-current historical dates. Next, rule conflict verification is performed to check whether two splitting types are configured simultaneously in the same log table. If a conflict exists, the configuration with higher priority is retained and an exception message is displayed. Then, duplicate entries are removed. If multiple identical configuration lines exist, only one valid entry is retained, and the rest redundant records are discarded. Finally, all rule entries that pass all the above verifications are summarized and stored using the original log table name as an index to generate the final set of table splitting rules, which will be used for subsequent table creation task registration and dynamic table name resolution.

[0037] It should be noted that in some special cases, if the table partitioning configuration file does not contain any valid partitioning entries, an empty table partitioning rule set will be generated, and all subsequent log writes will directly use the original table name without executing the table partitioning routing logic.

[0038] Step S20: Register table creation tasks for the dates to be split according to the current system time and the set of table splitting rules, and obtain the table splitting running status data.

[0039] The table creation task is a scheduled task used to create log shards for a specified date. It includes the target table name, trigger time, execution action, and exception handling logic. The sharding runtime status data records the runtime status data of currently active shards, pending table creation tasks, and sharding rule mappings, which is used to support subsequent table name resolution and write routing.

[0040] For example, there are two ways to register and execute table creation tasks. The first is a categorized serial batch registration. After the table creation task registration process officially starts, the set of table creation rules is first divided into two categories according to the splitting type: daily periodic table creation items and specified date table creation items. Daily periodic table creation items are processed first, extracting the splitting start date of each table, calculating the initial table creation trigger time and subsequent cycle based on the current system time, and registering cyclical table creation tasks in sequence while filling in missing table creation tasks for that day. After completing the registration of daily periodic tasks, specified date table creation items are processed next, extracting the list of dates to be split for each table, registering one-time table creation tasks for each future date, and filling in missing table creation tasks for that day. After all tasks are registered, the running status data is generated uniformly. This method has a clear and orderly registration logic, and the processing of each type of task is independent and controllable, making it less prone to task conflicts or registration deviations. It provides a reliable status basis for subsequent operation and is suitable for common scenarios with a small number of table creation tasks. The second method is grouped parallel asynchronous registration. The set of table creation rules is first grouped according to the splitting type, and the parallel registration processing of the two types of table creation items is started simultaneously. Within daily periodic groups, multiple subtasks are split by log table name to calculate trigger times and register recurring tasks in parallel. Within specified date groups, multiple subtasks are split by date dimension to register one-time table creation tasks in parallel. Both types of groups execute task registration in parallel, synchronously completing the daily table creation verification. After all subtasks are completed, all task information and created table information are asynchronously summarized to generate table running status data. Simultaneously, failed registration tasks are marked to provide a basis for subsequent operational alerts. This approach fully utilizes the system's parallel processing capabilities to complete batch task registration, shortens the initialization time after rule loading, and is suitable for high-availability scenarios with a large number of tables and the need for rapid service startup.

[0041] Before registering a task, the trigger point for creating each sub-table item can be determined based on the following methods.

[0042] In one alternative approach, a pre-defined fixed table creation timing rule is invoked. This rule uniformly sets a fixed daily time as the table creation trigger time, creating the required tables for the next day one day in advance. Based on the partitioning type and date of the partitioned items, the trigger time is directly calculated using the fixed timing rule. For daily recurring items, the calculation is performed at fixed intervals; for items with specified dates, the calculation is performed at the fixed time of the day preceding the corresponding date. This result is directly used for subsequent task registration. This method is logically simple and stable, with unified and controllable triggering rules. It requires no additional adaptation calculations, quickly determines the trigger time, and is suitable for standardized table partitioning scenarios with uniform requirements for table creation timing.

[0043] In another optional approach, the log data growth characteristics, peak business write periods, and system resource load patterns of each shard are first extracted. Simultaneously, historical table creation task execution time and resource consumption data are retrieved. Then, combined with the granularity requirements of the sharding strategy, the optimal table creation trigger point for each shard is dynamically calculated. For log tables with earlier write peaks, the table creation time is advanced to avoid business peaks. For periods with lower system load, table creation tasks are prioritized to reduce resource conflicts. For low-frequency log tables on specified dates, the lead time is adjusted as needed to ensure timely availability of the shard. The feasibility of the generated trigger point is verified, confirming that the corresponding system resources can support table creation execution. After verification, this trigger point is used as the table creation trigger point for this task registration. This method can flexibly generate customized trigger points tailored to the business characteristics of each table, without relying on unified fixed rules. It offers higher adaptation accuracy, effectively avoids business peaks and resource conflicts, improves the stability of table creation execution, and adapts to complex production scenarios with diverse log table types and varying business loads.

[0044] In an exemplary scheme for determining the operational status of sharded tables, the sharding rule set and the current system base time are first loaded. This set contains two types of entries: daily sharding rules and specified-date sharding rules. Each rule is pre-configured with corresponding date calculation logic and exception handling rules. Then, the daily sharding creation is executed. All sharding rule items are traversed, and the sharding items that need to take effect on that day are selected. The existence of each table is checked by connecting to the log database one by one. For non-existent shards, creation is performed using the original table as a structural template, and the information of the created shards for that day is recorded synchronously. Next, daily sharding task registration is executed. For each daily sharding item, the initial table creation trigger time is calculated based on the current time and the sharding start date. A cyclical table creation task with a 24-hour interval is registered, and the task identifier and trigger period are recorded. Finally, specified-date task registration is executed. For each specified-date sharding item's future sharding date, the corresponding table creation trigger time of the previous day is calculated, a one-time table creation task is registered, and the task identifier and trigger time are recorded. Next, task validity is verified, checking the validity of the trigger time of all registered tasks and whether the target table name conforms to the naming rules. Invalid and abnormal tasks are removed. Then, duplicate tasks are checked. If multiple table creation tasks exist for the same target table, only the one with the earliest trigger time is retained, and the rest redundant tasks are removed. Finally, the details of the table partitioning that has taken effect on the same day, the mapping relationship between all registered table creation tasks and rules are integrated to generate the final table partitioning running status data, which is used for subsequent dynamic table name resolution and write routing.

[0045] Step S30: Using the original log table name, the table running status data, and the current system time passed from the business side, the date calculation logic of the corresponding split type of the original log table name is matched to calculate the target table name.

[0046] The original log table name is the logical table name used by the business side when writing logs. It does not contain any date suffix and is completely consistent with the business table name before table partitioning. The date calculation logic is based on the calculation rules for matching the target partition table's corresponding date according to the partition type. For daily periodic categories, it directly matches the current date based on the current time. For specified date categories, it matches the nearest partitioned date based on the current time. The target partition table name is the physical table name that is actually executed after dynamic resolution. It is composed of the original table name concatenated with a standard format date suffix.

[0047] For example, there are two methods for resolving the target table name. The first is single-step synchronous real-time resolution. After a log write request arrives, the original log table name is used as the search key to query the table's running status data. After matching the corresponding split type, the date calculation logic is called, and the target table name is calculated in one go, combined with the current system time. This result is then directly returned to the write module for execution. This method has a simple and direct resolution logic, no additional caching overhead, and the calculation result is accurate in real time. It is suitable for typical scenarios with low write request volume and infrequent changes in table splitting rules. The second method is pre-cached batch resolution. After the table running status data is updated, the target table name for all table items for the current day and the next day is pre-calculated by date dimension, generating a mapping cache from the original table name to the physical table name. When a log write request arrives, the target table name is obtained directly by querying the cache mapping, without needing to execute the date calculation logic in real time. If the cache is not hit, it falls back to real-time resolution and updates the cache synchronously. This method pre-calculates the data, which can significantly reduce the resolution time under high-concurrency writes, improve the response speed of the write chain, and is suitable for high-throughput scenarios with large log write volume and high concurrency requests.

[0048] Before performing table name resolution, the date calculation logic for the corresponding split type can be determined based on the following methods.

[0049] In one alternative approach, the system's preset fixed-date matching rules are invoked. These rules provide standard date calculation logic for both types of partitioning. Based on the partitioning type matched by the original log table name, the corresponding preset calculation logic is directly called. For daily periodic partitioning, the current system time is used as the target date; for specified date partitioning, the nearest partitioning date less than the current time is used as the target date for target table name generation. This method is logically simple and stable, with unified and controllable calculation rules. It requires no additional adaptation calculations, can quickly determine the target date, and is suitable for common scenarios with a high degree of standardization in partitioning rules.

[0050] In another optional approach, the write timing characteristics, data query frequency, and sharding granularity requirements of the original log table for the corresponding business are first extracted. Simultaneously, historical sharding usage data and query performance data for that table are retrieved. Then, the sharding rules in the sharding runtime data are combined to dynamically adapt the optimal date calculation logic. For log tables with high-frequency writes and queries concentrated on the same day, the date matching precision is refined to ensure accurate write routing. For log tables with low-frequency writes and queries spanning multiple periods, the date backtracking logic is optimized to improve matching efficiency. For log tables with special business scenarios, custom date offsets and period adjustments are supported. The feasibility of the generated date calculation logic is verified, confirming that the calculation results conform to the sharding naming rules and table creation task arrangements. After verification, it is used as the calculation logic for this table name resolution. This method can flexibly generate customized calculation logic tailored to the business characteristics of each table, without relying on fixed preset rules. It offers higher adaptation accuracy, effectively balancing write routing accuracy and query backtracking efficiency, and is suitable for complex production scenarios with diverse business scenarios and significant differences in log table characteristics.

[0051] In an exemplary scheme for determining the target sub-table name, the system first receives the original log table name, current system time, and sub-table running status data from the business side. Using the original log table name as the search key, it performs a matching check in the sub-table running status data to generate a sub-table rule hit identifier. Then, it performs a branch determination. If no sub-table rule is hit, the original log table name is directly determined as a candidate target table name. If a sub-table rule is hit, the corresponding splitting type identifier and associated date rule information are extracted. Next, for the entries that hit the rule, the date calculation logic for the corresponding splitting type is called, and the effective base date of the target sub-table is calculated by combining it with the current system time. The effective base date is then converted to a standard date suffix in continuous number format, and candidate target sub-table names are generated according to the naming rules of concatenating the date suffix with the original table name. Then, an existence check is performed, comparing the candidate target sub-table name with the list of effective sub-tables in the sub-table running status data to confirm that the table entry has been created and is usable. If the check fails, emergency rebuild logic is triggered, and the sub-table running status data is updated synchronously. Finally, the target sub-table name that passes the check is output for subsequent log writing routing mapping.

[0052] It should be noted that in some special cases, if the original log table name does not match any table partitioning rules, the date calculation and suffix concatenation process will be skipped, and the original log table name will be returned as the target table partitioning name.

[0053] Step S40: Create a partition table according to the target partition table name, and map the write route of the business log to the partition table to obtain the target time-series partition table of the server database.

[0054] The table creation process involves generating a physical table with the same structure in the database based on the target table name and the original table structure. This includes three stages: existence verification, structure replication, and result feedback. Write routing automatically replaces the original logical table name passed from the business layer with the physical table name of the time-series partition, achieving a transparent forwarding mapping mechanism for directing log data to the corresponding date partition. Mapping is a forwarding mechanism that dynamically converts the original logical table name from the business side into a physical partition name, automatically routing write requests initiated by the business layer with the original table name to the corresponding time partition, making the table partitioning logic transparent to the business layer. The target time-series partition is a physical database table that has been partitioned according to the time dimension and carries the log data for the corresponding time period. Its table structure, indexes, and constraints completely replicate the original log table, and the data range is strictly limited to the corresponding time period.

[0055] In this embodiment, table creation can be performed in two ways. The first is the pre-creation mode, which relies on a registered scheduled table creation task to complete the creation of the target table in advance. When a write request arrives, only routing mapping needs to be performed, without real-time table creation. In this mode, table creation is completely decoupled from business writes, without consuming write link time, ensuring stable and low-latency log writes, and is suitable for core log scenarios with high write performance requirements. The second is the write-on-demand creation mode, where after the log write request parses the target table name, it first checks if the target table exists. If it does not exist, the table is created immediately using the original table as a template, and write routing is executed only after creation. This mode does not rely on scheduled tasks, can handle sudden table creation needs and abnormal table creation scenarios, ensuring that write requests do not fail due to missing tables, and is suitable for non-core log scenarios with high flexibility requirements.

[0056] In this embodiment, write route mapping can be implemented in two ways. The first is statement-level dynamic replacement. During the structured query statement assembly stage for log writing, the original table name field in the statement is directly replaced with the parsed target sub-table name. After the replacement, the statement is submitted to the database for write execution. This method has a simple and direct implementation logic, requires no additional intermediate layer components, and provides precise and controllable table name replacement, making it suitable for typical scenarios where business code interacts directly with the database layer. The second method is transparent forwarding through a proxy layer. All log write requests are intercepted through a database proxy middleware. The mapping replacement from the original table name to the target sub-table name is completed at the proxy layer, and the rewritten request is then forwarded to the database for execution. This method is completely non-intrusive to business code; changes to sub-table rules do not require adjustments to the business-side code. It allows for unified management of all write traffic and is suitable for distributed scenarios where multiple business modules share a log database under a microservice architecture.

[0057] In an exemplary scheme for executing table creation and write routing, the system first receives the parsed target table name and the corresponding original log table's structure metadata. It then connects to the log database to perform an existence check on the target table, generating a table existence status identifier. Subsequently, based on the table existence status identifier, branch processing is executed. If the target table does not exist, a creation operation is performed using the original log table as the same source template, completely replicating field definitions, index configurations, and constraint rules. After creation, the details of the effective table in the table's running status data are updated. If the target table already exists, the system directly enters the routing mapping stage. Next, write routing mapping is executed, dynamically replacing the original logical table name in the business-side log write request with the target table name, establishing a transparent mapping relationship from the logical table to the physical table, and recording routing mapping logs for operational troubleshooting. Then, log data writing is performed, submitting the business log data to the corresponding physical table for persistent storage, and receiving a write success result from the database. Finally, the sharding and persistence of the log data for the corresponding time period is completed, resulting in the target time-series sharded table in the server database, split according to the time dimension.

[0058] Further, please refer to Figure 2 , Figure 2This is the architecture diagram for the automatic table partitioning in this application. The automatic table partitioning process (split_table.csv, split table comma-separated values) is located on the database server (DBS). It handles the entire process from configuration to new table creation, including configuration loading, timer registration, game log database connection, and execution of table creation statements if the table doesn't exist. The process is divided into four stages: configuration loading, DBS startup and scheduling strategy, table creation execution, and result consumption. First, in the configuration loading stage, the configuration loading function (load_config, load configuration) reads the partitioning configuration file from the specified path, extracts the table name, partition type, and partition date fields, converts the year#month#day format dates in the file to partition timestamps, and then performs a partition type determination (split_type). Based on the classification of type 1 (daily partitioning) and type 2 (split by specified date partitioning), it generates a global partitioning configuration structure (G_split_table_config [table], Global split table configuration) in memory. This structure stores three core data categories: the list of dates to be partitioned (spliting_list), the partition type (split_type), and the partitioned time (splited_time). Next, the DBS startup and scheduling strategy phase begins. After the database server initializes the timer, the service initialization timer registration event (event_mgregist_server_init_timer) triggers the table creation timer registration operation (regist_create_split_table_timer). The configuration retrieval function for the tables to be split (get_need_split_table_config) organizes the list of tables to be created, groups them by split type and table name, and then executes the creation strategy judgment. Under the daily splitting strategy, if the start date has arrived, the table for that day will be created first, and the table for the next day will be created after 2 PM on that day. Under the specified date strategy, if the date is the same day, it will be created immediately; if the date is a future date, it will be created at 2 PM one day in advance. Then, the timer registration / triggering operation is executed. Daily splitting corresponds to the registration of a 24-hour cyclic timer, and specified date corresponds to the registration of a one-time timer.Next, the table creation execution phase begins. The table creation function (create_split_table) is called. If the split time is missing, the date of tomorrow at 00:00 is used. First, the game log database (game_log, game log database) is connected. The connection is completed by passing the data source name (dsn, data source name), port, and username (user) through the database connection function (mysql.connect). The password is obtained by decrypting from the configuration. If the connection fails, an alarm with alarm number 4003 (alarm_id = 4003, alarm identification = 4003) is triggered. After the connection is successful, a new table name in the format of year, month, and day (table_YYYYMMDD, table year month day) is calculated. If the table does not exist, the table creation statement (createtable if not exists) is executed. The table is created by completely replicating the original table structure by using the new table LIKE the original table. Finally, in the results and consumption phase, after the physical shards are created, they exist and can be used directly for subsequent writes. In log write selection scenarios, the log management module (log_mgr, log manager) calls the log table name retrieval function (get_log_table_name) to select the shard with the corresponding suffix based on the current time to complete the write. If a connection failure or Structured Query Language (SCL) execution failure occurs during the table creation process, the corresponding failure alarm is triggered. The note rule is that the date in the shard configuration file is the read / write usage date; actual creation is usually completed one day in advance at 2 PM. If the database server starts up after the creation point has passed, the corresponding shard will be created retroactively.

[0059] Second Embodiment This embodiment provides an exemplary scheme for constructing a set of table partitioning rules. In this example, the original configuration entries in the table partitioning configuration file are extracted line by line, and the fields are parsed according to a preset delimiter. Then, date format conversion and expired entry filtering are performed. Finally, the table names are used as indexes to complete grouping and aggregation, thus constructing a structured set of table partitioning rules. Step S10 includes steps A11 to A14: Step A11: In response to the automatic table partitioning command, extract the original configuration file entries from the table partitioning configuration file line by line to obtain the original configuration line set.

[0060] Step A12: Parse each line of configuration file in the original configuration line set field by field according to the preset delimiter, determine the split table name, split type and split date in sequence, and output the fieldized configuration entries.

[0061] Step A13: Convert the split date string in the fieldized configuration entry into a time value, remove the specified date type configuration entries that are earlier than the current time and are not from the current day, and obtain the valid configuration entries.

[0062] Step A14: Based on the retrieval index key of the split table name, group and aggregate the valid configuration entries according to the split type to construct the table splitting rule set.

[0063] The raw configuration line set is a collection of raw text lines read line by line from the table partitioning configuration file, without field decomposition. It is the initial processing unit in the configuration parsing process. The field-based configuration entry is a structured configuration unit that, after parsing with a preset delimiter, is split into three independent fields: partition table name, partition type, and partition date. It is the core processing object for subsequent validity checks. The time value is a comparable time-series quantified value obtained by converting the date string, used to determine whether the configuration entry has expired and to support subsequent date matching calculations.

[0064] In this example, when extracting the original configuration entries from the partitioned configuration file to obtain the original configuration line set, it can be done by performing a full synchronous read, reading the entire contents of the partitioned configuration file at once, and splitting it by newline characters to obtain all the original configuration lines, thus completing the collection of the original configuration line set. Alternatively, it can be done by incremental differential read, comparing the differences between the currently effective rules in memory and the contents of the configuration file, and extracting only the newly added, modified, and deleted configuration lines to generate the original configuration line set, thus completing the differential collection of configuration lines.

[0065] After collecting the original configuration line set, the field parsing process is initiated. For each line of configuration text in the original configuration line set, it is broken down field by field according to a preset delimiter, extracting the split table name, split type, and split date in sequence, and outputting fieldized configuration entries. Then, the split date string in the fieldized configuration entries is converted into a comparable time value, and all configuration entries of the specified date type are traversed and validated, removing expired entries that are earlier than the current time and not from the current day, thus obtaining valid configuration entries. Finally, using the split table name as the retrieval index key, all valid configuration entries are grouped and aggregated according to the split type. For each split table, the corresponding split mode, the list of dates to be split, and the split timestamps are stored, constructing a set of table partitioning rules. Through layered parsing validation and structured aggregation, the accuracy and retrieval efficiency of the table partitioning rules are improved, avoiding subsequent table creation and routing anomalies caused by non-standard configuration parsing.

[0066] For example, there are two ways to construct a set of partitioned rules based on valid configuration entries. The first is a serial, table-by-table aggregation construction. Based on the original configuration row order bound to the valid configuration entries, starting from the first entry, the partitioned table name, partition type, and partition date of each entry are extracted sequentially. After processing each entry, it is synchronously assigned to the rule group corresponding to the table name, and the list of dates to be partitioned and the partition type flag under that group are updated. If a duplicate configuration entry with the same table name is encountered, deduplication is performed, retaining the valid date and removing the duplicate entry. After all valid configuration entries have been processed, the initial value of the partitioned time is added to the rule group for each table name, and a complete set of partitioned rules is generated. This method uses row-by-row serial processing with row order locking and dynamic grouping of table names. By processing each entry in accordance with the original configuration order and updating the group dynamically, it avoids the mismatch problem of cross-table configurations and restores the original definition order of the partitioned configuration.

[0067] The second method involves parallel aggregation and construction within groups. It reads valid configuration entries and resolves global table name distribution. Based on the split table names within the entries, it performs clustering, grouping configuration entries with the same table name and split type into the same configuration group. It also marks the table name boundary nodes between groups, generating multiple configuration groups with no computational dependencies. Then, it synchronously initiates parallel processing for all partitioned configuration groups. Within each configuration group, it systematically organizes all split dates, performs expiration checks and deduplication sorting, generating a list of dates to be split and a split type marker for each group. After all parallel processing for configuration groups is complete, it supplements each group with initial values ​​for the split times and establishes an index mapping by table name, summarizing to generate a complete set of table partitioning rules. This method employs a construction logic of global table name clustering and parallel processing across all groups. By pre-emptively clustering global table name distribution, it locks the configuration group range for each log table in advance, reducing the number of invalid table name matches and improving the efficiency of rule construction under large-scale configurations.

[0068] Furthermore, the process of loading the table partitioning configuration is executed by the table partitioning configuration module (split_table_cfg_mgr, splittable configuration manager), with the input being the configuration file for partitioning value separators (split_table.csv, split table comma-separated values). After reading the configuration file, the partitioning configuration module parses the configuration items line by line. The first column is the name of the log table to be split, such as logs_exp or logs_create_item. The second column is the partitioning type, with a value of 1 indicating daily partitioning and a value of 2 indicating partitioning on a specified date. The third column is the partitioning date. When the partitioning type is 1, the date is the starting date in the format of year#month#day, and partitioning is automatic every day after the starting date. When the partitioning type is 2, the date is the specified partitioning date. Multiple rows can be configured for the same table to specify multiple partitioning dates. The date parsing stage splits the date string using "#" as the separator, extracts the year, month, and day, and converts them into timestamps. The configuration storage stage constructs a global split table configuration structure (G_split_table_config), using the table name as the key. Each table stores three types of parameters: split type (split_type), a list of dates to be split (spliting_list), and the most recent split date (splited_time). Simultaneously, expired configuration filtering logic is executed. For a specified date split (split type 2), if the configured date is earlier than the current time but not today, it is not added to the list of dates to be split; instead, the most recent split date record is updated to avoid duplicate table creation. Finally, the output is the global split table configuration structure containing the table splitting rules. This process corresponds to the entire configuration loading stage in the flowchart, including file reading, split type determination, and memory configuration generation, providing a rule basis for subsequent service startup and supplementary table creation, scheduled table creation, and transparent log writing routing.

[0069] Third Embodiment This embodiment provides an exemplary scheme for generating table partitioning status data. In this example, the table partitioning rule set is first classified and filtered according to the partitioning type, and the daily table partitioning verification is completed. Then, corresponding scheduled table creation tasks are registered for the two types of partitions. Finally, the complete table partitioning status data is generated by integrating the data according to the time axis. Step S20 includes steps B11 to B14: Step B11: According to the splitting type, divide the log table splitting rule items in the table splitting rule set into daily periodic table splitting items and specified date table splitting items, and obtain the table splitting item set to be created.

[0070] Step B12: Based on the set of table items to be created and the current system time, filter out the table items that are put into use on the current day, verify and reuse the original table structure one by one, and obtain a list of table items that have taken effect on the current day.

[0071] Step B13: Based on the list of active table sub-items for the day and the set of remaining table sub-items to be created, register a fixed-interval cyclic table creation task for the daily periodic table sub-items, and register a table creation task for the corresponding time for the table sub-items of the specified date, thereby obtaining a set of scheduled table creation tasks.

[0072] Step B14: Integrate the list of sub-tables that have taken effect on the same day with the set of scheduled table creation tasks, and generate the sub-table running status data according to the time axis.

[0073] The set of table creation items is a collection of all rule entries categorized by split type and awaiting table creation scheduling. It includes two categories of table creation rule entries: daily cycle and specified date. This set serves as the basic processing unit for subsequent supplementary creation and task registration. The list of table creation items already effective for the day is a detailed collection of table creation details that, after existence verification and supplementation, can directly handle log writing on that day. This is the core data ensuring immediate writability after service startup. The set of scheduled table creation tasks is a summary of all table creation tasks registered for future split dates. It includes daily table creation tasks triggered cyclically and specified date table creation tasks triggered only once. For example, the set of table creation items includes table creation rule entries corresponding to login logs, battle logs, and item logs; the list of table creation items already effective for the day records all writable date-suffixed table names for that day; and the set of scheduled table creation tasks stores the trigger time, target table name, and execution action parameters for each task.

[0074] In this example, when dividing the table partitioning rules to obtain the set of table partitioning items to be created, a full traversal classification method can be used. This involves iterating through all entries in the table partitioning rule set one by one, and classifying them into daily periodic partitioning items and specified date partitioning items based on the partitioning type identifier, thus completing the classification of the set of table partitioning items to be created. Alternatively, a rule pre-index mapping method can be used, based on the pre-built partitioning type index of the table partitioning rule set, to batch extract the two types of partitioning items to generate the set of table partitioning items to be created, thus completing the classification process.

[0075] After classifying the set of table shards to be created, the daily table shard creation process is initiated. Based on the set of table shards to be created and the current system time, all table shards that need to be put into use that day are selected. Each shard is then connected to the log database to perform existence checks. For missing shards, the complete structure of the original log table is reused to create them, resulting in a list of effective shards for the day. Subsequently, combining the list of effective shards for the day with the remaining set of table shards to be created, fixed-interval recurring table creation tasks are registered for daily periodic shards, and one-time table creation tasks with corresponding trigger times are registered for shards on specified dates, resulting in a set of scheduled table creation tasks. Finally, the list of effective shards for the day and the set of scheduled table creation tasks are integrated by time dimension, associated with corresponding splitting rule mapping relationships, and table shard running status data is generated. This layered creation scheduling and task registration improves the availability of the table sharding service and the accuracy of task scheduling, avoiding log write anomalies caused by missing tables.

[0076] For example, there are two ways to construct a set of scheduled table creation tasks from a set of table items to be created. The first is a serial, table-by-table scheduling construction. According to the original rule order of the set of table items to be created, starting from the first item, the splitting type, splitting date, and start time parameters of each item are extracted sequentially. After processing each item, the existence verification and supplementary creation of the table for that day are completed simultaneously. Then, the trigger time of the corresponding table creation task is calculated, and the corresponding type of table creation task is registered and added to the task set. If an expired or duplicate date item is encountered, a validity verification is performed, the split time stamp is updated, and the task registration is skipped. After all table items have been supplemented and the task registration is completed, all valid table creation tasks are summarized to generate a complete set of scheduled table creation tasks. This method adopts a rule-order locked, row-by-row serial processing and dynamic task registration construction logic. By processing and dynamically supplementing and registering according to the original rule order, it avoids the problems of task timing mismatch and duplicate table creation, ensuring the consistency between table creation scheduling and rule definition.

[0077] The second approach involves grouped parallel scheduling. This involves reading the set of table entries to be created and parsing the global splitting type distribution. Based on the splitting type, clustering is performed to divide the daily periodic table entries and the specified date table entries into two independent processing groups. Date boundary nodes within each group are marked, generating multiple sub-processing units that are independent of each other in terms of scheduling. Parallel processing is then initiated synchronously for all the divided sub-processing units. Within the daily periodic group, the initial table creation trigger point for each table is calculated in batches, and a unified cyclic table creation task is registered to complete the daily table creation. Within the specified date group, the table creation trigger point for each table is calculated in batches by date dimension, and a unified one-time table creation task is registered to complete the daily table creation. After all the parallel creation and task registration for all sub-processing units are completed, all valid table creation tasks and daily creation results are summarized to generate a complete set of scheduled table creation tasks. This method employs a construction logic of global type clustering partitioning and full group parallel scheduling. By pre-splitting type clustering, the scheduling processing scope of the two types of partitioned tables is locked in advance, reducing the number of invalid type determinations and improving the efficiency of task registration and initialization under large-scale partitioning rules.

[0078] Furthermore, the automatic table creation process for the current day after server startup is executed by the automatic table creation module (split_table_mgr). The inputs are the global split table configuration structure (G_split_table_config, Global split tableconfiguration) containing the splitting rules, the current server time, and the last maintenance time (which is the startup time). The automatic table creation module iterates through the global split table configuration structure, processing each splitting type separately. For daily splitting (type 1), it first checks if the configured start date is the current day or has expired. If it is, it creates the current day's split to ensure logs can be written correctly after startup. If the startup time has passed 2 PM, it creates the next day's split. Then, it registers a daily timer, setting the start time to 2 PM of the current day or the next day, and executes the table creation operation every 24 hours. If the start date is in the future, it calculates 2 PM of the day before the start date as the timer's start time; if the current time has passed that time, it directly executes the table creation. This process corresponds to all stages in the flowchart, including the completion of the database server (DBS) initialization timer, daily split determination, and registration of the triggered timer. It is closely linked to the table partitioning rule data output during the configuration loading stage, providing usable time-series table partitioning and continuous automatic table creation scheduling capabilities for subsequent log writing.

[0079] Fourth embodiment This embodiment provides an exemplary scheme for registering daily cyclic table creation tasks. In this example, the effective status and associated time nodes of daily table items are first marked by time series comparison. Then, the table creation for the next day is completed for the effective items. For items that are yet to be effective, the first trigger time is calculated and the creation is verified. Finally, a fixed-interval cyclic table creation task is registered for all daily table items. Please refer to... Figure 3 , Figure 3 This is a flowchart illustrating the fourth embodiment of the control method for time-series table partitioning of the server database in this application. Step B13 includes steps C11-C15: Step C11: Based on the list of effective table sub-items for the day and the daily periodic table sub-items, compare the corresponding split start date with the current system time, and mark the effective status and associated time node of each item to obtain the daily table sub-item set.

[0080] Step C12: Select effective table items from the daily table set, compare the current system time with the table creation time of the day, perform table partitioning operation on the next day for the effective table items that have exceeded the table creation time of the day, and update the table effective status set.

[0081] Step C13: Select the table items to be activated from the set of table sharding statuses, and calculate the table creation time point one day before the start date of each item's sharding as the initial table creation trigger point.

[0082] Step C14: Verify whether the current system time has exceeded the initial table creation trigger time and perform corresponding supplementary table creation to obtain the daily timed trigger parameter set.

[0083] Step C15: Based on the daily timed trigger parameter set, register a cyclic table creation task with a fixed interval for the daily sub-table items.

[0084] The daily table partition set is a summary of daily periodic table partitions that have undergone time-series comparison and verification, and are marked with their effective status and associated time nodes. It serves as the basic processing unit for subsequent supplementary creation and task registration. The table partition effective status set is a detailed set of partitions updated in real time after the daily table partition verification and the next day's table partition supplementation are completed. It records the range and status of currently created and usable partitions, and is the core basis for ensuring continuous and usable log writing. The initial table creation trigger time is a preset time point when the table creation action is first executed for the partition to be effective. It is uniformly set to a fixed table creation time point one day before the split start date, used to create the corresponding table for the corresponding date in advance. The daily scheduled trigger parameter set is a standardized set of parameters used for registering scheduled tasks after current time verification and supplementary calibration. It includes the initial trigger time, cycle interval, target table naming rules, and structure template information for each partition. For example, the daily table set contains the daily table splitting rules for the corresponding battle log, item log, and login log. The table splitting status set records the names of the tables that have been created on the current day and the next day. The initial table creation trigger time is uniformly set to 2 PM on the day before the corresponding date. The daily timed trigger parameter set carries the timer start time and 24-hour interval parameters for each table.

[0085] In this example, when performing time-series comparisons on daily periodic table entries to obtain the daily table set, it can be done by comparing and marking each entry one by one. This involves iterating through all daily periodic table entries, comparing the split start date with the current system time, marking the active and pending states, and recording the corresponding associated time nodes, thus generating the daily table set. Alternatively, a batch time-series interval matching method can be used. Based on the current system time, active and pending time intervals are divided, and table entries falling into the corresponding intervals are matched in batches and their status and time nodes are uniformly marked, thus quickly generating the daily table set.

[0086] After generating the daily table partition set, the next-day supplementary creation process for effective partitions is initiated. All effective partitions are selected from the daily set, and the current system time is compared with the preset creation time for the day. For effective partitions that have exceeded this time, the next-day partition creation operation is performed, and the partition details are updated synchronously to obtain the partition status set. Next, pending partitions are selected from the effective status set, and the preset creation time of the day before the partition start date for each item is calculated as the initial creation trigger time. Then, it is verified whether the current system time has exceeded the initial creation trigger time for each pending item. For items that have exceeded this time, the corresponding partition is supplemented, and the trigger parameters are calibrated to obtain the daily scheduled trigger parameter set. Finally, based on the daily scheduled trigger parameter set, a fixed-interval cyclical partition creation task is registered for all daily partitions. This layered time-series verification and tiered supplementary creation mechanism improves the trigger accuracy and availability of daily partition scheduled tasks, avoiding the problem of missing next-day partitions due to service startup time missing the regular partition creation time.

[0087] For example, there are two ways to register cyclic table creation tasks using the daily timed trigger parameter set. The first is a serial, table-by-table time-series calibration registration. Based on the original rule order bound to the daily timed trigger parameter set, starting with the first sub-table parameter, the initial trigger time, loop interval, and target table naming rule for each item are extracted sequentially. After processing each parameter, the creation status of the corresponding sub-table is synchronously verified. For sub-tables that have not yet been created, immediate creation is performed. Then, the corresponding cyclic table creation task is registered according to the calibrated trigger time and added to the task set. If an exception occurs where the start date has expired, time-series rollback calibration is performed, updating the split timestamps and adjusting the initial trigger time. After all sub-table parameters have been verified and the tasks registered, all valid cyclic tasks are summarized to generate a complete set of timed table creation tasks. This method uses a rule-series-locked, row-by-row serial processing and time-point dynamic calibration registration logic. By processing each item according to the original rule order and dynamically calibrating, it avoids task time point mismatch and missing sub-table creation problems, ensuring the consistency between table creation scheduling and rule definition.

[0088] The second method involves grouping and parallel triggering parameter calibration and registration. This method reads the daily set of timed triggering parameters and analyzes the global effective status distribution. Based on the effective status of table entries, it performs clustering, dividing effective and pending table entries into two independent processing groups. Time boundary nodes within each group are marked, generating multiple sub-processing units that are independent of each other in scheduling. Parallel processing is then initiated synchronously for all the divided sub-processing units. Within the effective groups, the table creation time of each table is checked in batches to ensure it has exceeded the previous state, and the next day's table creation and calibration cycle start time is uniformly executed. Within the pending groups, the initial table creation trigger time of each table is calculated in batches, the current time is checked to ensure it has exceeded the previous state, and the corresponding creation is completed, calibrating the initial triggering parameters. After all parallel calibration and creation of all sub-processing units are completed, all parameters are aggregated and uniformly registered as a fixed-interval cycle for table creation tasks, generating a complete set of timed table creation tasks. This method employs a registration logic that combines global state clustering partitioning with parallel calibration of all groups. By pre-emptively clustering the effective state, the scheduling and processing scope of the two types of table partitions is locked in advance, reducing the number of invalid timing judgments and improving the efficiency of task registration and initialization under large-scale daily table partitioning rules.

[0089] Furthermore, the daily table partitioning logic for partition type 1 runs on the database server (DBS), executing a full-process scheduling based on the global splittable configuration structure (G_split_table_config) and the current server time. After the timer is initialized on the database server, the daily periodic table partitioning entries in the global splittable configuration structure are iterated. First, it checks whether the configured start date is the current day or has expired. If it is, the table for that day is created to ensure that logs can be written normally after the server starts. If the server starts after 2 PM that day, the table for the next day is created. Then, a daily timer is registered, setting the start time to 2 PM that day or the next day, and executing the table creation operation cyclically every 24 hours. If the start date is determined to be in the future, the 2 PM of the day before the start date is calculated as the timer start time. If the current time has passed that time, the table creation is executed directly. When creating a table, the function to create a split table (create_split_table) is called, connecting to the game log database (game_log, game log database). If the table does not exist, a Structured Query Language (SQL) statement is executed to create it. The new table completely replicates the fields, indexes, and constraints of the original table by referencing the original table. This process completes the daily split table creation and long-term automatic table creation scheduling, corresponding to the entire process of daily split determination, timer registration and triggering, and table creation execution in the flowchart.

[0090] Fifth embodiment This embodiment provides an exemplary scheme for registering table creation tasks for specified dates. In this example, the dates to be split for the specified date table item are first compared with the current system time, dividing them into two categories: dates to be created that take effect on the current day and dates to be created that will take effect in the future. After completing the creation of the table for the current day, the table creation trigger point for each future date to be split is calculated and matched with the corresponding original table structure template. Finally, table creation tasks with corresponding trigger points are registered for all future dates to be split. Please refer to... Figure 4 , Figure 4 This is a flowchart illustrating the fifth embodiment of the control method for time-series table partitioning of the server database in this application. Step B13 includes steps D11-D14: Step D11: Based on the list of table segments that have taken effect on the current day and the table segment items for the specified date, compare the dates to be split in the table segment items for the specified date with the current system time, and divide them into dates to be created on the current day and dates to be created in the future.

[0091] Step D12: Using the date of creation to take effect on the current day, create a sub-table based on the original table structure to obtain a detailed set of sub-tables to be created on the current day.

[0092] Step D13: Based on the subdivision detail set, traverse the future effective dates to be created, calculate the creation time of the future effective dates to be created, and match the corresponding original table structure to obtain the future subdivision scheduled task parameter set.

[0093] Step D14: Based on the set of future table partitioning scheduled tasks, register the table creation task corresponding to the trigger time point for the future date to be partitioned.

[0094] The "Today Effective Date" refers to the split date in the specified date table entry that matches the current system time and needs to be created immediately after service startup. It is the core processing object to ensure that log data can be written normally during a specific time period of the day. The "Future Effective Date" refers to the split date in the specified date table entry that is later than the current system time and needs to be scheduled for creation in advance. It is the core triggering basis for one-time table creation tasks. The "Daily Supplementary Table Creation Details Set" is the details of effective tables generated after the creation of the table for the day's pending date. It records the table name, structure template, and creation status of all specified date tables for the day, and is a supplementary component of the list of effective tables for the day. The "Future Table Splitting Scheduled Task Parameter Set" is the standardized table creation task parameter generated for future pending split dates, including the target table name, trigger time, original table structure template, and execution action information. It is the input basis for registering a one-time table creation task. A one-time table creation task is a table creation scheduling task that is executed only once at a preset trigger time. It is specifically used for the early creation of specified date tables, and is automatically deregistered after execution, without incurring loop scheduling overhead. For example, the pending creation date for the current day corresponds to the specified log splitting date of the version update day, the pending creation date for the future day corresponds to the splitting dates of multiple subsequent activity nodes and version nodes, the detailed set of the partition table to be created on the current day records all partition table names created on the current day for the specified date, the parameter set of the future partition table scheduled task carries the trigger parameters of the fixed time point of each date, and after the one-time table creation task is triggered, the table creation statement is automatically executed to complete the partition table creation and mark the task completion status.

[0095] In this example, when dividing the dates to be split into those effective today and those effective in the future, a full, date-by-date time-series comparison can be performed. This involves iterating through all dates to be split in the specified date table entry, matching each date against the current system time, and categorizing them into those effective today and those effective in the future, thus completing the division of the two types of dates. Alternatively, a batch date range matching method can be used. Based on the current system time, the time boundaries for today and the future can be divided, and the dates to be split falling into the corresponding ranges can be matched in batches and uniformly categorized, thus achieving a fast division of the two types of dates.

[0096] After classifying the dates to be split, the daily table creation process is initiated. For all dates to be created that are effective on the current day, table creation is performed using the complete structure of the corresponding original log table as a template. The list of effective tables for the current day is updated synchronously, resulting in a detailed set of tables created that day. Then, based on this detailed set, all future dates to be created are iterated through. The preset table creation time for each future date to be split is calculated, and the corresponding original table structure template and naming rules are matched to generate standardized table creation task parameters, resulting in a set of future table creation scheduled task parameters. Finally, based on the set of future table creation scheduled task parameters, a one-time table creation task with a corresponding trigger time is registered for each future date to be split. This layered time-series classification and tiered creation mechanism improves the accuracy of table creation for specified dates and the efficiency of task scheduling, avoiding write delays and resource conflicts caused by temporary table creation.

[0097] For example, there are two ways to register a one-time table creation task using the future table partitioning scheduled task parameter set. The first is a serial, date-by-date time-series calibration registration. Based on the date order bound to the future table partitioning scheduled task parameter set, starting from the earliest date to be created, the trigger time, target table name, and structure template parameters for each date are extracted sequentially. After processing the parameters for each date, the current status of the corresponding partition is synchronously verified. For partitions that have been created in advance due to special circumstances, task registration is skipped. Then, the corresponding one-time table creation task is registered according to the calibrated trigger time and added to the task set. If an exception such as a duplicate date or an expired date is encountered, a validity check is performed, the split timestamp is updated, and task registration is skipped. After all parameters for all future dates have been verified and registered, all valid one-time table creation tasks are summarized to generate a complete set of scheduled table creation tasks. This method uses a date-series locked, row-by-row serial processing and time-point dynamic calibration registration logic. By processing each item according to the date order and performing dynamic status checks, it avoids the problems of duplicate task registration and expired table creation, ensuring accurate matching between the specified date table creation schedule and business requirements.

[0098] The second method involves parallel parameter calibration and registration for table partitioning and grouping. This method reads the parameter set of future table partitioning scheduled tasks and parses the global table partitioning distribution. Based on the original log table to which the creation date belongs, it performs clustering, grouping all future creation dates belonging to the same original table into the same processing group. It also marks the date sequence within each group, generating multiple sub-processing units that have no scheduling dependencies on each other. Then, it synchronously starts parallel processing for all the partitioned sub-processing units. Within each group, it batch calculates the table creation trigger point for each creation date, uniformly verifies date validity, matches the corresponding table structure template, and batch registers the corresponding one-time table creation tasks. After all the parallel calibration and task registration for all sub-processing units are completed, it summarizes all valid one-time table creation tasks to generate a complete set of scheduled table creation tasks. This method uses a global table-attached clustering partitioning and full-group parallel scheduling registration logic. By performing pre-emptive table-attached clustering, it locks the specified date task range for each log table in advance, reducing the number of invalid table structure matches and improving the efficiency of task registration and initialization under large-scale specified date table partitioning rules.

[0099] Furthermore, the process for splitting a specified date into tables (type 2) runs on the database server (DBS). The automatic table creation module iterates through all dates to be split in the corresponding log table. If a date is exactly today, the table for that date is created immediately. If the creation date is in the future, a one-time timer is registered to trigger table creation at 2 PM the day before the specified date. During the table creation execution phase, the table creation function (create_split_table) is called, connecting to the game log database (game_log), calculating the new table name in the format "original table name_year / month / day", such as logs_exp_20231109. A Structured Query Language (SQL) statement is executed to "create table if it does not exist". The new table completely replicates the fields, indexes, and constraint rules by referencing the original table, ensuring that the structure of the new table is completely consistent with the original table. If a connection or statement execution fails during the table creation process, a failure alarm with alarm number 4003 (alarm_id=4003, alarm identification=4003) will be triggered. After the table creation is completed, the physical partitioned table already exists, and subsequent writes can be used directly. The process finally outputs the confirmation result of the partitioned table created on the current day and the timer registration result of the future partitioned table, corresponding to the entire process of specified date split determination, one-time timer registration, table creation execution and result consumption in the flowchart.

[0100] Sixth Embodiment This embodiment provides an exemplary scheme for dynamically resolving target table names. In this example, the original log table name passed from the business side is first used as the search key to perform rule validation in the table running status data, generating a table rule hit identifier. Then, based on the hit identifier, branch processing is performed on the writing target parsing logic to obtain candidate table names. Finally, after confirming the table entry is usable through existence verification, the target table name is output. Step S30 includes steps E11~E13: Step E11: Based on the current system time, use the original log table name passed in by the business side as the search key to verify the table running status data and obtain the table rule hit identifier.

[0101] Step E12: Based on the hit identifier of the table partitioning rule, perform branching processing on the writing target parsing logic of the original log table name to obtain candidate table names.

[0102] Step E13: Perform an existence check between the candidate table name and the list of effective sub-tables in the sub-table running status data. After confirming that the table item meets the table name standard, output the target sub-table name.

[0103] The table partitioning rule hit flag is a status marker indicating whether the original log table matches the table partitioning rule. It is divided into two categories: hit and miss, and is the core criterion for writing to the target branch. The write target parsing logic calculates the processing rule for the target table name to be written based on the table partitioning rule. If the rule is not hit, the original table name is directly used. If the rule is hit, the date suffix is ​​calculated according to the partitioning type and concatenated to generate a new table name. The candidate table name is the table name to be verified after branch processing, including the original table name in the case of a miss and the concatenated table name with a date suffix in the case of a hit. For example, the table partitioning rule hit flag includes two status values: rule hit and rule miss. The write target parsing logic includes two branches: directly passing through the original table name and calculating the date suffix according to the partitioning type. The candidate table name includes the original log table name and the table name to be verified with a concatenated date suffix. The table name standard is a standardized guideline for unifying the naming format of time-series tables. It requires that the physical table name follow the fixed structure of the original log table name followed by an underscore and then an 8-digit consecutive year, month, and day. For example, the compliant table name standard format that matches the original table logs_exp is logs_exp_20260709. Names that do not conform to this format, have incorrect date digits, or are missing separators are all judged as not meeting the table name standard.

[0104] In this example, when verifying the matching status of sharding rules to obtain the sharding rule hit identifier, a real-time index retrieval method can be used. After receiving the original log table name from the business side, a search and matching operation is performed in the rule index of the sharding operation status data using the table name as the key, and the corresponding hit identifier is output to complete the rule verification. Alternatively, a pre-cached mapping matching method can be used. Based on the sharding operation status data, a mapping cache between the original table name and the rule is built in advance. After receiving the original log table name, the cache is directly queried to obtain the hit identifier, thereby completing the rule verification quickly.

[0105] After generating the table partitioning rule hit flags, the write target branch processing flow is initiated. Based on the table partitioning rule hit flags, the write target parsing logic for the original log table name is branched. If no table partitioning rule is hit, the original log table name is directly identified as a candidate table name. If a table partitioning rule is hit, the date calculation logic corresponding to the partition type is matched, and the effective base date is calculated by combining it with the current system time and appending a standard format date suffix to generate a candidate table name. Subsequently, the candidate table name is checked against the list of effective partitioned tables in the table partitioning running status data for existence verification. Once the table entry is confirmed to be created and usable, the target partitioned table name is output. This layered rule matching and hierarchical verification mechanism improves the accuracy and response speed of target partitioned table name parsing, avoiding write anomalies caused by rule mismatches or non-existent tables.

[0106] For example, there are two ways to obtain the target sub-table name from the candidate table name. The first is a serial step-by-step verification and parsing. Based on the arrival sequence of write requests, starting from the first request, rule matching, branch parsing, and existence verification are executed sequentially. After each request's rule matching is completed, a corresponding hit flag is generated synchronously and the process enters the branch processing. After the candidate table name is generated, the existence verification of the list of effective sub-tables is immediately executed. If the verification passes, the target sub-table name is output; if the verification fails, an emergency rebuild process is triggered and the sub-table running status data is updated. If a request that does not match the rule is encountered, the original table name is directly passed through and the subsequent date calculation process is skipped. After all the table name parsing for all write requests is completed, a unified parsing log is recorded for operation and maintenance troubleshooting. This method uses a step-by-step serial processing logic with request sequence locking and dynamic rebuild verification. By processing sequentially according to the arrival sequence of requests and real-time status verification, it avoids the problems of table name mismatch and invalid writes, and ensures the real-time consistency between write routing and sub-table status.

[0107] The second method is batch pre-caching parallel parsing. This involves reading the table's running status data and parsing the global table time window. Based on the current system time and future time windows, it pre-calculates the target table names for all table entries for the current and next day, generating a mapping cache table from original table names to physical table names, and marking the cache's valid time range. When batch write requests arrive, parallel table name parsing for all requests is initiated simultaneously. Each request directly queries the cache mapping to obtain candidate table names and synchronously performs cache validity checks. If a cache miss occurs, it reverts to the real-time parsing process and updates the cache synchronously. After all parallel parsing for all requests is completed, all valid target table names are aggregated and output to the write execution module. This method employs global time window pre-calculation and full-request parallel parsing logic. By pre-calculating and caching table names, it locks the target table name mapping within the valid time window in advance, reducing the number of real-time calculations under high concurrency and improving the efficiency and response speed of table name parsing under large-scale write requests.

[0108] Furthermore, the dynamic table name resolution process during log writing is executed by the dynamic table name resolution module (dynamic_table_resolver). The input includes the original table name requested by the business code, the current server time, the last maintenance time, and the global table splitting configuration structure (G_split_table_config). After receiving the original table name from the business code, the dynamic table name resolution module queries the global table splitting configuration structure to determine if the table is a split table. If it is not a split table, it directly returns the original table name for the business code to execute the write operation. If it is a split table and belongs to daily splitting (Type 1), it reads the split start time (split_time). If the current time is later than the start date, it generates a table suffix in the format of underscores followed by consecutive year, month, and day, using the current date, and concatenates them to obtain the complete split table name, for example, logs_exp_20231109. If it is a split table and belongs to specified date splitting (Type 2), it searches for the nearest date less than the current time in the list of dates to be split, and generates the corresponding table name suffix using that date. Subsequently, the log management module (log_mgr, log manager) calls the log table name retrieval function (get_log_table_name). When assembling the INSERT statement, the original table name is replaced with the parsed sub-table name, making the write route transparent to the business layer. This corresponds to the log writing table selection stage in the result and consumption phase of the flowchart, and finally outputs the sub-table name that should be written.

[0109] Seventh Embodiment This embodiment provides an exemplary scheme for parsing and generating candidate table names by writing a partitioned table to the target branch. In this example, firstly, based on the partitioning rule hit identifier, two types of branch parameters are divided: missed and hit, and branch determination results are generated. Then, the missed branches are processed to obtain the original table name candidates, and the hit branches are processed to extract the partitioning rules and calculate the effective base date using a date matching algorithm. Finally, the date suffix is ​​standardized and concatenated to generate the partitioned table candidate name. The two types of candidate table names are integrated to complete the output of the target table name. Please refer to... Figure 5 , Figure 5 This is a flowchart illustrating the seventh embodiment of the control method for time-series table partitioning of the server database in this application. Step E12 includes steps F11-F15: Step F11: Based on the hit identifier of the table partitioning rule, determine the write route branch to obtain the branch determination result including the missing branch parameters and the hit branch parameters.

[0110] Step F12: Based on the branch determination result of the missing branch parameters, mark the corresponding original log table name as a missing candidate table name.

[0111] Step F13: Based on the branch determination result of the hit branch parameters, extract the split type identifier and the date rule information to be split corresponding to the original log table.

[0112] Step F14: Based on the split type identifier, call the corresponding date matching and selection algorithm, and combine the current system time to match and calculate from the date rule information to be split, to obtain the effective base date corresponding to the split table.

[0113] Step F15: Convert the effective reference date into a date suffix in a continuous number format, and generate a matching candidate sub-table name according to the preset naming rules of concatenating the date suffix with the original table name. After integrating with the unmatched candidate table names, the target sub-table name is obtained.

[0114] The branch determination result is two independent parameter sets obtained by splitting based on the table partitioning rule hit identifier, including parameters for missed branches and parameters for hit branches. This serves as the top-level splitting basis for resolving candidate table names in two paths. Missed candidate table names are the original log table names directly used in scenarios without table partitioning rule matching, without needing date suffix concatenation. The partitioning type identifier is an enumerated flag distinguishing between daily periodic partitioning and specified date partitioning, used to schedule the appropriate date matching selection algorithm. The date rule information to be partitioned is the time series set of all legal partitioning dates stored in the corresponding log table, including the start date, historical partitioning dates, and future partitioning dates. The effective base date is the standard time series date of the data carried by the current write request after algorithm matching, and is the unique data source for generating the partition suffix. Hit candidate partition names are the physical partition names generated by concatenating the original log table name with a numerical year, month, and day suffix, such as logs_exp_20231109. The target partition name is the final physical table identifier used for SQL write replacement after integrating the candidate table names output from the two types of branches and undergoing subsequent availability verification. For example, the branch determination result distinguishes between three types of parameters: no table partitioning configuration, daily table partitioning, and table partitioning with a specified date. If the candidate table name is not matched, the original business table name is directly passed through. The split type identifier distinguishes between type 1 daily table partitioning and type 2 specified date table partitioning. The effective base date is the matched date or the most recent historical split date. The matched candidate table name follows the unified naming specification of "original table name_YYYYMMDD".

[0115] In this example, when performing write routing branch determination based on the table partitioning rule hit identifier to obtain the branch determination result, it can be done by serially determining each identifier one by one. The table partitioning rule hit identifier corresponding to a single write request is read at a time, and the parameters for missed or hit branches are filled in according to the identifier value, thus completing the branch determination result output for a single request and completing the branch routing parameter collection. Alternatively, a batch identifier grouping method can be used to receive the hit identifiers of multiple concurrent write requests at once, cluster them according to the identifier value, and synchronously generate a set of branch determination results corresponding to all requests, thus completing fast branch routing for a large number of requests.

[0116] After generating the branch determination results, a dual-branch parallel parsing process is initiated. The parameters of the missed branches in the branch determination results are read and directly bound to the original log table name to generate candidate table names for missed branches. Simultaneously, the parameters of the hit branches are read, extracting the corresponding log table's splitting type identifier and complete date rule information for the date to be split. Then, based on the splitting type identifier, a dedicated date matching and selection algorithm is scheduled, combining the current system time with the date rule information for the date to be split to match the effective base date corresponding to the current write. The effective base date is then uniformly converted to an 8-digit consecutive number format with a date suffix, and candidate table names for the hit branches are generated according to the preset naming rule of appending underscores and date suffixes to the original table name. Finally, the missing candidate table names and the hit candidate table names are integrated and output according to their branch affiliation, serving as input for subsequent existence verification. In this way, through a layered parsing architecture of two-level branching and type-specific date algorithms, the processing logic for the presence or absence of table partitioning rules is distinguished, adapting to the differentiated date matching rules of the two types of table partitioning. This improves the accuracy and processing efficiency of table name parsing in high-concurrency log writing scenarios, and avoids the problems of date matching deviation and table name concatenation format disorder caused by a unified algorithm.

[0117] For example, there are two ways to parse the two types of candidate table names separately based on the branch determination results and integrate them to obtain the target sub-table name candidate set. The first is single-request serial layered parsing. Based on the branch determination result bound to a single write request, starting from the branch splitting stage, the missing branch parameters are read first to complete the generation of the original table name candidates. If the branch parameters are determined to be hit, the entire process of split type extraction, date algorithm call, base date calculation, and suffix concatenation is executed serially to generate the hit candidate sub-table name. After the integration of the two types of candidate table names is completed, the parsing process of the next write request is entered. After the dual-branch parsing of each request is completed, the currently used split type and the matched effective base date are recorded synchronously for log tracking. If no branch parameters are hit, the date calculation and suffix concatenation process is skipped directly, and only the missing candidate table names are retained. After all write requests are parsed serially, the entire set of candidate table names is output uniformly. This method employs a hierarchical serial parsing logic with request timing locking, executing the dual-branch processing flow completely one by one. The processing links within a single request are independently isolated, and there is no interference across request parameters. It is suitable for operation and maintenance scenarios with low concurrency and high requirements for parsing log traceability.

[0118] The second method employs a multi-request grouping parallel hierarchical parsing approach. It performs global grouping parsing on the branch judgment results corresponding to batch write requests, clustering them based on branch parameter types into three independent processing units: request groups that missed rules, request groups that hit daily table partitions, and request groups that hit table partitions on a specified date. These groups have no computational dependencies and can be synchronously scheduled. For the request groups that missed rules, the original log table names are passed through in batches to generate candidate table names that missed rules. For the two types of request groups that hit rules, the splitting type identifier reading, date matching and selection algorithm calculation, effective base date calculation, and date suffix concatenation are executed synchronously and in parallel to generate corresponding candidate table names that hit rules. After all three groups have undergone parallel parsing, the two types of candidate table names are re-aligned and integrated according to the original write request order, outputting a complete set of candidate table names. This method uses a parsing logic of global branch clustering grouping and multi-grouping parallel operation, completing request splitting and grouping in advance, reusing multi-threaded computing power to process the date calculation and table name concatenation of massive write requests in parallel, eliminating the time-consuming bottleneck of serial processing, and adapting to high-throughput production scenarios with millions of concurrent log writes.

[0119] Furthermore, in the two main processes of reverse parsing of table names and automatic table creation triggered by timers, the reverse parsing process is executed by the reverse parsing module (reverse_table_parser). The input is a table name with a year, month, and day suffix, such as logs_exp_20231109, and the global splittable configuration structure (G_split_table_config). After receiving the table name, the reverse parsing module extracts the string before the last 9 characters as a candidate original table name. In the example, logs_exp is extracted from logs_exp_20231109. Then, the global splittable configuration structure is queried to verify whether the candidate original table is a configured split table. After the verification is successful, the original log table name is output. This process is adapted to the use case of the data mining module (DBM). When the data mining module obtains a table name with a date suffix, it obtains the original table name through reverse parsing, and then matches the field structure, indexes, and other metadata of the original table to achieve accurate parsing of the structured query language (SQL) field values. The automatic creation of future table partitions triggered by timers is executed by the automatic table creation module (split_table_mgr). The input is the timer callback parameters, including the target table name and an optional specified split time. Daily table partitioning corresponds to a 24-hour cyclic timer that is triggered at 2 PM every day. It calculates the timestamp of the next day at midnight and uses that date to generate a new table name, and executes the table creation structured query language. Specified date table partitioning corresponds to a one-time timer that is triggered at 2 PM the day before the specified split date. It generates a new table name with the target specified date and executes the table creation structured query language. When creating the table, it connects to the game log database (game_log, game log database) and executes the "create table if it does not exist" statement to replicate the complete structure of the original table. The process finally outputs a new table creation completion indicator. This corresponds to the entire chain of DBS timed strategy, table creation execution, and result consumption in the flowchart. The reverse parsing and timed table creation processes work together to support the full lifecycle management of time-series table partitioning for offline data parsing and online log writing, respectively.

[0120] Eighth embodiment This embodiment provides an exemplary scheme for table partitioning verification creation and transparent write routing. In this example, after resolving the target partition name, the existence of the target partition is first verified based on the original log table metadata. For missing partitions, the original table structure is replicated to complete immediate creation. Then, a write mapping relationship from logical tables to physical partitions is constructed. Finally, based on the mapping relationship, business logs are stored on-premises, generating a target time-series partitioned table. After step S40, steps G11~G14 are also included: Step G11: Connect the metadata of the original log table corresponding to the target partition table name to the log database to verify the existence of the target partition table and obtain the table existence status identifier.

[0121] Step G12: Using the table existence identifier, create a non-existent target partition table using the original log table as the same source template to obtain physical partition table readiness information.

[0122] Step G13: Based on the physical table readiness information, replace the original table name in the business-side log write instruction with the target table name, construct the write mapping relationship from logical table name to physical table, and obtain the routing mapping effective status data.

[0123] Step G14: Write the business log into the corresponding physical partition table according to the routing mapping effective status data to obtain the target time-series partition table in the server database.

[0124] The table existence status identifier is a binary status flag indicating whether the target shard table has been physically created in the log database. It is divided into two categories: existence and non-existence, and is the core criterion for dynamically creating shard tables. The physical shard table readiness information is a set of statuses output after the shard table creation is completed, including the target shard table name, database connection handle, table structure consistency verification result, and index activation flag. It is a prerequisite for enabling write routing. The route mapping activation status data is a binding mapping record between the logical original table name and the physical time-series shard table name, enabling write forwarding without the business layer's awareness. It stores the mapping binding time, write traffic statistics, and route anomaly flags. For example, the table existence status identifier distinguishes between a created / missing shard table, the physical shard table readiness information carries a successful execution receipt of the table creation SQL, and the route mapping activation status data record `logs_exp` maps to `logs_exp_20260709`, with the target time-series shard table being a physical storage table with the corresponding date suffix.

[0125] In this example, when performing existence verification of the target shard table based on the original log table metadata to obtain the table existence status identifier, it can be performed synchronously in real-time. This involves reading the target shard table name and original metadata corresponding to a single write request, synchronously establishing a database connection to execute the table query statement, and returning the table existence status identifier in real time, thus completing the table status verification for a single request. Alternatively, a batch pre-loading cache verification method can be used. When the shard table running status data is updated, the existence status of all shard tables to be used on the current and next day is queried in batches and cached. When a write request arrives, the table existence status identifier is directly read from the cache, thus achieving fast verification in high-concurrency scenarios.

[0126] After collecting the table existence status indicators, the dynamic table creation process is initiated. The table existence status indicators are read, and for target tables marked as non-existent, a replica table creation operation is performed using the complete metadata of the original log table as a source template. Field and index consistency are simultaneously verified, generating physical table readiness information. Subsequently, based on this physical table readiness information, business log write commands are traversed, and the original logical table names within the commands are globally replaced with the parsed target table names. A transparent write mapping relationship is established between the logical tables and the physical time-series tables, generating routing mapping activation status data. Finally, the routing mapping activation status data is read, and business logs are written in batches to the corresponding physical tables, completing the persistence of time-segmented log shards and generating the target time-series table in the server database. This three-layer linkage mechanism—pre-validation, dynamic supplementation, and transparent routing—solves write errors caused by missed table creation in scheduled tasks, while ensuring that business code can adapt to time-series tables without modification, balancing write stability and non-intrusive business characteristics.

[0127] For example, there are two implementation methods for constructing write mapping relationships and completing log writing based on physical sharding readiness information. The first method is single-request serial route replacement write. According to the timing sequence of a single business write request, the physical sharding readiness information is read first to confirm that the sharding is available. Then, the write instruction is parsed separately, the original table name is replaced with the target sharding name, a complete structured query statement is assembled, and then submitted to the database for write execution. The mapping and write process is completed for each single request before the next request is processed. If a sharding is not ready during the process, the write is paused and an immediate reconstruction is triggered. After the reconstruction is completed, the route mapping is retried. This method adopts a serial sentence-by-sentence processing logic with request timing lock. The mapping of a single request and the write process are independently isolated, which facilitates the accurate capture of single write anomalies and is suitable for low concurrency and operation and maintenance scenarios where business logs need to be traced one by one.

[0128] The second method is batch request parallel route replacement write. Multiple business write requests arriving in the same batch are processed globally as groups. Batch requests are clustered based on the target table name, with write requests for the same target table grouped into the same processing group. These groups have no data dependencies and can be scheduled in parallel. For each group, the physical table readiness information is read uniformly, and the original table name of all write instructions within the group is replaced in batches. A unified route mapping relationship is built in batches, and batch route mapping status data is generated synchronously. Then, business logs are submitted to the corresponding physical tables in batches by group for persistent writing. After all groups have completed parallel writing, the write receipts for the entire batch are summarized, and the target time-series table landing results are output uniformly. This method uses global table clustering grouping and multi-group parallel writing processing logic, performs batch request route replacement in advance, reuses the database's batch write capabilities, reduces the time spent on instruction assembly and database interaction in high-concurrency log scenarios, and is suitable for high-throughput production scenarios with millions of concurrent log writes.

[0129] Furthermore, the metadata of the original log table corresponding to the target partition name is extracted first. The game log database (game_log, game log database) is connected to perform the existence check of the target partition and output the table existence status indicator. Taking the target partition name logs_exp_20260709 as an example, it is checked whether the physical partition has been persistently stored. If the table existence status indicator indicates that the target partition does not exist, the table creation operation is performed by replicating all fields, indexes and constraint rules of the original log table logs_exp as the same source complete template. The execution statement is CREATE TABLE IF NOT EXISTS logs_exp_20260709 LIKE logs_exp, generating physical partition ready information. Based on the physical partition ready information, the INSERT command of the business side log is traversed, and the original logical table name logs_exp in the command is uniformly replaced with the parsed target partition name logs_exp_20260709. A transparent write mapping relationship between the logical table and the physical time-series partition is established and routing mapping effective status data is generated. Finally, the routing mapping status data is read, and the batch business logs are written one by one to the corresponding physical table logs_exp_20260709. This completes the persistence of the daily log data by time dimension, and finally obtains the target time-series table with the same structure as the original table in the server database, which carries the daily log data. The entire process does not require any modification to the business code and achieves complete transparency in writing to the routing table.

[0130] For example, the entire time-series automatic table partitioning process relies on the partition value separator configuration file (split_table.csv, split table comma-separated values) to start the full-link scheduling. The split_table.csv configuration file header contains three columns: table name, partition type, and partition date. The remarks specify that when the partition type is 2, multiple rows can be configured for the same table name, and each row specifies a partition date. The configuration example includes two configuration records: logs_exp, 1, 2023#8#24 and logs_corps, 2, 2023#8#24. They uniformly follow the partition naming rule of original table name_year, month, and day. The example is logs_exp_20231109. The "create a new table if it does not exist, refer to the original table" is used as the standardized table creation structured query language (SQL) template, that is, CREATE TABLE IF NOT EXISTS new table LIKE original table. The scheduled table creation trigger time is uniformly set to 2 pm every day, and the partitions required for the next day are pre-generated one day in advance. The overall module dependency chain is as follows: the split table configuration file (split_table.csv) is input to the split table configuration module (split_table_cfg_mgr, splittable configuration manager). After completing configuration parsing and rule aggregation, the split table configuration module outputs a global split table configuration structure (G_split_table_config, Global split table configuration) to the automatic table creation module (split_table_mgr, split table manager). After completing service startup and supplementary creation, scheduled task registration, and physical creation of the split table, the automatic table creation module generates split table running status data. The split table configuration module provides two types of core interfaces: dynamic table name resolution interface (get_log_table_name, get log table name) and split table reverse resolution interface (get_split_table_src_name, get split table source name). The business layer log management module (log_mgr, log manager) only calls the dynamic table name resolution interface to obtain the target shard name for writing, and is completely unaware of the underlying sharding rules and scheduled table creation logic. The data mining layer common definition module (mining_common_def, mining commondefinition) only calls the reverse resolution interface to extract the original log table name from the shard name with the date suffix, which is used to match the original table fields and index metadata to parse the SQL fields, and is also unaware of the underlying sharding scheduling logic.The process covers four major stages: configuration loading, database server (DBS) start-up and timing strategy, table creation execution, and result consumption. It connects the entire process of configuration parsing, timing determination, timer registration, database connection, table partitioning replication, write routing, and offline table name reverse resolution, realizing integrated automated management and control of table partitioning configuration, automatic table creation, transparent writing, and offline data parsing.

[0131] This application provides a server database time-series table partitioning device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the server database time-series table partitioning control method in the above embodiment 1.

[0132] The following is for reference. Figure 6 The diagram illustrates a structural schematic of a server database time-series partitioning device suitable for implementing embodiments of this application. The server database time-series partitioning device in this application may include, but is not limited to, mobile terminals such as factory control equipment and industrial gateways, as well as fixed terminals such as track signal acquisition units and data acquisition instruments. Figure 6 The server database time-series partitioning device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0133] like Figure 6As shown, the server database time-series table partitioning device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the server database time-series table partitioning device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the server database time-series table partitioning device to communicate wirelessly or wiredly with other devices to exchange data. Although server database time-series table partitioning devices with various systems are shown in the figure, it should be understood that it is not required to implement or have all the systems shown. It is possible to implement or have more or fewer systems instead.

[0134] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0135] The server database time-series partitioning device provided in this application, employing the server database time-series partitioning control method in the above embodiments, can solve the technical problem of low data operation efficiency. Compared with the prior art, the beneficial effects of the server database time-series partitioning device provided in this application are the same as the beneficial effects of the server database time-series partitioning control method provided in the above embodiments, and other technical features in this server database time-series partitioning device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0136] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0137] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0138] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the server database time-series table partitioning control method in the above embodiments.

[0139] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0140] The aforementioned computer-readable storage medium may be included in the server database time-series table partitioning device; or it may exist independently and not be assembled into the server database time-series table partitioning device.

[0141] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the server database time-series partitioning device, the server database time-series partitioning device: responds to an automatic partitioning instruction, extracts the partitioned table name, partitioning type, and partitioning date corresponding to the log table in the partitioning configuration file, and constructs a partitioning rule set in conjunction with the partitioning strategy; registers a table creation task for the date to be partitioned according to the current system time and the partitioning rule set, and obtains partitioning operation status data; matches the date calculation logic corresponding to the partitioning type of the original log table name with the original log table name passed in from the business side, the partitioning operation status data, and the current system time, and calculates the target partitioning table name; creates a partitioned table according to the target partitioning table name, and maps the write route of the business log to the partitioned table, thereby obtaining the target time-series partitioned table of the server database.

[0142] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0143] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation that may be implemented in systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0144] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0145] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described control method for time-series table partitioning of a server database, thereby solving the technical problem of low data operation efficiency. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the control method for time-series table partitioning of a server database provided in the above embodiments, and will not be repeated here.

[0146] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A control method for time-series table partitioning in a server database, characterized in that, The method includes: In response to the automatic table partitioning command, extract the partition table name, partition type and partition date corresponding to the log table in the partitioning configuration file, and construct a set of partitioning rules in combination with the partitioning strategy; Register table creation tasks for the dates to be split according to the current system time and the set of table splitting rules, and obtain table splitting running status data; The target sub-table name is calculated by matching the date calculation logic of the sub-table corresponding to the original log table name with the original log table name, the sub-table running status data and the current system time. Create a partitioned table based on the target partitioned table name, and map the write route of the business log to the partitioned table to obtain the target time-series partitioned table of the server database.

2. The control method for time-series table partitioning of a server database as described in claim 1, characterized in that, The steps of responding to the automatic table partitioning command, extracting the partitioned table name, partition type, and partition date corresponding to the log table in the partitioning configuration file, and constructing a set of partitioning rules in conjunction with the partitioning strategy include: In response to the automatic table partitioning command, the original configuration file entries in the table partitioning configuration file are extracted line by line to obtain the original configuration line set; Parse each line of the original configuration line set field by field according to the preset delimiter, determine the split table name, split type and split date in sequence, and output the fieldized configuration entries; Convert the split date strings in the fieldized configuration entries into time values, remove the specified date-type configuration entries that are earlier than the current time and are not from the current day, and obtain the valid configuration entries; Based on the retrieval index key of the split table name, the valid configuration entries are grouped and aggregated according to the split type to construct the table splitting rule set.

3. The control method for time-series table partitioning of a server database as described in claim 1, characterized in that, The step of registering table creation tasks for the dates to be split according to the current system time and the set of table splitting rules, and obtaining table splitting running status data, includes: According to the splitting type, the log table splitting rule items in the table splitting rule set are divided into daily periodic table splitting items and specified date table splitting items, and a set of table splitting items to be created is obtained by classification. Based on the set of table items to be created and the current system time, the table items put into use on the day are selected, and the original table structure is verified and reused one by one to obtain the list of table items that have taken effect on the day. Based on the list of table sub-items that have taken effect on the current day and the set of table sub-items that are still to be created, register a fixed-interval cyclic table creation task for the daily periodic table sub-items, and register a table creation task for the corresponding time for the table sub-items of the specified date, so as to obtain a set of timed table creation tasks. Integrate the list of sub-tables that have taken effect on the same day with the set of scheduled table creation tasks, and generate the running status data of the sub-tables according to the time axis.

4. The control method for time-series table partitioning of a server database as described in claim 3, characterized in that, The steps of registering fixed-interval cyclic table creation tasks for the daily periodic table items and registering corresponding time table creation tasks for the specified date table items, based on the list of effective table items for the day and the set of remaining table items to be created, to obtain a set of scheduled table creation tasks include: Based on the list of effective table sub-items for the day and the daily periodic table sub-items, the corresponding split start date is compared with the current system time, and the effective status and associated time node of each item are marked to obtain the daily table sub-item set. Effective table items are selected from the daily table set. By comparing the current system time with the table creation time of the day, the effective table items that have exceeded the table creation time of the day are split into tables for the next day, and the table effective status set is updated. Select the table items to be effective from the set of table effective statuses, and calculate the table creation time point one day before the start date of each item's split as the first table creation trigger time point; Verify whether the current system time has exceeded the initial table creation trigger time and perform corresponding supplementary table creation to obtain the daily timed trigger parameter set; Based on the daily timed trigger parameter set, a cyclic table creation task with a fixed interval is registered for the daily table entries.

5. The control method for time-series table partitioning of a server database as described in claim 3, characterized in that, The steps of registering fixed-interval cyclic table creation tasks for the daily periodic table items and registering corresponding time table creation tasks for the specified date table items, based on the list of effective table items for the day and the set of remaining table items to be created, to obtain a set of scheduled table creation tasks include: Based on the list of table segments that have taken effect on the current day and the table segments for the specified date, the dates to be split in the table segments for the specified date are compared with the current system time and divided into dates to be created on the current day and dates to be created in the future. Based on the effective pending date, the original table structure is used to create sub-tables, resulting in a detailed set of sub-tables added on that day. Based on the subdivision detail set, the future effective dates to be created are traversed, the creation time of the future effective dates to be created is calculated, and the corresponding original table structure is matched to obtain the set of future subdivision scheduled task parameters. Based on the set of parameters for the future table partitioning scheduled tasks, register the table creation task with the corresponding trigger time for the future date to be partitioned.

6. The control method for time-series table partitioning of a server database as described in claim 1, characterized in that, The step of matching the original log table name, the table's running status data, and the current system time, with the date calculation logic corresponding to the partition type of the original log table name, to calculate the target partition table name includes: Based on the current system time, the original log table name passed in by the business side is used as the retrieval key to verify the table running status data and obtain the table rule hit identifier. Based on the hit identifier of the table partitioning rule, the writing target parsing logic of the original log table name is branched to obtain candidate table names; The candidate table name is checked against the list of effective sub-tables in the sub-table running status data for existence. After confirming that the table item meets the table name standard, the target sub-table name is output.

7. The control method for time-series table partitioning of a server database as described in claim 6, characterized in that, The step of performing branching processing on the write target parsing logic of the original log table name according to the hit identifier of the table partitioning rule to obtain the candidate table name includes: Based on the hit identifier of the table partitioning rule, the write route branch is determined, and the branch determination result including the missed branch parameters and the hit branch parameters is obtained. Based on the branch determination result of the missing branch parameters, the corresponding original log table name is marked as a missing candidate table name; Based on the branch determination result of the hit branch parameters, extract the split type identifier and the date rule information to be split corresponding to the original log table; The corresponding date matching and selection algorithm is invoked based on the splitting type identifier, and the effective base date corresponding to the splitting table is obtained by matching and calculating from the date rule information to be split in combination with the current system time; The effective reference date is converted into a date suffix in a continuous number format, and a target candidate table name is generated by concatenating the date suffix with the original table name according to a preset naming rule. The target table name is obtained by integrating the target candidate table name with the target candidate table name.

8. The control method for time-series table partitioning of a server database as described in claim 1, characterized in that, The steps of creating a partitioned table based on the target partitioned table name and mapping the write routes of the business logs to the partitioned table to obtain the target time-series partitioned table of the server database include: Connect the metadata of the original log table corresponding to the target partition table name to the log database to verify the existence of the target partition table and obtain the table existence status identifier. By using the table existence identifier, non-existent target partition tables are created using the original log table as the same source template, thus obtaining physical partition table readiness information; Based on the physical table readiness information, the original table name in the business-side log writing instruction is replaced with the target table name, and a writing mapping relationship from logical table name to physical table is constructed to obtain the routing mapping effective status data. The business logs are written to the corresponding physical partition table based on the routing mapping status data to obtain the target time-series partition table in the server database.

9. A time-series table partitioning device for a server database, characterized in that, The server database time-series partitioning device includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the control method for server database time-series partitioning as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the server database time-series table control method as described in any one of claims 1 to 8.

Images