introduced the max_statement_time system variable. When set to a non-zero value, the server attempts to abort any queries taking longer than this time in seconds.
The abortion is not immediate; the server checks the timer status at specific intervals during execution. Consequently, a query may run slightly longer than the specified time before being detected and stopped.
The default is zero, and no limits are then applied. The aborted query has no effect on any larger transaction or connection contexts. The variable is of type double, thus you can use subsecond timeout. For example you can use value 0.01 for 10 milliseconds timeout.
The value can be set globally or per session, as well as per user or per query (see below). Replicas are not affected by this variable, however from , there is which serves the same purpose on replicas only.
An associated status variable, , stores the number of queries that have exceeded the execution time specified by , and a MAX_STATEMENT_TIME_EXCEEDED column was added to the and Information Schema tables.
The feature was based upon a patch by Davi Arnaut.
Important Note on Reliability
MAX_STATEMENT_TIME relies on the execution thread checking the "killed" flag, which happens intermittently.
Long Running Operations: If a query enters a long processing phase where the flag is not checked (e.g., certain storage engine operations or complex calculations), it may continue running significantly past the limit.
can be stored per user with the syntax.
By using in conjunction with , it is possible to limit the execution time of individual queries. For example:
max_statement_time per query
Individual queries can also be limited by adding a MAX_STATEMENT_TIME clause to the query. For example:
does not work in embedded servers.
does not work for statements in a Galera cluster (see for discussion).
Check Intervals: The timeout is checked only at specific points during query execution. Queries stuck in operations where the check code path is not hit will not abort until they reach a checkpoint. This can result in query times exceeding the MAX_STATEMENT_TIME value.
MySQL 5.7.4 introduced similar functionality, but the MariaDB implementation differs in a number of ways.
The MySQL version of (max_execution_time) is defined in millseconds, not seconds
MySQL's implementation can only kill SELECTs, while MariaDB's can kill any queries (excluding stored procedures).
MariaDB only introduced the status variable, while MySQL also introduced a number of other variables which were not seen as necessary in MariaDB.
variable
This page is licensed: CC BY-SA / Gnu FDL
Resource Protection: Because the abort is not guaranteed to be instantaneous or strictly enforced in all code paths, MAX_STATEMENT_TIME should not be relied upon as the sole mechanism for preventing resource exhaustion (such as filling up temporary disk space).
SELECT MAX_STATEMENT_TIME = N ...SET STATEMENT MAX_STATEMENT_TIME=N FOR...SET STATEMENT max_statement_time=100 FOR
SELECT field1 FROM table_name ORDER BY field1;SELECT MAX_STATEMENT_TIME=2 * FROM t1;