I have a query that looks like this:
SELECT id FROM user WHERE id='47'
The ID is indexed and reads for this query are always fast when using profiling data, like this.
SET profiling = 1;
SHOW PROFILES;
The queries always execute in around 0.0002 seconds.
However, if I profile the query from the PHP side, like this:
$current = microtime(true);
$data = $conn->query($full_query);
$elapsed = microtime(true) - $current;
Then occasionally maybe 1 out 50 of these queries will take something like .2 seconds. However, in my test script I have code to test this that profiles the query using SET profiling = 1; and even though the PHP round trip through PDO might be .2 seconds the query time was still 0.0002.
Things I know, or know that aren't causing the issue:
- The query isn't slow. When I look at the same query, from the same query run, profiled in PHP and profiled using SET PROFILING the query is always fast and never logged in the slow query log even when it shows taking .2 seconds from the PHP side.
- This is not skip-name-resolve related - this is inconsistent and I have skip-name-resolve already on
- This is not query cache related, the behavior exists in both
- This behavior happens even on queries coming out of the cache.
- The query doesn't actually select the ID, but I use this query for testing to show that it isn't a disk access issue since that field is definitely indexed.
- This tables is only 10-20 megs with something like a 1 meg index. The machine shows very little load and innodb is not using all of its buffers.
- This is tested against a table that has no other activity against it other than my test queries.
Does anyone have any ideas of what else to check? This seems to me to be a networking issue, but I need to be able to see it and find the issue to fix it and I'm running out of places to check next. Any ideas?
question from:
https://stackoverflow.com/questions/20590013/mysql-query-randomly-lags 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…