Design and Implementation of MySQL SQL Flow‑Control (Throttling) Feature

Introduction: This document describes the purpose, requirements and overall structure of a SQL flow‑control (throttling) feature for MySQL.

Requirement overview: In production environments high CPU usage caused by heavy or slow SQL can affect all services; the feature aims to limit non‑critical queries to protect core workloads.

Software architecture: The MySQL kernel is extended with a flow‑control module that loads rules from a system table into memory, parses them according to a configurable delimiter, and matches incoming query strings during execution.

Detailed design – Function design: Provides external management commands (du_flow_control, du_flow_control_case_sensitive, du_flow_control_reserve_user, du_flow_control_delimiter) and their semantics.

Rule management: Rules are stored in the table du_flow_control_rules (id, type, max_concur, orig_str). The module supports reading, removing and parsing rules, loading them at server start or when the delimiter changes.

Example rule‑table creation: SET @cmd="CREATE TABLE IF NOT EXISTS du_flow_control_rules ("; id BIGINT NOT NULL AUTO_INCREMENT COMMENT 'Id of the flow control rules.', type ENUM('SELECT','UPDATE','INSERT','DELETE') NOT NULL COMMENT 'Type of flow control rules.', max_concur INT NOT NULL COMMENT 'Max concurrent of sql.', orig_str VARCHAR(1024) NOT NULL COMMENT 'Original string of flow control rules.', PRIMARY KEY(id)) ENGINE=INNODB COMMENT 'Flow control rules info.';

Flow control process: At startup rules are loaded; during query execution the engine checks system‑table queries, reserved users, case‑sensitivity flag, and matches the query against the rule list. If a rule matches, concurrency counters are updated and the query may be throttled.

Performance considerations: The switch adds negligible overhead when disabled; when enabled matching is performed in memory with separate lists per statement type, and impact depends on rule count and complexity.

Limitations: Reserved users are exempt, stored procedures/triggers/functions are not throttled, and excessive rule numbers can affect performance.

Conclusion: The design introduces a low‑intrusion, configurable SQL throttling mechanism for MySQL that isolates core workloads while keeping the core engine unchanged.