### 27.12.8 Performance Schema Connection Tables

[27.12.8.1 The accounts Table](performance-schema-accounts-table.html)
[27.12.8.2 The hosts Table](performance-schema-hosts-table.html)
[27.12.8.3 The users Table](performance-schema-users-table.html)

 When a client connects to the MySQL server, it does so under a particular user name and from a particular host. The Performance Schema provides statistics about these connections, tracking them per account (user and host combination) as well as separately per user name and host name, using these tables:

* [`accounts`](performance-schema-accounts-table.html): Connection statistics per client account

* [`hosts`](performance-schema-hosts-table.html): Connection statistics per client host name

* [`users`](performance-schema-users-table.html): Connection statistics per client user name

 The meaning of “account” in the connection tables is similar to its meaning in the MySQL grant tables in the `mysql` system database, in the sense that the term refers to a combination of user and host values. They differ in that, for grant tables, the host part of an account can be a pattern, whereas for Performance Schema tables, the host value is always a specific nonpattern host name.

 Each connection table has `CURRENT_CONNECTIONS` and `TOTAL_CONNECTIONS` columns to track the current and total number of connections per “tracking value” on which its statistics are based. The tables differ in what they use for the tracking value. The [`accounts`](performance-schema-accounts-table.html) table has `USER` and `HOST` columns to track connections per user and host combination. The [`users`](performance-schema-users-table.html) and [`hosts`](performance-schema-hosts-table.html) tables have a `USER` and `HOST` column, respectively, to track connections per user name and host name.

 The Performance Schema also counts internal threads and threads for user sessions that failed to authenticate, using rows with `USER` and `HOST` column values of `NULL`.

 Suppose that clients named `user1` and `user2` each connect one time from `hosta` and `hostb`. The Performance Schema tracks the connections as follows:

* The [`accounts`](performance-schema-accounts-table.html) table has four rows, for the `user1`/`hosta`, `user1`/`hostb`, `user2`/`hosta`, and `user2`/`hostb` account values, each row counting one connection per account.

* The [`hosts`](performance-schema-hosts-table.html) table has two rows, for `hosta` and `hostb`, each row counting two connections per host name.

* The [`users`](performance-schema-users-table.html) table has two rows, for `user1` and `user2`, each row counting two connections per user name.

 When a client connects, the Performance Schema determines which row in each connection table applies, using the tracking value appropriate to each table. If there is no such row, one is added. Then the Performance Schema increments by one the `CURRENT_CONNECTIONS` and `TOTAL_CONNECTIONS` columns in that row.

 When a client disconnects, the Performance Schema decrements by one the `CURRENT_CONNECTIONS` column in the row and leaves the `TOTAL_CONNECTIONS` column unchanged.

[`TRUNCATE TABLE`](truncate-table.html) is permitted for connection tables. It has these effects:

* Rows are removed for accounts, hosts, or users that have no current connections (rows with `CURRENT_CONNECTIONS = 0`).

* Nonremoved rows are reset to count only current connections: For rows with `CURRENT_CONNECTIONS > 0`, `TOTAL_CONNECTIONS` is reset to `CURRENT_CONNECTIONS`.

* Summary tables that depend on the connection table are implicitly truncated, as described later in this section.

 The Performance Schema maintains summary tables that aggregate connection statistics for various event types by account, host, or user. These tables have `_summary_by_account`, `_summary_by_host`, or `_summary_by_user` in the name. To identify them, use this query:

```
mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
       WHERE TABLE_SCHEMA = 'performance_schema'
       AND TABLE_NAME REGEXP '_summary_by_(account|host|user)'
       ORDER BY TABLE_NAME;
+------------------------------------------------------+
| TABLE_NAME                                           |
+------------------------------------------------------+
| events_errors_summary_by_account_by_error            |
| events_errors_summary_by_host_by_error               |
| events_errors_summary_by_user_by_error               |
| events_stages_summary_by_account_by_event_name       |
| events_stages_summary_by_host_by_event_name          |
| events_stages_summary_by_user_by_event_name          |
| events_statements_summary_by_account_by_event_name   |
| events_statements_summary_by_host_by_event_name      |
| events_statements_summary_by_user_by_event_name      |
| events_transactions_summary_by_account_by_event_name |
| events_transactions_summary_by_host_by_event_name    |
| events_transactions_summary_by_user_by_event_name    |
| events_waits_summary_by_account_by_event_name        |
| events_waits_summary_by_host_by_event_name           |
| events_waits_summary_by_user_by_event_name           |
| memory_summary_by_account_by_event_name              |
| memory_summary_by_host_by_event_name                 |
| memory_summary_by_user_by_event_name                 |
+------------------------------------------------------+
```

 For details about individual connection summary tables, consult the section that describes tables for the summarized event type:

* Wait event summaries: [Section 27.12.20.1, “Wait Event Summary Tables”](performance-schema-wait-summary-tables.html)

* Stage event summaries: [Section 27.12.20.2, “Stage Summary Tables”](performance-schema-stage-summary-tables.html)

* Statement event summaries: [Section 27.12.20.3, “Statement Summary Tables”](performance-schema-statement-summary-tables.html)

* Transaction event summaries: [Section 27.12.20.5, “Transaction Summary Tables”](performance-schema-transaction-summary-tables.html)

* Memory event summaries: [Section 27.12.20.10, “Memory Summary Tables”](performance-schema-memory-summary-tables.html)

* Error event summaries: [Section 27.12.20.11, “Error Summary Tables”](performance-schema-error-summary-tables.html)

[`TRUNCATE TABLE`](truncate-table.html) is permitted for connection summary tables. It removes rows for accounts, hosts, or users with no connections, and resets the summary columns to zero for the remaining rows. In addition, each summary table that is aggregated by account, host, user, or thread is implicitly truncated by truncation of the connection table on which it depends. The following table describes the relationship between connection table truncation and implicitly truncated tables.

[]()

**Table 27.2 Implicit Effects of Connection Table Truncation**

|Truncated Connection Table|                            Implicitly Truncated Summary Tables                             |
|--------------------------|--------------------------------------------------------------------------------------------|
|        `accounts`        |          Tables with names containing `_summary_by_account`, `_summary_by_thread`          |
|         `hosts`          |Tables with names containing `_summary_by_account`, `_summary_by_host`, `_summary_by_thread`|
|         `users`          |Tables with names containing `_summary_by_account`, `_summary_by_user`, `_summary_by_thread`|

 Truncating a `_summary_global` summary table also implicitly truncates its corresponding connection and thread summary tables. For example, truncating [`events_waits_summary_global_by_event_name`](performance-schema-wait-summary-tables.html) implicitly truncates the wait event summary tables that are aggregated by account, host, user, or thread.

