8.2.

8 Adding Accounts, Assigning Privileges, and Dropping Accounts

To manage MySQL accounts, use the SQL statements intended for that purpose:

• CREATE USER and DROP USER create and remove accounts.

• GRANT and REVOKE assign privileges to and revoke privileges from accounts.

• SHOW GRANTS displays account privilege assignments.

Account-management statements cause the server to make appropriate modifications to the

underlying grant tables.

Note

Direct modification of grant tables using statements such as INSERT, UPDATE, or DELETE is discouraged
and done at your own risk. The server is free to ignore rows that become malformed as a result of such
modifications.

For any operation that modifies a grant table, the server checks whether the table has the expected
structure and produces an error if not. To update the tables to the expected structure, perform the
MySQL upgrade procedure.

for creating accounts is to use the GUI tool MySQL Workbench. Also, several third-party programs offer
capabilities for MySQL account administration. phpMyAdmin is one such program.

Creating Accounts and Granting Privileges

The following examples show how to use the mysql client program to set up new accounts. These
examples assume that the MySQL root account has the CREATE USER privilege and all privileges that it
grants to other accounts.

At the command line, connect to the server as the MySQL root user, supplying the appropriate
password at the password prompt:

$> mysql -u root -p

Enter password: (enter root password here)

After connecting to the server, you can add new accounts. The following example uses CREATE
USER and GRANT statements to set up four accounts (where you see 'password', substitute an
appropriate password):

CREATE USER 'finley'@'localhost'

IDENTIFIED BY 'password';

GRANT ALL

ON *.*

TO 'finley'@'localhost'

WITH GRANT OPTION;

CREATE USER 'finley'@'%.example.com'

 IDENTIFIED BY 'password';

GRANT ALL

ON *.*

TO 'finley'@'%.example.com'

WITH GRANT OPTION;

CREATE USER 'admin'@'localhost'

IDENTIFIED BY 'password';

GRANT RELOAD,PROCESS

ON *.*

TO 'admin'@'localhost';

CREATE USER 'dummy'@'localhost';

The accounts created by those statements have the following properties:

• Two accounts have a user name of finley. Both are superuser accounts with full global
privileges to do anything. The 'finley'@'localhost' account can be used only when connecting
from the local host. The 'finley'@'%.example.com' account uses the '%' wildcard in the host
part, so it can be used to connect from any host in the example.com domain.

The 'finley'@'localhost' account is necessary if there is an anonymous-user account for localhost.

Without the 'finley'@'localhost' account, that anonymous-user account takes precedence
when finley connects from the local host and finley is treated as an anonymous user. The reason for
this is that the anonymous-user account has a more specific Host column value than
the 'finley'@'%' account and thus comes earlier in the user table sort order. (For information
about user table sorting, see Section 8.2.6, “Access Control, Stage 1: Connection Verification”.)

• The 'admin'@'localhost' account can be used only by admin to connect from the local host. It
is granted the global RELOAD and PROCESS administrative privileges. These privileges enable
the admin user to execute the mysqladmin reload, mysqladmin refresh, and mysqladmin
flush-xxx commands, as well as mysqladmin processlist . No privileges are granted for
accessing any databases. You could add such privileges using GRANT statements.

• The 'dummy'@'localhost' account has no password (which is insecure and not recommended).
This account can be used only to connect from the local host. No privileges are granted. It is
assumed that you grant specific privileges to the account using GRANT statements.

The previous example grants privileges at the global level. The next example creates three accounts
and grants them access at lower levels; that is, to specific databases or objects within databases. Each
account has a user name of custom, but the host name parts differ:

CREATE USER 'custom'@'localhost'

IDENTIFIED BY 'password';
GRANT ALL

ON bankaccount.*

TO 'custom'@'localhost';

CREATE USER 'custom'@'host47.example.com'

IDENTIFIED BY 'password';

GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP

ON expenses.*

TO 'custom'@'host47.example.com';

CREATE USER 'custom'@'%.example.com'

IDENTIFIED BY 'password';

GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP

ON customer.addresses

TO 'custom'@'%.example.com';

The three accounts can be used as follows:

• The 'custom'@'localhost' account has all database-level privileges to access

the bankaccount database. The account can be used to connect to the server only from the
local host.

• The 'custom'@'host47.example.com' account has specific database-level privileges to access

the expenses database. The account can be used to connect to the server only from the
host host47.example.com.

• The 'custom'@'%.example.com' account has specific table-level privileges to access

the addresses table in the customer database, from any host in the example.com domain. The
account can be used to connect to the server from all machines in the domain due to use of
the % wildcard character in the host part of the account name.

Checking Account Privileges and Properties

To see the privileges for an account, use SHOW GRANTS:

mysql> SHOW GRANTS FOR 'admin'@'localhost';

+-----------------------------------------------------+

| Grants for admin@localhost |

+-----------------------------------------------------+

| GRANT RELOAD, PROCESS ON *.* TO `admin`@`localhost` |

+-----------------------------------------------------+

To see nonprivilege properties for an account, use SHOW CREATE USER:

mysql> SET print_identified_with_as_hex = ON;

mysql> SHOW CREATE USER 'admin'@'localhost'\G

*************************** 1. row ***************************

CREATE USER for admin@localhost: CREATE USER `admin`@`localhost`

IDENTIFIED WITH 'caching_sha2_password'

AS
0x24412430303524301D0E17054E2241362B1419313C3E44326F294133734B30792F436E777642703
73039612E32445250786D43594F45354532324B6169794F47457852796E32

REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK

PASSWORD HISTORY DEFAULT

PASSWORD REUSE INTERVAL DEFAULT

PASSWORD REQUIRE CURRENT DEFAULT

Enabling the print_identified_with_as_hex system variable causes SHOW CREATE USER to display hash
values that contain unprintable characters as hexadecimal strings rather than as regular string literals.

Revoking Account Privileges

To revoke account privileges, use the REVOKE statement. Privileges can be revoked at different levels,
just as they can be granted at different levels.

Revoke global privileges:

REVOKE ALL

ON *.*

FROM 'finley'@'%.example.com';

REVOKE RELOAD

ON *.*

FROM 'admin'@'localhost';

Revoke database-level privileges:

REVOKE CREATE,DROP

ON expenses.*

FROM 'custom'@'host47.example.com';

Revoke table-level privileges:

REVOKE INSERT,UPDATE,DELETE

ON customer.addresses

FROM 'custom'@'%.example.com';

To check the effect of privilege revocation, use SHOW GRANTS:

mysql> SHOW GRANTS FOR 'admin'@'localhost';

+---------------------------------------------+

| Grants for admin@localhost |

+---------------------------------------------+

| GRANT PROCESS ON *.* TO `admin`@`localhost` |

+---------------------------------------------+

Dropping Accounts

To remove an account, use the DROP USER statement. For example, to drop some of the accounts
created previously:

DROP USER 'finley'@'localhost';

DROP USER 'finley'@'%.example.com';

DROP USER 'admin'@'localhost';

DROP USER 'dummy'@'localhost';

10.12.3.1 How MySQL Uses Memory

MySQL allocates buffers and caches to improve performance of database operations. The default
configuration is designed to permit a MySQL server to start on a virtual machine that has
approximately 512MB of RAM. You can improve MySQL performance by increasing the values of
certain cache and buffer-related system variables. You can also modify the default configuration to run
MySQL on systems with limited memory.

The following list describes some of the ways that MySQL uses memory. Where applicable, relevant
system variables are referenced. Some items are storage engine or feature specific.

• The InnoDB buffer pool is a memory area that holds cached InnoDB data for tables, indexes,
and other auxiliary buffers. For efficiency of high-volume read operations, the buffer pool is
divided into pages that can potentially hold multiple rows. For efficiency of cache
management, the buffer pool is implemented as a linked list of pages; data that is rarely used
is aged out of the cache, using a variation of the LRU algorithm. For more information,
see Section 17.5.1, “Buffer Pool”.
The size of the buffer pool is important for system performance:

o InnoDB allocates memory for the entire buffer pool at server startup,
using malloc() operations. The innodb_buffer_pool_size system variable defines the
buffer pool size. Typically, a recommended innodb_buffer_pool_size value is 50 to 75
percent of system memory. innodb_buffer_pool_size can be configured dynamically,
while the server is running. For more information, see Section 17.8.3.1, “Configuring
InnoDB Buffer Pool Size”.

o On systems with a large amount of memory, you can improve concurrency by dividing
the buffer pool into multiple buffer pool instances.
The innodb_buffer_pool_instances system variable defines the number of buffer pool
instances.

o A buffer pool that is too small may cause excessive churning as pages are flushed from
the buffer pool only to be required again a short time later.

o A buffer pool that is too large may cause swapping due to competition for memory.

• The storage engine interface enables the optimizer to provide information about the size of
the record buffer to be used for scans that the optimizer estimates are likely to read multiple
rows. The buffer size can vary based on the size of the estimate. InnoDB uses this variable-size
buffering capability to take advantage of row prefetching, and to reduce the overhead of
latching and B-tree navigation.

• All threads share the MyISAM key buffer. The key_buffer_size system variable determines its
size.

For each MyISAM table the server opens, the index file is opened once; the data file is opened once
for each concurrently running thread that accesses the table. For each concurrent thread, a table
structure, column structures for each column, and a buffer of size 3 * N are allocated (where N is the
maximum row length, not counting BLOB columns). A BLOB column requires five to eight bytes plus
the length of the BLOB data. The MyISAM storage engine maintains one extra row buffer for internal
use.

• The myisam_use_mmap system variable can be set to 1 to enable memory-mapping for

all MyISAM tables.

• If an internal in-memory temporary table becomes too large (as determined

by tmp_table_size and max_heap_table_size), MySQL automatically converts the table from
in-memory to on-disk format, which uses the InnoDB storage engine. You can increase the
permissible temporary table size as described in Section 10.4.4, “Internal Temporary Table Use
in MySQL”.

For MEMORY tables explicitly created with CREATE TABLE, only the max_heap_table_size system
variable determines how large a table can grow, and there is no conversion to on-disk format.

• The MySQL Performance Schema is a feature for monitoring MySQL server execution at a low
level. The Performance Schema dynamically allocates memory incrementally, scaling its
memory use to actual server load, instead of allocating required memory during server
startup. Once memory is allocated, it is not freed until the server is restarted. For more
information, see Section 29.17, “The Performance Schema Memory-Allocation Model”.
 • Each thread that the server uses to manage client connections requires some thread-specific
space. The following list indicates these and which system variables control their size:

o A stack (thread_stack)

o A connection buffer (net_buffer_length)

o A result buffer (net_buffer_length)

The connection buffer and result buffer each begin with a size equal to net_buffer_length bytes, but
are dynamically enlarged up to max_allowed_packet bytes as needed. The result buffer shrinks
to net_buffer_length bytes after each SQL statement. While a statement is running, a copy of the
current statement string is also allocated.

Each connection thread uses memory for computing statement digests. The server
allocates max_digest_length bytes per session. See Section 29.10, “Performance Schema Statement
Digests and Sampling”.

• All threads share the same base memory.

• When a thread is no longer needed, the memory allocated to it is released and returned to
the system unless the thread goes back into the thread cache. In that case, the memory
remains allocated.

• Each request that performs a sequential scan of a table allocates a read buffer.
The read_buffer_size system variable determines the buffer size.

• When reading rows in an arbitrary sequence (for example, following a sort), a random-read
buffer may be allocated to avoid disk seeks. The read_rnd_buffer_size system variable
determines the buffer size.

• All joins are executed in a single pass, and most joins can be done without even using a
temporary table. Most temporary tables are memory-based hash tables. Temporary tables
with a large row length (calculated as the sum of all column lengths) or that
contain BLOB columns are stored on disk.

• Most requests that perform a sort allocate a sort buffer and zero to two temporary files
depending on the result set size. See Section B.3.3.5, “Where MySQL Stores Temporary Files”.

• Almost all parsing and calculating is done in thread-local and reusable memory pools. No
memory overhead is needed for small items, thus avoiding the normal slow memory allocation
and freeing. Memory is allocated only for unexpectedly large strings.

• For each table having BLOB columns, a buffer is enlarged dynamically to read in
larger BLOB values. If you scan a table, the buffer grows as large as the largest BLOB value.

• MySQL requires memory and descriptors for the table cache. Handler structures for all in-use
tables are saved in the table cache and managed as “First In, First Out” (FIFO).
The table_open_cache system variable defines the initial table cache size;
see Section 10.4.3.1, “How MySQL Opens and Closes Tables”.

MySQL also requires memory for the table definition cache. The table_definition_cache system
variable defines the number of table definitions that can be stored in the table definition cache. If you
use a large number of tables, you can create a large table definition cache to speed up the opening of
tables. The table definition cache takes less space and does not use file descriptors, unlike the table
cache.

• A FLUSH TABLES statement or mysqladmin flush-tables command closes all tables that are not
in use at once and marks all in-use tables to be closed when the currently executing thread
finishes. This effectively frees most in-use memory. FLUSH TABLES does not return until all
tables have been closed.

• The server caches information in memory as a result of GRANT, CREATE USER, CREATE SERVER,
and INSTALL PLUGIN statements. This memory is not released by the
corresponding REVOKE, DROP USER, DROP SERVER, and UNINSTALL PLUGIN statements, so
for a server that executes many instances of the statements that cause caching, there is an
increase in cached memory use unless it is freed with FLUSH PRIVILEGES.

• In a replication topology, the following settings affect memory usage, and can be adjusted as
required:

o The max_allowed_packet system variable on a replication source limits the maximum

message size that the source sends to its replicas for processing. This setting defaults
to 64M.

o The system variable replica_pending_jobs_size_max on a multithreaded replica sets

the maximum amount of memory that is made available for holding messages
awaiting processing. This setting defaults to 128M. The memory is only allocated when
needed, but it might be used if your replication topology handles large transactions
sometimes. It is a soft limit, and larger transactions can be processed.

o The rpl_read_size system variable on a replication source or replica controls the

minimum amount of data in bytes that is read from the binary log files and relay log
files. The default is 8192 bytes. A buffer the size of this value is allocated for each
thread that reads from the binary log and relay log files, including dump threads on
sources and coordinator threads on replicas.

o The binlog_transaction_dependency_history_size system variable limits the number

of row hashes held as an in-memory history.

o The max_binlog_cache_size system variable specifies the upper limit of memory

usage by an individual transaction.

o The max_binlog_stmt_cache_size system variable specifies the upper limit of memory

usage by the statement cache.

ps and other system status programs may report that mysqld uses a lot of memory. This may be caused
by thread stacks on different memory addresses. For example, the Solaris version of ps counts the
unused memory between stacks as used memory. To verify this, check available swap with swap -s.
We test mysqld with several memory-leakage detectors (both commercial and Open Source), so there
should be no memory leaks.