The Proxy as a Security Layer
Because the proxy reads every SQL statement, it can enforce a query firewall — blocking or flagging queries that match dangerous patterns before they reach the database.
Common use cases:
- Block unparameterized queries: Reject any query that looks like it contains a literal string in a
WHEREclause (potential SQL injection). - Block table scans: Reject
SELECTstatements without aWHEREclause on large tables. - Rate limiting: Limit how many queries per second a specific user or application can send.
- Kill long-running queries: Automatically terminate queries that exceed a time threshold.
In ProxySQL, a blocking rule is another mysql_query_rules insert — one that matches the dangerous pattern (say, a SELECT against users with no WHERE clause) and sets an error_msg instead of a destination hostgroup.
The application receives a clean error message. The dangerous query never reaches the database.
Observability: The Stats Tables
ProxySQL maintains internal statistics tables in its admin database. These are invaluable for diagnosing performance problems: stats_mysql_query_digest ranks every normalized query by total execution time, call count, and min/max latency, while stats_mysql_connection_pool reports per-backend connection health (used/free connections, latency) for each hostgroup.
This gives you a query performance profile without enabling slow query logs on the database itself — and it covers 100% of queries, not just those exceeding a threshold.
Interviewers sometimes ask: "How would you identify the top 5 most expensive queries in a production MySQL system without enabling the slow query log?" The proxy stats tables are the answer. ProxySQL's stats_mysql_query_digest captures every query, aggregates by normalized digest, and reports total execution time, call count, and latency percentiles — all with zero impact on the database server.