Timeline for Periodically very slow execution of simplest queries
Current License: CC BY-SA 3.0
9 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jan 13, 2017 at 20:06 | comment | added | Pustovalov Dmitry |
I am sure nobody locks this table. It was filled with data once, nobody updates it, the only read query is simple select: SELECT id INTO v_game_id FROM game WHERE product_id = a_game_id;
|
|
Jan 13, 2017 at 20:03 | comment | added | Rick James |
Lock_time dates back before InnoDB existed; I don't trust its semantics to have been updated when InnoDB was added. (Just a gut feeling.)
|
|
Jan 13, 2017 at 20:01 | comment | added | Rick James | Search your code for all other references (read or write) to that table. Then identify the length of the transactions they are in. | |
Jan 13, 2017 at 19:51 | comment | added | Pustovalov Dmitry | How can I forcefully grab table lock if I just make consistent non-locking read? | |
Jan 13, 2017 at 19:47 | comment | added | Pustovalov Dmitry | According to this: stackoverflow.com/questions/19036176/… Lock time is the time spend before the query starts executing. I.e., time waiting for other threads to give up their locks on the data the current query needs to lock. | |
Jan 13, 2017 at 19:45 | comment | added | Rick James |
Query_time is elapsed time, including all kinds of delays.
|
|
Jan 13, 2017 at 19:44 | comment | added | Rick James |
I don't think Lock_time takes transaction locks into account.
|
|
Jan 13, 2017 at 19:42 | comment | added | Pustovalov Dmitry | Query_time: 14.532574 Lock_time: 0.050162 As far as I understand: Lock_time - time that query wait to execute because of other query, it's pretty small here actually I don't understand why it is > 0 because it should be consistent non-locking read so nothing to wait here... And query_time is actual query time and I think problem is here. | |
Jan 13, 2017 at 19:37 | history | answered | Rick James | CC BY-SA 3.0 |