Bug #81632 MySQL 5.7 GLOBAL_STATUS table lost much of the data
Submitted: 28 May 2016 15:05 Modified: 8 Jun 2016 7:33
Reporter: Peter Zaitsev Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server: Performance Schema Severity:S3 (Non-critical)
Version:5.7.11, 5.7.12 OS:Any
Assigned to: Marc ALFF CPU Architecture:Any

[28 May 2016 15:05] Peter Zaitsev
Description:
I have noticed what SHOW GLOBAL STATUS produces a lot more rows than SELECT FROM PERFORMANCE_SCHEMA.GLOBAL_STATUS which I would assume should have the same amount of data

How to repeat:
See Above.

SELECT * FROM PERFORMANCE_SCHEMA.GLOBAL_STATUS misses on many key values

| Bytes_received                                | 194179199392            |
| Bytes_sent                                    | 6256342340217           |
| Com_stmt_reprepare                            | 0                       |
| Connection_errors_accept                      | 0                       |
| Connection_errors_internal                    | 0                       |
| Connection_errors_max_connections             | 0                       |
| Connection_errors_peer_address                | 0                       |
| Connection_errors_select                      | 0                       |
| Connection_errors_tcpwrap                     | 0                       |
| Connections                                   | 3400944                 |

As you can see in this case there is only one Com_XXX command is listed.
[28 May 2016 15:26] Peter Laursen
On 5.7.12 (Windows 64 bit server) I get

SELECT * FROM PERFORMANCE_SCHEMA.GLOBAL_STATUS;

(will attach a text file as it is too long for this system)

.. what seems ok to me.
[28 May 2016 15:27] Peter Laursen
SELECT * FROM PERFORMANCE_SCHEMA.GLOBAL_STATUS result

Attachment: status.txt (text/plain), 20.07 KiB.

[28 May 2016 15:28] Peter Zaitsev
Peter,

Do you get Same number of rows when you do SHOW GLOBAL STATUS vs 

SELECT * FROM PERFORMANCE_SCHEMA.GLOBAL_STATUS ?  

Can you just paste row counts ?
[28 May 2016 15:30] Peter Zaitsev
Peter,

Checked your status - see you do not have nearly all Com_XXX out there 

There is not even Com_Select !
[28 May 2016 15:36] Peter Zaitsev
OK,

This looks to be the documented behavior 

http://dev.mysql.com/doc/refman/5.7/en/performance-schema-status-variable-tables.html

"The Performance Schema does not collect statistics for Com_xxx status variables in the status variable tables. To obtain global and per-session statement execution counts, use the events_statements_summary_global_by_event_name and events_statements_summary_by_thread_by_event_name tables, respectively. For example:"

I do not think it is a great decision though.  Now I can get a lot of values from "SHOW GLOBAL STATUS" so they are there but I lost convenient SQL interface to them as  INFORMATION_SCHEMA.GLOBAL_STATUS is gone and Performance Schema global status does not collect some of them.
[28 May 2016 16:08] Peter Laursen
@PZ - you are absolutely right!

My result rowcounts are:
SELECT * FROM P_S.GLOBAL_STATUS: 206
SHOW GLOBAL STATUS: 353
[28 May 2016 16:10] Peter Laursen
SHOW GLOBAL STATUS result

Attachment: showgloba.txt (text/plain), 34.32 KiB.

[28 May 2016 16:23] Peter Laursen
This is also a surprise for me.
[30 May 2016 7:22] MySQL Verification Team
Hello Peter,

Thank you for the report and feedback!

Thanks,
Umesh
[8 Jun 2016 7:33] Marc ALFF
This is not a bug, it works as intended.

SHOW GLOBAL STATUS historically printed both:
- general status counters
- statement statistics (only the count)

With the performance schema, statement statistics are in the statements related tables.

If P_S GLOBAL STATUS should also contain statement statistics, consider this: should it be expanded to include transactions, stages, waits, memory, and any future instrumentation statistics as well (probably not) ? Why treating statements counters differently then ?