I’ve hit a recent change which took me by surprise.
I was used to checking for the ‘questions‘ global status variables to see the total amount of queries the server performs. So, for example, I could run com_select/questions to learn the SELECT ratio out of all queries.
Apparently, as of 5.0.72–5.0.76 & 5.1.31 this has changed. A new status variable was introduced, called ‘queries‘.
The change being? questions does not any longer indicate the number of queries the server has executed: only the number of queries requested by the client (so, calling on a stored routine only counts as 1, regardless of how many queries the routine executes). The new queries variable indicates the amount of server queries issued (see the 5.0 and 5.1 docs for details).
So, as of 5.0.72 or 5.1.31, the calculation should be com_select/com_queries (or com_select_diff/com_queries_diff) to learn the SELECT ratio of all queries. I learned this due to a bug report on mycheckpoint, which presented some 10265% SELECT ratio…
My take on this is that it could have been worked out differently: instead of changing the meaning of an existing variable, questions could have remained as it was, with the introduction of, say, client_questions, which would only indicate client number of issued queries.
I believe changing the meaning of status variables at such late versions (5.0.76 is quite late!) invites trouble: code that used to work on already then-stable versions (e.g. 5.0.51) would behave differently after upgrade. Such changes should best take place while still in BETA phase.
See MySQL bugs 24289 and 41131.
I noticed this issue a while ago as well when I saw differing qps information reported from innotop. Turns out it was because newer versions of innotop use the Queries status variable.
I filed a bug for it:
http://code.google.com/p/innotop/issues/detail?id=27
It’s annoying that such a change was made since it means that monitoring/reporting tools can have inconsistent behavior across minor revisions of MySQL.
.. so for performance monitoring logic would have to be something like (in the famous PPPL language = *Peter’s Private Programming Language*)
CASE
version >= 5.0.75 and version use ‘queries’ status variable
version >= 5.1.31 and version use ‘queries’ status variable //see note
ELSE ===> use ‘questions’ variables
(according to docs all 5.4 versions have ‘queries’ – but not 100% sure about details with (the abandoned) 6.0 thing).
sshit .. what I psoted truncated.
try again:
version >= 5.0.75 and version = 5.1.31 and version < 6.0 …
What is the issue with this Blog system?? Doesn’t it understand plain text 😉
CASE
version GTorEq 5.0.75 and version LT 5.1.0: use ‘queries’ status variable;
version GTorEq 5.1.31 and version LT 6.0: use ‘queries’ status variable;
ELSE use ‘questions’status variables