I have a very slow query that is built by the ORM and I'm curios how could I find out the exact query being executed.
I cannot monitor it from the mysql-slow.log because it never finishes the execution (as in I don't have eternity to wait for it, more than an hour in an still waiting).
Also I cannot get the query from the ORM, just after execution. And the only way I think of getting it is from the process list.
show processlist \G
But my problem is that most of the query is trimmed of, even before the from keyword.
This question has been asked before but with no answer https://stackoverflow.com/questions/3741356/find-queries-from-process-id-mysql-5-1-x
Any suggestions?
If your query is formatted in multiple lines, some MySQL clients will only display the first line. To see full output run SHOW FULL PROCESSLIST; query in MySQL console.
Related
When I execute \s in MySQL console, I get a bunch of information. Also the information I don't care about. I just want to get slow queries and Queries per second avg.
I found solution for slow_queries because it is present in the status table of MySQL. However, Queries per second average isn't available in the MySQL status table.
Is there any way to get only Queries per second average? I can use grep to scrap the information I need in the SSH Console but I don't want to expose MySQL password in logs. This process is automated and not manual. So, the process has to be non-interactive.
I tried to find information in the performance_schema but it looks like I am missing something. Is this value calculated while execution of \s command?
I'm using MySQL workbench to run a query. The query is reasonably big. When I limit the results to say 50 records the results are as expected. But when I remove the limit, the query runs for ~ 5 minutes then prompts me to re-enter my password. After doing so I see the query has not run and has stopped working.
It seems like there is a setting that kicks me off after a certain amount of time but I cannot see it in the drop down menus.
Has anyone experienced this? Any advice?
** Update**
Query ran and Workbench says results returned but they are not and I got the screen shot error pop up here:
It sounds like one of three things are the likely culprit.
MySql Workbench may be timing out.
This may help with #1
Go to Edit -> Preferences -> SQL Editor and set to a higher value this
parameter: DBMS connection read time out (in seconds). For instance:
86400.
Close and reopen MySQL Workbench. Kill your previously query that
probably is running and run the query again.
The mySQL server is timing out
You will need access to the server's timeout configuration
Something network related (but far less likely if your timeout happens consistently at around 5 mins)
There are a number of factors that might need adjusting.
If #2, you will need access to the server's timeout configuration
If #3, well, there are a number of factors that might need adjusting.
I have a mysql SELECT query which is fast (<0.1 sec) but only the first time I run it. It joins 3 tables together (using indices) and has a relatively simple WHERE statement. When I run it by hand in the phpmyadmin (always changing numbers in the WHERE so that it isn't cached) it is always fast but when I have php run several copies of it in a row, the first one is fast and the others hang for ~400 sec. My only guess is that somehow mysql is running out of memory for the connection and then has to do expensive paging.
My general question is how can I fix this behavior, but my specific questions are without actually closing and restarting the connection how can I make these queries coming from php be seen as separate just like the queries coming from phpmyadmin, how can I tell mysql to flush any memory when the request is done, and does this sound like a memory issue to you?
Well I found the answer at least in my case and I'm putting it here for anyone in the future who runs into a similar issue. The query I was running had a lot of results returned and MYSQL's query cache was causing a lot of overhead. When you run a query MYSQL will save it and its output so that it can quickly answer future identical requests quickly. All I had to do was put SQL_NO_CACHE and the speed was back to normal. Just look out if your incoming query is large or the results are very large because it can take considerable resources for MYSQL to decide when to kick things out.
I'm using SQL Server 2008 and just recently started having an intermittent problem while querying a database.
At least once a day I'm having timeouts with many of our applications because of a slow query. There is no particular time this happens; sometimes in the morning, sometimes afternoon. Every time I begin troubleshooting the problem, it fixes itself within minutes.
Normally I use this query:
SELECT Name FROM Demographics WHERE Name IS NOT NULL
and it runs in < 1 second. However, during these "problem times" the query will take around 3 minutes. Once the query goes through, I can run it again and it works just fine (almost instantly).
Also, while the query above is running, I can use this:
SELECT Name FROM Demographics
and it runs perfectly. No delay. The only difference is the WHERE clause. So, where do I begin troubleshooting? What tools should I be using to find the cause?
Thanks in advance.
The first thing to do is to look at the execution plan of the query. To do this, open a query window in Management Studio, and then choose Include Actual Execution Plan in the Query menu. Run your query, then go to the Execution Plan tab and save the plan.
When you see the performance problem, repeat these steps. Then, load both execution plans, and compare them to see what is different. If there are differences, they will probably point you in the right direction to find the problem.
Look to see if you are being blocked by another process during the trouble periods.
I have some strange bug into a application(or is it the MySQL build?) that causes queries to remain in "locked" state forever, filling up the max number of threads.
I read about setting the wait_timeout variable to kill the "bogus" threads after a period of time. This works ok, but I would like to log the killed queries for further inspection/making sure backup scripts are not killed.
Is there any possibility to do that?
Thanks.
You might be able to use the slow log, but I'm not sure if the problem is that they never complete. Worth a shot.
Also, you may be able to see what's going on by running SHOW FULL PROCESSLIST while you've got dead threads. It should show you what the problem is and what the query was.
If you can simulate this in a development environment, you could also turn on general query logging (which records every statement) and then just tail the log after it crashes.
In the past, I have tagged queries with a unique comment (per query type):
/* Query_12345 */ SELECT ... FROM ... WHERE ... LIMIT ...
A background process would poll SHOW FULL PROCESSLIST and look for any queries that were more than X seconds long, and tagged with Query_NNNNN.
Finally, it would kill them if they went on too long. This allowed the server to breath while we figured out how to optimize the 80,000,000 record table that was slowing things down.