SHOW Statements This statement is intended to help the DBA understand the effects that different Performance Schema options have on memory requirements. Name  values consist of two parts, which name an internal buffer and a buffer attribute, respectively. Interpret buffer names as follows: •An internal buffer that is not exposed as a table is named within parentheses. Examples: (pfs_cond_class).size ,  (pfs_mutex_class).memory . •An internal buffer that is exposed as a table in the  performance_schema  database is named after the table, without parentheses. Examples:  events_waits_history.size ,  mutex_instances.count . •A value that applies to the Performance Schema as a whole begins with  performance_schema Example:  performance_schema.memory . •For a table,  tbl_name .memory  is the product of  size  and  count . For the Performance Schema as a whole,  performance_schema.memory  is the sum of all the memory used (the sum of all other  memory values). • count  is the number of internal records, such as the number of rows in a table.  count  values can be changed using Performance Schema configuration options. • size  is the size of the internal record used by the implementation, such as the size of a row in a table. size  values cannot be changed. Buffer attributes have these meanings: In some cases, there is a direct relationship between a Performance Schema configuration parameter and a  SHOW ENGINE  value. For example,  events_waits_history_long.count corresponds to  performance_schema_events_waits_history_long_size . In other cases, the relationship is more complex. For example,  events_waits_history.count  corresponds to performance_schema_events_waits_history_size  (the number of rows per thread) multiplied by performance_schema_max_thread_instances  ( the number of threads). SHOW ENGINE NDB STATUS.   If the server has the  NDB  storage engine enabled,  SHOW ENGINE NDB STATUS  displays cluster status information such as the number of connected data nodes, the cluster connectstring, and cluster binary log epochs, as well as counts of various Cluster API objects created by the MySQL Server when connected to the cluster. Sample output from this statement is shown here: mysql>  SHOW ENGINE NDB STATUS; +------------+-----------------------+--------------------------------------------------+ | Type | Name | Status | +------------+-----------------------+--------------------------------------------------+ | ndbcluster | connection | cluster_node_id=7, connected_host=198.51.100.103, connected_port=1186, number_of_data_nodes=4, number_of_ready_data_nodes=3, connect_count=0 | | ndbcluster | NdbTransaction | created=6, free=0, sizeof=212 | | ndbcluster | NdbOperation | created=8, free=8, sizeof=660 | | ndbcluster | NdbIndexScanOperation | created=1, free=1, sizeof=744 | | ndbcluster | NdbIndexOperation | created=0, free=0, sizeof=664 | | ndbcluster | NdbRecAttr | created=1285, free=1285, sizeof=60 | | ndbcluster | NdbApiSignal | created=16, free=16, sizeof=136 | | ndbcluster | NdbLabel | created=0, free=0, sizeof=196 | | ndbcluster | NdbBranch | created=0, free=0, sizeof=24 | | ndbcluster | NdbSubroutine | created=0, free=0, sizeof=68 | | ndbcluster | NdbCall | created=0, free=0, sizeof=16 | | ndbcluster | NdbBlob | created=1, free=1, sizeof=264 | | ndbcluster | NdbReceiver | created=4, free=0, sizeof=68 | | ndbcluster | binlog | latest_epoch=155467, latest_trans_epoch=148126, latest_received_binlog_epoch=0, latest_handled_binlog_epoch=0, latest_applied_binlog_epoch=0 | 2925