In MySQL C APIs, is there a way to set a max execution time? Like using mysql_options() we can set connect timeout, read timeout etc... Likewise is there a way to set a max execution time for any query through that connect session or a mysql_real_query() call?
After our client gets disconnected for any reason, our MySQL server continues to run the query. We want something that we can dynamically set by clients for its each sessions or each query.
In documentation I see that we can hint a max execution time in the select / insert statements with MAX_EXECUTION_TIME(n). But I am looking for an option that can be set through API calls rather than using this in the select or insert statements.
Related
I'm stuck trying to clear up lag and timing issues with my Laravel site and was curious if there was a way to check the timing of connections between the host the Laravel site and its MySQL database's host.
I'm trying to eliminate possibilities of where lag comes in and I want to make sure the two being on separate hosts (though in the same local network) isn't the issue.
Since Laravel is implemented in PHP, you can do something like so.
$TimeQuerySent = microtime(true) ;
// Send Request
$TimeQueryReturned = microtime(true) ;
$TimeConsumed = $TimeQueryReturned - $TimeQuerySent ;
The foregoing takes advantage of the fact that calling microtime in this manner cause it to return a floating point number. Since time progresses forward, $TimeQueryReturned is always greater than $TimeQuerySent, and the microsecond precision should be adequate if there is more than a fleeting lag on the connection.
Of course, the above measures only the overall time consumed by the request, which includes time spent by the server executing the query.
Getting information from the server side can be achieved by adding something like the following to your query.
declare StartTime FLOAT;
set StartTime=UNIX_TIMESTAMP(UTC_TIMESTAMP(6));
select starttime,....
When the first statement is the very first statement in your stored routine or dynamically generated SQL statement, StartTime returns the time when the query began executing on the server, which is about as close as you can get to precisely when the MySQL engine started working on it. Requesting UTC_TIMESTAMP(6) causes the timestamp to be returned to the nearest microsecond, and implicitly casts it to float, while wrapping the UNIX_TIMESTAMP function around it converts the returned timestamp to a Unix timestamp. Since all three values are floating point Unix timestamps, you can compare all three times to put a finer point on whether the delay is a network lag or a query execution lag.
This can help Laravel Debugbar (Integrates PHP Debug Bar)
I have a database query which deletes from database with some given conditions. The query is being initiated by an endpoint which timeouts if the query takes a long time (which it does). The service which calls this endpoint needs to do some other tasks after this operation is successful. So we need to know when this query completes. The query is :
DELETE FROM foo WHERE creation_time BETWEEN ? AND ? AND bar_id = ?
How do I know when the query completes? I am using jdbctemplate for querying the database.
I thought of one option but now sure how the between query works internally.
I thought of creating a status endpoint which checks if the query is still running? The endpoint will check if there is any row in foo where creation_time = FROM and bar_id = id.
But I don't know how mysql handles the BETWEEN query internally. If it starts deleting from the FROM or the TO or anything in between.
Short question : How do I check if my query is still running or finished with jdbctemplate?
You can execute the SHOW FULL PROCESSLIST; command. See the MySQL docs for a good description of the command.
This will show all running threads, along with the query that is currently executing and the time that it has been running.
Then parse the output to see if your query is still running.
Hope this helps.
Is there a way to test query timeouts systematically using a MySQL 5.6 server without overloading the server by some insane busy query? Is it maybe possible to build testing SQL statements (read and/or write) that run infinitely (or several minutes) without driving the server into the ground?
MySQL has a sleep() function, so you can do this:
SELECT SLEEP(10);
to craft a query that will take 10 seconds without taking up resources. Sleep returns either 0 or 1 so you can take advantage of that to craft an update or delete query that will have no effect:
UPDATE users SET username='blah' WHERE id=1 AND SLEEP(1) > 1;
you need to ensure that the rest of the where clause (id=1 in this case) matches exactly one row. If it matches more than one row, it will sleep for every single row it matches, if it matches zero, it will return immediately.
Consider the query:
SELECT #xxx As thevar FROM (SELECT #xxx:=1) as temp
Will the resulting query always yield 1, even if there are many other similar queries running at the same time (or as close to the same time as they can get) that are setting #xxx to a different integer.
Also, what exactly is the scope of #xxx?
I'm trying to determine if this is a safe (albeit hacky) way to insure a variable is set to the value I want for the life a specific query.
These queries are run against a single instance of MySQL 5.5 and may be done on the same connection or different connections to the database.
From what I have just tested, it seems the variable is seen only on the current connection. Or more precisely on the connection on which it is set.
I believe your SQL Statement has the same effect as the SET statement for User Defined Variables.
The documentation for which states that:
User-defined variables are connection-specific. That is, a user variable defined by one client cannot be seen or used by other clients. All variables for a given client connection are automatically freed when that client exits.
Thus if the other queries are using there own separate connections, than they will have their own copies of #xxx, and will not interfere with each other. And your hack will work as expected. But if same connection is used and the order of query execution cannot be guaranteed then, other queries can change #xxx and affect the subsequent queries.
Regarding if this always return 1:
SELECT #xxx As thevar FROM (SELECT #xxx:=1) as temp
It should, BUT if using the same connection there is an outlier chance that a Seperate Thread using the same connection executes SET #xxx=2 just after the execution of the subquery and before outer select. Please correct me if I'm wrong about ATOMICITY of SELECT here.
While working with MySQL and some really "performance greedy queries" I noticed, that if I run such a greedy query it could take 2 or 3 minutes to be computed. But if I retry the query immediately after it finished the first time, it takes only some seconds. Does MySQL store something like "the last x queries"?
The short answer is yes. there is a Query Cache.
The query cache stores the text of a SELECT statement together with the corresponding result that was sent to the client. If an identical statement is received later, the server retrieves the results from the query cache rather than parsing and executing the statement again. The query cache is shared among sessions, so a result set generated by one client can be sent in response to the same query issued by another client.
from here
The execution plan for the query will be calculated and re-used. The data can be cached, so subsequent executions will be faster.
Yes, depending on how the MySQL Server is configured, it may be using the query cache. This stores the results of identical queries until a certain limit (which you can set if you control the server) has been reached. Read http://dev.mysql.com/doc/refman/5.1/en/query-cache.html to find out more about how to tune your query cache to speed up your application if it issues many identical queries.