Table of Contents
MySQL Server (mysqld) is the main program that does most of the work in a MySQL installation. This chapter provides an overview of MySQL Server and covers general server administration:
Server configuration
The data directory, particularly the mysql
system database
The server log files
Management of multiple servers on a single machine
For additional information on administrative topics, see also:
mysqld is the MySQL server. The following discussion covers these MySQL server configuration topics:
Startup options that the server supports. You can specify these options on the command line, through configuration files, or both.
Server system variables. These variables reflect the current state and values of the startup options, some of which can be modified while the server is running.
Server status variables. These variables contain counters and statistics about runtime operation.
How to set the server SQL mode. This setting modifies certain aspects of SQL syntax and semantics, for example for compatibility with code from other database systems, or to control the error handling for particular situations.
Configuring and using IPv6 support.
Configuring and using time zone support.
Server-side help capabilities.
The server shutdown process. There are performance and reliability considerations depending on the type of table (transactional or nontransactional) and whether you use replication.
For listings of MySQL server variables and options that have been added, deprecated, or removed in MySQL 8.0, see Section 1.5, “Server and Status Variables and Options Added, Deprecated, or Removed in MySQL 8.0”.
Not all storage engines are supported by all MySQL server binaries and configurations. To find out how to determine which storage engines your MySQL server installation supports, see Section 13.7.6.16, “SHOW ENGINES Syntax”.
The MySQL server, mysqld, has many command options and system variables that can be set at startup to configure its operation. To determine the command option and system variable values used by the server, execute this command:
shell> mysqld --verbose --help
The command produces a list of all mysqld options and configurable system variables. Its output includes the default option and variable values and looks something like this:
abort-slave-event-count 0 allow-suspicious-udfs FALSE archive ON auto-increment-increment 1 auto-increment-offset 1 autocommit TRUE automatic-sp-privileges TRUE avoid-temporal-upgrade FALSE back-log 80 basedir /home/jon/bin/mysql-8.0/ ... tmpdir /tmp transaction-alloc-block-size 8192 transaction-isolation REPEATABLE-READ transaction-prealloc-size 4096 transaction-read-only FALSE transaction-write-set-extraction OFF updatable-views-with-limit YES validate-user-plugins TRUE verbose TRUE wait-timeout 28800
To see the current system variable values used by the server as it runs, connect to it and execute this statement:
mysql> SHOW VARIABLES;
To see some statistical and status indicators for a running server, execute this statement:
mysql> SHOW STATUS;
System variable and status information also is available using the mysqladmin command:
shell>mysqladmin variables
shell>mysqladmin extended-status
For a full description of all command options, system variables, and status variables, see these sections:
More detailed monitoring information is available from the Performance Schema; see Chapter 25, MySQL Performance Schema.
If you specify an option on the command line for mysqld or mysqld_safe, it remains in effect only for that invocation of the server. To use the option every time the server runs, put it in an option file. See Section 4.2.6, “Using Option Files”.
The MySQL server has many operating parameters, which you can change at server startup using command-line options or configuration files (option files). It is also possible to change many parameters at runtime. For general instructions on setting parameters at startup or runtime, see Section 5.1.6, “Server Command Options”, and Section 5.1.7, “Server System Variables”.
On Windows, MySQL Installer interacts with the user and creates a
file named my.ini
in the base installation
directory as the default option file.
On Windows, the .ini
or
.cnf
option file extension might not be
displayed.
After completing the installation process, you can edit the
default option file at any time to modify the parameters used by
the server. For example, to use a parameter setting in the file
that is commented with a #
character at the
beginning of the line, remove the #
, and modify
the parameter value if necessary. To disable a setting, either add
a #
to the beginning of the line or remove it.
For non-Windows platforms, no default option file is created during either the server installation or the data directory initialization process. Create your option file by following the instructions given in Section 4.2.6, “Using Option Files”. Without an option file, the server just starts with its default settings—see Section 5.1.2, “Server Configuration Defaults” on how to check those settings.
For additional information about option file format and syntax, see Section 4.2.6, “Using Option Files”.
The following table provides a list of all the command line
options, system variables, and status variables applicable within
mysqld
.
The table lists command-line options (Cmd-line), options valid in configuration files (Option file), server system variables (System Var), and status variables (Status var) in one unified list, with notification of where each option/variable is valid. If a server option set on the command line or in an option file differs from the name of the corresponding server system, the variable name is noted immediately below the corresponding option. For system and status variables, the scope of the variable is shown (Var Scope) as either global, session, or both. Please see the corresponding sections for details on setting and using the options and variables. Where appropriate, a direct link to further information on the item as available.
Table 5.1 Command-Line Option, System Variable, and Status Variable Summary
Notes:
1. This option is dynamic, but only the server should set this information. You should not set the value of this variable manually.
The following table provides a list of all the system variables
applicable within mysqld
.
The table lists command-line options (Cmd-line), options valid in configuration files (Option file), server system variables (System Var), and status variables (Status var) in one unified list, with notification of where each option/variable is valid. If a server option set on the command line or in an option file differs from the name of the corresponding server system, the variable name is noted immediately below the corresponding option. The scope of the variable is shown (Var Scope) as either global, session, or both. Please see the corresponding sections for details on setting and using the options and variables. Where appropriate, a direct link to further information on the item as available.
Table 5.2 System Variable Summary
Name | Cmd-Line | Option File | System Var | Var Scope | Dynamic |
---|---|---|---|---|---|
activate_all_roles_on_login | Yes | Yes | Yes | Global | Yes |
audit_log_buffer_size | Yes | Yes | Yes | Global | No |
audit_log_compression | Yes | Yes | Yes | Global | No |
audit_log_connection_policy | Yes | Yes | Yes | Global | Yes |
audit_log_current_session | Yes | Both | No | ||
audit_log_encryption | Yes | Yes | Yes | Global | No |
audit_log_exclude_accounts | Yes | Yes | Yes | Global | Yes |
audit_log_file | Yes | Yes | Yes | Global | No |
audit_log_filter_id | Yes | Both | No | ||
audit_log_flush | Yes | Global | Yes | ||
audit_log_format | Yes | Yes | Yes | Global | No |
audit_log_include_accounts | Yes | Yes | Yes | Global | Yes |
audit_log_policy | Yes | Yes | Yes | Global | No |
audit_log_read_buffer_size | Yes | Yes | Yes | Varies | Varies |
audit_log_rotate_on_size | Yes | Yes | Yes | Global | Yes |
audit_log_statement_policy | Yes | Yes | Yes | Global | Yes |
audit_log_strategy | Yes | Yes | Yes | Global | No |
authentication_ldap_sasl_auth_method_name | Yes | Yes | Yes | Global | Yes |
authentication_ldap_sasl_bind_base_dn | Yes | Yes | Yes | Global | Yes |
authentication_ldap_sasl_bind_root_dn | Yes | Yes | Yes | Global | Yes |
authentication_ldap_sasl_bind_root_pwd | Yes | Yes | Yes | Global | Yes |
authentication_ldap_sasl_ca_path | Yes | Yes | Yes | Global | Yes |
authentication_ldap_sasl_group_search_attr | Yes | Yes | Yes | Global | Yes |
authentication_ldap_sasl_group_search_filter | Yes | Yes | Yes | Global | Yes |
authentication_ldap_sasl_init_pool_size | Yes | Yes | Yes | Global | Yes |
authentication_ldap_sasl_log_status | Yes | Yes | Yes | Global | Yes |
authentication_ldap_sasl_max_pool_size | Yes | Yes | Yes | Global | Yes |
authentication_ldap_sasl_server_host | Yes | Yes | Yes | Global | Yes |
authentication_ldap_sasl_server_port | Yes | Yes | Yes | Global | Yes |
authentication_ldap_sasl_tls | Yes | Yes | Yes | Global | Yes |
authentication_ldap_sasl_user_search_attr | Yes | Yes | Yes | Global | Yes |
authentication_ldap_simple_auth_method_name | Yes | Yes | Yes | Global | Yes |
authentication_ldap_simple_bind_base_dn | Yes | Yes | Yes | Global | Yes |
authentication_ldap_simple_bind_root_dn | Yes | Yes | Yes | Global | Yes |
authentication_ldap_simple_bind_root_pwd | Yes | Yes | Yes | Global | Yes |
authentication_ldap_simple_ca_path | Yes | Yes | Yes | Global | Yes |
authentication_ldap_simple_group_search_attr | Yes | Yes | Yes | Global | Yes |
authentication_ldap_simple_group_search_filter | Yes | Yes | Yes | Global | Yes |
authentication_ldap_simple_init_pool_size | Yes | Yes | Yes | Global | Yes |
authentication_ldap_simple_log_status | Yes | Yes | Yes | Global | Yes |
authentication_ldap_simple_max_pool_size | Yes | Yes | Yes | Global | Yes |
authentication_ldap_simple_server_host | Yes | Yes | Yes | Global | Yes |
authentication_ldap_simple_server_port | Yes | Yes | Yes | Global | Yes |
authentication_ldap_simple_tls | Yes | Yes | Yes | Global | Yes |
authentication_ldap_simple_user_search_attr | Yes | Yes | Yes | Global | Yes |
auto_generate_certs | Yes | Yes | Yes | Global | No |
auto_increment_increment | Yes | Both | Yes | ||
auto_increment_offset | Yes | Both | Yes | ||
autocommit | Yes | Yes | Yes | Both | Yes |
automatic_sp_privileges | Yes | Global | Yes | ||
avoid_temporal_upgrade | Yes | Yes | Yes | Global | Yes |
back_log | Yes | Global | No | ||
basedir | Yes | Yes | Yes | Global | No |
big-tables | Yes | Yes | Yes | ||
- Variable: big_tables | Yes | Both | Yes | ||
bind-address | Yes | Yes | No | ||
- Variable: bind_address | Yes | Global | No | ||
binlog_cache_size | Yes | Yes | Yes | Global | Yes |
binlog_checksum | Yes | Global | Yes | ||
binlog_direct_non_transactional_updates | Yes | Yes | Yes | Both | Yes |
binlog_error_action | Yes | Yes | Yes | Global | Yes |
binlog_expire_logs_seconds | Yes | Yes | Yes | Global | Yes |
binlog-format | Yes | Yes | Yes | ||
- Variable: binlog_format | Yes | Both | Yes | ||
binlog_group_commit_sync_delay | Yes | Yes | Yes | Global | Yes |
binlog_group_commit_sync_no_delay_count | Yes | Yes | Yes | Global | Yes |
binlog_gtid_simple_recovery | Yes | Yes | Yes | Global | No |
binlog_max_flush_queue_time | Yes | Global | Yes | ||
binlog_order_commits | Yes | Global | Yes | ||
binlog_row_image | Yes | Yes | Yes | Both | Yes |
binlog_row_metadata | Yes | Yes | Yes | Global | Yes |
binlog_row_value_options | Yes | Yes | Yes | Both | Yes |
binlog_rows_query_log_events | Yes | Yes | Yes | Both | Yes |
binlog_stmt_cache_size | Yes | Yes | Yes | Global | Yes |
binlog_transaction_dependency_history_size | Yes | Yes | Yes | Global | Yes |
binlog_transaction_dependency_tracking | Yes | Yes | Yes | Global | Yes |
block_encryption_mode | Yes | Yes | Yes | Both | Yes |
bulk_insert_buffer_size | Yes | Yes | Yes | Both | Yes |
caching_sha2_password_auto_generate_rsa_keys | Yes | Yes | Yes | Global | No |
caching_sha2_password_private_key_path | Yes | Yes | Yes | Global | No |
caching_sha2_password_public_key_path | Yes | Yes | Yes | Global | No |
character_set_client | Yes | Both | Yes | ||
character_set_connection | Yes | Both | Yes | ||
character_set_database (note 1) | Yes | Both | Yes | ||
character-set-filesystem | Yes | Yes | Yes | ||
- Variable: character_set_filesystem | Yes | Both | Yes | ||
character_set_results | Yes | Both | Yes | ||
character-set-server | Yes | Yes | Yes | ||
- Variable: character_set_server | Yes | Both | Yes | ||
character_set_system | Yes | Global | No | ||
character-sets-dir | Yes | Yes | No | ||
- Variable: character_sets_dir | Yes | Global | No | ||
check_proxy_users | Yes | Yes | Yes | Global | Yes |
collation_connection | Yes | Both | Yes | ||
collation_database (note 1) | Yes | Both | Yes | ||
collation-server | Yes | Yes | Yes | ||
- Variable: collation_server | Yes | Both | Yes | ||
completion_type | Yes | Yes | Yes | Both | Yes |
concurrent_insert | Yes | Yes | Yes | Global | Yes |
connect_timeout | Yes | Yes | Yes | Global | Yes |
connection_control_failed_connections_threshold | Yes | Yes | Yes | Global | Yes |
connection_control_max_connection_delay | Yes | Yes | Yes | Global | Yes |
connection_control_min_connection_delay | Yes | Yes | Yes | Global | Yes |
core_file | Yes | Global | No | ||
cte_max_recursion_depth | Yes | Yes | Yes | Both | Yes |
daemon_memcached_enable_binlog | Yes | Yes | Yes | Global | No |
daemon_memcached_engine_lib_name | Yes | Yes | Yes | Global | No |
daemon_memcached_engine_lib_path | Yes | Yes | Yes | Global | No |
daemon_memcached_option | Yes | Yes | Yes | Global | No |
daemon_memcached_r_batch_size | Yes | Yes | Yes | Global | No |
daemon_memcached_w_batch_size | Yes | Yes | Yes | Global | No |
datadir | Yes | Yes | Yes | Global | No |
date_format | Yes | Global | No | ||
datetime_format | Yes | Global | No | ||
debug | Yes | Yes | Yes | Both | Yes |
debug_sync | Yes | Session | Yes | ||
default_authentication_plugin | Yes | Yes | Yes | Global | No |
default_collation_for_utf8mb4 | Yes | Yes | Both | Yes | |
default_password_lifetime | Yes | Yes | Yes | Global | Yes |
default-storage-engine | Yes | Yes | Yes | ||
- Variable: default_storage_engine | Yes | Both | Yes | ||
default_tmp_storage_engine | Yes | Yes | Yes | Both | Yes |
default_week_format | Yes | Yes | Yes | Both | Yes |
delay-key-write | Yes | Yes | Yes | ||
- Variable: delay_key_write | Yes | Global | Yes | ||
delayed_insert_limit | Yes | Yes | Yes | Global | Yes |
delayed_insert_timeout | Yes | Yes | Yes | Global | Yes |
delayed_queue_size | Yes | Yes | Yes | Global | Yes |
disabled_storage_engines | Yes | Yes | Yes | Global | No |
disconnect_on_expired_password | Yes | Yes | Yes | Global | No |
div_precision_increment | Yes | Yes | Yes | Both | Yes |
dragnet.log_error_filter_rules | Yes | Yes | Yes | Global | Yes |
end_markers_in_json | Yes | Both | Yes | ||
enforce-gtid-consistency | Yes | Yes | Yes | Global | Yes |
enforce_gtid_consistency | Yes | Yes | Yes | Global | Yes |
eq_range_index_dive_limit | Yes | Both | Yes | ||
error_count | Yes | Session | No | ||
event-scheduler | Yes | Yes | Yes | ||
- Variable: event_scheduler | Yes | Global | Yes | ||
executed_gtids_compression_period | Yes | Global | Yes | ||
expire_logs_days | Yes | Yes | Yes | Global | Yes |
explicit_defaults_for_timestamp | Yes | Yes | Yes | Both | Yes |
external_user | Yes | Session | No | ||
flush | Yes | Yes | Yes | Global | Yes |
flush_time | Yes | Yes | Yes | Global | Yes |
foreign_key_checks | Yes | Both | Yes | ||
ft_boolean_syntax | Yes | Yes | Yes | Global | Yes |
ft_max_word_len | Yes | Yes | Yes | Global | No |
ft_min_word_len | Yes | Yes | Yes | Global | No |
ft_query_expansion_limit | Yes | Yes | Yes | Global | No |
ft_stopword_file | Yes | Yes | Yes | Global | No |
general-log | Yes | Yes | Yes | ||
- Variable: general_log | Yes | Global | Yes | ||
general_log_file | Yes | Yes | Yes | Global | Yes |
group_concat_max_len | Yes | Yes | Yes | Both | Yes |
group_replication_allow_local_disjoint_gtids_join | Yes | Yes | Yes | Global | Yes |
group_replication_allow_local_lower_version_join | Yes | Yes | Yes | Global | Yes |
group_replication_auto_increment_increment | Yes | Yes | Yes | Global | Yes |
group_replication_bootstrap_group | Yes | Yes | Yes | Global | Yes |
group_replication_communication_debug_options | Yes | Yes | Yes | Global | Yes |
group_replication_components_stop_timeout | Yes | Yes | Yes | Global | Yes |
group_replication_compression_threshold | Yes | Yes | Yes | Global | Yes |
group_replication_enforce_update_everywhere_checks | Yes | Yes | Yes | Global | Yes |
group_replication_exit_state_action | Yes | Yes | Yes | Global | Yes |
group_replication_flow_control_applier_threshold | Yes | Yes | Yes | Global | Yes |
group_replication_flow_control_certifier_threshold | Yes | Yes | Yes | Global | Yes |
group_replication_flow_control_hold_percent | Yes | Yes | Yes | Global | Yes |
group_replication_flow_control_max_commit_quota | Yes | Yes | Yes | ||
- Variable: group_replication_flow_control_min_quota | Yes | Global | Yes | ||
group_replication_flow_control_member_quota_percent | Yes | Yes | Yes | Global | Yes |
group_replication_flow_control_min_quota | Yes | Yes | Yes | Global | Yes |
group_replication_flow_control_min_recovery_quota | Yes | Yes | Yes | Global | Yes |
group_replication_flow_control_mode | Yes | Yes | Yes | Global | Yes |
group_replication_flow_control_period | Yes | Yes | Yes | Global | Yes |
group_replication_flow_control_release_percent | Yes | Yes | Yes | Global | Yes |
group_replication_force_members | Yes | Yes | Yes | Global | Yes |
group_replication_group_name | Yes | Yes | Yes | Global | Yes |
group_replication_group_seeds | Yes | Yes | Yes | Global | Yes |
group_replication_gtid_assignment_block_size | Yes | Yes | Yes | Global | Yes |
group_replication_ip_whitelist | Yes | Yes | Yes | Global | Yes |
group_replication_local_address | Yes | Yes | Yes | Global | Yes |
group_replication_member_weight | Yes | Yes | Yes | Global | Yes |
group_replication_poll_spin_loops | Yes | Yes | Yes | Global | Yes |
group_replication_recovery_complete_at | Yes | Yes | Yes | Global | Yes |
group_replication_recovery_get_public_key | Yes | Yes | Yes | Global | Yes |
group_replication_recovery_public_key_path | Yes | Yes | Yes | Global | Yes |
group_replication_recovery_reconnect_interval | Yes | Yes | Yes | Global | Yes |
group_replication_recovery_retry_count | Yes | Yes | Yes | Global | Yes |
group_replication_recovery_ssl_ca | Yes | Yes | Yes | Global | Yes |
group_replication_recovery_ssl_capath | Yes | Yes | Yes | Global | Yes |
group_replication_recovery_ssl_cert | Yes | Yes | Yes | Global | Yes |
group_replication_recovery_ssl_cipher | Yes | Yes | Yes | Global | Yes |
group_replication_recovery_ssl_crl | Yes | Yes | Yes | Global | Yes |
group_replication_recovery_ssl_crlpath | Yes | Yes | Yes | Global | Yes |
group_replication_recovery_ssl_key | Yes | Yes | Yes | Global | Yes |
group_replication_recovery_ssl_verify_server_cert | Yes | Yes | Yes | Global | Yes |
group_replication_recovery_use_ssl | Yes | Yes | Yes | Global | Yes |
group_replication_single_primary_mode | Yes | Yes | Yes | Global | Yes |
group_replication_ssl_mode | Yes | Yes | Yes | Global | Yes |
group_replication_start_on_boot | Yes | Yes | Yes | Global | Yes |
group_replication_transaction_size_limit | Yes | Yes | Yes | Global | Yes |
group_replication_unreachable_majority_timeout | Yes | Yes | Yes | Global | Yes |
gtid_executed | Yes | Varies | No | ||
gtid_executed_compression_period | Yes | Global | Yes | ||
gtid-mode | Yes | Yes | Yes | ||
- Variable: gtid_mode | Yes | Global | Yes | ||
gtid_mode | Yes | Global | Yes | ||
gtid_next | Yes | Session | Yes | ||
gtid_owned | Yes | Both | No | ||
gtid_purged | Yes | Global | Yes | ||
have_compress | Yes | Global | No | ||
have_crypt | Yes | Global | No | ||
have_dynamic_loading | Yes | Global | No | ||
have_geometry | Yes | Global | No | ||
have_openssl | Yes | Global | No | ||
have_profiling | Yes | Global | No | ||
have_query_cache | Yes | Global | No | ||
have_rtree_keys | Yes | Global | No | ||
have_ssl | Yes | Global | No | ||
have_statement_timeout | Yes | Global | No | ||
have_symlink | Yes | Global | No | ||
histogram_generation_max_mem_size | Yes | Yes | Yes | Both | Yes |
host_cache_size | Yes | Global | Yes | ||
hostname | Yes | Global | No | ||
identity | Yes | Session | Yes | ||
ignore-builtin-innodb | Yes | Yes | No | ||
- Variable: ignore_builtin_innodb | Yes | Global | No | ||
information_schema_stats_expiry | Yes | Yes | Yes | Both | Yes |
init_connect | Yes | Yes | Yes | Global | Yes |
init-file | Yes | Yes | No | ||
- Variable: init_file | Yes | Global | No | ||
init_slave | Yes | Yes | Yes | Global | Yes |
innodb_adaptive_flushing | Yes | Yes | Yes | Global | Yes |
innodb_adaptive_flushing_lwm | Yes | Yes | Yes | Global | Yes |
innodb_adaptive_hash_index | Yes | Yes | Yes | Global | Yes |
innodb_adaptive_hash_index_parts | Yes | Yes | Yes | Global | No |
innodb_adaptive_max_sleep_delay | Yes | Yes | Yes | Global | Yes |
innodb_api_bk_commit_interval | Yes | Yes | Yes | Global | Yes |
innodb_api_disable_rowlock | Yes | Yes | Yes | Global | No |
innodb_api_enable_binlog | Yes | Yes | Yes | Global | No |
innodb_api_enable_mdl | Yes | Yes | Yes | Global | No |
innodb_api_trx_level | Yes | Yes | Yes | Global | Yes |
innodb_autoextend_increment | Yes | Yes | Yes | Global | Yes |
innodb_autoinc_lock_mode | Yes | Yes | Yes | Global | No |
innodb_background_drop_list_empty | Yes | Yes | Yes | Global | Yes |
innodb_buffer_pool_chunk_size | Yes | Yes | Yes | Global | No |
innodb_buffer_pool_debug | Yes | Yes | Yes | Global | No |
innodb_buffer_pool_dump_at_shutdown | Yes | Yes | Yes | Global | Yes |
innodb_buffer_pool_dump_now | Yes | Yes | Yes | Global | Yes |
innodb_buffer_pool_dump_pct | Yes | Yes | Yes | Global | Yes |
innodb_buffer_pool_filename | Yes | Yes | Yes | Global | Yes |
innodb_buffer_pool_instances | Yes | Yes | Yes | Global | No |
innodb_buffer_pool_load_abort | Yes | Yes | Yes | Global | Yes |
innodb_buffer_pool_load_at_startup | Yes | Yes | Yes | Global | No |
innodb_buffer_pool_load_now | Yes | Yes | Yes | Global | Yes |
innodb_buffer_pool_size | Yes | Yes | Yes | Global | Yes |
innodb_change_buffer_max_size | Yes | Yes | Yes | Global | Yes |
innodb_change_buffering | Yes | Yes | Yes | Global | Yes |
innodb_change_buffering_debug | Yes | Yes | Yes | Global | Yes |
innodb_checkpoint_disabled | Yes | Yes | Yes | Global | Yes |
innodb_checksum_algorithm | Yes | Yes | Yes | Global | Yes |
innodb_cmp_per_index_enabled | Yes | Yes | Yes | Global | Yes |
innodb_commit_concurrency | Yes | Yes | Yes | Global | Yes |
innodb_compress_debug | Yes | Yes | Yes | Global | Yes |
innodb_compression_failure_threshold_pct | Yes | Yes | Yes | Global | Yes |
innodb_compression_level | Yes | Yes | Yes | Global | Yes |
innodb_compression_pad_pct_max | Yes | Yes | Yes | Global | Yes |
innodb_concurrency_tickets | Yes | Yes | Yes | Global | Yes |
innodb_data_file_path | Yes | Yes | Yes | Global | No |
innodb_data_home_dir | Yes | Yes | Yes | Global | No |
innodb_ddl_log_crash_reset_debug | Yes | Yes | Yes | Global | Yes |
innodb_deadlock_detect | Yes | Yes | Yes | Global | Yes |
innodb_dedicated_server | Yes | Yes | Yes | Global | No |
innodb_default_row_format | Yes | Yes | Yes | Global | Yes |
innodb_directories | Yes | Yes | Yes | Global | No |
innodb_disable_sort_file_cache | Yes | Yes | Yes | Global | Yes |
innodb_doublewrite | Yes | Yes | Yes | Global | No |
innodb_fast_shutdown | Yes | Yes | Yes | Global | Yes |
innodb_fil_make_page_dirty_debug | Yes | Yes | Yes | Global | Yes |
innodb_file_per_table | Yes | Yes | Yes | Global | Yes |
innodb_fill_factor | Yes | Yes | Yes | Global | Yes |
innodb_flush_log_at_timeout | Yes | Global | Yes | ||
innodb_flush_log_at_trx_commit | Yes | Yes | Yes | Global | Yes |
innodb_flush_method | Yes | Yes | Yes | Global | No |
innodb_flush_neighbors | Yes | Yes | Yes | Global | Yes |
innodb_flush_sync | Yes | Yes | Yes | Global | Yes |
innodb_flushing_avg_loops | Yes | Yes | Yes | Global | Yes |
innodb_force_load_corrupted | Yes | Yes | Yes | Global | No |
innodb_force_recovery | Yes | Yes | Yes | Global | No |
innodb_fsync_threshold | Yes | Yes | Yes | Global | Yes |
innodb_ft_aux_table | Yes | Yes | Yes | Global | Yes |
innodb_ft_cache_size | Yes | Yes | Yes | Global | No |
innodb_ft_enable_diag_print | Yes | Yes | Yes | Global | Yes |
innodb_ft_enable_stopword | Yes | Yes | Yes | Global | Yes |
innodb_ft_max_token_size | Yes | Yes | Yes | Global | No |
innodb_ft_min_token_size | Yes | Yes | Yes | Global | No |
innodb_ft_num_word_optimize | Yes | Yes | Yes | Global | Yes |
innodb_ft_result_cache_limit | Yes | Yes | Yes | Global | Yes |
innodb_ft_server_stopword_table | Yes | Yes | Yes | Global | Yes |
innodb_ft_sort_pll_degree | Yes | Yes | Yes | Global | No |
innodb_ft_total_cache_size | Yes | Yes | Yes | Global | No |
innodb_ft_user_stopword_table | Yes | Yes | Yes | Both | Yes |
innodb_io_capacity | Yes | Yes | Yes | Global | Yes |
innodb_io_capacity_max | Yes | Yes | Yes | Global | Yes |
innodb_limit_optimistic_insert_debug | Yes | Yes | Yes | Global | Yes |
innodb_lock_wait_timeout | Yes | Yes | Yes | Both | Yes |
innodb_log_buffer_size | Yes | Yes | Yes | Global | Varies |
innodb_log_checksums | Yes | Yes | Yes | Global | Yes |
innodb_log_compressed_pages | Yes | Yes | Yes | Global | Yes |
innodb_log_file_size | Yes | Yes | Yes | Global | No |
innodb_log_files_in_group | Yes | Yes | Yes | Global | No |
innodb_log_group_home_dir | Yes | Yes | Yes | Global | No |
innodb_log_spin_cpu_abs_lwm | Yes | Yes | Yes | Global | Yes |
innodb_log_spin_cpu_pct_hwm | Yes | Yes | Yes | Global | Yes |
innodb_log_wait_for_flush_spin_hwm | Yes | Yes | Yes | Global | Yes |
innodb_log_write_ahead_size | Yes | Yes | Yes | Global | Yes |
innodb_lru_scan_depth | Yes | Yes | Yes | Global | Yes |
innodb_max_dirty_pages_pct | Yes | Yes | Yes | Global | Yes |
innodb_max_dirty_pages_pct_lwm | Yes | Yes | Yes | Global | Yes |
innodb_max_purge_lag | Yes | Yes | Yes | Global | Yes |
innodb_max_purge_lag_delay | Yes | Yes | Yes | Global | Yes |
innodb_max_undo_log_size | Yes | Yes | Yes | Global | Yes |
innodb_merge_threshold_set_all_debug | Yes | Yes | Yes | Global | Yes |
innodb_monitor_disable | Yes | Yes | Yes | Global | Yes |
innodb_monitor_enable | Yes | Yes | Yes | Global | Yes |
innodb_monitor_reset | Yes | Yes | Yes | Global | Yes |
innodb_monitor_reset_all | Yes | Yes | Yes | Global | Yes |
innodb_numa_interleave | Yes | Yes | Yes | Global | No |
innodb_old_blocks_pct | Yes | Yes | Yes | Global | Yes |
innodb_old_blocks_time | Yes | Yes | Yes | Global | Yes |
innodb_online_alter_log_max_size | Yes | Yes | Yes | Global | Yes |
innodb_open_files | Yes | Yes | Yes | Global | No |
innodb_optimize_fulltext_only | Yes | Yes | Yes | Global | Yes |
innodb_page_cleaners | Yes | Yes | Yes | Global | No |
innodb_page_size | Yes | Yes | Yes | Global | No |
innodb_print_all_deadlocks | Yes | Yes | Yes | Global | Yes |
innodb_print_ddl_logs | Yes | Yes | Yes | Global | Yes |
innodb_purge_batch_size | Yes | Yes | Yes | Global | Yes |
innodb_purge_rseg_truncate_frequency | Yes | Yes | Yes | Global | Yes |
innodb_purge_threads | Yes | Yes | Yes | Global | No |
innodb_random_read_ahead | Yes | Yes | Yes | Global | Yes |
innodb_read_ahead_threshold | Yes | Yes | Yes | Global | Yes |
innodb_read_io_threads | Yes | Yes | Yes | Global | No |
innodb_read_only | Yes | Yes | Yes | Global | No |
innodb_redo_log_encrypt | Yes | Yes | Yes | Global | Yes |
innodb_replication_delay | Yes | Yes | Yes | Global | Yes |
innodb_rollback_on_timeout | Yes | Yes | Yes | Global | No |
innodb_rollback_segments | Yes | Yes | Yes | Global | Yes |
innodb_saved_page_number_debug | Yes | Yes | Yes | Global | Yes |
innodb_scan_directories | Yes | Yes | Yes | Global | No |
innodb_sort_buffer_size | Yes | Yes | Yes | Global | No |
innodb_spin_wait_delay | Yes | Yes | Yes | Global | Yes |
innodb_stats_auto_recalc | Yes | Yes | Yes | Global | Yes |
innodb_stats_include_delete_marked | Yes | Yes | Yes | Global | Yes |
innodb_stats_method | Yes | Yes | Yes | Global | Yes |
innodb_stats_on_metadata | Yes | Yes | Yes | Global | Yes |
innodb_stats_persistent | Yes | Yes | Yes | Global | Yes |
innodb_stats_persistent_sample_pages | Yes | Yes | Yes | Global | Yes |
innodb_stats_transient_sample_pages | Yes | Yes | Yes | Global | Yes |
innodb_status_output | Yes | Yes | Yes | Global | Yes |
innodb_status_output_locks | Yes | Yes | Yes | Global | Yes |
innodb_strict_mode | Yes | Yes | Yes | Both | Yes |
innodb_sync_array_size | Yes | Yes | Yes | Global | No |
innodb_sync_debug | Yes | Yes | Yes | Global | No |
innodb_sync_spin_loops | Yes | Yes | Yes | Global | Yes |
innodb_table_locks | Yes | Yes | Yes | Both | Yes |
innodb_temp_data_file_path | Yes | Yes | Yes | Global | No |
innodb_temp_tablespaces_dir | Yes | Yes | Yes | Global | No |
innodb_thread_concurrency | Yes | Yes | Yes | Global | Yes |
innodb_thread_sleep_delay | Yes | Yes | Yes | Global | Yes |
innodb_tmpdir | Yes | Yes | Yes | Both | Yes |
innodb_trx_purge_view_update_only_debug | Yes | Yes | Yes | Global | Yes |
innodb_trx_rseg_n_slots_debug | Yes | Yes | Yes | Global | Yes |
innodb_undo_directory | Yes | Yes | Yes | Global | No |
innodb_undo_log_encrypt | Yes | Yes | Yes | Global | Yes |
innodb_undo_log_truncate | Yes | Yes | Yes | Global | Yes |
innodb_undo_logs | Yes | Yes | Yes | Global | Yes |
innodb_undo_tablespaces | Yes | Yes | Yes | Global | Varies |
innodb_use_native_aio | Yes | Yes | Yes | Global | No |
innodb_version | Yes | Global | No | ||
innodb_write_io_threads | Yes | Yes | Yes | Global | No |
insert_id | Yes | Session | Yes | ||
interactive_timeout | Yes | Yes | Yes | Both | Yes |
internal_tmp_disk_storage_engine | Yes | Yes | Yes | Global | Yes |
internal_tmp_mem_storage_engine | Yes | Yes | Yes | Both | Yes |
join_buffer_size | Yes | Yes | Yes | Both | Yes |
keep_files_on_create | Yes | Yes | Yes | Both | Yes |
key_buffer_size | Yes | Yes | Yes | Global | Yes |
key_cache_age_threshold | Yes | Yes | Yes | Global | Yes |
key_cache_block_size | Yes | Yes | Yes | Global | Yes |
key_cache_division_limit | Yes | Yes | Yes | Global | Yes |
keyring_aws_cmk_id | Yes | Yes | Yes | Global | Yes |
keyring_aws_conf_file | Yes | Yes | Yes | Global | No |
keyring_aws_data_file | Yes | Yes | Yes | Global | No |
keyring_aws_region | Yes | Yes | Yes | Global | Yes |
keyring_encrypted_file_data | Yes | Yes | Yes | Global | Yes |
keyring_encrypted_file_password | Yes | Yes | Yes | Global | Yes |
keyring_file_data | Yes | Yes | Yes | Global | Yes |
keyring_okv_conf_dir | Yes | Yes | Yes | Global | Yes |
keyring_operations | Yes | Global | Yes | ||
language | Yes | Yes | Yes | Global | No |
large_files_support | Yes | Global | No | ||
large_page_size | Yes | Global | No | ||
large-pages | Yes | Yes | No | ||
- Variable: large_pages | Yes | Global | No | ||
last_insert_id | Yes | Session | Yes | ||
lc-messages | Yes | Yes | Yes | ||
- Variable: lc_messages | Yes | Both | Yes | ||
lc-messages-dir | Yes | Yes | No | ||
- Variable: lc_messages_dir | Yes | Global | No | ||
lc_time_names | Yes | Both | Yes | ||
license | Yes | Global | No | ||
local_infile | Yes | Global | Yes | ||
lock_wait_timeout | Yes | Yes | Yes | Both | Yes |
locked_in_memory | Yes | Global | No | ||
log-bin | Yes | Yes | Yes | Global | No |
log_bin | Yes | Global | No | ||
log_bin_basename | Yes | Global | No | ||
log_bin_index | Yes | Global | No | ||
log-bin-trust-function-creators | Yes | Yes | Yes | ||
- Variable: log_bin_trust_function_creators | Yes | Global | Yes | ||
log-bin-use-v1-row-events | Yes | Yes | No | ||
- Variable: log_bin_use_v1_row_events | Yes | Global | No | ||
log_bin_use_v1_row_events | Yes | Yes | Yes | Global | No |
log_builtin_as_identified_by_password | Yes | Yes | Yes | Global | Yes |
log-error | Yes | Yes | No | ||
- Variable: log_error | Yes | Global | No | ||
log_error_filter_rules | Yes | Yes | Yes | Global | Yes |
log_error_services | Yes | Yes | Yes | Global | Yes |
log_error_suppression_list | Yes | Yes | Yes | Global | Yes |
log_error_verbosity | Yes | Yes | Yes | Global | Yes |
log-output | Yes | Yes | Yes | ||
- Variable: log_output | Yes | Global | Yes | ||
log-queries-not-using-indexes | Yes | Yes | Yes | ||
- Variable: log_queries_not_using_indexes | Yes | Global | Yes | ||
log-slave-updates | Yes | Yes | No | ||
- Variable: log_slave_updates | Yes | Global | No | ||
log_slave_updates | Yes | Yes | Yes | Global | No |
log_slow_admin_statements | Yes | Global | Yes | ||
log_slow_slave_statements | Yes | Global | Yes | ||
log_statements_unsafe_for_binlog | Yes | Global | Yes | ||
log_syslog | Yes | Yes | Yes | Global | Yes |
log_syslog_facility | Yes | Yes | Yes | Global | Yes |
log_syslog_include_pid | Yes | Yes | Yes | Global | Yes |
log_syslog_tag | Yes | Yes | Yes | Global | Yes |
log_throttle_queries_not_using_indexes | Yes | Global | Yes | ||
log_timestamps | Yes | Yes | Yes | Global | Yes |
log-warnings | Yes | Yes | Yes | ||
- Variable: log_warnings | Yes | Global | Yes | ||
long_query_time | Yes | Yes | Yes | Both | Yes |
low-priority-updates | Yes | Yes | Yes | ||
- Variable: low_priority_updates | Yes | Both | Yes | ||
lower_case_file_system | Yes | Global | No | ||
lower_case_table_names | Yes | Yes | Yes | Global | No |
mandatory_roles | Yes | Yes | Yes | Global | Yes |
master_info_repository | Yes | Yes | Yes | Global | Yes |
master_verify_checksum | Yes | Global | Yes | ||
max_allowed_packet | Yes | Yes | Yes | Both | Yes |
max_binlog_cache_size | Yes | Yes | Yes | Global | Yes |
max_binlog_size | Yes | Yes | Yes | Global | Yes |
max_binlog_stmt_cache_size | Yes | Yes | Yes | Global | Yes |
max_connect_errors | Yes | Yes | Yes | Global | Yes |
max_connections | Yes | Yes | Yes | Global | Yes |
max_delayed_threads | Yes | Yes | Yes | Both | Yes |
max_digest_length | Yes | Yes | Yes | Global | No |
max_error_count | Yes | Yes | Yes | Both | Yes |
max_execution_time | Yes | Yes | Yes | Both | Yes |
max_heap_table_size | Yes | Yes | Yes | Both | Yes |
max_insert_delayed_threads | Yes | Both | Yes | ||
max_join_size | Yes | Yes | Yes | Both | Yes |
max_length_for_sort_data | Yes | Yes | Yes | Both | Yes |
max_points_in_geometry | Yes | Yes | Yes | Both | Yes |
max_prepared_stmt_count | Yes | Yes | Yes | Global | Yes |
max_relay_log_size | Yes | Yes | Yes | Global | Yes |
max_seeks_for_key | Yes | Yes | Yes | Both | Yes |
max_sort_length | Yes | Yes | Yes | Both | Yes |
max_sp_recursion_depth | Yes | Yes | Yes | Both | Yes |
max_tmp_tables | Yes | Both | Yes | ||
max_user_connections | Yes | Yes | Yes | Both | Yes |
max_write_lock_count | Yes | Yes | Yes | Global | Yes |
mecab_rc_file | Yes | Yes | Yes | Global | No |
metadata_locks_cache_size | Yes | Global | No | ||
metadata_locks_hash_instances | Yes | Global | No | ||
min-examined-row-limit | Yes | Yes | Yes | Both | Yes |
multi_range_count | Yes | Yes | Yes | Both | Yes |
myisam_data_pointer_size | Yes | Yes | Yes | Global | Yes |
myisam_max_sort_file_size | Yes | Yes | Yes | Global | Yes |
myisam_mmap_size | Yes | Yes | Yes | Global | No |
myisam_recover_options | Yes | Global | No | ||
myisam_repair_threads | Yes | Yes | Yes | Both | Yes |
myisam_sort_buffer_size | Yes | Yes | Yes | Both | Yes |
myisam_stats_method | Yes | Yes | Yes | Both | Yes |
myisam_use_mmap | Yes | Yes | Yes | Global | Yes |
mysql_firewall_mode | Yes | Yes | Yes | Global | Yes |
mysql_firewall_trace | Yes | Yes | Yes | Global | Yes |
mysql_native_password_proxy_users | Yes | Yes | Yes | Global | Yes |
mysqlx | Yes | Yes | Yes | Global | No |
mysqlx-bind-address | Yes | Yes | Yes | Global | No |
mysqlx_bind_address | Yes | Yes | Yes | Global | No |
mysqlx-connect-timeout | Yes | Yes | Yes | Global | Yes |
mysqlx_connect_timeout | Yes | Yes | Yes | Global | Yes |
mysqlx_document_id_unique_prefix | Yes | Yes | Yes | Global | Yes |
mysqlx-idle-worker-thread-timeout | Yes | Yes | Yes | Global | Yes |
mysqlx_idle_worker_thread_timeout | Yes | Yes | Yes | Global | Yes |
mysqlx-interactive-timeout | Yes | Yes | Yes | Global | Yes |
mysqlx_interactive_timeout | Yes | Yes | Yes | Global | Yes |
mysqlx-max-allowed-packet | Yes | Yes | Yes | Global | Yes |
mysqlx_max_allowed_packet | Yes | Yes | Yes | Global | Yes |
mysqlx-max-connections | Yes | Yes | Yes | Global | Yes |
mysqlx_max_connections | Yes | Yes | Yes | Global | Yes |
mysqlx-min-worker-threads | Yes | Yes | Yes | Global | Yes |
mysqlx_min_worker_threads | Yes | Yes | Yes | Global | Yes |
mysqlx-port | Yes | Yes | Yes | Global | No |
mysqlx_port | Yes | Yes | Yes | Global | No |
mysqlx-port-open-timeout | Yes | Yes | Yes | Global | No |
mysqlx_port_open_timeout | Yes | Yes | Yes | Global | No |
mysqlx-read-timeout | Yes | Yes | Yes | Session | Yes |
mysqlx_read_timeout | Yes | Yes | Yes | Session | Yes |
mysqlx-socket | Yes | Yes | Yes | Global | No |
mysqlx_socket | Yes | Yes | Yes | Global | No |
mysqlx-ssl-ca | Yes | Yes | Yes | Global | No |
mysqlx-ssl-capath | Yes | Yes | Yes | Global | No |
mysqlx-ssl-cert | Yes | Yes | Yes | Global | No |
mysqlx-ssl-crl | Yes | Yes | Yes | Global | No |
mysqlx-ssl-crlpath | Yes | Yes | Yes | Global | No |
mysqlx-ssl-key | Yes | Yes | Yes | Global | No |
mysqlx-wait-timeout | Yes | Yes | Yes | Session | Yes |
mysqlx_wait_timeout | Yes | Yes | Yes | Session | Yes |
mysqlx-write-timeout | Yes | Yes | Yes | Session | Yes |
mysqlx_write_timeout | Yes | Yes | Yes | Session | Yes |
named_pipe | Yes | Global | No | ||
ndb-batch-size | Yes | Yes | Yes | Global | No |
ndb-blob-write-batch-bytes | Yes | Yes | Yes | Both | Yes |
ndb-cluster-connection-pool | Yes | Yes | Yes | Global | No |
ndb-cluster-connection-pool-nodeids | Yes | Yes | Yes | Global | No |
ndb-deferred-constraints | Yes | Yes | Yes | ||
- Variable: ndb_deferred_constraints | Yes | Both | Yes | ||
ndb_deferred_constraints | Yes | Yes | Yes | Both | Yes |
ndb-distribution | Yes | Yes | Yes | ||
- Variable: ndb_distribution | Yes | Global | Yes | ||
ndb_distribution | Yes | Yes | Yes | Global | Yes |
ndb_eventbuffer_free_percent | Yes | Yes | Yes | Global | Yes |
ndb_eventbuffer_max_alloc | Yes | Yes | Yes | Global | Yes |
ndb_force_send | Yes | Yes | Yes | Both | Yes |
ndb_index_stat_enable | Yes | Yes | Yes | Both | Yes |
ndb_index_stat_option | Yes | Yes | Yes | Both | Yes |
ndb_join_pushdown | Yes | Both | Yes | ||
ndb-log-apply-status | Yes | Yes | No | ||
- Variable: ndb_log_apply_status | Yes | Global | No | ||
ndb_log_apply_status | Yes | Yes | Yes | Global | No |
ndb_log_binlog_index | Yes | Yes | Global | Yes | |
ndb-log-empty-epochs | Yes | Yes | Yes | Global | Yes |
ndb-log-empty-update | Yes | Yes | Yes | Global | Yes |
ndb-log-transaction-id | Yes | Yes | No | ||
- Variable: ndb_log_transaction_id | Yes | Global | No | ||
ndb_log_updated_only | Yes | Yes | Yes | Global | Yes |
ndb_optimization_delay | Yes | Global | Yes | ||
ndb_optimized_node_selection | Yes | Yes | Yes | Global | No |
ndb_recv_thread_cpu_mask | Yes | Global | Yes | ||
ndb_report_thresh_binlog_epoch_slip | Yes | Yes | Yes | Global | Yes |
ndb_report_thresh_binlog_mem_usage | Yes | Yes | Yes | Global | Yes |
ndb_show_foreign_key_mock_tables | Yes | Yes | Yes | Global | Yes |
Ndb_slave_max_replicated_epoch | Yes | Global | No | ||
ndb_table_no_logging | Yes | Session | Yes | ||
ndb_use_transactions | Yes | Yes | Yes | Both | Yes |
ndb_version | Yes | Global | No | ||
ndb_version_string | Yes | Global | No | ||
ndb-wait-setup | Yes | Yes | Yes | Global | No |
ndbinfo_database | Yes | Global | No | ||
ndbinfo_max_rows | Yes | Yes | Both | Yes | |
ndbinfo_show_hidden | Yes | Yes | Both | Yes | |
ndbinfo_version | Yes | Global | No | ||
net_buffer_length | Yes | Yes | Yes | Both | Yes |
net_read_timeout | Yes | Yes | Yes | Both | Yes |
net_retry_count | Yes | Yes | Yes | Both | Yes |
net_write_timeout | Yes | Yes | Yes | Both | Yes |
new | Yes | Yes | Yes | Both | Yes |
ngram_token_size | Yes | Yes | Yes | Global | No |
offline_mode | Yes | Yes | Yes | Global | Yes |
old | Yes | Yes | Yes | Global | No |
old-alter-table | Yes | Yes | Yes | ||
- Variable: old_alter_table | Yes | Both | Yes | ||
old_passwords | Yes | Both | Yes | ||
open-files-limit | Yes | Yes | No | ||
- Variable: open_files_limit | Yes | Global | No | ||
optimizer_prune_level | Yes | Yes | Yes | Both | Yes |
optimizer_search_depth | Yes | Yes | Yes | Both | Yes |
optimizer_switch | Yes | Yes | Yes | Both | Yes |
optimizer_trace | Yes | Both | Yes | ||
optimizer_trace_features | Yes | Both | Yes | ||
optimizer_trace_limit | Yes | Both | Yes | ||
optimizer_trace_max_mem_size | Yes | Both | Yes | ||
optimizer_trace_offset | Yes | Both | Yes | ||
parser_max_mem_size | Yes | Yes | Yes | Both | Yes |
password_history | Yes | Yes | Yes | Global | Yes |
password_require_current | Yes | Yes | Yes | Global | Yes |
password_reuse_interval | Yes | Yes | Yes | Global | Yes |
performance_schema | Yes | Yes | Yes | Global | No |
performance_schema_accounts_size | Yes | Yes | Yes | Global | No |
performance_schema_digests_size | Yes | Yes | Yes | Global | No |
performance_schema_error_size | Yes | Yes | Yes | Global | No |
performance_schema_events_stages_history_long_size | Yes | Yes | Yes | Global | No |
performance_schema_events_stages_history_size | Yes | Yes | Yes | Global | No |
performance_schema_events_statements_history_long_size | Yes | Yes | Yes | Global | No |
performance_schema_events_statements_history_size | Yes | Yes | Yes | Global | No |
performance_schema_events_transactions_history_long_size | Yes | Yes | Yes | Global | No |
performance_schema_events_transactions_history_size | Yes | Yes | Yes | Global | No |
performance_schema_events_waits_history_long_size | Yes | Yes | Yes | Global | No |
performance_schema_events_waits_history_size | Yes | Yes | Yes | Global | No |
performance_schema_hosts_size | Yes | Yes | Yes | Global | No |
performance_schema_max_cond_classes | Yes | Yes | Yes | Global | No |
performance_schema_max_cond_instances | Yes | Yes | Yes | Global | No |
performance_schema_max_digest_length | Yes | Yes | Yes | Global | No |
performance_schema_max_digest_sample_age | Yes | Yes | Yes | Global | Yes |
performance_schema_max_file_classes | Yes | Yes | Yes | Global | No |
performance_schema_max_file_handles | Yes | Yes | Yes | Global | No |
performance_schema_max_file_instances | Yes | Yes | Yes | Global | No |
performance_schema_max_index_stat | Yes | Yes | Yes | Global | No |
performance_schema_max_memory_classes | Yes | Yes | Yes | Global | No |
performance_schema_max_metadata_locks | Yes | Yes | Yes | Global | No |
performance_schema_max_mutex_classes | Yes | Yes | Yes | Global | No |
performance_schema_max_mutex_instances | Yes | Yes | Yes | Global | No |
performance_schema_max_prepared_statements_instances | Yes | Yes | Yes | Global | No |
performance_schema_max_program_instances | Yes | Yes | Yes | Global | No |
performance_schema_max_rwlock_classes | Yes | Yes | Yes | Global | No |
performance_schema_max_rwlock_instances | Yes | Yes | Yes | Global | No |
performance_schema_max_socket_classes | Yes | Yes | Yes | Global | No |
performance_schema_max_socket_instances | Yes | Yes | Yes | Global | No |
performance_schema_max_sql_text_length | Yes | Yes | Yes | Global | No |
performance_schema_max_stage_classes | Yes | Yes | Yes | Global | No |
performance_schema_max_statement_classes | Yes | Yes | Yes | Global | No |
performance_schema_max_statement_stack | Yes | Yes | Yes | Global | No |
performance_schema_max_table_handles | Yes | Yes | Yes | Global | No |
performance_schema_max_table_instances | Yes | Yes | Yes | Global | No |
performance_schema_max_table_lock_stat | Yes | Yes | Yes | Global | No |
performance_schema_max_thread_classes | Yes | Yes | Yes | Global | No |
performance_schema_max_thread_instances | Yes | Yes | Yes | Global | No |
performance_schema_session_connect_attrs_size | Yes | Yes | Yes | Global | No |
performance_schema_setup_actors_size | Yes | Yes | Yes | Global | No |
performance_schema_setup_objects_size | Yes | Yes | Yes | Global | No |
performance_schema_users_size | Yes | Yes | Yes | Global | No |
persisted_globals_load | Yes | Yes | Yes | Global | No |
pid-file | Yes | Yes | No | ||
- Variable: pid_file | Yes | Global | No | ||
plugin_dir | Yes | Yes | Yes | Global | No |
port | Yes | Yes | Yes | Global | No |
preload_buffer_size | Yes | Yes | Yes | Both | Yes |
profiling | Yes | Both | Yes | ||
profiling_history_size | Yes | Yes | Yes | Both | Yes |
protocol_version | Yes | Global | No | ||
proxy_user | Yes | Session | No | ||
pseudo_slave_mode | Yes | Session | Yes | ||
pseudo_thread_id | Yes | Session | Yes | ||
query_alloc_block_size | Yes | Yes | Yes | Both | Yes |
query_cache_limit | Yes | Yes | Yes | Global | Yes |
query_cache_min_res_unit | Yes | Yes | Yes | Global | Yes |
query_cache_size | Yes | Yes | Yes | Global | Yes |
query_cache_type | Yes | Yes | Yes | Both | Yes |
query_cache_wlock_invalidate | Yes | Yes | Yes | Both | Yes |
query_prealloc_size | Yes | Yes | Yes | Both | Yes |
rand_seed1 | Yes | Session | Yes | ||
rand_seed2 | Yes | Session | Yes | ||
range_alloc_block_size | Yes | Yes | Yes | Both | Yes |
range_optimizer_max_mem_size | Yes | Yes | Yes | Both | Yes |
rbr_exec_mode | Yes | Both | Yes | ||
read_buffer_size | Yes | Yes | Yes | Both | Yes |
read_only | Yes | Yes | Yes | Global | Yes |
read_rnd_buffer_size | Yes | Yes | Yes | Both | Yes |
regexp_stack_limit | Yes | Yes | Yes | Global | Yes |
regexp_time_limit | Yes | Yes | Yes | Global | Yes |
relay-log | Yes | Yes | No | ||
- Variable: relay_log | Yes | Global | No | ||
relay_log_basename | Yes | Global | No | ||
relay-log-index | Yes | Yes | No | ||
- Variable: relay_log_index | Yes | Global | No | ||
relay_log_index | Yes | Yes | Yes | Global | No |
relay_log_info_file | Yes | Yes | Yes | Global | No |
relay_log_info_repository | Yes | Global | Yes | ||
relay_log_purge | Yes | Yes | Yes | Global | Yes |
relay_log_recovery | Yes | Yes | Yes | Global | No |
relay_log_space_limit | Yes | Yes | Yes | Global | No |
report-host | Yes | Yes | No | ||
- Variable: report_host | Yes | Global | No | ||
report-password | Yes | Yes | No | ||
- Variable: report_password | Yes | Global | No | ||
report-port | Yes | Yes | No | ||
- Variable: report_port | Yes | Global | No | ||
report-user | Yes | Yes | No | ||
- Variable: report_user | Yes | Global | No | ||
require_secure_transport | Yes | Yes | Yes | Global | Yes |
resultset_metadata | Yes | Session | Yes | ||
rewriter_enabled | Yes | Global | Yes | ||
rewriter_verbose | Yes | Global | Yes | ||
rpl_read_size | Yes | Yes | Yes | Global | Yes |
rpl_semi_sync_master_enabled | Yes | Global | Yes | ||
rpl_semi_sync_master_timeout | Yes | Global | Yes | ||
rpl_semi_sync_master_trace_level | Yes | Global | Yes | ||
rpl_semi_sync_master_wait_for_slave_count | Yes | Global | Yes | ||
rpl_semi_sync_master_wait_no_slave | Yes | Global | Yes | ||
rpl_semi_sync_master_wait_point | Yes | Global | Yes | ||
rpl_semi_sync_slave_enabled | Yes | Global | Yes | ||
rpl_semi_sync_slave_trace_level | Yes | Global | Yes | ||
rpl_stop_slave_timeout | Yes | Yes | Yes | Global | Yes |
schema_definition_cache | Yes | Yes | Yes | Global | Yes |
secure-auth | Yes | Yes | Yes | ||
- Variable: secure_auth | Yes | Global | Yes | ||
secure-file-priv | Yes | Yes | No | ||
- Variable: secure_file_priv | Yes | Global | No | ||
server-id | Yes | Yes | Yes | ||
- Variable: server_id | Yes | Global | Yes | ||
server_uuid | Yes | Global | No | ||
session_track_gtids | Yes | Yes | Yes | Both | Yes |
session_track_schema | Yes | Yes | Yes | Both | Yes |
session_track_state_change | Yes | Yes | Yes | Both | Yes |
session_track_system_variables | Yes | Yes | Yes | Both | Yes |
sha256_password_auto_generate_rsa_keys | Yes | Yes | Yes | Global | No |
sha256_password_private_key_path | Yes | Yes | Yes | Global | No |
sha256_password_proxy_users | Yes | Yes | Yes | Global | Yes |
sha256_password_public_key_path | Yes | Yes | Yes | Global | No |
shared_memory | Yes | Yes | Yes | Global | No |
shared_memory_base_name | Yes | Yes | Yes | Global | No |
show_compatibility_56 | Yes | Yes | Yes | Global | Yes |
show_create_table_verbosity | Yes | Yes | Yes | Both | Yes |
show_old_temporals | Yes | Yes | Yes | Both | Yes |
simplified_binlog_gtid_recovery | Yes | Yes | Yes | Global | No |
skip_external_locking | Yes | Yes | Yes | Global | No |
skip-name-resolve | Yes | Yes | No | ||
- Variable: skip_name_resolve | Yes | Global | No | ||
skip-networking | Yes | Yes | No | ||
- Variable: skip_networking | Yes | Global | No | ||
skip-show-database | Yes | Yes | No | ||
- Variable: skip_show_database | Yes | Global | No | ||
slave_allow_batching | Yes | Yes | Yes | Global | Yes |
slave_checkpoint_group | Yes | Yes | Yes | Global | Yes |
slave_checkpoint_period | Yes | Yes | Yes | Global | Yes |
slave_compressed_protocol | Yes | Yes | Yes | Global | Yes |
slave_exec_mode | Yes | Yes | Yes | Global | Yes |
slave-load-tmpdir | Yes | Yes | No | ||
- Variable: slave_load_tmpdir | Yes | Global | No | ||
slave_max_allowed_packet | Yes | Global | Yes | ||
slave-net-timeout | Yes | Yes | Yes | ||
- Variable: slave_net_timeout | Yes | Global | Yes | ||
slave_parallel_type | Yes | Global | Yes | ||
slave_parallel_workers | Yes | Yes | Global | Yes | |
slave_pending_jobs_size_max | Yes | Yes | Global | Yes | |
slave_preserve_commit_order | Yes | Yes | Global | Yes | |
slave_rows_search_algorithms | Yes | Global | Yes | ||
slave-skip-errors | Yes | Yes | No | ||
- Variable: slave_skip_errors | Yes | Global | No | ||
slave_sql_verify_checksum | Yes | Global | Yes | ||
slave_transaction_retries | Yes | Yes | Yes | Global | Yes |
slave_type_conversions | Yes | Yes | Yes | Global | No |
slow_launch_time | Yes | Yes | Yes | Global | Yes |
slow-query-log | Yes | Yes | Yes | ||
- Variable: slow_query_log | Yes | Global | Yes | ||
slow_query_log_file | Yes | Yes | Yes | Global | Yes |
socket | Yes | Yes | Yes | Global | No |
sort_buffer_size | Yes | Yes | Yes | Both | Yes |
sql_auto_is_null | Yes | Both | Yes | ||
sql_big_selects | Yes | Both | Yes | ||
sql_buffer_result | Yes | Both | Yes | ||
sql_log_bin | Yes | Session | Yes | ||
sql_log_off | Yes | Both | Yes | ||
sql-mode | Yes | Yes | Yes | ||
- Variable: sql_mode | Yes | Both | Yes | ||
sql_notes | Yes | Both | Yes | ||
sql_quote_show_create | Yes | Both | Yes | ||
sql_require_primary_key | Yes | Yes | Yes | Both | Yes |
sql_safe_updates | Yes | Both | Yes | ||
sql_select_limit | Yes | Both | Yes | ||
sql_slave_skip_counter | Yes | Global | Yes | ||
sql_warnings | Yes | Both | Yes | ||
ssl-ca | Yes | Yes | No | ||
- Variable: ssl_ca | Yes | Global | No | ||
ssl-capath | Yes | Yes | No | ||
- Variable: ssl_capath | Yes | Global | No | ||
ssl-cert | Yes | Yes | No | ||
- Variable: ssl_cert | Yes | Global | No | ||
ssl-cipher | Yes | Yes | No | ||
- Variable: ssl_cipher | Yes | Global | No | ||
ssl-crl | Yes | Yes | No | ||
- Variable: ssl_crl | Yes | Global | No | ||
ssl-crlpath | Yes | Yes | No | ||
- Variable: ssl_crlpath | Yes | Global | No | ||
ssl_fips_mode | Yes | Yes | Yes | Global | Yes |
ssl-key | Yes | Yes | No | ||
- Variable: ssl_key | Yes | Global | No | ||
stored_program_cache | Yes | Yes | Yes | Global | Yes |
stored_program_definition_cache | Yes | Yes | Yes | Global | Yes |
super_read_only | Yes | Yes | Yes | Global | Yes |
sync_binlog | Yes | Yes | Yes | Global | Yes |
sync_master_info | Yes | Yes | Yes | Global | Yes |
sync_relay_log | Yes | Yes | Yes | Global | Yes |
sync_relay_log_info | Yes | Yes | Yes | Global | Yes |
syseventlog.facility | Yes | Yes | Yes | Global | Yes |
syseventlog.include_pid | Yes | Yes | Yes | Global | Yes |
syseventlog.tag | Yes | Yes | Yes | Global | Yes |
system_time_zone | Yes | Global | No | ||
table_definition_cache | Yes | Global | Yes | ||
table_open_cache | Yes | Global | Yes | ||
table_open_cache_instances | Yes | Global | No | ||
tablespace_definition_cache | Yes | Yes | Yes | Global | Yes |
temptable_max_ram | Yes | Yes | Yes | Global | Yes |
thread_cache_size | Yes | Yes | Yes | Global | Yes |
thread_handling | Yes | Yes | Yes | Global | No |
thread_pool_algorithm | Yes | Yes | Yes | Global | No |
thread_pool_high_priority_connection | Yes | Yes | Yes | Both | Yes |
thread_pool_max_unused_threads | Yes | Yes | Yes | Global | Yes |
thread_pool_prio_kickup_timer | Yes | Yes | Yes | Both | Yes |
thread_pool_size | Yes | Yes | Yes | Global | No |
thread_pool_stall_limit | Yes | Yes | Yes | Global | Yes |
thread_stack | Yes | Yes | Yes | Global | No |
time_format | Yes | Global | No | ||
time_zone | Yes | Both | Yes | ||
timestamp | Yes | Session | Yes | ||
tls_version | Yes | Yes | Yes | Global | No |
tmp_table_size | Yes | Yes | Yes | Both | Yes |
tmpdir | Yes | Yes | Yes | Global | No |
transaction_alloc_block_size | Yes | Yes | Yes | Both | Yes |
transaction_allow_batching | Yes | Session | Yes | ||
transaction-isolation | Yes | Yes | Yes | ||
- Variable: transaction_isolation | Yes | Both | Yes | ||
transaction_prealloc_size | Yes | Yes | Yes | Both | Yes |
transaction-read-only | Yes | Yes | Yes | ||
- Variable: transaction_read_only | Yes | Both | Yes | ||
transaction_write_set_extraction | Yes | Yes | Both | Yes | |
tx_isolation | Yes | Both | Yes | ||
tx_read_only | Yes | Both | Yes | ||
unique_checks | Yes | Both | Yes | ||
updatable_views_with_limit | Yes | Yes | Yes | Both | Yes |
use_secondary_engine | Yes | Session | Yes | ||
validate_password_check_user_name | Yes | Yes | Yes | Global | Yes |
validate_password_dictionary_file | Yes | Global | Yes | ||
validate_password_length | Yes | Global | Yes | ||
validate_password_mixed_case_count | Yes | Global | Yes | ||
validate_password_number_count | Yes | Global | Yes | ||
validate_password_policy | Yes | Global | Yes | ||
validate_password_special_char_count | Yes | Global | Yes | ||
validate_password.check_user_name | Yes | Yes | Yes | Global | Yes |
validate_password.dictionary_file | Yes | Global | Yes | ||
validate_password.length | Yes | Global | Yes | ||
validate_password.mixed_case_count | Yes | Global | Yes | ||
validate_password.number_count | Yes | Global | Yes | ||
validate_password.policy | Yes | Global | Yes | ||
validate_password.special_char_count | Yes | Global | Yes | ||
validate_user_plugins | Yes | Global | No | ||
version | Yes | Global | No | ||
version_comment | Yes | Global | No | ||
version_compile_machine | Yes | Global | No | ||
version_compile_os | Yes | Global | No | ||
version_compile_zlib | Yes | Global | No | ||
version_tokens_session | Yes | Yes | Yes | Both | Yes |
version_tokens_session_number | Yes | Yes | Yes | Both | No |
wait_timeout | Yes | Yes | Yes | Both | Yes |
warning_count | Yes | Session | No | ||
windowing_use_high_precision | Yes | Yes | Yes | Both | Yes |
Notes:
1. This option is dynamic, but only the server should set this information. You should not set the value of this variable manually.
The following table provides a list of all the status variables
applicable within mysqld
.
The table lists each variable's data type and scope. Where appropriate, a direct link to further information on the item as available.
Table 5.3 Status Variable Summary
Variable Name | Variable Type | Variable Scope |
---|---|---|
Aborted_clients |
integer | GLOBAL |
Aborted_connects |
integer | GLOBAL |
Acl_cache_items_count |
GLOBAL |
|
Audit_log_current_size |
integer | GLOBAL |
Audit_log_event_max_drop_size |
integer | GLOBAL |
Audit_log_events |
integer | GLOBAL |
Audit_log_events_filtered |
integer | GLOBAL |
Audit_log_events_lost |
integer | GLOBAL |
Audit_log_events_written |
integer | GLOBAL |
Audit_log_total_size |
integer | GLOBAL |
Audit_log_write_waits |
integer | GLOBAL |
Binlog_cache_disk_use |
integer | GLOBAL |
Binlog_cache_use |
integer | GLOBAL |
Binlog_stmt_cache_disk_use |
integer | GLOBAL |
Binlog_stmt_cache_use |
integer | GLOBAL |
Bytes_received |
integer | GLOBAL | SESSION |
Bytes_sent |
integer | GLOBAL | SESSION |
Caching_sha2_password_rsa_public_key |
GLOBAL |
|
Com_admin_commands |
integer | GLOBAL | SESSION |
Com_alter_db |
integer | GLOBAL | SESSION |
Com_alter_event |
integer | GLOBAL | SESSION |
Com_alter_function |
integer | GLOBAL | SESSION |
Com_alter_procedure |
integer | GLOBAL | SESSION |
Com_alter_resource_group |
GLOBAL |
|
Com_alter_server |
integer | GLOBAL | SESSION |
Com_alter_table |
integer | GLOBAL | SESSION |
Com_alter_tablespace |
integer | GLOBAL | SESSION |
Com_alter_user |
integer | GLOBAL | SESSION |
Com_alter_user_default_role |
GLOBAL |
|
Com_analyze |
integer | GLOBAL | SESSION |
Com_assign_to_keycache |
integer | GLOBAL | SESSION |
Com_begin |
integer | GLOBAL | SESSION |
Com_binlog |
integer | GLOBAL | SESSION |
Com_call_procedure |
integer | GLOBAL | SESSION |
Com_change_db |
integer | GLOBAL | SESSION |
Com_change_master |
integer | GLOBAL | SESSION |
Com_change_repl_filter |
integer | GLOBAL | SESSION |
Com_check |
integer | GLOBAL | SESSION |
Com_checksum |
integer | GLOBAL | SESSION |
Com_commit |
integer | GLOBAL | SESSION |
Com_create_db |
integer | GLOBAL | SESSION |
Com_create_event |
integer | GLOBAL | SESSION |
Com_create_function |
integer | GLOBAL | SESSION |
Com_create_index |
integer | GLOBAL | SESSION |
Com_create_procedure |
integer | GLOBAL | SESSION |
Com_create_resource_group |
GLOBAL |
|
Com_create_role |
GLOBAL |
|
Com_create_server |
integer | GLOBAL | SESSION |
Com_create_table |
integer | GLOBAL | SESSION |
Com_create_trigger |
integer | GLOBAL | SESSION |
Com_create_udf |
integer | GLOBAL | SESSION |
Com_create_user |
integer | GLOBAL | SESSION |
Com_create_view |
integer | GLOBAL | SESSION |
Com_dealloc_sql |
integer | GLOBAL | SESSION |
Com_delete |
integer | GLOBAL | SESSION |
Com_delete_multi |
integer | GLOBAL | SESSION |
Com_do |
integer | GLOBAL | SESSION |
Com_drop_db |
integer | GLOBAL | SESSION |
Com_drop_event |
integer | GLOBAL | SESSION |
Com_drop_function |
integer | GLOBAL | SESSION |
Com_drop_index |
integer | GLOBAL | SESSION |
Com_drop_procedure |
integer | GLOBAL | SESSION |
Com_drop_resource_group |
GLOBAL |
|
Com_drop_role |
GLOBAL |
|
Com_drop_server |
integer | GLOBAL | SESSION |
Com_drop_table |
integer | GLOBAL | SESSION |
Com_drop_trigger |
integer | GLOBAL | SESSION |
Com_drop_user |
integer | GLOBAL | SESSION |
Com_drop_view |
integer | GLOBAL | SESSION |
Com_empty_query |
integer | GLOBAL | SESSION |
Com_execute_sql |
integer | GLOBAL | SESSION |
Com_explain_other |
integer | GLOBAL | SESSION |
Com_flush |
integer | GLOBAL | SESSION |
Com_get_diagnostics |
integer | GLOBAL | SESSION |
Com_grant |
integer | GLOBAL | SESSION |
Com_grant_roles |
GLOBAL |
|
Com_group_replication_start |
GLOBAL |
|
Com_group_replication_stop |
GLOBAL |
|
Com_ha_close |
integer | GLOBAL | SESSION |
Com_ha_open |
integer | GLOBAL | SESSION |
Com_ha_read |
integer | GLOBAL | SESSION |
Com_help |
integer | GLOBAL | SESSION |
Com_insert |
integer | GLOBAL | SESSION |
Com_insert_select |
integer | GLOBAL | SESSION |
Com_install_component |
GLOBAL |
|
Com_install_plugin |
integer | GLOBAL | SESSION |
Com_kill |
integer | GLOBAL | SESSION |
Com_load |
integer | GLOBAL | SESSION |
Com_lock_tables |
integer | GLOBAL | SESSION |
Com_optimize |
integer | GLOBAL | SESSION |
Com_preload_keys |
integer | GLOBAL | SESSION |
Com_prepare_sql |
integer | GLOBAL | SESSION |
Com_purge |
integer | GLOBAL | SESSION |
Com_purge_before_date |
integer | GLOBAL | SESSION |
Com_release_savepoint |
integer | GLOBAL | SESSION |
Com_rename_table |
integer | GLOBAL | SESSION |
Com_rename_user |
integer | GLOBAL | SESSION |
Com_repair |
integer | GLOBAL | SESSION |
Com_replace |
integer | GLOBAL | SESSION |
Com_replace_select |
integer | GLOBAL | SESSION |
Com_reset |
integer | GLOBAL | SESSION |
Com_resignal |
integer | GLOBAL | SESSION |
Com_revoke |
integer | GLOBAL | SESSION |
Com_revoke_all |
integer | GLOBAL | SESSION |
Com_revoke_roles |
GLOBAL |
|
Com_rollback |
integer | GLOBAL | SESSION |
Com_rollback_to_savepoint |
integer | GLOBAL | SESSION |
Com_savepoint |
integer | GLOBAL | SESSION |
Com_select |
integer | GLOBAL | SESSION |
Com_set_option |
integer | GLOBAL | SESSION |
Com_set_resource_group |
GLOBAL |
|
Com_set_role |
GLOBAL |
|
Com_show_authors |
integer | GLOBAL | SESSION |
Com_show_binlog_events |
integer | GLOBAL | SESSION |
Com_show_binlogs |
integer | GLOBAL | SESSION |
Com_show_charsets |
integer | GLOBAL | SESSION |
Com_show_collations |
integer | GLOBAL | SESSION |
Com_show_contributors |
integer | GLOBAL | SESSION |
Com_show_create_db |
integer | GLOBAL | SESSION |
Com_show_create_event |
integer | GLOBAL | SESSION |
Com_show_create_func |
integer | GLOBAL | SESSION |
Com_show_create_proc |
integer | GLOBAL | SESSION |
Com_show_create_table |
integer | GLOBAL | SESSION |
Com_show_create_trigger |
integer | GLOBAL | SESSION |
Com_show_create_user |
integer | GLOBAL | SESSION |
Com_show_databases |
integer | GLOBAL | SESSION |
Com_show_engine_logs |
integer | GLOBAL | SESSION |
Com_show_engine_mutex |
integer | GLOBAL | SESSION |
Com_show_engine_status |
integer | GLOBAL | SESSION |
Com_show_errors |
integer | GLOBAL | SESSION |
Com_show_events |
integer | GLOBAL | SESSION |
Com_show_fields |
integer | GLOBAL | SESSION |
Com_show_function_code |
integer | GLOBAL | SESSION |
Com_show_function_status |
integer | GLOBAL | SESSION |
Com_show_grants |
integer | GLOBAL | SESSION |
Com_show_keys |
integer | GLOBAL | SESSION |
Com_show_master_status |
integer | GLOBAL | SESSION |
Com_show_ndb_status |
integer | GLOBAL | SESSION |
Com_show_new_master |
integer | GLOBAL | SESSION |
Com_show_open_tables |
integer | GLOBAL | SESSION |
Com_show_plugins |
integer | GLOBAL | SESSION |
Com_show_privileges |
integer | GLOBAL | SESSION |
Com_show_procedure_code |
integer | GLOBAL | SESSION |
Com_show_procedure_status |
integer | GLOBAL | SESSION |
Com_show_processlist |
integer | GLOBAL | SESSION |
Com_show_profile |
integer | GLOBAL | SESSION |
Com_show_profiles |
integer | GLOBAL | SESSION |
Com_show_relaylog_events |
integer | GLOBAL | SESSION |
Com_show_slave_hosts |
integer | GLOBAL | SESSION |
Com_show_slave_status |
integer | GLOBAL | SESSION |
Com_show_slave_status_nonblocking |
integer | GLOBAL | SESSION |
Com_show_status |
integer | GLOBAL | SESSION |
Com_show_storage_engines |
integer | GLOBAL | SESSION |
Com_show_table_status |
integer | GLOBAL | SESSION |
Com_show_tables |
integer | GLOBAL | SESSION |
Com_show_triggers |
integer | GLOBAL | SESSION |
Com_show_variables |
integer | GLOBAL | SESSION |
Com_show_warnings |
integer | GLOBAL | SESSION |
Com_shutdown |
integer | GLOBAL | SESSION |
Com_signal |
integer | GLOBAL | SESSION |
Com_slave_start |
integer | GLOBAL | SESSION |
Com_slave_stop |
integer | GLOBAL | SESSION |
Com_stmt_close |
integer | GLOBAL | SESSION |
Com_stmt_execute |
integer | GLOBAL | SESSION |
Com_stmt_fetch |
integer | GLOBAL | SESSION |
Com_stmt_prepare |
integer | GLOBAL | SESSION |
Com_stmt_reprepare |
integer | GLOBAL | SESSION |
Com_stmt_reset |
integer | GLOBAL | SESSION |
Com_stmt_send_long_data |
integer | GLOBAL | SESSION |
Com_truncate |
integer | GLOBAL | SESSION |
Com_uninstall_component |
GLOBAL |
|
Com_uninstall_plugin |
integer | GLOBAL | SESSION |
Com_unlock_tables |
integer | GLOBAL | SESSION |
Com_update |
integer | GLOBAL | SESSION |
Com_update_multi |
integer | GLOBAL | SESSION |
Com_xa_commit |
integer | GLOBAL | SESSION |
Com_xa_end |
integer | GLOBAL | SESSION |
Com_xa_prepare |
integer | GLOBAL | SESSION |
Com_xa_recover |
integer | GLOBAL | SESSION |
Com_xa_rollback |
integer | GLOBAL | SESSION |
Com_xa_start |
integer | GLOBAL | SESSION |
Compression |
integer | SESSION |
Connection_control_delay_generated |
GLOBAL |
|
Connection_errors_accept |
integer | GLOBAL |
Connection_errors_internal |
integer | GLOBAL |
Connection_errors_max_connections |
integer | GLOBAL |
Connection_errors_peer_address |
integer | GLOBAL |
Connection_errors_select |
integer | GLOBAL |
Connection_errors_tcpwrap |
integer | GLOBAL |
Connections |
integer | GLOBAL |
Created_tmp_disk_tables |
integer | GLOBAL | SESSION |
Created_tmp_files |
integer | GLOBAL |
Created_tmp_tables |
integer | GLOBAL | SESSION |
Delayed_errors |
integer | GLOBAL |
Delayed_insert_threads |
integer | GLOBAL |
Delayed_writes |
integer | GLOBAL |
dragnet.Status |
string | GLOBAL |
Firewall_access_denied |
integer | GLOBAL |
Firewall_access_granted |
integer | GLOBAL |
Firewall_cached_entries |
integer | GLOBAL |
Flush_commands |
integer | GLOBAL |
group_replication_primary_member |
string | GLOBAL |
Handler_commit |
integer | GLOBAL | SESSION |
Handler_delete |
integer | GLOBAL | SESSION |
Handler_external_lock |
integer | GLOBAL | SESSION |
Handler_mrr_init |
integer | GLOBAL | SESSION |
Handler_prepare |
integer | GLOBAL | SESSION |
Handler_read_first |
integer | GLOBAL | SESSION |
Handler_read_key |
integer | GLOBAL | SESSION |
Handler_read_last |
integer | GLOBAL | SESSION |
Handler_read_next |
integer | GLOBAL | SESSION |
Handler_read_prev |
integer | GLOBAL | SESSION |
Handler_read_rnd |
integer | GLOBAL | SESSION |
Handler_read_rnd_next |
integer | GLOBAL | SESSION |
Handler_rollback |
integer | GLOBAL | SESSION |
Handler_savepoint |
integer | GLOBAL | SESSION |
Handler_savepoint_rollback |
integer | GLOBAL | SESSION |
Handler_update |
integer | GLOBAL | SESSION |
Handler_write |
integer | GLOBAL | SESSION |
Innodb_available_undo_logs |
integer | GLOBAL |
Innodb_buffer_pool_bytes_data |
integer | GLOBAL |
Innodb_buffer_pool_bytes_dirty |
integer | GLOBAL |
Innodb_buffer_pool_dump_status |
string | GLOBAL |
Innodb_buffer_pool_load_status |
string | GLOBAL |
Innodb_buffer_pool_pages_data |
integer | GLOBAL |
Innodb_buffer_pool_pages_dirty |
integer | GLOBAL |
Innodb_buffer_pool_pages_flushed |
integer | GLOBAL |
Innodb_buffer_pool_pages_free |
integer | GLOBAL |
Innodb_buffer_pool_pages_latched |
integer | GLOBAL |
Innodb_buffer_pool_pages_misc |
integer | GLOBAL |
Innodb_buffer_pool_pages_total |
integer | GLOBAL |
Innodb_buffer_pool_read_ahead |
integer | GLOBAL |
Innodb_buffer_pool_read_ahead_evicted |
integer | GLOBAL |
Innodb_buffer_pool_read_ahead_rnd |
integer | GLOBAL |
Innodb_buffer_pool_read_requests |
integer | GLOBAL |
Innodb_buffer_pool_reads |
integer | GLOBAL |
Innodb_buffer_pool_resize_status |
string | GLOBAL |
Innodb_buffer_pool_wait_free |
integer | GLOBAL |
Innodb_buffer_pool_write_requests |
integer | GLOBAL |
Innodb_data_fsyncs |
integer | GLOBAL |
Innodb_data_pending_fsyncs |
integer | GLOBAL |
Innodb_data_pending_reads |
integer | GLOBAL |
Innodb_data_pending_writes |
integer | GLOBAL |
Innodb_data_read |
integer | GLOBAL |
Innodb_data_reads |
integer | GLOBAL |
Innodb_data_writes |
integer | GLOBAL |
Innodb_data_written |
integer | GLOBAL |
Innodb_dblwr_pages_written |
integer | GLOBAL |
Innodb_dblwr_writes |
integer | GLOBAL |
Innodb_have_atomic_builtins |
integer | GLOBAL |
Innodb_log_waits |
integer | GLOBAL |
Innodb_log_write_requests |
integer | GLOBAL |
Innodb_log_writes |
integer | GLOBAL |
Innodb_num_open_files |
integer | GLOBAL |
Innodb_os_log_fsyncs |
integer | GLOBAL |
Innodb_os_log_pending_fsyncs |
integer | GLOBAL |
Innodb_os_log_pending_writes |
integer | GLOBAL |
Innodb_os_log_written |
integer | GLOBAL |
Innodb_page_size |
integer | GLOBAL |
Innodb_pages_created |
integer | GLOBAL |
Innodb_pages_read |
integer | GLOBAL |
Innodb_pages_written |
integer | GLOBAL |
Innodb_row_lock_current_waits |
integer | GLOBAL |
Innodb_row_lock_time |
integer | GLOBAL |
Innodb_row_lock_time_avg |
integer | GLOBAL |
Innodb_row_lock_time_max |
integer | GLOBAL |
Innodb_row_lock_waits |
integer | GLOBAL |
Innodb_rows_deleted |
integer | GLOBAL |
Innodb_rows_inserted |
integer | GLOBAL |
Innodb_rows_read |
integer | GLOBAL |
Innodb_rows_updated |
integer | GLOBAL |
Innodb_truncated_status_writes |
integer | GLOBAL |
Key_blocks_not_flushed |
integer | GLOBAL |
Key_blocks_unused |
integer | GLOBAL |
Key_blocks_used |
integer | GLOBAL |
Key_read_requests |
integer | GLOBAL |
Key_reads |
integer | GLOBAL |
Key_write_requests |
integer | GLOBAL |
Key_writes |
integer | GLOBAL |
Last_query_cost |
numeric | SESSION |
Last_query_partial_plans |
integer | SESSION |
Locked_connects |
integer | GLOBAL |
Max_execution_time_exceeded |
integer | GLOBAL | SESSION |
Max_execution_time_set |
integer | GLOBAL | SESSION |
Max_execution_time_set_failed |
integer | GLOBAL | SESSION |
Max_used_connections |
integer | GLOBAL |
Max_used_connections_time |
datetime | GLOBAL |
mecab_charset |
string | GLOBAL |
Mysqlx_aborted_clients |
integer | GLOBAL |
Mysqlx_address |
string | GLOBAL |
Mysqlx_bytes_received |
integer | GLOBAL | SESSION |
Mysqlx_bytes_sent |
integer | GLOBAL | SESSION |
Mysqlx_connection_accept_errors |
integer | GLOBAL | SESSION |
Mysqlx_connection_errors |
integer | GLOBAL | SESSION |
Mysqlx_connections_accepted |
integer | GLOBAL |
Mysqlx_connections_closed |
integer | GLOBAL |
Mysqlx_connections_rejected |
integer | GLOBAL |
Mysqlx_crud_create_view |
integer | GLOBAL | SESSION |
Mysqlx_crud_delete |
integer | GLOBAL | SESSION |
Mysqlx_crud_drop_view |
integer | GLOBAL | SESSION |
Mysqlx_crud_find |
integer | GLOBAL | SESSION |
Mysqlx_crud_insert |
integer | GLOBAL | SESSION |
Mysqlx_crud_modify_view |
integer | GLOBAL | SESSION |
Mysqlx_crud_update |
integer | GLOBAL | SESSION |
Mysqlx_errors_sent |
integer | GLOBAL | SESSION |
Mysqlx_errors_unknown_message_type |
integer | GLOBAL | SESSION |
Mysqlx_expect_close |
integer | GLOBAL | SESSION |
Mysqlx_expect_open |
integer | GLOBAL | SESSION |
Mysqlx_init_error |
integer | GLOBAL | SESSION |
Mysqlx_notice_other_sent |
integer | GLOBAL | SESSION |
Mysqlx_notice_warning_sent |
integer | GLOBAL | SESSION |
Mysqlx_port |
string | GLOBAL |
Mysqlx_rows_sent |
integer | GLOBAL | SESSION |
Mysqlx_sessions |
integer | GLOBAL |
Mysqlx_sessions_accepted |
integer | GLOBAL |
Mysqlx_sessions_closed |
integer | GLOBAL |
Mysqlx_sessions_fatal_error |
integer | GLOBAL |
Mysqlx_sessions_killed |
integer | GLOBAL |
Mysqlx_sessions_rejected |
integer | GLOBAL |
Mysqlx_socket |
string | GLOBAL |
Mysqlx_ssl_accept_renegotiates |
integer | GLOBAL |
Mysqlx_ssl_accepts |
integer | GLOBAL |
Mysqlx_ssl_active |
integer | GLOBAL | SESSION |
Mysqlx_ssl_cipher |
integer | GLOBAL | SESSION |
Mysqlx_ssl_cipher_list |
integer | GLOBAL | SESSION |
Mysqlx_ssl_ctx_verify_depth |
integer | GLOBAL | SESSION |
Mysqlx_ssl_ctx_verify_mode |
integer | GLOBAL | SESSION |
Mysqlx_ssl_finished_accepts |
integer | GLOBAL |
Mysqlx_ssl_server_not_after |
integer | GLOBAL |
Mysqlx_ssl_server_not_before |
integer | GLOBAL |
Mysqlx_ssl_verify_depth |
integer | GLOBAL |
Mysqlx_ssl_verify_mode |
integer | GLOBAL |
Mysqlx_ssl_version |
integer | GLOBAL | SESSION |
Mysqlx_stmt_create_collection |
integer | GLOBAL | SESSION |
Mysqlx_stmt_create_collection_index |
integer | GLOBAL | SESSION |
Mysqlx_stmt_disable_notices |
integer | GLOBAL | SESSION |
Mysqlx_stmt_drop_collection |
integer | GLOBAL | SESSION |
Mysqlx_stmt_drop_collection_index |
integer | GLOBAL | SESSION |
Mysqlx_stmt_enable_notices |
integer | GLOBAL | SESSION |
Mysqlx_stmt_ensure_collection |
string | GLOBAL | SESSION |
Mysqlx_stmt_execute_mysqlx |
integer | GLOBAL | SESSION |
Mysqlx_stmt_execute_sql |
integer | GLOBAL | SESSION |
Mysqlx_stmt_execute_xplugin |
integer | GLOBAL | SESSION |
Mysqlx_stmt_kill_client |
integer | GLOBAL | SESSION |
Mysqlx_stmt_list_clients |
integer | GLOBAL | SESSION |
Mysqlx_stmt_list_notices |
integer | GLOBAL | SESSION |
Mysqlx_stmt_list_objects |
integer | GLOBAL | SESSION |
Mysqlx_stmt_ping |
integer | GLOBAL | SESSION |
Mysqlx_worker_threads |
integer | GLOBAL |
Mysqlx_worker_threads_active |
integer | GLOBAL |
Ndb_api_bytes_received_count |
integer | GLOBAL |
Ndb_api_bytes_received_count_session |
integer | SESSION |
Ndb_api_bytes_received_count_slave |
integer | GLOBAL |
Ndb_api_bytes_sent_count |
integer | GLOBAL |
Ndb_api_bytes_sent_count_slave |
integer | GLOBAL |
Ndb_api_event_bytes_count_injector |
integer | GLOBAL |
Ndb_api_event_data_count_injector |
integer | GLOBAL |
Ndb_api_event_nondata_count_injector |
integer | GLOBAL |
Ndb_api_pk_op_count |
integer | GLOBAL |
Ndb_api_pk_op_count_session |
integer | SESSION |
Ndb_api_pk_op_count_slave |
integer | GLOBAL |
Ndb_api_pruned_scan_count |
integer | GLOBAL |
Ndb_api_pruned_scan_count_session |
integer | SESSION |
Ndb_api_range_scan_count_slave |
integer | GLOBAL |
Ndb_api_read_row_count |
integer | GLOBAL |
Ndb_api_read_row_count_session |
integer | SESSION |
Ndb_api_scan_batch_count_slave |
integer | GLOBAL |
Ndb_api_table_scan_count |
integer | GLOBAL |
Ndb_api_table_scan_count_session |
integer | SESSION |
Ndb_api_trans_abort_count |
integer | GLOBAL |
Ndb_api_trans_abort_count_session |
integer | SESSION |
Ndb_api_trans_abort_count_slave |
integer | GLOBAL |
Ndb_api_trans_close_count |
integer | GLOBAL |
Ndb_api_trans_close_count_session |
integer | SESSION |
Ndb_api_trans_close_count_slave |
integer | GLOBAL |
Ndb_api_trans_commit_count |
integer | GLOBAL |
Ndb_api_trans_commit_count_session |
integer | SESSION |
Ndb_api_trans_commit_count_slave |
integer | GLOBAL |
Ndb_api_trans_local_read_row_count_slave |
integer | GLOBAL |
Ndb_api_trans_start_count |
integer | GLOBAL |
Ndb_api_trans_start_count_session |
integer | SESSION |
Ndb_api_trans_start_count_slave |
integer | GLOBAL |
Ndb_api_uk_op_count |
integer | GLOBAL |
Ndb_api_uk_op_count_slave |
integer | GLOBAL |
Ndb_api_wait_exec_complete_count |
integer | GLOBAL |
Ndb_api_wait_exec_complete_count_session |
integer | SESSION |
Ndb_api_wait_exec_complete_count_slave |
integer | GLOBAL |
Ndb_api_wait_meta_request_count |
integer | GLOBAL |
Ndb_api_wait_meta_request_count_session |
integer | SESSION |
Ndb_api_wait_nanos_count |
integer | GLOBAL |
Ndb_api_wait_nanos_count_session |
integer | SESSION |
Ndb_api_wait_nanos_count_slave |
integer | GLOBAL |
Ndb_api_wait_scan_result_count |
integer | GLOBAL |
Ndb_api_wait_scan_result_count_session |
integer | SESSION |
Ndb_api_wait_scan_result_count_slave |
integer | GLOBAL |
Ndb_cluster_node_id |
integer | GLOBAL | SESSION |
Ndb_config_from_host |
integer | GLOBAL | SESSION |
Ndb_config_from_port |
integer | GLOBAL | SESSION |
Ndb_conflict_fn_epoch_trans |
integer | GLOBAL |
Ndb_conflict_fn_max |
integer | GLOBAL |
Ndb_conflict_fn_old |
integer | GLOBAL |
Ndb_conflict_trans_detect_iter_count |
integer | GLOBAL |
Ndb_conflict_trans_row_reject_count |
integer | GLOBAL |
Ndb_last_commit_epoch_server |
integer | GLOBAL |
Ndb_last_commit_epoch_session |
integer | SESSION |
Ndb_number_of_data_nodes |
integer | GLOBAL |
Ndb_pushed_queries_defined |
integer | GLOBAL |
Ndb_pushed_queries_executed |
integer | GLOBAL |
Ndb_scan_count |
integer | GLOBAL |
Not_flushed_delayed_rows |
integer | GLOBAL |
Ongoing_anonymous_gtid_violating_transaction_count |
integer | GLOBAL |
Ongoing_anonymous_transaction_count |
integer | GLOBAL |
Ongoing_automatic_gtid_violating_transaction_count |
integer | GLOBAL |
Open_files |
integer | GLOBAL |
Open_streams |
integer | GLOBAL |
Open_table_definitions |
integer | GLOBAL |
Open_tables |
integer | GLOBAL | SESSION |
Opened_files |
integer | GLOBAL |
Opened_table_definitions |
integer | GLOBAL | SESSION |
Opened_tables |
integer | GLOBAL | SESSION |
original_commit_timestamp |
numeric | SESSION |
Performance_schema_accounts_lost |
integer | GLOBAL |
Performance_schema_cond_classes_lost |
integer | GLOBAL |
Performance_schema_cond_instances_lost |
integer | GLOBAL |
Performance_schema_digest_lost |
integer | GLOBAL |
Performance_schema_file_classes_lost |
integer | GLOBAL |
Performance_schema_file_handles_lost |
integer | GLOBAL |
Performance_schema_file_instances_lost |
integer | GLOBAL |
Performance_schema_hosts_lost |
integer | GLOBAL |
Performance_schema_index_stat_lost |
integer | GLOBAL |
Performance_schema_locker_lost |
integer | GLOBAL |
Performance_schema_memory_classes_lost |
integer | GLOBAL |
Performance_schema_metadata_lock_lost |
integer | GLOBAL |
Performance_schema_mutex_classes_lost |
integer | GLOBAL |
Performance_schema_mutex_instances_lost |
integer | GLOBAL |
Performance_schema_nested_statement_lost |
integer | GLOBAL |
Performance_schema_prepared_statements_lost |
integer | GLOBAL |
Performance_schema_program_lost |
integer | GLOBAL |
Performance_schema_rwlock_classes_lost |
integer | GLOBAL |
Performance_schema_rwlock_instances_lost |
integer | GLOBAL |
Performance_schema_session_connect_attrs_longest_seen |
GLOBAL |
|
Performance_schema_session_connect_attrs_lost |
integer | GLOBAL |
Performance_schema_socket_classes_lost |
integer | GLOBAL |
Performance_schema_socket_instances_lost |
integer | GLOBAL |
Performance_schema_stage_classes_lost |
integer | GLOBAL |
Performance_schema_statement_classes_lost |
integer | GLOBAL |
Performance_schema_table_handles_lost |
integer | GLOBAL |
Performance_schema_table_instances_lost |
integer | GLOBAL |
Performance_schema_table_lock_stat_lost |
integer | GLOBAL |
Performance_schema_thread_classes_lost |
integer | GLOBAL |
Performance_schema_thread_instances_lost |
integer | GLOBAL |
Performance_schema_users_lost |
integer | GLOBAL |
Prepared_stmt_count |
integer | GLOBAL |
Qcache_free_blocks |
integer | GLOBAL |
Qcache_free_memory |
integer | GLOBAL |
Qcache_hits |
integer | GLOBAL |
Qcache_inserts |
integer | GLOBAL |
Qcache_lowmem_prunes |
integer | GLOBAL |
Qcache_not_cached |
integer | GLOBAL |
Qcache_queries_in_cache |
integer | GLOBAL |
Qcache_total_blocks |
integer | GLOBAL |
Queries |
integer | GLOBAL | SESSION |
Questions |
integer | GLOBAL | SESSION |
Rewriter_number_loaded_rules |
integer | GLOBAL |
Rewriter_number_reloads |
integer | GLOBAL |
Rewriter_number_rewritten_queries |
integer | GLOBAL |
Rewriter_reload_error |
boolean | GLOBAL |
Rpl_semi_sync_master_clients |
integer | GLOBAL |
Rpl_semi_sync_master_net_avg_wait_time |
integer | GLOBAL |
Rpl_semi_sync_master_net_wait_time |
integer | GLOBAL |
Rpl_semi_sync_master_net_waits |
integer | GLOBAL |
Rpl_semi_sync_master_no_times |
integer | GLOBAL |
Rpl_semi_sync_master_no_tx |
integer | GLOBAL |
Rpl_semi_sync_master_status |
boolean | GLOBAL |
Rpl_semi_sync_master_timefunc_failures |
integer | GLOBAL |
Rpl_semi_sync_master_tx_avg_wait_time |
integer | GLOBAL |
Rpl_semi_sync_master_tx_wait_time |
integer | GLOBAL |
Rpl_semi_sync_master_tx_waits |
integer | GLOBAL |
Rpl_semi_sync_master_wait_pos_backtraverse |
integer | GLOBAL |
Rpl_semi_sync_master_wait_sessions |
integer | GLOBAL |
Rpl_semi_sync_master_yes_tx |
integer | GLOBAL |
Rpl_semi_sync_slave_status |
boolean | GLOBAL |
Rsa_public_key |
string | GLOBAL |
Secondary_engine_execution_count |
GLOBAL | SESSION |
|
Select_full_join |
integer | GLOBAL | SESSION |
Select_full_range_join |
integer | GLOBAL | SESSION |
Select_range |
integer | GLOBAL | SESSION |
Select_range_check |
integer | GLOBAL | SESSION |
Select_scan |
integer | GLOBAL | SESSION |
Slave_heartbeat_period |
numeric | GLOBAL |
Slave_last_heartbeat |
GLOBAL |
|
Slave_open_temp_tables |
integer | GLOBAL |
Slave_received_heartbeats |
GLOBAL |
|
Slave_retried_transactions |
integer | GLOBAL |
Slave_rows_last_search_algorithm_used |
string | GLOBAL |
Slave_running |
GLOBAL |
|
Slow_launch_threads |
integer | GLOBAL | SESSION |
Slow_queries |
integer | GLOBAL | SESSION |
Sort_merge_passes |
integer | GLOBAL | SESSION |
Sort_range |
integer | GLOBAL | SESSION |
Sort_rows |
integer | GLOBAL | SESSION |
Sort_scan |
integer | GLOBAL | SESSION |
Ssl_accept_renegotiates |
integer | GLOBAL |
Ssl_accepts |
integer | GLOBAL |
Ssl_callback_cache_hits |
integer | GLOBAL |
Ssl_cipher |
string | GLOBAL | SESSION |
Ssl_cipher_list |
string | GLOBAL | SESSION |
Ssl_client_connects |
integer | GLOBAL |
Ssl_connect_renegotiates |
integer | GLOBAL |
Ssl_ctx_verify_depth |
integer | GLOBAL |
Ssl_ctx_verify_mode |
integer | GLOBAL |
Ssl_default_timeout |
integer | GLOBAL | SESSION |
Ssl_finished_accepts |
integer | GLOBAL |
Ssl_finished_connects |
integer | GLOBAL |
Ssl_server_not_after |
integer | GLOBAL | SESSION |
Ssl_server_not_before |
integer | GLOBAL | SESSION |
Ssl_session_cache_hits |
integer | GLOBAL |
Ssl_session_cache_misses |
integer | GLOBAL |
Ssl_session_cache_mode |
string | GLOBAL |
Ssl_session_cache_overflows |
integer | GLOBAL |
Ssl_session_cache_size |
integer | GLOBAL |
Ssl_session_cache_timeouts |
integer | GLOBAL |
Ssl_sessions_reused |
integer | GLOBAL | SESSION |
Ssl_used_session_cache_entries |
integer | GLOBAL |
Ssl_verify_depth |
integer | GLOBAL | SESSION |
Ssl_verify_mode |
integer | GLOBAL | SESSION |
Ssl_version |
string | GLOBAL | SESSION |
Table_locks_immediate |
integer | GLOBAL |
Table_locks_waited |
integer | GLOBAL |
Table_open_cache_hits |
integer | GLOBAL | SESSION |
Table_open_cache_misses |
integer | GLOBAL | SESSION |
Table_open_cache_overflows |
integer | GLOBAL | SESSION |
Tc_log_max_pages_used |
integer | GLOBAL |
Tc_log_page_size |
integer | GLOBAL |
Tc_log_page_waits |
integer | GLOBAL |
Threads_cached |
integer | GLOBAL |
Threads_connected |
integer | GLOBAL |
Threads_created |
integer | GLOBAL |
Threads_running |
integer | GLOBAL |
Uptime |
integer | GLOBAL |
Uptime_since_flush_status |
integer | GLOBAL |
validate_password_dictionary_file_last_parsed |
datetime | GLOBAL |
validate_password_dictionary_file_words_count |
integer | GLOBAL |
validate_password.dictionary_file_last_parsed |
datetime | GLOBAL |
validate_password.dictionary_file_words_count |
integer | GLOBAL |
When you start the mysqld server, you can specify program options using any of the methods described in Section 4.2.3, “Specifying Program Options”. The most common methods are to provide options in an option file or on the command line. However, in most cases it is desirable to make sure that the server uses the same options each time it runs. The best way to ensure this is to list them in an option file. See Section 4.2.6, “Using Option Files”. That section also describes option file format and syntax.
mysqld reads options from the
[mysqld]
and [server]
groups. mysqld_safe reads options from the
[mysqld]
, [server]
,
[mysqld_safe]
, and
[safe_mysqld]
groups.
mysql.server reads options from the
[mysqld]
and [mysql.server]
groups.
mysqld accepts many command options. For a brief summary, execute this command:
mysqld --help
To see the full list, use this command:
mysqld --verbose --help
Some of the items in the list are actually system variables that
can be set at server startup. These can be displayed at runtime
using the SHOW VARIABLES
statement.
Some items displayed by the preceding mysqld
command do not appear in SHOW
VARIABLES
output; this is because they are options only
and not system variables.
The following list shows some of the most common server options. Additional options are described in other sections:
Options that affect security: See Section 6.1.4, “Security-Related mysqld Options and Variables”.
SSL-related options: See Section 6.4.2, “Command Options for Encrypted Connections”.
Binary log control options: See Section 5.4.4, “The Binary Log”.
Replication-related options: See Section 17.1.6, “Replication and Binary Logging Options and Variables”.
Options for loading plugins such as pluggable storage engines: See Section 5.6.1, “Installing and Uninstalling Plugins”.
Options specific to particular storage engines: See Section 15.13, “InnoDB Startup Options and System Variables” and Section 16.2.1, “MyISAM Startup Options”.
Some options control the size of buffers or caches. For a given buffer, the server might need to allocate internal data structures. These structures typically are allocated from the total memory allocated to the buffer, and the amount of space required might be platform dependent. This means that when you assign a value to an option that controls a buffer size, the amount of space actually available might differ from the value assigned. In some cases, the amount might be less than the value assigned. It is also possible that the server will adjust a value upward. For example, if you assign a value of 0 to an option for which the minimal value is 1024, the server will set the value to 1024.
Values for buffer sizes, lengths, and stack sizes are given in bytes unless otherwise specified.
Some options take file name values. Unless otherwise specified,
the default file location is the data directory if the value is a
relative path name. To specify the location explicitly, use an
absolute path name. Suppose that the data directory is
/var/mysql/data
. If a file-valued option is
given as a relative path name, it will be located under
/var/mysql/data
. If the value is an absolute
path name, its location is as given by the path name.
You can also set the values of server system variables at server
startup by using variable names as options. To assign a value to a
server system variable, use an option of the form
--
.
For example,
var_name
=value
--sort_buffer_size=384M
sets the
sort_buffer_size
variable to a
value of 384MB.
When you assign a value to a variable, MySQL might automatically correct the value to stay within a given range, or adjust the value to the closest permissible value if only certain values are permitted.
To restrict the maximum value to which a system variable can be
set at runtime with the
SET
statement, specify this maximum by using an option of the form
--maximum-
at server startup.
var_name
=value
You can change the values of most system variables at runtime with
the SET
statement. See Section 13.7.5.1, “SET Syntax for Variable Assignment”.
Section 5.1.7, “Server System Variables”, provides a full description for all variables, and additional information for setting them at server startup and runtime. For information on changing system variables, see Section 5.1.1, “Configuring the Server”.
--help
, -?
Property | Value |
---|---|
Command-Line Format | --help |
Display a short help message and exit. Use both the
--verbose
and
--help
options to see the full
message.
Property | Value |
---|---|
Command-Line Format | --allow-suspicious-udfs |
Type | boolean |
Default Value | FALSE |
This option controls whether user-defined functions that have
only an xxx
symbol for the main function
can be loaded. By default, the option is off and only UDFs
that have at least one auxiliary symbol can be loaded; this
prevents attempts at loading functions from shared object
files other than those containing legitimate UDFs. See
Section 28.4.2.6, “UDF Security Precautions”.
Property | Value |
---|---|
Command-Line Format | --ansi |
Use standard (ANSI) SQL syntax instead of MySQL syntax. For
more precise control over the server SQL mode, use the
--sql-mode
option instead. See
Section 1.8, “MySQL Standards Compliance”, and
Section 5.1.10, “Server SQL Modes”.
--basedir=
,
dir_name
-b
dir_name
Property | Value |
---|---|
Command-Line Format | --basedir=dir_name |
System Variable | basedir |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | directory name |
Default Value (>= 8.0.2) | parent of mysqld installation directory |
Default Value (<= 8.0.1) | configuration-dependent default |
The path to the MySQL installation directory. This option sets
the basedir
system variable.
The server executable determines its own full path name at
startup and uses the parent of the directory in which it is
located as the default
basedir
value. This in turn
enables the server to use that
basedir
when searching for
server-related information such as the
share
directory containing error
messages.
Property | Value |
---|---|
Command-Line Format | --big-tables |
System Variable | big_tables |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
Enable large result sets by saving all temporary sets in files. This option prevents most “table full” errors, but also slows down queries for which in-memory tables would suffice. The server is able to handle large result sets automatically by using memory for small temporary tables and switching to disk tables where necessary.
Property | Value |
---|---|
Command-Line Format | --bind-address=addr |
System Variable | bind_address |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | string |
Default Value | * |
The MySQL server listens on one or more network sockets for
TCP/IP connections. Each socket is bound to one address, but
it is possible for an address to map onto multiple network
interfaces. To specify how the server should listen for TCP/IP
connections, use the
--bind-address
option at server
startup:
Prior to MySQL 8.0.13,
--bind-address
accepts a
single address value, which may specify a single
non-wildcard IP address or host name, or one of the
wildcard address formats that permit listening on multiple
network interfaces (*
,
0.0.0.0
, or ::
).
As of MySQL 8.0.13,
--bind-address
accepts a
single value as just described, or a list of
comma-separated values. When the option names a list of
multiple values, each value must specify a single
non-wildcard IP address or host name; none can specify a
wildcard address format (*
,
0.0.0.0
, or ::
).
IP addresses can be specified as IPv4 or IPv6 addresses. For any option value that is a host name, the server resolves the name to an IP address and binds to that address. If a host name resolves to multiple IP addresses, the server uses the first IPv4 address if there are any, or the first IPv6 address otherwise.
The server treats different types of addresses as follows:
If the address is *
, the server accepts
TCP/IP connections on all server host IPv4 interfaces,
and, if the server host supports IPv6, on all IPv6
interfaces. Use this address to permit both IPv4 and IPv6
connections on all server interfaces. This value is the
default. If the option specifies a list of multiple
values, this value is not permitted.
If the address is 0.0.0.0
, the server
accepts TCP/IP connections on all server host IPv4
interfaces. If the option specifies a list of multiple
values, this value is not permitted.
If the address is ::
, the server
accepts TCP/IP connections on all server host IPv4 and
IPv6 interfaces. If the option specifies a list of
multiple values, this value is not permitted.
If the address is an IPv4-mapped address, the server
accepts TCP/IP connections for that address, in either
IPv4 or IPv6 format. For example, if the server is bound
to ::ffff:127.0.0.1
, clients can
connect using --host=127.0.0.1
or
--host=::ffff:127.0.0.1
.
If the address is a “regular” IPv4 or IPv6
address (such as 127.0.0.1
or
::1
), the server accepts TCP/IP
connections only for that IPv4 or IPv6 address.
If binding to any address fails, the server produces an error and does not start.
Examples:
--bind-address=*
The server listens on all IPv4 or IPv6 addresses, as
specified by the *
wildcard.
--bind-address=198.51.100.20
The server listens only on the
198.51.100.20
IPv4 address.
--bind-address=198.51.100.20,2001:db8:0:f101::1
The server listens on the 198.51.100.20
IPv4 address and the 2001:db8:0:f101::1
IPv6 address.
--bind-address=198.51.100.20,*
This produces an error because wildcard addresses are not
permitted when
--bind-address
names a list
of multiple values.
When --bind-address
names a
single value (wildcard or non-wildcard), the server listens on
a single socket, which for a wildcard address may be bound to
multiple network interfaces. When
--bind-address
names a list of
multiple values, the server listens on one socket per value,
with each socket bound to a single network interface. The
number of sockets is linear with the number of values
specified. Depending on operating system connection-acceptance
efficiency, long value lists might incur a performance penalty
for accepting TCP/IP connections.
If you intend to bind the server to a specific address, be
sure that the mysql.user
grant table
contains an account with administrative privileges that you
can use to connect to that address. Otherwise, you will not be
able to shut down the server. For example, if you bind the
server to *
, you can connect to it using
all existing accounts. But if you bind the server to
::1
, it accepts connections only on that
address. In that case, first make sure that the
'root'@'::1'
account is present in the
mysql.user
table so you can still connect
to the server to shut it down.
--binlog-format={ROW|STATEMENT|MIXED}
Property | Value |
---|---|
Command-Line Format | --binlog-format=format |
System Variable | binlog_format |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value | ROW |
Valid Values |
|
Specify whether to use row-based, statement-based, or mixed replication. Statement-based is the default in MySQL 8.0. See Section 17.2.1, “Replication Formats”.
Under some conditions, changing this variable at runtime is not possible, or causes replication to fail. See Section 5.4.4.2, “Setting The Binary Log Format”, for more information.
Setting the binary logging format without enabling binary
logging sets the
binlog_format
global system
variable and logs a warning.
Property | Value |
---|---|
Command-Line Format | --character-sets-dir=dir_name |
System Variable | character_sets_dir |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | directory name |
The directory where character sets are installed. See Section 10.14, “Character Set Configuration”.
--character-set-client-handshake
Property | Value |
---|---|
Command-Line Format | --character-set-client-handshake |
Type | boolean |
Default Value | TRUE |
Do not ignore character set information sent by the client. To
ignore client information and use the default server character
set, use
--skip-character-set-client-handshake
;
this makes MySQL behave like MySQL 4.0.
--character-set-filesystem=
charset_name
Property | Value |
---|---|
Command-Line Format | --character-set-filesystem=name |
System Variable | character_set_filesystem |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value | binary |
The file system character set. This option sets the
character_set_filesystem
system variable.
--character-set-server=
,
charset_name
-C
charset_name
Property | Value |
---|---|
Command-Line Format | --character-set-server |
System Variable | character_set_server |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value (>= 8.0.1) | utf8mb4 |
Default Value (8.0.0) | latin1 |
Use charset_name
as the default
server character set. See
Section 10.14, “Character Set Configuration”. If you use this
option to specify a nondefault character set, you should also
use --collation-server
to
specify the collation.
--chroot=
,
dir_name
-r
dir_name
Property | Value |
---|---|
Command-Line Format | --chroot=dir_name |
Type | directory name |
Put the mysqld server in a closed
environment during startup by using the
chroot()
system call. This is a recommended
security measure. Use of this option somewhat limits
LOAD DATA
INFILE
and
SELECT ... INTO
OUTFILE
.
--collation-server=
collation_name
Property | Value |
---|---|
Command-Line Format | --collation-server |
System Variable | collation_server |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value (>= 8.0.1) | utf8mb4_0900_ai_ci |
Default Value (8.0.0) | latin1_swedish_ci |
Use collation_name
as the default
server collation. See Section 10.14, “Character Set Configuration”.
Property | Value |
---|---|
Command-Line Format | --console |
Platform Specific | Windows |
(Windows only.) Cause the default error log destination to be the console. This affects log writers that base their own output destination on the default destination. See Section 5.4.2, “The Error Log”. mysqld does not close the console window if this option is used.
--console
takes precedence over
--log-error
if both are given.
Property | Value |
---|---|
Command-Line Format | --core-file |
Type | boolean |
Default Value | OFF |
Write a core file if mysqld dies. The name
and location of the core file is system dependent. On Linux, a
core file named
core.
is
written to the current working directory of the process, which
for mysqld is the data directory.
pid
pid
represents the process ID of
the server process. On macOS, a core file named
core.
is
written to the pid
/cores
directory. On
Solaris, use the coreadm command to specify
where to write the core file and how to name it.
For some systems, to get a core file you must also specify the
--core-file-size
option to
mysqld_safe. See
Section 4.3.2, “mysqld_safe — MySQL Server Startup Script”. On some systems, such as
Solaris, you do not get a core file if you are also using the
--user
option. There might be
additional restrictions or limitations. For example, it might
be necessary to execute ulimit -c unlimited
before starting the server. Consult your system documentation.
--daemonize
,
-D
Property | Value |
---|---|
Command-Line Format | --daemonize[={OFF|ON}] |
Type | boolean |
Default Value | OFF |
This option causes the server to run as a traditional, forking daemon, permitting it to work with operating systems that use systemd for process control. For more information, see Section 2.5.9, “Managing MySQL Server with systemd”.
--daemonize
is mutually
exclusive with --initialize
and
--initialize-insecure
.
If the server is started using the
--daemonize
option and is not connected to a
tty device, a default error logging option of
--log-error=""
is used in the absence of an
explicit logging option, to direct error output to the default
log file.
-D
is a synonym for
--daemonize
.
--datadir=
,
dir_name
-h
dir_name
Property | Value |
---|---|
Command-Line Format | --datadir=dir_name |
System Variable | datadir |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | directory name |
The path to the MySQL server data directory. This option sets
the datadir
system variable.
See the description of that variable.
--debug[=
,
debug_options
]-# [
debug_options
]
Property | Value |
---|---|
Command-Line Format | --debug[=debug_options] |
System Variable | debug |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value (Windows) | d:t:i:O,\mysqld.trace |
Default Value (Unix) | d:t:i:o,/tmp/mysqld.trace |
If MySQL is configured with the
-DWITH_DEBUG=1
CMake option, you can use this option to
get a trace file of what mysqld is doing. A
typical debug_options
string is
d:t:o,
.
The default is file_name
d:t:i:o,/tmp/mysqld.trace
on
Unix and d:t:i:O,\mysqld.trace
on Windows.
Using -DWITH_DEBUG=1
to
configure MySQL with debugging support enables you to use the
--debug="d,parser_debug"
option
when you start the server. This causes the Bison parser that
is used to process SQL statements to dump a parser trace to
the server's standard error output. Typically, this output is
written to the error log.
This option may be given multiple times. Values that begin
with +
or -
are added to
or subtracted from the previous value. For example,
--debug=T
--debug=+P
sets the value to
P:T
.
For more information, see Section 28.5.3, “The DBUG Package”.
Property | Value |
---|---|
Command-Line Format | --debug-sync-timeout[=#] |
Type | integer |
Controls whether the Debug Sync facility for testing and
debugging is enabled. Use of Debug Sync requires that MySQL be
configured with the
-DENABLE_DEBUG_SYNC=1
CMake option (see
Section 2.8.4, “MySQL Source-Configuration Options”). If Debug Sync
is not compiled in, this option is not available. The option
value is a timeout in seconds. The default value is 0, which
disables Debug Sync. To enable it, specify a value greater
than 0; this value also becomes the default timeout for
individual synchronization points. If the option is given
without a value, the timeout is set to 300 seconds.
For a description of the Debug Sync facility and how to use synchronization points, see MySQL Internals: Test Synchronization.
Property | Value |
---|---|
Command-Line Format | --default-storage-engine=name |
System Variable | default_storage_engine |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value | InnoDB |
Set the default storage engine for tables. See
Chapter 16, Alternative Storage Engines. This option sets the
storage engine for permanent tables only. To set the storage
engine for TEMPORARY
tables, set the
default_tmp_storage_engine
system variable.
If you disable the default storage engine at server startup,
you must set the default engine for both permanent and
TEMPORARY
tables to a different engine or
the server will not start.
Property | Value |
---|---|
Command-Line Format | --default-time-zone=name |
Type | string |
Set the default server time zone. This option sets the global
time_zone
system variable. If
this option is not given, the default time zone is the same as
the system time zone (given by the value of the
system_time_zone
system
variable.
--defaults-extra-file=
file_name
Read this option file after the global option file but (on
Unix) before the user option file. If the file does not exist
or is otherwise inaccessible, an error occurs.
file_name
is interpreted relative
to the current directory if given as a relative path name
rather than a full path name. This must be the first option on
the command line if it is used.
For additional information about this option, see Section 4.2.7, “Command-Line Options that Affect Option-File Handling”.
Read only the given option file. If the file does not exist or
is otherwise inaccessible, an error occurs.
file_name
is interpreted relative
to the current directory if given as a relative path name
rather than a full path name.
Exception: Even with
--defaults-file
,
mysqld reads
mysqld-auto.cnf
.
This must be the first option on the command line if it is
used, except that if the server is started with the
--defaults-file
and
--install
(or
--install-manual
) options,
--install
(or
--install-manual
) must be
first.
For additional information about this option, see Section 4.2.7, “Command-Line Options that Affect Option-File Handling”.
Read not only the usual option groups, but also groups with
the usual names and a suffix of
str
. For example,
mysqld normally reads the
[mysqld]
group. If the
--defaults-group-suffix=_other
option is given, mysqld also reads the
[mysqld_other]
group.
For additional information about this option, see Section 4.2.7, “Command-Line Options that Affect Option-File Handling”.
--delay-key-write[={OFF|ON|ALL}]
Property | Value |
---|---|
Command-Line Format | --delay-key-write[=name] |
System Variable | delay_key_write |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value | ON |
Valid Values |
|
Specify how to use delayed key writes. Delayed key writing
causes key buffers not to be flushed between writes for
MyISAM
tables. OFF
disables delayed key writes. ON
enables
delayed key writes for those tables that were created with the
DELAY_KEY_WRITE
option.
ALL
delays key writes for all
MyISAM
tables. See
Section 5.1.1, “Configuring the Server”, and
Section 16.2.1, “MyISAM Startup Options”.
If you set this variable to ALL
, you
should not use MyISAM
tables from within
another program (such as another MySQL server or
myisamchk) when the tables are in use.
Doing so leads to index corruption.
Property | Value |
---|---|
Command-Line Format | --des-key-file=file_name |
Deprecated | Yes (removed in 8.0.3) |
This option was removed in MySQL 8.0.3.
--early-plugin-load=
plugin_list
Property | Value |
---|---|
Command-Line Format | --early-plugin-load=plugin_list |
Type | string |
Default Value | empty string |
This option tells the server which plugins to load before
loading mandatory built-in plugins and before storage engine
initialization. If multiple
--early-plugin-load
options are
given, only the last one is used.
The option value is a semicolon-separated list of
name
=
plugin_library
and plugin_library
values. Each
name
is the name of a plugin to
load, and plugin_library
is the
name of the library file that contains the plugin code. If a
plugin library is named without any preceding plugin name, the
server loads all plugins in the library. The server looks for
plugin library files in the directory named by the
plugin_dir
system variable.
For example, if plugins named myplug1
and
myplug2
have library files
myplug1.so
and
myplug2.so
, use this option to perform an
early plugin load:
shell> mysqld --early-plugin-load="myplug1=myplug1.so;myplug2=myplug2.so"
Quotes are used around the argument value because otherwise a
semicolon (;
) is interpreted as a special
character by some command interpreters. (Unix shells treat it
as a command terminator, for example.)
Each named plugin is loaded early for a single invocation of
mysqld only. After a restart, the plugin is
not loaded early unless
--early-plugin-load
is used
again.
If the server is started using
--initialize
or
--initialize-insecure
, plugins
specified by
--early-plugin-load
are not
loaded.
If the server is run with
--help
, plugins specified by
--early-plugin-load
are loaded
but not initialized. This behavior ensures that plugin options
are displayed in the help message.
The default --early-plugin-load
value is empty. To load the keyring_file
plugin, you must use an explicit
--early-plugin-load
option with
a nonempty value.
The InnoDB
tablespace encryption feature
relies on the keyring_file
plugin for
encryption key management, and the
keyring_file
plugin must be loaded prior to
storage engine initialization to facilitate
InnoDB
recovery for encrypted tables.
Administrators who want the keyring_file
plugin loaded at startup should use the appropriate nonempty
option value; for example, keyring_file.so
on Unix and Unix-like systems and
keyring_file.dll
on Windows.
For information about InnoDB
tablespace
encryption, see
Section 15.7.11, “InnoDB Tablespace Encryption”. For general
information about plugin loading, see
Section 5.6.1, “Installing and Uninstalling Plugins”.
Property | Value |
---|---|
Command-Line Format | --enable-named-pipe |
Platform Specific | Windows |
Enable support for named pipes. This option applies only on Windows.
Property | Value |
---|---|
Command-Line Format | --event-scheduler[=value] |
System Variable | event_scheduler |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value (>= 8.0.3) | ON |
Default Value (<= 8.0.2) | OFF |
Valid Values |
|
Enable or disable, and start or stop, the event scheduler.
For detailed information, see
The
--event-scheduler
Option.
--exit-info[=
,
flags
]-T [
flags
]
Property | Value |
---|---|
Command-Line Format | --exit-info[=flags] |
Type | integer |
This is a bitmask of different flags that you can use for debugging the mysqld server. Do not use this option unless you know exactly what it does!
Property | Value |
---|---|
Command-Line Format | --external-locking |
Type | boolean |
Default Value | FALSE |
Enable external locking (system locking), which is disabled by
default. If you use this option on a system on which
lockd
does not fully work (such as Linux),
it is easy for mysqld to deadlock.
To disable external locking explicitly, use
--skip-external-locking
.
External locking affects only
MyISAM
table access. For more
information, including conditions under which it can and
cannot be used, see Section 8.11.5, “External Locking”.
Property | Value |
---|---|
Command-Line Format | --flush |
System Variable | flush |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
Flush (synchronize) all changes to disk after each SQL statement. Normally, MySQL does a write of all changes to disk only after each SQL statement and lets the operating system handle the synchronizing to disk. See Section B.5.3.3, “What to Do If MySQL Keeps Crashing”.
If --flush
is specified, the
value of flush_time
does
not matter and changes to
flush_time
have no effect
on flush behavior.
Property | Value |
---|---|
Command-Line Format | --gdb |
Type | boolean |
Default Value | FALSE |
Install an interrupt handler for SIGINT
(needed to stop mysqld with
^C
to set breakpoints) and disable stack
tracing and core file handling. See Section 28.5, “Debugging and Porting MySQL”.
On Windows, this option also suppresses the forking that is
used to implement the RESTART
statement: Forking enables one process to act as a monitor to
the other, which acts as the server. However, forking makes
determining the server process to attach to for debugging more
difficult, so starting the server with
--gdb
suppresses forking. For a
server started with this option,
RESTART
simply exits and does
not restart.
In non-debug settings,
--no-monitor
may be used to
suppress forking the monitor process.
Property | Value |
---|---|
Command-Line Format | --general-log |
System Variable | general_log |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
Specify the initial general query log state. With no argument
or an argument of 1, the
--general-log
option enables
the log. If omitted or given with an argument of 0, the option
disables the log.
--initialize
,
-I
Property | Value |
---|---|
Command-Line Format | --initialize |
Type | boolean |
Default Value | OFF |
This option is used to initialize a MySQL installation by
creating the data directory and populating the tables in the
mysql
system database. For more
information, see
Section 2.9.1.1, “Initializing the Data Directory Manually Using mysqld”.
When the server is started with
--initialize
, some
functionality is unavailable that limits the statements
permitted in any file named by the
--init-file
option. For more information, see
the description of that option. In addition, the
disabled_storage_engines
system variable has no effect.
--initialize
is mutually
exclusive with --daemonize
.
-I
is a synonym for
--initialize
.
Property | Value |
---|---|
Command-Line Format | --initialize-insecure |
Type | boolean |
Default Value | OFF |
This option is used to initialize a MySQL installation by
creating the data directory and populating the tables in the
mysql
system database. This option implies
--initialize
. For more
information, see the description of that option, and
Section 2.9.1.1, “Initializing the Data Directory Manually Using mysqld”.
--initialize-insecure
is
mutually exclusive with
--daemonize
.
Property | Value |
---|---|
Command-Line Format | --init-file=file_name |
System Variable | init_file |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | file name |
Read SQL statements from this file at startup. Each statement must be on a single line and should not include comments.
If the server is started with the
--initialize
or
--initialize-insecure
option,
it operates in bootstap mode and some functionality is
unavailable that limits the statements permitted in the file.
These include statements that relate to account management
(such as CREATE USER
or
GRANT
), replication, and global
transaction identifiers. See
Section 17.1.3, “Replication with Global Transaction Identifiers”.
--innodb-
xxx
Set an option for the InnoDB
storage
engine. The InnoDB
options are listed in
Section 15.13, “InnoDB Startup Options and System Variables”.
Property | Value |
---|---|
Command-Line Format | --install [service_name] |
Platform Specific | Windows |
(Windows only) Install the server as a Windows service that
starts automatically during Windows startup. The default
service name is MySQL
if no
service_name
value is given. For
more information, see Section 2.3.5.8, “Starting MySQL as a Windows Service”.
If the server is started with the
--defaults-file
and
--install
options,
--install
must be first.
--install-manual
[
service_name
]
Property | Value |
---|---|
Command-Line Format | --install-manual [service_name] |
Platform Specific | Windows |
(Windows only) Install the server as a Windows service that
must be started manually. It does not start automatically
during Windows startup. The default service name is
MySQL
if no
service_name
value is given. For
more information, see Section 2.3.5.8, “Starting MySQL as a Windows Service”.
If the server is started with the
--defaults-file
and
--install-manual
options,
--install-manual
must be
first.
--language=
lang_name
,
-L lang_name
Property | Value |
---|---|
Command-Line Format | --language=name |
Deprecated | Yes; use lc-messages-dir |
System Variable | language |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | directory name |
Default Value | /usr/local/mysql/share/mysql/english/ |
The language to use for error messages.
lang_name
can be given as the
language name or as the full path name to the directory where
the language files are installed. See
Section 10.11, “Setting the Error Message Language”.
--lc-messages-dir
and
--lc-messages
should be used
rather than --language
, which
is deprecated (and handled as an alias for
--lc-messages-dir
). The
--language
option will be
removed in a future MySQL release.
Property | Value |
---|---|
Command-Line Format | --large-pages |
System Variable | large_pages |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Platform Specific | Linux |
Type | boolean |
Default Value | FALSE |
Some hardware/operating system architectures support memory pages greater than the default (usually 4KB). The actual implementation of this support depends on the underlying hardware and operating system. Applications that perform a lot of memory accesses may obtain performance improvements by using large pages due to reduced Translation Lookaside Buffer (TLB) misses.
MySQL supports the Linux implementation of large page support
(which is called HugeTLB in Linux). See
Section 8.12.3.2, “Enabling Large Page Support”. For Solaris support of
large pages, see the description of the
--super-large-pages
option.
--large-pages
is disabled by
default.
Property | Value |
---|---|
Command-Line Format | --lc-messages=name |
System Variable | lc_messages |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value | en_US |
The locale to use for error messages. The default is
en_US
. The server converts the argument to
a language name and combines it with the value of
--lc-messages-dir
to produce
the location for the error message file. See
Section 10.11, “Setting the Error Message Language”.
Property | Value |
---|---|
Command-Line Format | --lc-messages-dir=dir_name |
System Variable | lc_messages_dir |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | directory name |
The directory where error messages are located. The server
uses the value together with the value of
--lc-messages
to produce the
location for the error message file. See
Section 10.11, “Setting the Error Message Language”.
Property | Value |
---|---|
Command-Line Format | --local-service |
(Windows only) A --local-service
option
following the service name causes the server to run using the
LocalService
Windows account that has
limited system privileges. If both
--defaults-file
and
--local-service
are given following the
service name, they can be in any order. See
Section 2.3.5.8, “Starting MySQL as a Windows Service”.
Property | Value |
---|---|
Command-Line Format | --log-error[=file_name] |
System Variable | log_error |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | file name |
Set the default error log destination to the named file. This affects log writers that base their own output destination on the default destination. See Section 5.4.2, “The Error Log”.
If the option names no file, the default error log destination
on Unix and Unix-like systems is a file named
in the data directory. The default destination on Windows is
the same, unless the host_name
.err--pid-file
option is specified. In that case, the file name is the PID
file base name with a suffix of .err
in
the data directory.
If the option names a file, the default destination is that
file (with an .err
suffix added if the
name has no suffix), located under the data directory unless
an absolute path name is given to specify a different
location.
If error log output cannot be redirected to the error log file, an error occurs and startup fails.
On Windows, --console
takes
precedence over --log-error
if
both are given. In this case, the default error log
destination is the console rather than a file.
Property | Value |
---|---|
Command-Line Format | --log-isam[=file_name] |
Type | file name |
Log all MyISAM
changes to this file (used
only when debugging MyISAM
).
Property | Value |
---|---|
Command-Line Format | --log-output=name |
System Variable | log_output |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | set |
Default Value | FILE |
Valid Values |
|
This option determines the destination for general query log
and slow query log output. The option value can be given as
one or more of the words TABLE
,
FILE
, or NONE
.
TABLE
select logging to the
general_log
and
slow_log
tables in the
mysql
database as a destination.
FILE
selects logging to log files as a
destination. NONE
disables logging. If
NONE
is present in the option value, it
takes precedence over any other words that are present.
TABLE
and FILE
can both
be given to select to both log output destinations.
This option selects log output destinations, but does not
enable log output. To do that, use the
--general_log
and
--slow_query_log
options. For
FILE
logging, the
--general_log_file
and
-slow_query_log_file
options determine the
log file location. For more information, see
Section 5.4.1, “Selecting General Query and Slow Query Log Output Destinations”.
--log-queries-not-using-indexes
Property | Value |
---|---|
Command-Line Format | --log-queries-not-using-indexes |
System Variable | log_queries_not_using_indexes |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
If you are using this option with the slow query log enabled, queries that are expected to retrieve all rows are logged. See Section 5.4.5, “The Slow Query Log”. This option does not necessarily mean that no index is used. For example, a query that uses a full index scan uses an index but would be logged because the index would not limit the number of rows.
Property | Value |
---|---|
Command-Line Format | --log-raw[=value] |
Type | boolean |
Default Value | OFF |
Passwords in certain statements written to the general query
log, slow query log, and binary log are rewritten by the
server not to occur literally in plain text. Password
rewriting can be suppressed for the general query log by
starting the server with the
--log-raw
option. This option
may be useful for diagnostic purposes, to see the exact text
of statements as received by the server, but for security
reasons is not recommended for production use.
If a query rewrite plugin is installed, the
--log-raw
option affects
statement logging as follows:
For more information, see Section 6.1.2.3, “Passwords and Logging”.
Property | Value |
---|---|
Command-Line Format | --log-short-format |
Type | boolean |
Default Value | FALSE |
Log less information to the slow query log, if it has been activated.
Property | Value |
---|---|
Command-Line Format | --log-tc=file_name |
Type | file name |
Default Value | tc.log |
The name of the memory-mapped transaction coordinator log file
(for XA transactions that affect multiple storage engines when
the binary log is disabled). The default name is
tc.log
. The file is created under the
data directory if not given as a full path name. This option
is unused.
Property | Value |
---|---|
Command-Line Format | --log-tc-size=# |
Type | integer |
Default Value | 6 * page size |
Minimum Value | 6 * page size |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
The size in bytes of the memory-mapped transaction coordinator log. The default and minimum values are 6 times the page size, and the value must be a multiple of the page size.
--log-warnings[=
,
level
]-W [
level
]
Property | Value |
---|---|
Command-Line Format | --log-warnings[=#] |
Deprecated | Yes (removed in 8.0.3) |
System Variable | log_warnings |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 2 |
Minimum Value | 0 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
This option was removed in MySQL 8.0.3. Use the
log_error_verbosity
system
variable instead.
Property | Value |
---|---|
Command-Line Format | --low-priority-updates |
System Variable | low_priority_updates |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | FALSE |
Give table-modifying operations
(INSERT
,
REPLACE
,
DELETE
,
UPDATE
) lower priority than
selects. This can also be done using {INSERT |
REPLACE | DELETE | UPDATE} LOW_PRIORITY ...
to lower
the priority of only one query, or by SET
LOW_PRIORITY_UPDATES=1
to change the priority in one
thread. This affects only storage engines that use only
table-level locking (MyISAM
,
MEMORY
, MERGE
). See
Section 8.11.2, “Table Locking Issues”.
--min-examined-row-limit=
number
Property | Value |
---|---|
Command-Line Format | --min-examined-row-limit=# |
System Variable | min_examined_row_limit |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 0 |
Minimum Value | 0 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
When this option is set, queries which examine fewer than
number
rows are not written to the
slow query log. The default is 0.
Property | Value |
---|---|
Command-Line Format | --memlock |
Type | boolean |
Default Value | FALSE |
Lock the mysqld process in memory. This option might help if you have a problem where the operating system is causing mysqld to swap to disk.
--memlock
works on systems that
support the mlockall()
system call; this
includes Solaris, most Linux distributions that use a 2.4 or
higher kernel, and perhaps other Unix systems. On Linux
systems, you can tell whether or not
mlockall()
(and thus this option) is
supported by checking to see whether or not it is defined in
the system mman.h
file, like this:
shell> grep mlockall /usr/include/sys/mman.h
If mlockall()
is supported, you should see
in the output of the previous command something like the
following:
extern int mlockall (int __flags) __THROW;
Use of this option may require you to run the server as
root
, which, for reasons of security, is
normally not a good idea. See
Section 6.1.5, “How to Run MySQL as a Normal User”.
On Linux and perhaps other systems, you can avoid the need
to run the server as root
by changing the
limits.conf
file. See the notes
regarding the memlock limit in
Section 8.12.3.2, “Enabling Large Page Support”.
You must not try to use this option on a system that does
not support the mlockall()
system call;
if you do so, mysqld will very likely
crash as soon as you try to start it.
Property | Value |
---|---|
Command-Line Format | --myisam-block-size=# |
Type | integer |
Default Value | 1024 |
Minimum Value | 1024 |
Maximum Value | 16384 |
The block size to be used for MyISAM
index
pages.
--myisam-recover-options[=
option
[,option
]...]]
Property | Value |
---|---|
Command-Line Format | --myisam-recover-options[=name] |
Type | enumeration |
Default Value | OFF |
Valid Values |
|
Set the MyISAM
storage engine recovery
mode. The option value is any combination of the values of
OFF
, DEFAULT
,
BACKUP
, FORCE
, or
QUICK
. If you specify multiple values,
separate them by commas. Specifying the option with no
argument is the same as specifying DEFAULT
,
and specifying with an explicit value of ""
disables recovery (same as a value of OFF
).
If recovery is enabled, each time mysqld
opens a MyISAM
table, it checks whether the
table is marked as crashed or was not closed properly. (The
last option works only if you are running with external
locking disabled.) If this is the case,
mysqld runs a check on the table. If the
table was corrupted, mysqld attempts to
repair it.
The following options affect how the repair works.
Option | Description |
---|---|
OFF |
No recovery. |
DEFAULT |
Recovery without backup, forcing, or quick checking. |
BACKUP |
If the data file was changed during recovery, save a backup of the
file as
. |
FORCE |
Run recovery even if we would lose more than one row from the
.MYD file. |
QUICK |
Do not check the rows in the table if there are not any delete blocks. |
Before the server automatically repairs a table, it writes a
note about the repair to the error log. If you want to be able
to recover from most problems without user intervention, you
should use the options BACKUP,FORCE
. This
forces a repair of a table even if some rows would be deleted,
but it keeps the old data file as a backup so that you can
later examine what happened.
Do not read any option files. If program startup fails due to
reading unknown options from an option file,
--no-defaults
can be used to
prevent them from being read. This must be the first option on
the command line if it is used.
For additional information about this option, see Section 4.2.7, “Command-Line Options that Affect Option-File Handling”.
Property | Value |
---|---|
Command-Line Format | --no-dd-upgrade |
Introduced | 8.0.4 |
Type | boolean |
Default Value | FALSE |
Prevents the automatic upgrade of data dictionary tables when starting the MySQL server. This option would typically be used when starting the MySQL server following an in-place upgrade of the MySQL server to a new version, which may include changes to data dictionary table definitions.
When --no-dd-upgrade
is
specified, and the server finds that the data dictionary
version of the server is different from the version stored in
the data dictionary, startup fails with an error stating that
data dictionary upgrade is prohibited.
During a normal startup, the data dictionary version of the server is compared to the version stored in the data dictionary to determine if data dictionary table definitions should be upgraded. If an upgrade is necessary and supported, the server creates data dictionary tables with updated definitions, copies persisted metadata to the new tables, atomically replaces the old tables with the new ones, and reinitializes the data dictionary. If an upgrade is not necessary, startup continues without updating data dictionary tables.
Property | Value |
---|---|
Command-Line Format | --no-monitor |
Introduced | 8.0.12 |
Platform Specific | Windows |
Type | boolean |
Default Value | FALSE |
(Windows only). This option suppresses the forking that is
used to implement the RESTART
statement: Forking enables one process to act as a monitor to
the other, which acts as the server. For a server started with
this option, RESTART
simply
exits and does not restart.
--no-monitor
is not available
prior to MySQL 8.0.12. The
--gdb
option can be used as a
workaround.
Property | Value |
---|---|
Command-Line Format | --old-alter-table |
System Variable | old_alter_table |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
When this option is given, the server does not use the
optimized method of processing an ALTER
TABLE
operation. It reverts to using a temporary
table, copying over the data, and then renaming the temporary
table to the original, as used by MySQL 5.0 and earlier. For
more information on the operation of
ALTER TABLE
, see
Section 13.1.8, “ALTER TABLE Syntax”.
Property | Value |
---|---|
Command-Line Format | --old-style-user-limits |
Type | boolean |
Default Value | FALSE |
Enable old-style user limits. (Before MySQL 5.0.3, account
resource limits were counted separately for each host from
which a user connected rather than per account row in the
user
table.) See
Section 6.3.6, “Setting Account Resource Limits”.
Property | Value |
---|---|
Command-Line Format | --open-files-limit=# |
System Variable | open_files_limit |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 5000, with possible adjustment |
Minimum Value | 0 |
Maximum Value | platform dependent |
Changes the number of file descriptors available to
mysqld. You should try increasing the value
of this option if mysqld gives you the
error Too many open files
.
mysqld uses the option value to reserve
descriptors with setrlimit()
. Internally,
the maximum value for this option is the maximum unsigned
integer value, but the actual maximum is platform dependent.
If the requested number of file descriptors cannot be
allocated, mysqld writes a warning to the
error log.
mysqld may attempt to allocate more than
the requested number of descriptors (if they are available),
using the values of
max_connections
and
table_open_cache
to estimate
whether more descriptors will be needed.
On Unix, the value cannot be set greater than ulimit -n.
--performance-schema-xxx
Configure a Performance Schema option. For details, see Section 25.13, “Performance Schema Command Options”.
Property | Value |
---|---|
Command-Line Format | --pid-file=file_name |
System Variable | pid_file |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | file name |
The path name of the process ID file. The server creates the
file in the data directory unless an absolute path name is
given to specify a different directory. If you specify this
option, you must specify a value. If you do not specify this
option, MySQL uses a default value of
,
where host_name
.pidhost_name
is the name of the
host machine.
The process ID file is used by other programs such as mysqld_safe to determine the server's process ID. On Windows, this variable also affects the default error log file name. See Section 5.4.2, “The Error Log”.
Specifies an option that pertains to a server plugin. For
example, many storage engines can be built as plugins, and for
such engines, options for them can be specified with a
--plugin
prefix. Thus, the
--innodb_file_per_table
option
for InnoDB
can be specified as
--plugin-innodb_file_per_table
.
For boolean options that can be enabled or disabled, the
--skip
prefix and other alternative formats
are supported as well (see
Section 4.2.5, “Program Option Modifiers”). For example,
--skip-plugin-innodb_file_per_table
disables innodb_file_per_table
.
The rationale for the --plugin
prefix is that
it enables plugin options to be specified unambiguously if
there is a name conflict with a built-in server option. For
example, were a plugin writer to name a plugin
“sql” and implement a “mode” option,
the option name might be
--sql-mode
, which would
conflict with the built-in option of the same name. In such
cases, references to the conflicting name are resolved in
favor of the built-in option. To avoid the ambiguity, users
can specify the plugin option as
--plugin-sql-mode
. Use of the
--plugin
prefix for plugin options is
recommended to avoid any question of ambiguity.
Property | Value |
---|---|
Command-Line Format | --plugin-load=plugin_list |
Type | string |
This option tells the server to load the named plugins at
startup. If multiple
--plugin-load
options are
given, only the last one is used. Additional plugins to load
may be specified using
--plugin-load-add
options.
The option value is a semicolon-separated list of
name
=
plugin_library
and plugin_library
values. Each
name
is the name of a plugin to
load, and plugin_library
is the
name of the library file that contains the plugin code. If a
plugin library is named without any preceding plugin name, the
server loads all plugins in the library. The server looks for
plugin library files in the directory named by the
plugin_dir
system variable.
For example, if plugins named myplug1
and
myplug2
have library files
myplug1.so
and
myplug2.so
, use this option to perform an
early plugin load:
shell> mysqld --plugin-load="myplug1=myplug1.so;myplug2=myplug2.so"
Quotes are used around the argument value here because
otherwise semicolon (;
) is interpreted as a
special character by some command interpreters. (Unix shells
treat it as a command terminator, for example.)
Each named plugin is loaded for a single invocation of
mysqld only. After a restart, the plugin is
not loaded unless --plugin-load
is used again. This is in contrast to
INSTALL PLUGIN
, which adds an
entry to the mysql.plugins
table to cause
the plugin to be loaded for every normal server startup.
Under normal startup, the server determines which plugins to
load by reading the mysql.plugins
system
table. If the server is started with the
--skip-grant-tables
option, it
does not consult the mysql.plugins
table
and does not load plugins listed there.
--plugin-load
enables plugins
to be loaded even when
--skip-grant-tables
is given.
--plugin-load
also enables
plugins to be loaded at startup that cannot be loaded at
runtime.
For additional information about plugin loading, see Section 5.6.1, “Installing and Uninstalling Plugins”.
Property | Value |
---|---|
Command-Line Format | --plugin-load-add=plugin_list |
Type | string |
This option complements the
--plugin-load
option.
--plugin-load-add
adds a plugin
or plugins to the set of plugins to be loaded at startup. The
argument format is the same as for
--plugin-load
.
--plugin-load-add
can be used
to avoid specifying a large set of plugins as a single long
unwieldy --plugin-load
argument.
--plugin-load-add
can be given
in the absence of
--plugin-load
, but any instance
of --plugin-load-add
that
appears before --plugin-load
.
has no effect because
--plugin-load
resets the set of
plugins to load. In other words, these options:
--plugin-load=x --plugin-load-add=y
are equivalent to this option:
--plugin-load="x;y"
But these options:
--plugin-load-add=y --plugin-load=x
are equivalent to this option:
--plugin-load=x
For additional information about plugin loading, see Section 5.6.1, “Installing and Uninstalling Plugins”.
--port=
,
port_num
-P
port_num
Property | Value |
---|---|
Command-Line Format | --port=# |
System Variable | port |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 3306 |
Minimum Value | 0 |
Maximum Value | 65535 |
The port number to use when listening for TCP/IP connections.
On Unix and Unix-like systems, the port number must be 1024 or
higher unless the server is started by the
root
system user.
Property | Value |
---|---|
Command-Line Format | --port-open-timeout=# |
Type | integer |
Default Value | 0 |
On some systems, when the server is stopped, the TCP/IP port might not become available immediately. If the server is restarted quickly afterward, its attempt to reopen the port can fail. This option indicates how many seconds the server should wait for the TCP/IP port to become free if it cannot be opened. The default is not to wait.
Print the program name and all options that it gets from
option files. Password values are masked. This must be the
first option on the command line if it is used, except that it
may be used immediately after
--defaults-file
or
--defaults-extra-file
.
For additional information about this option, see Section 4.2.7, “Command-Line Options that Affect Option-File Handling”.
Property | Value |
---|---|
Command-Line Format | --remove [service_name] |
Platform Specific | Windows |
(Windows only) Remove a MySQL Windows service. The default
service name is MySQL
if no
service_name
value is given. For
more information, see Section 2.3.5.8, “Starting MySQL as a Windows Service”.
Property | Value |
---|---|
Command-Line Format | --safe-user-create |
Type | boolean |
Default Value | FALSE |
If this option is enabled, a user cannot create new MySQL
users by using the GRANT
statement unless the user has the
INSERT
privilege for the
mysql.user
table or any column in the
table. If you want a user to have the ability to create new
users that have those privileges that the user has the right
to grant, you should grant the user the following privilege:
GRANT INSERT(user) ON mysql.user TO 'user_name
'@'host_name
';
This ensures that the user cannot change any privilege columns
directly, but has to use the
GRANT
statement to give
privileges to other users.
Property | Value |
---|---|
Command-Line Format | --secure-auth |
Deprecated | Yes (removed in 8.0.3) |
System Variable | secure_auth |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | ON |
Valid Values | ON |
This option was removed in MySQL 8.0.3.
Property | Value |
---|---|
Command-Line Format | --secure-file-priv=dir_name |
System Variable | secure_file_priv |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | string |
Default Value | platform specific |
Valid Values |
|
This option sets the
secure_file_priv
system
variable, which is used to limit the effect of data import and
export operations, such as those performed by the
LOAD DATA
and
SELECT ... INTO
OUTFILE
statements and the
LOAD_FILE()
function. For more
information, see the description of
secure_file_priv
.
Property | Value |
---|---|
Command-Line Format | --shared-memory[={0,1}] |
System Variable | shared_memory |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Platform Specific | Windows |
Type | boolean |
Default Value | FALSE |
Enable shared-memory connections by local clients. This option is available only on Windows.
--shared-memory-base-name=
name
Property | Value |
---|---|
Command-Line Format | --shared-memory-base-name=name |
System Variable | shared_memory_base_name |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Platform Specific | Windows |
Type | string |
Default Value | MYSQL |
The name of shared memory to use for shared-memory
connections. This option is available only on Windows. The
default name is MYSQL
. The name is case
sensitive.
Turn off the ability to select and insert at the same time on
MyISAM
tables. (This is to be used only if
you think you have found a bug in this feature.) See
Section 8.11.3, “Concurrent Inserts”.
Property | Value |
---|---|
Command-Line Format |
|
Turns the Event Scheduler OFF
. This is not
the same as disabling the Event Scheduler, which requires
setting
--event-scheduler=DISABLED
; see
The
--event-scheduler
Option, for more
information.
Property | Value |
---|---|
Command-Line Format | --skip-grant-tables |
Type | boolean |
Default Value | FALSE |
This option causes the server to start without using the
privilege system at all, which gives anyone with access to the
server unrestricted access to all
databases. You can cause a running server to start
using the grant tables again by executing mysqladmin
flush-privileges or mysqladmin
reload command from a system shell, or by issuing a
MySQL FLUSH PRIVILEGES
statement after connecting to the server.
If the server is started with the
--skip-grant-tables
option to
disable authentication checks, the server enables
--skip-networking
automatically
to prevent remote connections.
This option also causes the server to suppress during its
startup sequence the loading of user-defined functions (UDFs),
scheduled events, and plugins that were installed with the
INSTALL PLUGIN
statement. To
cause plugins to be loaded anyway, use the
--plugin-load
option.
--skip-grant-tables
also causes
the disabled_storage_engines
system variable to have no effect.
This option does not cause loading of server components to be suppressed during server startup.
FLUSH PRIVILEGES
might be
executed implicitly by other actions performed after startup.
For example, mysql_upgrade flushes the
privileges during the upgrade procedure.
Property | Value |
---|---|
Command-Line Format | --skip-host-cache |
Disable use of the internal host cache for faster name-to-IP resolution. In this case, the server performs a DNS lookup every time a client connects. See Section 8.12.4.2, “DNS Lookup Optimization and the Host Cache”.
Use of --skip-host-cache
is
similar to setting the
host_cache_size
system
variable to 0, but
host_cache_size
is more
flexible because it can also be used to resize, enable, or
disable the host cache at runtime, not just at server startup.
If you start the server with
--skip-host-cache
, that does
not prevent changes to the value of
host_cache_size
, but such
changes have no effect and the cache is not re-enabled even if
host_cache_size
is set larger
than 0.
Disable the InnoDB
storage engine. In this
case, because the default storage engine is
InnoDB
, the server will not start
unless you also use
--default-storage-engine
and
--default-tmp-storage-engine
to
set the default to some other engine for both permanent and
TEMPORARY
tables.
The InnoDB
storage engine cannot be
disabled, and the
--skip-innodb
option is deprecated and has no effect. Its use results in a
warning. This option will be removed in a future MySQL
release.
Property | Value |
---|---|
Command-Line Format | --skip-name-resolve |
System Variable | skip_name_resolve |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
Do not resolve host names when checking client connections.
Use only IP addresses. If you use this option, all
Host
column values in the grant tables must
be IP addresses. See Section 8.12.4.2, “DNS Lookup Optimization and the Host Cache”.
Depending on the network configuration of your system and the
Host
values for your accounts, clients may
need to connect using an explicit --host
option, such as --host=127.0.0.1
or
--host=::1
.
An attempt to connect to the host 127.0.0.1
normally resolves to the localhost
account.
However, this fails if the server is run with the
--skip-name-resolve
option. If
you plan to do that, make sure that an account exists that can
accept a connection. For example, to be able to connect as
root
using
--host=127.0.0.1
or
--host=::1
, create these accounts:
CREATE USER 'root'@'127.0.0.1' IDENTIFIED BY 'root-password
'; CREATE USER 'root'@'::1' IDENTIFIED BY 'root-password
';
Property | Value |
---|---|
Command-Line Format | --skip-networking |
System Variable | skip_networking |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Do not listen for TCP/IP connections at all. All interaction with mysqld must be made using named pipes or shared memory (on Windows) or Unix socket files (on Unix). This option is highly recommended for systems where only local clients are permitted. See Section 8.12.4.2, “DNS Lookup Optimization and the Host Cache”.
If the server is started with the
--skip-grant-tables
option to
disable authentication checks, the server enables
--skip-networking
to prevent
remote connections.
Options that begin with --ssl
specify whether to permit clients to connect using SSL and
indicate where to find SSL keys and certificates. See
Section 6.4.2, “Command Options for Encrypted Connections”.
Property | Value |
---|---|
Command-Line Format | --standalone |
Platform Specific | Windows |
Available on Windows only; instructs the MySQL server not to run as a service.
Property | Value |
---|---|
Command-Line Format | --super-large-pages |
Platform Specific | Solaris |
Type | boolean |
Default Value | FALSE |
Standard use of large pages in MySQL attempts to use the
largest size supported, up to 4MB. Under Solaris, a
“super large pages” feature enables uses of pages
up to 256MB. This feature is available for recent SPARC
platforms. It can be enabled or disabled by using the
--super-large-pages
or
--skip-super-large-pages
option.
--symbolic-links
,
--skip-symbolic-links
Property | Value |
---|---|
Command-Line Format | --symbolic-links |
Deprecated | 8.0.2 |
Type | boolean |
Default Value (>= 8.0.2) | OFF |
Default Value (<= 8.0.1) | ON |
Enable or disable symbolic link support. On Unix, enabling
symbolic links means that you can link a
MyISAM
index file or data file to another
directory with the INDEX DIRECTORY
or
DATA DIRECTORY
option of the
CREATE TABLE
statement. If you
delete or rename the table, the files that its symbolic links
point to also are deleted or renamed. See
Section 8.12.2.2, “Using Symbolic Links for MyISAM Tables on Unix”.
Symbolic link support, along with the the
--symbolic-links
option that
controls it, is deprecated and will be removed in a future
version of MySQL. In addition, the option is disabled by
default. The related
have_symlink
system
variable also is deprecated and will be removed in a future
version of MySQL.
This option has no meaning on Windows.
Property | Value |
---|---|
Command-Line Format | --skip-show-database |
System Variable | skip_show_database |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
This option sets the
skip_show_database
system
variable that controls who is permitted to use the
SHOW DATABASES
statement. See
Section 5.1.7, “Server System Variables”.
Property | Value |
---|---|
Command-Line Format | --skip-stack-trace |
Do not write stack traces. This option is useful when you are running mysqld under a debugger. On some systems, you also must use this option to get a core file. See Section 28.5, “Debugging and Porting MySQL”.
Property | Value |
---|---|
Command-Line Format | --slow-query-log |
System Variable | slow_query_log |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
Specify the initial slow query log state. With no argument or
an argument of 1, the
--slow-query-log
option enables
the log. If omitted or given with an argument of 0, the option
disables the log.
Property | Value |
---|---|
Command-Line Format | --slow-start-timeout=# |
Type | integer |
Default Value | 15000 |
This option controls the Windows service control manager's service start timeout. The value is the maximum number of milliseconds that the service control manager waits before trying to kill the windows service during startup. The default value is 15000 (15 seconds). If the MySQL service takes too long to start, you may need to increase this value. A value of 0 means there is no timeout.
Property | Value |
---|---|
Command-Line Format | --socket={file_name|pipe_name} |
System Variable | socket |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | string |
Default Value (Other) | /tmp/mysql.sock |
Default Value (Windows) | MySQL |
On Unix, this option specifies the Unix socket file to use
when listening for local connections. The default value is
/tmp/mysql.sock
. If this option is given,
the server creates the file in the data directory unless an
absolute path name is given to specify a different directory.
On Windows, the option specifies the pipe name to use when
listening for local connections that use a named pipe. The
default value is MySQL
(not case
sensitive).
--sql-mode=
value
[,value
[,value
...]]
Property | Value |
---|---|
Command-Line Format | --sql-mode=name |
System Variable | sql_mode |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | set |
Default Value (>= 8.0.11) | ONLY_FULL_GROUP_BY STRICT_TRANS_TABLES NO_ZERO_IN_DATE NO_ZERO_DATE ERROR_FOR_DIVISION_BY_ZERO NO_ENGINE_SUBSTITUTION |
Default Value (<= 8.0.4) | ONLY_FULL_GROUP_BY STRICT_TRANS_TABLES NO_ZERO_IN_DATE NO_ZERO_DATE ERROR_FOR_DIVISION_BY_ZERO NO_AUTO_CREATE_USER NO_ENGINE_SUBSTITUTION |
Valid Values (>= 8.0.11) |
|
Valid Values (>= 8.0.1, <= 8.0.4) |
|
Valid Values (8.0.0) |
|
Set the SQL mode. See Section 5.1.10, “Server SQL Modes”.
MySQL installation programs may configure the SQL mode during the installation process.
If the SQL mode differs from the default or from what you expect, check for a setting in an option file that the server reads at startup.
Property | Value |
---|---|
Command-Line Format | --sysdate-is-now |
Type | boolean |
Default Value | FALSE |
SYSDATE()
by default returns
the time at which it executes, not the time at which the
statement in which it occurs begins executing. This differs
from the behavior of NOW()
.
This option causes SYSDATE()
to
be an alias for NOW()
. For
information about the implications for binary logging and
replication, see the description for
SYSDATE()
in
Section 12.7, “Date and Time Functions” and for SET
TIMESTAMP
in
Section 5.1.7, “Server System Variables”.
--tc-heuristic-recover={COMMIT|ROLLBACK}
Property | Value |
---|---|
Command-Line Format | --tc-heuristic-recover=name |
Type | enumeration |
Default Value | COMMIT |
Valid Values |
|
The type of decision to use in the heuristic recovery process. To use this option, two or more storage engines that support XA transactions must be installed.
Property | Value |
---|---|
Command-Line Format | --temp-pool |
Deprecated | Yes (removed in 8.0.1) |
Type | boolean |
Default Value (Other) | FALSE |
Default Value (Linux) | TRUE |
This option is obsolete and was removed in MySQL 8.0.1.
Property | Value |
---|---|
Command-Line Format | --transaction-isolation=name |
System Variable | transaction_isolation |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value | REPEATABLE-READ |
Valid Values |
|
Sets the default transaction isolation level. The
level
value can be
READ-UNCOMMITTED
,
READ-COMMITTED
,
REPEATABLE-READ
, or
SERIALIZABLE
. See
Section 13.3.7, “SET TRANSACTION Syntax”.
The default transaction isolation level can also be set at
runtime using the SET
TRANSACTION
statement or by setting the
transaction_isolation
system
variable.
Property | Value |
---|---|
Command-Line Format | --transaction-read-only |
System Variable | transaction_read_only |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
Sets the default transaction access mode. By default, read-only mode is disabled, so the mode is read/write.
To set the default transaction access mode at runtime, use the
SET TRANSACTION
statement or
set the transaction_read_only
system variable. See Section 13.3.7, “SET TRANSACTION Syntax”.
--tmpdir=
,
dir_name
-t
dir_name
Property | Value |
---|---|
Command-Line Format | --tmpdir=dir_name |
System Variable | tmpdir |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | directory name |
The path of the directory to use for creating temporary files.
It might be useful if your default /tmp
directory resides on a partition that is too small to hold
temporary tables. This option accepts several paths that are
used in round-robin fashion. Paths should be separated by
colon characters (:
) on Unix and semicolon
characters (;
) on Windows. If the MySQL
server is acting as a replication slave, you should not set
--tmpdir
to point to a
directory on a memory-based file system or to a directory that
is cleared when the server host restarts. For more information
about the storage location of temporary files, see
Section B.5.3.5, “Where MySQL Stores Temporary Files”. A replication slave needs
some of its temporary files to survive a machine restart so
that it can replicate temporary tables or
LOAD DATA
INFILE
operations. If files in the temporary file
directory are lost when the server restarts, replication
fails.
--user={
,
user_name
|user_id
}-u
{
user_name
|user_id
}
Property | Value |
---|---|
Command-Line Format | --user=name |
Type | string |
Run the mysqld server as the user having
the name user_name
or the numeric
user ID user_id
.
(“User” in this context refers to a system login
account, not a MySQL user listed in the grant tables.)
This option is mandatory when starting
mysqld as root
. The
server changes its user ID during its startup sequence,
causing it to run as that particular user rather than as
root
. See
Section 6.1.1, “Security Guidelines”.
To avoid a possible security hole where a user adds a
--user=root
option to a
my.cnf
file (thus causing the server to
run as root
), mysqld
uses only the first --user
option specified and produces a warning if there are multiple
--user
options. Options in
/etc/my.cnf
and
$MYSQL_HOME/my.cnf
are processed before
command-line options, so it is recommended that you put a
--user
option in
/etc/my.cnf
and specify a value other
than root
. The option in
/etc/my.cnf
is found before any other
--user
options, which ensures
that the server runs as a user other than
root
, and that a warning results if any
other --user
option is found.
Use this option with the --help
option for detailed help.
--version
, -V
Display version information and exit.
The MySQL server maintains many system variables that indicate how
it is configured. Each system variable has a default value. System
variables can be set at server startup using options on the
command line or in an option file. Most of them can be changed
dynamically at runtime using the
SET
statement, which enables you to modify operation of the server
without having to stop and restart it. You can also use system
variable values in expressions.
At runtime, setting the global value of a system variable normally
requires the SYSTEM_VARIABLES_ADMIN
or SUPER
privilege, with exceptions
as noted in individual variable descriptions. For some system
variables, setting the session value also requires the sme
privilege; again, with exceptions as noted in individual variable
descriptions.
There are several ways to see the names and values of system variables:
To see the values that a server will use based on its compiled-in defaults and any option files that it reads, use this command:
mysqld --verbose --help
To see the values that a server will use based on its compiled-in defaults, ignoring the settings in any option files, use this command:
mysqld --no-defaults --verbose --help
To see the current values used by a running server, use the
SHOW VARIABLES
statement or the
Performance Schema system variable tables. See
Section 25.11.13, “Performance Schema System Variable Tables”.
This section provides a description of each system variable. For a system variable summary table, see Section 5.1.4, “Server System Variable Reference”. For more information about manipulation of system variables, see Section 5.1.8, “Using System Variables”.
For additional system variable information, see these sections:
Section 5.1.8, “Using System Variables”, discusses the syntax for setting and displaying system variable values.
Section 5.1.8.3, “Dynamic System Variables”, lists the variables that can be set at runtime.
Information on tuning system variables can be found in Section 5.1.1, “Configuring the Server”.
Section 15.13, “InnoDB Startup Options and System Variables”, lists
InnoDB
system variables.
For information on server system variables specific to replication, see Section 17.1.6, “Replication and Binary Logging Options and Variables”.
Some of the following variable descriptions refer to
“enabling” or “disabling” a variable.
These variables can be enabled with the
SET
statement by setting them to ON
or
1
, or disabled by setting them to
OFF
or 0
. Boolean
variables can be set at startup to the values
ON
, TRUE
,
OFF
, and FALSE
(not case
sensitive), as well as 1
and
0
. See Section 4.2.5, “Program Option Modifiers”.
Some system variables control the size of buffers or caches. For a given buffer, the server might need to allocate internal data structures. These structures typically are allocated from the total memory allocated to the buffer, and the amount of space required might be platform dependent. This means that when you assign a value to a system variable that controls a buffer size, the amount of space actually available might differ from the value assigned. In some cases, the amount might be less than the value assigned. It is also possible that the server will adjust a value upward. For example, if you assign a value of 0 to a variable for which the minimal value is 1024, the server will set the value to 1024.
Values for buffer sizes, lengths, and stack sizes are given in bytes unless otherwise specified.
Some system variables take file name values. Unless otherwise
specified, the default file location is the data directory if the
value is a relative path name. To specify the location explicitly,
use an absolute path name. Suppose that the data directory is
/var/mysql/data
. If a file-valued variable is
given as a relative path name, it will be located under
/var/mysql/data
. If the value is an absolute
path name, its location is as given by the path name.
Property | Value |
---|---|
Command-Line Format | --activate-all-roles-on-login |
Introduced | 8.0.2 |
System Variable | activate_all_roles_on_login |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
Whether to enable automatic activation of all granted roles when users log in to the server:
If
activate_all_roles_on_login
is enabled, the server activates all roles granted to each
account at login time. This takes precedence over default
roles specified with SET DEFAULT
ROLE
.
If
activate_all_roles_on_login
is disabled, the server activates the default roles
specified with SET DEFAULT
ROLE
, if any, at login time.
Granted roles include those granted explicitly to the user and
those named in the
mandatory_roles
system
variable value.
activate_all_roles_on_login
applies only at login time, and at the beginning of execution
for stored programs and views that execute in definer context.
To change the active roles within a session, use
SET ROLE
. To change the active
roles for a stored program, the program body should execute
SET ROLE
.
authentication_windows_log_level
Property | Value |
---|---|
Command-Line Format | --authentication-windows-log-level |
Introduced | 8.0.11 |
Type | integer |
Default Value | 0 |
Minimum Value | 0 |
Maximum Value | 4 |
This variable is available only if the
authentication_windows
Windows
authentication plugin is enabled and debugging code is
enabled. See
Section 6.5.1.6, “Windows Pluggable Authentication”.
This variable sets the logging level for the Windows authentication plugin. The following table shows the permitted values.
Value | Description |
---|---|
0 | No logging |
1 | Log only error messages |
2 | Log level 1 messages and warning messages |
3 | Log level 2 messages and information notes |
4 | Log level 3 messages and debug messages |
authentication_windows_use_principal_name
Property | Value |
---|---|
Command-Line Format | --authentication-windows-use-principal-name |
Introduced | 8.0.11 |
Type | boolean |
Default Value | ON |
This variable is available only if the
authentication_windows
Windows
authentication plugin is enabled. See
Section 6.5.1.6, “Windows Pluggable Authentication”.
A client that authenticates using the
InitSecurityContext()
function should
provide a string identifying the service to which it connects
(targetName
). MySQL uses the
principal name (UPN) of the account under which the server is
running. The UPN has the form
and need not be registered anywhere to be used. This UPN is
sent by the server at the beginning of authentication
handshake.
user_id
@computer_name
This variable controls whether the server sends the UPN in the
initial challenge. By default, the variable is enabled. For
security reasons, it can be disabled to avoid sending the
server's account name to a client in clear text. If the
variable is disabled, the server always sends a
0x00
byte in the first challenge, the
client does not specify targetName
,
and as a result, NTLM authentication is used.
If the server fails to obtain its UPN (which will happen primarily in environments that do not support Kerberos authentication), the UPN is not sent by the server and NTLM authentication is used.
Property | Value |
---|---|
Command-Line Format | --autocommit[=#] |
System Variable | autocommit |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | ON |
The autocommit mode. If set to 1, all changes to a table take
effect immediately. If set to 0, you must use
COMMIT
to accept a transaction
or ROLLBACK
to cancel it. If autocommit
is 0 and you change it to 1, MySQL performs an automatic
COMMIT
of any open transaction.
Another way to begin a transaction is to use a
START
TRANSACTION
or
BEGIN
statement. See Section 13.3.1, “START TRANSACTION, COMMIT, and ROLLBACK Syntax”.
By default, client connections begin with
autocommit
set to 1. To cause
clients to begin with a default of 0, set the global
autocommit
value by starting
the server with the
--autocommit=0
option. To set
the variable using an option file, include these lines:
[mysqld] autocommit=0
Property | Value |
---|---|
System Variable | automatic_sp_privileges |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | TRUE |
When this variable has a value of 1 (the default), the server
automatically grants the
EXECUTE
and
ALTER ROUTINE
privileges to the
creator of a stored routine, if the user cannot already
execute and alter or drop the routine. (The
ALTER ROUTINE
privilege is
required to drop the routine.) The server also automatically
drops those privileges from the creator when the routine is
dropped. If
automatic_sp_privileges
is 0,
the server does not automatically add or drop these
privileges.
The creator of a routine is the account used to execute the
CREATE
statement for it. This might not be
the same as the account named as the
DEFINER
in the routine definition.
See also Section 23.2.2, “Stored Routines and MySQL Privileges”.
Property | Value |
---|---|
Command-Line Format | --auto-generate-certs[={OFF|ON}] |
System Variable | auto_generate_certs |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | ON |
This variable is available if the server was compiled using OpenSSL (see Section 6.4.4, “OpenSSL Versus wolfSSL”). It controls whether the server autogenerates SSL key and certificate files in the data directory, if they do not already exist.
At startup, the server automatically generates server-side and
client-side SSL certificate and key files in the data
directory if the
auto_generate_certs
system
variable is enabled, no SSL options other than
--ssl
are specified, and the
server-side SSL files are missing from the data directory.
These files enable secure client connections using SSL; see
Section 6.4.1, “Configuring MySQL to Use Encrypted Connections”.
For more information about SSL file autogeneration, including file names and characteristics, see Section 6.4.3.1, “Creating SSL and RSA Certificates and Keys using MySQL”
The
sha256_password_auto_generate_rsa_keys
and
caching_sha2_password_auto_generate_rsa_keys
system variables are related but control autogeneration of RSA
key-pair files needed for secure password exchange using RSA
over unencypted connections.
Property | Value |
---|---|
Command-Line Format | --avoid-temporal-upgrade={OFF|ON} |
Deprecated | Yes |
System Variable | avoid_temporal_upgrade |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
This variable controls whether ALTER
TABLE
implicitly upgrades temporal columns found to
be in pre-5.6.4 format (TIME
,
DATETIME
, and
TIMESTAMP
columns without
support for fractional seconds precision). Upgrading such
columns requires a table rebuild, which prevents any use of
fast alterations that might otherwise apply to the operation
to be performed.
This variable is disabled by default. Enabling it causes
ALTER TABLE
not to rebuild
temporal columns and thereby be able to take advantage of
possible fast alterations.
This variable is deprecated and will be removed in a future MySQL release.
Property | Value |
---|---|
System Variable | back_log |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | -1 (signifies autosizing; do not assign this literal value) |
Minimum Value | 1 |
Maximum Value | 65535 |
The number of outstanding connection requests MySQL can have.
This comes into play when the main MySQL thread gets very many
connection requests in a very short time. It then takes some
time (although very little) for the main thread to check the
connection and start a new thread. The
back_log
value indicates how
many requests can be stacked during this short time before
MySQL momentarily stops answering new requests. You need to
increase this only if you expect a large number of connections
in a short period of time.
In other words, this value is the size of the listen queue for
incoming TCP/IP connections. Your operating system has its own
limit on the size of this queue. The manual page for the Unix
listen()
system call should have more
details. Check your OS documentation for the maximum value for
this variable. back_log
cannot be set higher than your operating system limit.
The default value is the value of
max_connections
, which
enables the permitted backlog to adjust to the maximum
permitted number of connections.
Property | Value |
---|---|
Command-Line Format | --basedir=dir_name |
System Variable | basedir |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | directory name |
Default Value (>= 8.0.2) | parent of mysqld installation directory |
Default Value (<= 8.0.1) | configuration-dependent default |
The path to the MySQL installation base directory.
Property | Value |
---|---|
Command-Line Format | --big-tables |
System Variable | big_tables |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
If set to 1, all temporary tables are stored on disk rather
than in memory. This is a little slower, but the error
The table
does not occur for
tbl_name
is
fullSELECT
operations that require
a large temporary table. The default value for a new
connection is 0 (use in-memory temporary tables). Normally,
you should never need to set this variable. When in-memory
internal temporary tables are managed by
the TempTable
storage engine (the default),
and the maximum amount of memory that can be occupied by the
TempTable
storage engine is exceeded, the
TempTable
storage engine starts storing
data to temporary files on disk. When in-memory temporary
tables are managed by the MEMORY
storage
engine, in-memory tables are automatically converted to
disk-based tables as required. For more information, see
Section 8.4.4, “Internal Temporary Table Use in MySQL”.
Property | Value |
---|---|
Command-Line Format | --bind-address=addr |
System Variable | bind_address |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | string |
Default Value | * |
The value of the --bind-address
option.
Property | Value |
---|---|
Command-Line Format | --block-encryption-mode=# |
System Variable | block_encryption_mode |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value | aes-128-ecb |
This variable controls the block encryption mode for
block-based algorithms such as AES. It affects encryption for
AES_ENCRYPT()
and
AES_DECRYPT()
.
block_encryption_mode
takes a
value in
aes-
format, where keylen
-mode
keylen
is the key
length in bits and mode
is the
encryption mode. The value is not case-sensitive. Permitted
keylen
values are 128, 192, and
256. Permitted encryption modes depend on whether MySQL was
compiled using OpenSSL or wolfSSL:
For OpenSSL, permitted mode
values are: ECB
,
CBC
, CFB1
,
CFB8
, CFB128
,
OFB
For wolfSSL, permitted mode
values are: ECB
, CBC
For example, this statement causes the AES encryption functions to use a key length of 256 bits and the CBC mode:
SET block_encryption_mode = 'aes-256-cbc';
An error occurs for attempts to set
block_encryption_mode
to a
value containing an unsupported key length or a mode that the
SSL library does not support.
Property | Value |
---|---|
Command-Line Format | --bulk-insert-buffer-size=# |
System Variable | bulk_insert_buffer_size |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
Default Value | 8388608 |
Minimum Value | 0 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
MyISAM
uses a special tree-like cache to
make bulk inserts faster for
INSERT ...
SELECT
, INSERT ... VALUES (...), (...),
...
, and
LOAD DATA
INFILE
when adding data to nonempty tables. This
variable limits the size of the cache tree in bytes per
thread. Setting it to 0 disables this optimization. The
default value is 8MB.
caching_sha2_password_auto_generate_rsa_keys
Property | Value |
---|---|
Command-Line Format | --caching-sha2-password-auto-generate-rsa-keys[={OFF|ON}] |
Introduced | 8.0.4 |
System Variable | caching_sha2_password_auto_generate_rsa_keys |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | ON |
This variable is available if the server was compiled using OpenSSL (see Section 6.4.4, “OpenSSL Versus wolfSSL”). The server uses it to determine whether to autogenerate RSA private/public key-pair files in the data directory if they do not already exist.
At startup, the server automatically generates RSA
private/public key-pair files in the data directory if all of
these conditions are true: The
sha256_password_auto_generate_rsa_keys
or
caching_sha2_password_auto_generate_rsa_keys
system variable is enabled; no RSA options are specified; the
RSA files are missing from the data directory. These key-pair
files enable secure password exchange using RSA over
unencrypted connections for accounts authenticated by the
sha256_password
or
caching_sha2_password
plugin; see
Section 6.5.1.2, “SHA-256 Pluggable Authentication”, and
Section 6.5.1.3, “Caching SHA-2 Pluggable Authentication”.
For more information about RSA file autogeneration, including file names and characteristics, see Section 6.4.3.1, “Creating SSL and RSA Certificates and Keys using MySQL”
The auto_generate_certs
system variable is related but controls autogeneration of SSL
certificate and key files needed for secure connections using
SSL.
caching_sha2_password_private_key_path
Property | Value |
---|---|
Command-Line Format | --caching-sha2-password-private-key-path=file_name |
Introduced | 8.0.3 |
System Variable | caching_sha2_password_private_key_path |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | file name |
Default Value | private_key.pem |
This variable specifies the path name of the RSA private key
file for the caching_sha2_password
authentication plugin. If the file is named as a relative
path, it is interpreted relative to the server data directory.
The file must be in PEM format.
Because this file stores a private key, its access mode should be restricted so that only the MySQL server can read it.
For information about
caching_sha2_password
, see
Section 6.5.1.3, “Caching SHA-2 Pluggable Authentication”.
caching_sha2_password_public_key_path
Property | Value |
---|---|
Command-Line Format | --caching-sha2-password-public-key-path=file_name |
Introduced | 8.0.3 |
System Variable | caching_sha2_password_public_key_path |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | file name |
Default Value | public_key.pem |
This variable specifies the path name of the RSA public key
file for the caching_sha2_password
authentication plugin. If the file is named as a relative
path, it is interpreted relative to the server data directory.
The file must be in PEM format.
For information about
caching_sha2_password
, including
information about how clients request the RSA public key, see
Section 6.5.1.3, “Caching SHA-2 Pluggable Authentication”.
Property | Value |
---|---|
System Variable | character_set_client |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value (>= 8.0.1) | utf8mb4 |
Default Value (8.0.0) | utf8 |
The character set for statements that arrive from the client.
The session value of this variable is set using the character
set requested by the client when the client connects to the
server. (Many clients support a
--default-character-set
option to enable this
character set to be specified explicitly. See also
Section 10.4, “Connection Character Sets and Collations”.) The global value of the
variable is used to set the session value in cases when the
client-requested value is unknown or not available, or the
server is configured to ignore client requests:
The client is from a version of MySQL older than MySQL 4.1, and thus does not request a character set.
The client requests a character set not known to the
server. For example, a Japanese-enabled client requests
sjis
when connecting to a server not
configured with sjis
support.
mysqld was started with the
--skip-character-set-client-handshake
option, which causes it to ignore client character set
configuration. This reproduces MySQL 4.0 behavior and is
useful should you wish to upgrade the server without
upgrading all the clients.
ucs2
, utf16
,
utf16le
, and utf32
cannot be used as a client character set, which means that
they also do not work for SET
NAMES
or SET CHARACTER
SET
.
Property | Value |
---|---|
System Variable | character_set_connection |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value (>= 8.0.1) | utf8mb4 |
Default Value (8.0.0) | utf8 |
The character set used for literals that do not have a character set introducer and for number-to-string conversion. For information about introducers, see Section 10.3.8, “Character Set Introducers”.
Property | Value |
---|---|
System Variable | character_set_database |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value (>= 8.0.1) | utf8mb4 |
Default Value (8.0.0) | latin1 |
Footnote | This option is dynamic, but only the server should set this information. You should not set the value of this variable manually. |
The character set used by the default database. The server
sets this variable whenever the default database changes. If
there is no default database, the variable has the same value
as character_set_server
.
The global
character_set_database
and
collation_database
system
variables are deprecated and will be removed in a future
version of MySQL.
Assigning a value to the session
character_set_database
and
collation_database
system
variables is deprecated and assignments produce a warning. The
session variables will become read only in a future version of
MySQL and assignments will produce an error. It will remain
possible to access the session variables to determine the
database character set and collation for the default database.
Property | Value |
---|---|
Command-Line Format | --character-set-filesystem=name |
System Variable | character_set_filesystem |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value | binary |
The file system character set. This variable is used to
interpret string literals that refer to file names, such as in
the LOAD DATA
INFILE
and
SELECT ... INTO
OUTFILE
statements and the
LOAD_FILE()
function. Such file
names are converted from
character_set_client
to
character_set_filesystem
before the file opening attempt occurs. The default value is
binary
, which means that no conversion
occurs. For systems on which multibyte file names are
permitted, a different value may be more appropriate. For
example, if the system represents file names using UTF-8, set
character_set_filesystem
to
'utf8'
.
Property | Value |
---|---|
System Variable | character_set_results |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value (>= 8.0.1) | utf8mb4 |
Default Value (8.0.0) | utf8 |
The character set used for returning query results such as result sets or error messages to the client.
Property | Value |
---|---|
Command-Line Format | --character-set-server |
System Variable | character_set_server |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value (>= 8.0.1) | utf8mb4 |
Default Value (8.0.0) | latin1 |
The server's default character set.
Property | Value |
---|---|
System Variable | character_set_system |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | string |
Default Value | utf8 |
The character set used by the server for storing identifiers.
The value is always utf8
.
Property | Value |
---|---|
Command-Line Format | --character-sets-dir=dir_name |
System Variable | character_sets_dir |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | directory name |
The directory where character sets are installed.
Property | Value |
---|---|
Command-Line Format | --check-proxy-users=[={OFF|ON}] |
System Variable | check_proxy_users |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
Some authentication plugins implement proxy user mapping for
themselves (for example, the PAM and Windows authentication
plugins). Other authentication plugins do not support proxy
users by default. Of these, some can request that the MySQL
server itself map proxy users according to granted proxy
privileges: mysql_native_password
,
sha256_password
.
If the check_proxy_users
system variable is enabled, the server performs proxy user
mapping for any authentication plugins that make such a
request. However, it may also be necessary to enable
plugin-specific system variables to take advantage of server
proxy user mapping support:
For the mysql_native_password
plugin,
enable
mysql_native_password_proxy_users
.
For the sha256_password
plugin, enable
sha256_password_proxy_users
.
For information about user proxying, see Section 6.3.11, “Proxy Users”.
Property | Value |
---|---|
System Variable | collation_connection |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
The collation of the connection character set.
Property | Value |
---|---|
System Variable | collation_database |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value (>= 8.0.1) | utf8mb4_0900_ai_ci |
Default Value (8.0.0) | latin1_swedish_ci |
Footnote | This option is dynamic, but only the server should set this information. You should not set the value of this variable manually. |
The collation used by the default database. The server sets
this variable whenever the default database changes. If there
is no default database, the variable has the same value as
collation_server
.
The global
character_set_database
and
collation_database
system
variables are deprecated and will be removed in a future
version of MySQL.
Assigning a value to the session
character_set_database
and
collation_database
system
variables is deprecated and assignments produce a warning. The
session variables will become read only in a future version of
MySQL and assignments will produce an error. It will remain
possible to access the session variables to determine the
database character set and collation for the default database.
Property | Value |
---|---|
Command-Line Format | --collation-server |
System Variable | collation_server |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value (>= 8.0.1) | utf8mb4_0900_ai_ci |
Default Value (8.0.0) | latin1_swedish_ci |
The server's default collation.
Property | Value |
---|---|
Command-Line Format | --completion-type=# |
System Variable | completion_type |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value | NO_CHAIN |
Valid Values |
|
The transaction completion type. This variable can take the values shown in the following table. The variable can be assigned using either the name values or corresponding integer values.
Value | Description |
---|---|
NO_CHAIN (or 0) |
COMMIT and
ROLLBACK
are unaffected. This is the default value. |
CHAIN (or 1) |
COMMIT and
ROLLBACK
are equivalent to COMMIT AND CHAIN
and ROLLBACK AND CHAIN , respectively.
(A new transaction starts immediately with the same
isolation level as the just-terminated transaction.) |
RELEASE (or 2) |
COMMIT and
ROLLBACK
are equivalent to COMMIT RELEASE and
ROLLBACK RELEASE , respectively. (The
server disconnects after terminating the transaction.) |
completion_type
affects
transactions that begin with
START
TRANSACTION
or
BEGIN
and
end with COMMIT
or
ROLLBACK
. It
does not apply to implicit commits resulting from execution of
the statements listed in Section 13.3.3, “Statements That Cause an Implicit Commit”. It
also does not apply for
XA
COMMIT
,
XA
ROLLBACK
, or when
autocommit=1
.
Property | Value |
---|---|
Command-Line Format | --concurrent-insert[=#] |
System Variable | concurrent_insert |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value | AUTO |
Valid Values |
|
If AUTO
(the default), MySQL permits
INSERT
and
SELECT
statements to run
concurrently for MyISAM
tables that have no
free blocks in the middle of the data file. If you start
mysqld with
--skip-new
,
this variable is set to NEVER
.
This variable can take the values shown in the following table. The variable can be assigned using either the name values or corresponding integer values.
Value | Description |
---|---|
NEVER (or 0) |
Disables concurrent inserts |
AUTO (or 1) |
(Default) Enables concurrent insert for MyISAM tables
that do not have holes |
ALWAYS (or 2) |
Enables concurrent inserts for all MyISAM tables,
even those that have holes. For a table with a hole, new
rows are inserted at the end of the table if it is in
use by another thread. Otherwise, MySQL acquires a
normal write lock and inserts the row into the hole. |
See also Section 8.11.3, “Concurrent Inserts”.
Property | Value |
---|---|
Command-Line Format | --connect-timeout=# |
System Variable | connect_timeout |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 10 |
Minimum Value | 2 |
Maximum Value | 31536000 |
The number of seconds that the mysqld
server waits for a connect packet before responding with
Bad handshake
. The default value is 10
seconds.
Increasing the
connect_timeout
value might
help if clients frequently encounter errors of the form
Lost connection to MySQL server at
'
.
XXX
', system error:
errno
Property | Value |
---|---|
System Variable | core_file |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
Whether to write a core file if the server crashes. This
variable is set by the
--core-file
option.
Property | Value |
---|---|
Command-Line Format | --cte-max-recursion-depth=# |
Introduced | 8.0.3 |
System Variable | cte_max_recursion_depth |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 1000 |
Minimum Value | 0 |
Maximum Value | 4294967295 |
The common table expression (CTE) maximum recursion depth. The server terminates execution of any CTE that recurses more levels than the value of this variable. For more information, see Limiting Common Table Expression Recursion.
Property | Value |
---|---|
Command-Line Format | --datadir=dir_name |
System Variable | datadir |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | directory name |
The path to the MySQL server data directory. Relative paths
are resolved with respect to the current directory. If the
server will be started automatically (that is, in contexts for
which you cannot assume what the current directory will be),
it is best to specify the
datadir
value as an absolute
path.
This system variable was removed in MySQL 8.0.3.
This system variable was removed in MySQL 8.0.3.
Property | Value |
---|---|
Command-Line Format | --debug[=debug_options] |
System Variable | debug |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value (Windows) | d:t:i:O,\mysqld.trace |
Default Value (Unix) | d:t:i:o,/tmp/mysqld.trace |
This variable indicates the current debugging settings. It is
available only for servers built with debugging support. The
initial value comes from the value of instances of the
--debug
option given at server
startup. The global and session values may be set at runtime.
The SYSTEM_VARIABLES_ADMIN
or
SUPER
privilege is required,
even for the session value.
Assigning a value that begins with +
or
-
cause the value to added to or subtracted
from the current value:
mysql>SET debug = 'T';
mysql>SELECT @@debug;
+---------+ | @@debug | +---------+ | T | +---------+ mysql>SET debug = '+P';
mysql>SELECT @@debug;
+---------+ | @@debug | +---------+ | P:T | +---------+ mysql>SET debug = '-P';
mysql>SELECT @@debug;
+---------+ | @@debug | +---------+ | T | +---------+
For more information, see Section 28.5.3, “The DBUG Package”.
Property | Value |
---|---|
System Variable | debug_sync |
Scope | Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
This variable is the user interface to the Debug Sync
facility. Use of Debug Sync requires that MySQL be configured
with the -DENABLE_DEBUG_SYNC=1
CMake option (see
Section 2.8.4, “MySQL Source-Configuration Options”). If Debug Sync
is not compiled in, this system variable is not available.
The global variable value is read only and indicates whether
the facility is enabled. By default, Debug Sync is disabled
and the value of debug_sync
is OFF
. If the server is started with
--debug-sync-timeout=
,
where N
N
is a timeout value greater
than 0, Debug Sync is enabled and the value of
debug_sync
is ON -
current signal
followed by the signal name. Also,
N
becomes the default timeout for
individual synchronization points.
The session value can be read by any user and will have the
same value as the global variable. The session value can be
set by users that have the
SYSTEM_VARIABLES_ADMIN
or
SUPER
privilege to control
synchronization points.
For a description of the Debug Sync facility and how to use synchronization points, see MySQL Internals: Test Synchronization.
Property | Value |
---|---|
Command-Line Format | --default-authentication-plugin=plugin_name |
System Variable | default_authentication_plugin |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value (>= 8.0.4) | caching_sha2_password |
Default Value (<= 8.0.3) | mysql_native_password |
Valid Values (>= 8.0.3) |
|
Valid Values (<= 8.0.2) |
|
The default authentication plugin. These values are permitted:
mysql_native_password
: Use MySQL native
passwords; see
Section 6.5.1.1, “Native Pluggable Authentication”.
sha256_password
: Use SHA-256 passwords;
see Section 6.5.1.2, “SHA-256 Pluggable Authentication”.
caching_sha2_password
: Use SHA-256
passwords; see
Section 6.5.1.3, “Caching SHA-2 Pluggable Authentication”.
In MySQL 8.0, caching_sha2_password
is
the default authentication plugin rather than
mysql_native_password
. For information
about the implications of this change for server operation
and compatibility of the server with clients and connectors,
see caching_sha2_password as the Preferred Authentication Plugin.
The
default_authentication_plugin
value affects these aspects of server operation:
It determines which authentication plugin the server
assigns to new accounts created by
CREATE USER
and
GRANT
statements that do
not explicitly specify an authentication plugin.
For an account created with the following statement, the server associates the account with the default authentication plugin and assigns the account the given password, hashed as required by that plugin:
CREATE USER ... IDENTIFIED BY 'cleartext password
';
Property | Value |
---|---|
Introduced | 8.0.11 |
System Variable | default_collation_for_utf8mb4 |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Valid Values |
|
For internal use by replication. This system variable is set
to the default collation for the utf8mb4
character set. The value of the variable is replicated from a
master to a slave so that the slave can correctly process data
originating from a master with a different default collation
for utf8mb4
. This variable is primarily
intended to support replication from a MySQL 5.7 or older
master server to a MySQL 8.0 slave server, or group
replication with a MySQL 5.7 primary node and one or more
MySQL 8.0 secondaries. The default collation for
utf8mb4
in MySQL 5.7 is
utf8mb4_general_ci
, but
utf8mb4_0900_ai_ci
in MySQL 8.0. The
variable is not present in releases earlier than MySQL 8.0, so
if the slave does not receive a value for the variable, it
assumes the master is from an earlier release and sets the
value to the previous default collation
utf8mb4_general_ci
.
The default utf8mb4
collation is used in
the following statements:
CREATE TABLE
and
ALTER TABLE
having a
CHARACTER SET utf8mb4
clause without a
COLLATION
clause, either for the table
character set or for a column character set.
CREATE DATABASE
and
ALTER DATABASE
having a
CHARACTER SET utf8mb4
clause without a
COLLATION
clause.
Any statement containing a string literal of the form
_utf8mb4'
without a
some
text
'COLLATE
clause.
Property | Value |
---|---|
Command-Line Format | --default-password-lifetime=# |
System Variable | default_password_lifetime |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 0 |
Minimum Value | 0 |
Maximum Value | 65535 |
This variable defines the global automatic password expiration
policy. The default
default_password_lifetime
value is 0, which disables automatic password expiration. If
the value of
default_password_lifetime
is
a positive integer N
, it indicates
the permitted password lifetime; passwords must be changed
every N
days.
The global password expiration policy can be overridden as
desired for individual accounts using the password expiration
option of the CREATE USER
and
ALTER USER
statements. See
Section 6.3.8, “Password Management”.
Property | Value |
---|---|
Command-Line Format | --default-storage-engine=name |
System Variable | default_storage_engine |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value | InnoDB |
The default storage engine. This variable sets the storage
engine for permanent tables only. To set the storage engine
for TEMPORARY
tables, set the
default_tmp_storage_engine
system variable.
To see which storage engines are available and enabled, use
the SHOW ENGINES
statement or
query the INFORMATION_SCHEMA
ENGINES
table.
If you disable the default storage engine at server startup,
you must set the default engine for both permanent and
TEMPORARY
tables to a different engine or
the server will not start.
Property | Value |
---|---|
Command-Line Format | --default-tmp-storage-engine=name |
System Variable | default_tmp_storage_engine |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | enumeration |
Default Value | InnoDB |
The default storage engine for TEMPORARY
tables (created with
CREATE TEMPORARY
TABLE
). To set the storage engine for permanent
tables, set the
default_storage_engine
system
variable. Also see the discussion of that variable regarding
possible values.
If you disable the default storage engine at server startup,
you must set the default engine for both permanent and
TEMPORARY
tables to a different engine or
the server will not start.
Property | Value |
---|---|
Command-Line Format | --default-week-format=# |
System Variable | default_week_format |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 0 |
Minimum Value | 0 |
Maximum Value | 7 |
The default mode value to use for the
WEEK()
function. See
Section 12.7, “Date and Time Functions”.
Property | Value |
---|---|
Command-Line Format | --delay-key-write[=name] |
System Variable | delay_key_write |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value | ON |
Valid Values |
|
This option applies only to MyISAM
tables.
It can have one of the following values to affect handling of
the DELAY_KEY_WRITE
table option that can
be used in CREATE TABLE
statements.
Option | Description |
---|---|
OFF |
DELAY_KEY_WRITE is ignored. |
ON |
MySQL honors any DELAY_KEY_WRITE option specified in
CREATE TABLE statements.
This is the default value. |
ALL |
All new opened tables are treated as if they were created with the
DELAY_KEY_WRITE option enabled. |
If DELAY_KEY_WRITE
is enabled for a table,
the key buffer is not flushed for the table on every index
update, but only when the table is closed. This speeds up
writes on keys a lot, but if you use this feature, you should
add automatic checking of all MyISAM
tables
by starting the server with the
--myisam-recover-options
option
(for example,
--myisam-recover-options=BACKUP,FORCE
).
See Section 5.1.6, “Server Command Options”, and
Section 16.2.1, “MyISAM Startup Options”.
If you enable external locking with
--external-locking
, there is
no protection against index corruption for tables that use
delayed key writes.
Property | Value |
---|---|
Command-Line Format | --delayed-insert-limit=# |
Deprecated | Yes |
System Variable | delayed_insert_limit |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 100 |
Minimum Value | 1 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
This system variable is deprecated (because
DELAYED
inserts are not supported), and
will be removed in a future release.
Property | Value |
---|---|
Command-Line Format | --delayed-insert-timeout=# |
Deprecated | Yes |
System Variable | delayed_insert_timeout |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 300 |
This system variable is deprecated (because
DELAYED
inserts are not supported), and
will be removed in a future release.
Property | Value |
---|---|
Command-Line Format | --delayed-queue-size=# |
Deprecated | Yes |
System Variable | delayed_queue_size |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 1000 |
Minimum Value | 1 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
This system variable is deprecated (because
DELAYED
inserts are not supported), and
will be removed in a future release.
Property | Value |
---|---|
Command-Line Format | --disabled-storage-engines=engine[,engine]... |
System Variable | disabled_storage_engines |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | string |
Default Value | empty string |
This variable indicates which storage engines cannot be used
to create tables or tablespaces. For example, to prevent new
MyISAM
or FEDERATED
tables from being created, start the server with these lines
in the server option file:
[mysqld] disabled_storage_engines="MyISAM,FEDERATED"
By default,
disabled_storage_engines
is
empty (no engines disabled), but it can be set to a
comma-separated list of one or more engines (not case
sensitive). Any engine named in the value cannot be used to
create tables or tablespaces with CREATE
TABLE
or CREATE
TABLESPACE
, and cannot be used with
ALTER TABLE ...
ENGINE
or
ALTER
TABLESPACE ... ENGINE
to change the storage engine
of existing tables or tablespaces. Attempts to do so result in
an ER_DISABLED_STORAGE_ENGINE
error.
disabled_storage_engines
does
not restrict other DDL statements for existing tables, such as
CREATE INDEX
,
TRUNCATE TABLE
,
ANALYZE TABLE
,
DROP TABLE
, or
DROP TABLESPACE
. This permits a
smooth transition so that existing tables or tablespaces that
use a disabled engine can be migrated to a permitted engine by
means such as
ALTER TABLE ...
ENGINE
.
permitted_engine
It is permitted to set the
default_storage_engine
or
default_tmp_storage_engine
system variable to a storage engine that is disabled. This
could cause applications to behave erratically or fail,
although that might be a useful technique in a development
environment for identifying applications that use disabled
engines, so that they can be modified.
disabled_storage_engines
is
disabled and has no effect if the server is started with any
of these options: --initialize
,
--initialize-insecure
,
--skip-grant-tables
.
Setting
disabled_storage_engines
might cause an issue with mysql_upgrade.
For details, see Section 4.4.5, “mysql_upgrade — Check and Upgrade MySQL Tables”.
disconnect_on_expired_password
Property | Value |
---|---|
Command-Line Format | --disconnect-on-expired-password[=#] |
System Variable | disconnect_on_expired_password |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | ON |
This variable controls how the server handles clients with expired passwords:
If the client indicates that it can handle expires
passwords, the value of
disconnect_on_expired_password
is irrelevant. The server permits the client to connect
but puts it in sandbox mode.
If the client does not indicate that it can handle expires
passwords, the server handles the client according to the
value of
disconnect_on_expired_password
:
If
disconnect_on_expired_password
:
is enabled, the server disconnects the client.
If
disconnect_on_expired_password
:
is disabled, the server permits the client to connect
but puts it in sandbox mode.
For more information about the interaction of client and server settings relating to expired-password handling, see Section 6.3.9, “Server Handling of Expired Passwords”.
Property | Value |
---|---|
Command-Line Format | --div-precision-increment=# |
System Variable | div_precision_increment |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
Default Value | 4 |
Minimum Value | 0 |
Maximum Value | 30 |
This variable indicates the number of digits by which to
increase the scale of the result of division operations
performed with the
/
operator.
The default value is 4. The minimum and maximum values are 0
and 30, respectively. The following example illustrates the
effect of increasing the default value.
mysql>SELECT 1/7;
+--------+ | 1/7 | +--------+ | 0.1429 | +--------+ mysql>SET div_precision_increment = 12;
mysql>SELECT 1/7;
+----------------+ | 1/7 | +----------------+ | 0.142857142857 | +----------------+
dragnet.log_error_filter_rules
Property | Value |
---|---|
Command-Line Format | --dragnet.log-error-filter-rules |
Introduced | 8.0.4 |
System Variable | dragnet.log_error_filter_rules |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value | IF prio>=INFORMATION THEN drop. IF EXISTS source_line THEN unset source_line. |
The filter rules that control operation of the
log_filter_dragnet
error log filter
component. If log_filter_dragnet
is not
installed,
dragnet.log_error_filter_rules
is unavailable. If log_filter_dragnet
is
installed but not enabled, changes to
dragnet.log_error_filter_rules
have no effect.
As of MySQL 8.0.12, the
dragnet.Status
status
variable can be consulted to determine the result of the most
recent assignment to
dragnet.log_error_filter_rules
.
Prior to MySQL 8.0.12, successful assignments to
dragnet.log_error_filter_rules
at runtime produce a note confirming the new value:
mysql>SET GLOBAL dragnet.log_error_filter_rules = 'IF prio <> 0 THEN unset prio.';
Query OK, 0 rows affected, 1 warning (0.00 sec) mysql>SHOW WARNINGS\G
*************************** 1. row *************************** Level: Note Code: 4569 Message: filter configuration accepted: SET @@global.dragnet.log_error_filter_rules= 'IF prio!=ERROR THEN unset prio.';
The value displayed by SHOW
WARNINGS
indicates the “decompiled”
canonical representation after the rule set has been
successfully parsed and compiled into internal form.
Semantically, this canonical form is identical to the value
assigned to
dragnet.log_error_filter_rules
,
but there may be some differences between the assigned and
canonical values, as illustrated by the preceding example:
The <>
operator is changed to
!=
.
The numeric priority of 0 is changed to the corresponding
severity symbol ERROR
.
Optional spaces are removed.
For additional information, see Section 5.4.2.5, “Error Log Filtering”, and Section 5.5.1, “Error Log Components”.
Property | Value |
---|---|
System Variable | end_markers_in_json |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | boolean |
Default Value | OFF |
Whether optimizer JSON output should add end markers. See MySQL Internals: The end_markers_in_json System Variable.
Property | Value |
---|---|
System Variable | eq_range_index_dive_limit |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
Default Value | 200 |
Minimum Value | 0 |
Maximum Value | 4294967295 |
This variable indicates the number of equality ranges in an
equality comparison condition when the optimizer should switch
from using index dives to index statistics in estimating the
number of qualifying rows. It applies to evaluation of
expressions that have either of these equivalent forms, where
the optimizer uses a nonunique index to look up
col_name
values:
col_name
IN(val1
, ...,valN
)col_name
=val1
OR ... ORcol_name
=valN
In both cases, the expression contains
N
equality ranges. The optimizer
can make row estimates using index dives or index statistics.
If eq_range_index_dive_limit
is greater than 0, the optimizer uses existing index
statistics instead of index dives if there are
eq_range_index_dive_limit
or
more equality ranges. Thus, to permit use of index dives for
up to N
equality ranges, set
eq_range_index_dive_limit
to
N
+ 1. To disable use of index
statistics and always use index dives regardless of
N
, set
eq_range_index_dive_limit
to
0.
For more information, see Equality Range Optimization of Many-Valued Comparisons.
To update table index statistics for best estimates, use
ANALYZE TABLE
.
The number of errors that resulted from the last statement that generated messages. This variable is read only. See Section 13.7.6.17, “SHOW ERRORS Syntax”.
Property | Value |
---|---|
Command-Line Format | --event-scheduler[=value] |
System Variable | event_scheduler |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value (>= 8.0.3) | ON |
Default Value (<= 8.0.2) | OFF |
Valid Values |
|
This variable indicates the status of the Event Scheduler;
possible values are ON
,
OFF
, and DISABLED
, with
the default being ON
. This variable and its
effects on the Event Scheduler's operation are discussed in
greater detail in the
Overview section
of the Events chapter.
explicit_defaults_for_timestamp
Property | Value |
---|---|
Command-Line Format | --explicit-defaults-for-timestamp=# |
Deprecated | Yes |
System Variable | explicit_defaults_for_timestamp |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value (>= 8.0.2) | ON |
Default Value (<= 8.0.1) | OFF |
This system variable determines whether the server enables
certain nonstandard behaviors for default values and
NULL
-value handling in
TIMESTAMP
columns. By default,
explicit_defaults_for_timestamp
is enabled, which disables the nonstandard behaviors.
Disabling
explicit_defaults_for_timestamp
results in a warning.
The global and session values may be set at runtime. The
SYSTEM_VARIABLES_ADMIN
or
SUPER
privilege is required,
even for the session value.
If
explicit_defaults_for_timestamp
is disabled, the server enables the nonstandard behaviors and
handles TIMESTAMP
columns as
follows:
TIMESTAMP
columns not
explicitly declared with the NULL
attribute are automatically declared with the NOT
NULL
attribute. Assigning such a column a value
of NULL
is permitted and sets the
column to the current timestamp.
The first TIMESTAMP
column
in a table, if not explicitly declared with the
NULL
attribute or an explicit
DEFAULT
or ON UPDATE
attribute, is automatically declared with the
DEFAULT CURRENT_TIMESTAMP
and
ON UPDATE CURRENT_TIMESTAMP
attributes.
TIMESTAMP
columns following
the first one, if not explicitly declared with the
NULL
attribute or an explicit
DEFAULT
attribute, are automatically
declared as DEFAULT '0000-00-00
00:00:00'
(the “zero” timestamp).
For inserted rows that specify no explicit value for such
a column, the column is assigned '0000-00-00
00:00:00'
and no warning occurs.
Depending on whether strict SQL mode or the
NO_ZERO_DATE
SQL mode is
enabled, a default value of '0000-00-00
00:00:00'
may be invalid. Be aware that the
TRADITIONAL
SQL mode
includes strict mode and
NO_ZERO_DATE
. See
Section 5.1.10, “Server SQL Modes”.
The nonstandard behaviors just described are deprecated and will be removed in a future MySQL release.
If
explicit_defaults_for_timestamp
is enabled, the server disables the nonstandard behaviors and
handles TIMESTAMP
columns as
follows:
It is not possible to assign a
TIMESTAMP
column a value of
NULL
to set it to the current
timestamp. To assign the current timestamp, set the column
to CURRENT_TIMESTAMP
or a
synonym such as NOW()
.
TIMESTAMP
columns not
explicitly declared with the NOT NULL
attribute are automatically declared with the
NULL
attribute and permit
NULL
values. Assigning such a column a
value of NULL
sets it to
NULL
, not the current timestamp.
TIMESTAMP
columns declared
with the NOT NULL
attribute do not
permit NULL
values. For inserts that
specify NULL
for such a column, the
result is either an error for a single-row insert or if
strict SQL mode is enabled, or '0000-00-00
00:00:00'
is inserted for multiple-row inserts
with strict SQL mode disabled. In no case does assigning
the column a value of NULL
set it to
the current timestamp.
TIMESTAMP
columns
explicitly declared with the NOT NULL
attribute and without an explicit
DEFAULT
attribute are treated as having
no default value. For inserted rows that specify no
explicit value for such a column, the result depends on
the SQL mode. If strict SQL mode is enabled, an error
occurs. If strict SQL mode is not enabled, the column is
declared with the implicit default of '0000-00-00
00:00:00'
and a warning occurs. This is similar
to how MySQL treats other temporal types such as
DATETIME
.
No TIMESTAMP
column is
automatically declared with the DEFAULT
CURRENT_TIMESTAMP
or ON UPDATE
CURRENT_TIMESTAMP
attributes. Those attributes
must be explicitly specified.
The first TIMESTAMP
column
in a table is not handled differently from
TIMESTAMP
columns following
the first one.
If
explicit_defaults_for_timestamp
is disabled at server startup, this warning appears in the
error log:
[Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
As indicated by the warning, to disable the deprecated
nonstandard behaviors, enable the
explicit_defaults_for_timestamp
system variable at server startup.
explicit_defaults_for_timestamp
is itself deprecated because its only purpose is to permit
control over deprecated
TIMESTAMP
behaviors that are
to be removed in a future MySQL release. When removal of
those behaviors occurs,
explicit_defaults_for_timestamp
will have no purpose and will be removed as well.
For additional information, see Section 11.3.5, “Automatic Initialization and Updating for TIMESTAMP and DATETIME”.
Property | Value |
---|---|
System Variable | external_user |
Scope | Session |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | string |
The external user name used during the authentication process,
as set by the plugin used to authenticate the client. With
native (built-in) MySQL authentication, or if the plugin does
not set the value, this variable is NULL
.
See Section 6.3.11, “Proxy Users”.
Property | Value |
---|---|
Command-Line Format | --flush |
System Variable | flush |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
If ON
, the server flushes (synchronizes)
all changes to disk after each SQL statement. Normally, MySQL
does a write of all changes to disk only after each SQL
statement and lets the operating system handle the
synchronizing to disk. See Section B.5.3.3, “What to Do If MySQL Keeps Crashing”. This
variable is set to ON
if you start
mysqld with the
--flush
option.
If flush
is enabled, the
value of flush_time
does
not matter and changes to
flush_time
have no effect
on flush behavior.
Property | Value |
---|---|
Command-Line Format | --flush-time=# |
System Variable | flush_time |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 0 |
Minimum Value | 0 |
If this is set to a nonzero value, all tables are closed every
flush_time
seconds to free up
resources and synchronize unflushed data to disk. This option
is best used only on systems with minimal resources.
If flush
is enabled, the
value of flush_time
does
not matter and changes to
flush_time
have no effect
on flush behavior.
Property | Value |
---|---|
System Variable | foreign_key_checks |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | boolean |
Default Value | 1 |
If set to 1 (the default), foreign key constraints for
InnoDB
tables are checked. If set to 0,
foreign key constraints are ignored, with a couple of
exceptions. When re-creating a table that was dropped, an
error is returned if the table definition does not conform to
the foreign key constraints referencing the table. Likewise,
an ALTER TABLE
operation
returns an error if a foreign key definition is incorrectly
formed. For more information, see
Section 13.1.18.6, “Using FOREIGN KEY Constraints”.
Typically you leave this setting enabled during normal
operation, to enforce
referential
integrity. Disabling foreign key checking can be useful
for reloading InnoDB
tables in an order
different from that required by their parent/child
relationships. See
Section 15.8.1.6, “InnoDB and FOREIGN KEY Constraints”.
Setting foreign_key_checks
to 0 also
affects data definition statements:
DROP
SCHEMA
drops a schema even if it contains tables
that have foreign keys that are referred to by tables outside
the schema, and DROP TABLE
drops tables that have foreign keys that are referred to by
other tables.
Setting foreign_key_checks
to 1 does not
trigger a scan of the existing table data. Therefore, rows
added to the table while
foreign_key_checks = 0
will
not be verified for consistency.
Dropping an index required by a foreign key constraint is
not permitted, even with
foreign_key_checks=0
. The
foreign key constraint must be removed before dropping the
index.
Property | Value |
---|---|
Command-Line Format | --ft-boolean-syntax=name |
System Variable | ft_boolean_syntax |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value | + -><()~*:""&| |
The list of operators supported by boolean full-text searches
performed using IN BOOLEAN MODE
. See
Section 12.9.2, “Boolean Full-Text Searches”.
The default variable value is
'+ -><()~*:""&|'
. The rules
for changing the value are as follows:
Operator function is determined by position within the string.
The replacement value must be 14 characters.
Each character must be an ASCII nonalphanumeric character.
Either the first or second character must be a space.
No duplicates are permitted except the phrase quoting operators in positions 11 and 12. These two characters are not required to be the same, but they are the only two that may be.
Positions 10, 13, and 14 (which by default are set to
:
, &
, and
|
) are reserved for future extensions.
Property | Value |
---|---|
Command-Line Format | --ft-max-word-len=# |
System Variable | ft_max_word_len |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | integer |
Minimum Value | 10 |
The maximum length of the word to be included in a
MyISAM
FULLTEXT
index.
FULLTEXT
indexes on
MyISAM
tables must be rebuilt after
changing this variable. Use REPAIR TABLE
.
tbl_name
QUICK
Property | Value |
---|---|
Command-Line Format | --ft-min-word-len=# |
System Variable | ft_min_word_len |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 4 |
Minimum Value | 1 |
The minimum length of the word to be included in a
MyISAM
FULLTEXT
index.
FULLTEXT
indexes on
MyISAM
tables must be rebuilt after
changing this variable. Use REPAIR TABLE
.
tbl_name
QUICK
Property | Value |
---|---|
Command-Line Format | --ft-query-expansion-limit=# |
System Variable | ft_query_expansion_limit |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 20 |
Minimum Value | 0 |
Maximum Value | 1000 |
The number of top matches to use for full-text searches
performed using WITH QUERY EXPANSION
.
Property | Value |
---|---|
Command-Line Format | --ft-stopword-file=file_name |
System Variable | ft_stopword_file |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | file name |
The file from which to read the list of stopwords for
full-text searches on MyISAM
tables. The
server looks for the file in the data directory unless an
absolute path name is given to specify a different directory.
All the words from the file are used; comments are
not honored. By default, a built-in list
of stopwords is used (as defined in the
storage/myisam/ft_static.c
file). Setting
this variable to the empty string (''
)
disables stopword filtering. See also
Section 12.9.4, “Full-Text Stopwords”.
FULLTEXT
indexes on
MyISAM
tables must be rebuilt after
changing this variable or the contents of the stopword file.
Use REPAIR TABLE
.
tbl_name
QUICK
Property | Value |
---|---|
Command-Line Format | --general-log |
System Variable | general_log |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
Whether the general query log is enabled. The value can be 0
(or OFF
) to disable the log or 1 (or
ON
) to enable the log. The default value
depends on whether the
--general_log
option is given.
The destination for log output is controlled by the
log_output
system variable;
if that value is NONE
, no log entries are
written even if the log is enabled.
Property | Value |
---|---|
Command-Line Format | --general-log-file=file_name |
System Variable | general_log_file |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | file name |
Default Value | host_name.log |
The name of the general query log file. The default value is
,
but the initial value can be changed with the
host_name
.log--general_log_file
option.
Property | Value |
---|---|
Command-Line Format | --group-concat-max-len=# |
System Variable | group_concat_max_len |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
Default Value | 1024 |
Minimum Value | 4 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
The maximum permitted result length in bytes for the
GROUP_CONCAT()
function. The
default is 1024.
YES
if the zlib
compression library is available to the server,
NO
if not. If not, the
COMPRESS()
and
UNCOMPRESS()
functions cannot
be used.
This system variable was removed in MySQL 8.0.3.
YES
if mysqld supports
dynamic loading of plugins, NO
if not. If
the value is NO
, you cannot use options
such as --plugin-load
to load
plugins at server startup, or the INSTALL
PLUGIN
statement to load plugins at runtime.
YES
if the server supports spatial data
types, NO
if not.
This variable is an alias for
have_ssl
.
YES
if statement profiling capability is
present, NO
if not. If present, the
profiling
system variable controls whether
this capability is enabled or disabled. See
Section 13.7.6.31, “SHOW PROFILES Syntax”.
This variable is deprecated and will be removed in a future MySQL release.
The query cache was removed in MySQL 8.0.3.
have_query_cache
is
deprecated, always has a value of NO
, and
will be removed in a future MySQL release.
YES
if RTREE
indexes are
available, NO
if not. (These are used for
spatial indexes in MyISAM
tables.)
YES
if mysqld supports
SSL connections, NO
if not.
DISABLED
indicates that the server was
compiled with SSL support, but was not started with the
appropriate
--ssl-
options.
For more information, see
Section 6.4.5, “Building MySQL with Support for Encrypted Connections”.
xxx
Property | Value |
---|---|
System Variable | have_statement_timeout |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | boolean |
Whether the statement execution timeout feature is available
(see Statement Execution Time Optimizer Hints). The
value can be NO
if the background thread
used by this feature could not be initialized.
YES
if symbolic link support is enabled,
NO
if not. This is required on Unix for
support of the DATA DIRECTORY
and
INDEX DIRECTORY
table options. If the
server is started with the
--skip-symbolic-links
option, the value is DISABLED
.
This variable has no meaning on Windows.
Symbolic link support, along with the the
--symbolic-links
option that
controls it, is deprecated and will be removed in a future
version of MySQL. In addition, the option is disabled by
default. The related
have_symlink
system
variable also is deprecated and will be removed in a future
version of MySQL.
histogram_generation_max_mem_size
Property | Value |
---|---|
Command-Line Format | --histogram-generation-max-mem-size=# |
Introduced | 8.0.2 |
System Variable | histogram_generation_max_mem_size |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 20000000 |
Minimum Value | 1000000 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
The maximum amount of memory available for generating histogram statistics. See Section 8.9.6, “Optimizer Statistics”, and Section 13.7.3.1, “ANALYZE TABLE Syntax”.
The global and session values may be set at runtime. The
SYSTEM_VARIABLES_ADMIN
or
SUPER
privilege is required,
even for the session value.
Property | Value |
---|---|
System Variable | host_cache_size |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | -1 (signifies autosizing; do not assign this literal value) |
Minimum Value | 0 |
Maximum Value | 65536 |
The size of the internal host cache (see
Section 8.12.4.2, “DNS Lookup Optimization and the Host Cache”). Setting the size to 0 disables
the host cache. Changing the cache size at runtime implicitly
causes a FLUSH HOSTS
operation
to clear the host cache and truncate the
host_cache
table.
The default value is 128, plus 1 for a value of
max_connections
up to 500,
plus 1 for every increment of 20 over 500 in the
max_connections
value, capped
to a limit of 2000.
Use of --skip-host-cache
is
similar to setting the
host_cache_size
system
variable to 0, but
host_cache_size
is more
flexible because it can also be used to resize, enable, or
disable the host cache at runtime, not just at server startup.
If you start the server with
--skip-host-cache
, that does
not prevent changes to the value of
host_cache_size
, but such
changes have no effect and the cache is not re-enabled even if
host_cache_size
is set larger
than 0.
The server sets this variable to the server host name at startup.
This variable is a synonym for the
last_insert_id
variable. It
exists for compatibility with other database systems. You can
read its value with SELECT @@identity
, and
set it using SET identity
.
Property | Value |
---|---|
Command-Line Format | --init-connect=name |
System Variable | init_connect |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
A string to be executed by the server for each client that
connects. The string consists of one or more SQL statements,
separated by semicolon characters. For example, each client
session begins by default with autocommit mode enabled. For
older servers (before MySQL 5.5.8), there is no global
autocommit
system variable to
specify that autocommit should be disabled by default, but as
a workaround init_connect
can
be used to achieve the same effect:
SET GLOBAL init_connect='SET autocommit=0';
The init_connect
variable can
also be set on the command line or in an option file. To set
the variable as just shown using an option file, include these
lines:
[mysqld] init_connect='SET autocommit=0'
For users that have the
CONNECTION_ADMIN
or
SUPER
privilege, the content of
init_connect
is not executed.
This is done so that an erroneous value for
init_connect
does not prevent
all clients from connecting. For example, the value might
contain a statement that has a syntax error, thus causing
client connections to fail. Not executing
init_connect
for users that
have the CONNECTION_ADMIN
or
SUPER
privilege enables them to
open a connection and fix the
init_connect
value.
As of MySQL 8.0.5,
init_connect
execution is
skipped for any client user with an expired password. This is
done because such a user cannot execute arbitrary statements,
and thus init_connect
execution will fail, leaving the client unable to connect.
Skipping init_connect
execution enables the user to connect and change password.
The server discards any result sets produced by statements in
the value of init_connect
.
information_schema_stats_expiry
Property | Value |
---|---|
Command-Line Format | --information-schema-stats-expiry=value |
Introduced | 8.0.3 |
System Variable | information_schema_stats_expiry |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 86400 |
Minimum Value | 0 |
Maximum Value | 31536000 |
Some INFORMATION_SCHEMA
tables contain
columns that provide table statistics:
STATISTICS.CARDINALITY TABLES.AUTO_INCREMENT TABLES.AVG_ROW_LENGTH TABLES.CHECKSUM TABLES.CHECK_TIME TABLES.CREATE_TIME TABLES.DATA_FREE TABLES.DATA_LENGTH TABLES.INDEX_LENGTH TABLES.MAX_DATA_LENGTH TABLES.TABLE_ROWS TABLES.UPDATE_TIME
Those columns represent dynamic table metadata; that is, information that changes as table contents change.
By default, MySQL retrieves cached values for those columns
from the mysql.index_stats
and
mysql.table_stats
dictionary tables when
the columns are queried, which is more efficient than
retrieving statistics directly from the storage engine. If
cached statistics are not available or have expired, MySQL
retrieves the latest statistics from the storage engine and
caches them in the mysql.index_stats
and
mysql.table_stats
dictionary tables.
Subsequent queries retrieve the cached statistics until the
cached statistics expire.
The
information_schema_stats_expiry
session variable defines the period of time before cached
statistics expire. The default is 86400 seconds (24 hours),
but the time period can be extended to as much as one year.
To update cached values at any time for a given table, use
ANALYZE TABLE
.
To always retrieve the latest statistics directly from the
storage engine and bypass cached values, set
information_schema_stats_expiry
to 0
.
Querying statistics columns does not store or update
statistics in the mysql.index_stats
and
mysql.table_stats
dictionary tables under
these circumstances:
When cached statistics have not expired.
When
information_schema_stats_expiry
is set to 0.
When the server is started in
read_only
,
super_read_only
,
transaction_read_only
, or
innodb_read_only
mode.
When the query also fetches Performance Schema data.
information_schema_stats_expiry
is a session variable, and each client session can define its
own expiration value. Statistics that are retrieved from the
storage engine and cached by one session are available to
other sessions.
For related information, see Section 8.2.3, “Optimizing INFORMATION_SCHEMA Queries”.
Property | Value |
---|---|
Command-Line Format | --init-file=file_name |
System Variable | init_file |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | file name |
The name of the file specified with the
--init-file
option when you
start the server. This should be a file containing SQL
statements that you want the server to execute when it starts.
Each statement must be on a single line and should not include
comments. For more information, see the description of
--init-file
.
innodb_
xxx
InnoDB
system variables are
listed in Section 15.13, “InnoDB Startup Options and System Variables”. These variables
control many aspects of storage, memory use, and I/O patterns
for InnoDB
tables, and are especially
important now that InnoDB
is the default
storage engine.
The value to be used by the following
INSERT
or
ALTER TABLE
statement when
inserting an AUTO_INCREMENT
value. This is
mainly used with the binary log.
Property | Value |
---|---|
Command-Line Format | --interactive-timeout=# |
System Variable | interactive_timeout |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 28800 |
Minimum Value | 1 |
The number of seconds the server waits for activity on an
interactive connection before closing it. An interactive
client is defined as a client that uses the
CLIENT_INTERACTIVE
option to
mysql_real_connect()
. See also
wait_timeout
.
internal_tmp_disk_storage_engine
Property | Value |
---|---|
Command-Line Format | --internal-tmp-disk-storage-engine=# |
System Variable | internal_tmp_disk_storage_engine |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value | INNODB |
Valid Values |
|
The storage engine for on-disk internal temporary tables (see
Section 8.4.4, “Internal Temporary Table Use in MySQL”). Permitted values
are MYISAM
and INNODB
(the default).
The optimizer uses the
storage engine defined by
internal_tmp_disk_storage_engine
for on-disk internal temporary tables.
When using
internal_tmp_disk_storage_engine=INNODB
(the default), queries that generate on-disk internal
temporary tables that exceed
InnoDB
row or column limits will return Row size
too large or Too many
columns errors. The workaround is to set
internal_tmp_disk_storage_engine
to MYISAM
.
internal_tmp_mem_storage_engine
Property | Value |
---|---|
Command-Line Format | --internal-tmp-mem-storage-engine=# |
Introduced | 8.0.2 |
System Variable | internal_tmp_mem_storage_engine |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | enumeration |
Default Value | TempTable |
Valid Values |
|
The storage engine for in-memory internal temporary tables
(see Section 8.4.4, “Internal Temporary Table Use in MySQL”). Permitted
values are TempTable
(the default) and
MEMORY
.
The optimizer uses the
storage engine defined by
internal_tmp_mem_storage_engine
for in-memory internal temporary tables.
Property | Value |
---|---|
Command-Line Format | --join-buffer-size=# |
System Variable | join_buffer_size |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
Default Value | 262144 |
Minimum Value | 128 |
Maximum Value (Other, 64-bit platforms) | 18446744073709547520 |
Maximum Value (Other, 32-bit platforms) | 4294967295 |
Maximum Value (Windows) | 4294967295 |
The minimum size of the buffer that is used for plain index
scans, range index scans, and joins that do not use indexes
and thus perform full table scans. Normally, the best way to
get fast joins is to add indexes. Increase the value of
join_buffer_size
to get a
faster full join when adding indexes is not possible. One join
buffer is allocated for each full join between two tables. For
a complex join between several tables for which indexes are
not used, multiple join buffers might be necessary.
Unless Batched Key Access (BKA) is used, there is no gain from setting the buffer larger than required to hold each matching row, and all joins allocate at least the minimum size, so use caution in setting this variable to a large value globally. It is better to keep the global setting small and change to a larger setting only in sessions that are doing large joins. Memory allocation time can cause substantial performance drops if the global size is larger than needed by most queries that use it.
When BKA is used, the value of
join_buffer_size
defines how
large the batch of keys is in each request to the storage
engine. The larger the buffer, the more sequential access will
be to the right hand table of a join operation, which can
significantly improve performance.
The default is 256KB. The maximum permissible setting for
join_buffer_size
is
4GB−1. Larger values are permitted for 64-bit platforms
(except 64-bit Windows, for which large values are truncated
to 4GB−1 with a warning).
For additional information about join buffering, see Section 8.2.1.6, “Nested-Loop Join Algorithms”. For information about Batched Key Access, see Section 8.2.1.11, “Block Nested-Loop and Batched Key Access Joins”.
Property | Value |
---|---|
Command-Line Format | --keep-files-on-create=# |
System Variable | keep_files_on_create |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
If a MyISAM
table is created with no
DATA DIRECTORY
option, the
.MYD
file is created in the database
directory. By default, if MyISAM
finds an
existing .MYD
file in this case, it
overwrites it. The same applies to .MYI
files for tables created with no INDEX
DIRECTORY
option. To suppress this behavior, set the
keep_files_on_create
variable
to ON
(1), in which case
MyISAM
will not overwrite existing files
and returns an error instead. The default value is
OFF
(0).
If a MyISAM
table is created with a
DATA DIRECTORY
or INDEX
DIRECTORY
option and an existing
.MYD
or .MYI
file is
found, MyISAM always returns an error. It will not overwrite a
file in the specified directory.
Property | Value |
---|---|
Command-Line Format | --key-buffer-size=# |
System Variable | key_buffer_size |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 8388608 |
Minimum Value | 8 |
Maximum Value (64-bit platforms) | OS_PER_PROCESS_LIMIT |
Maximum Value (32-bit platforms) | 4294967295 |
Index blocks for MyISAM
tables are buffered
and are shared by all threads.
key_buffer_size
is the size
of the buffer used for index blocks. The key buffer is also
known as the key cache.
The maximum permissible setting for
key_buffer_size
is
4GB−1 on 32-bit platforms. Larger values are permitted
for 64-bit platforms. The effective maximum size might be
less, depending on your available physical RAM and per-process
RAM limits imposed by your operating system or hardware
platform. The value of this variable indicates the amount of
memory requested. Internally, the server allocates as much
memory as possible up to this amount, but the actual
allocation might be less.
You can increase the value to get better index handling for
all reads and multiple writes; on a system whose primary
function is to run MySQL using the
MyISAM
storage engine, 25% of the
machine's total memory is an acceptable value for this
variable. However, you should be aware that, if you make the
value too large (for example, more than 50% of the
machine's total memory), your system might start to page
and become extremely slow. This is because MySQL relies on the
operating system to perform file system caching for data
reads, so you must leave some room for the file system cache.
You should also consider the memory requirements of any other
storage engines that you may be using in addition to
MyISAM
.
For even more speed when writing many rows at the same time,
use LOCK TABLES
. See
Section 8.2.5.1, “Optimizing INSERT Statements”.
You can check the performance of the key buffer by issuing a
SHOW STATUS
statement and
examining the
Key_read_requests
,
Key_reads
,
Key_write_requests
, and
Key_writes
status variables.
(See Section 13.7.6, “SHOW Syntax”.) The
Key_reads/Key_read_requests
ratio should
normally be less than 0.01. The
Key_writes/Key_write_requests
ratio is
usually near 1 if you are using mostly updates and deletes,
but might be much smaller if you tend to do updates that
affect many rows at the same time or if you are using the
DELAY_KEY_WRITE
table option.
The fraction of the key buffer in use can be determined using
key_buffer_size
in
conjunction with the
Key_blocks_unused
status
variable and the buffer block size, which is available from
the key_cache_block_size
system variable:
1 - ((Key_blocks_unused * key_cache_block_size) / key_buffer_size)
This value is an approximation because some space in the key buffer is allocated internally for administrative structures. Factors that influence the amount of overhead for these structures include block size and pointer size. As block size increases, the percentage of the key buffer lost to overhead tends to decrease. Larger blocks results in a smaller number of read operations (because more keys are obtained per read), but conversely an increase in reads of keys that are not examined (if not all keys in a block are relevant to a query).
It is possible to create multiple MyISAM
key caches. The size limit of 4GB applies to each cache
individually, not as a group. See
Section 8.10.2, “The MyISAM Key Cache”.
Property | Value |
---|---|
Command-Line Format | --key-cache-age-threshold=# |
System Variable | key_cache_age_threshold |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 300 |
Minimum Value | 100 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
This value controls the demotion of buffers from the hot sublist of a key cache to the warm sublist. Lower values cause demotion to happen more quickly. The minimum value is 100. The default value is 300. See Section 8.10.2, “The MyISAM Key Cache”.
Property | Value |
---|---|
Command-Line Format | --key-cache-block-size=# |
System Variable | key_cache_block_size |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 1024 |
Minimum Value | 512 |
Maximum Value | 16384 |
The size in bytes of blocks in the key cache. The default value is 1024. See Section 8.10.2, “The MyISAM Key Cache”.
Property | Value |
---|---|
Command-Line Format | --key-cache-division-limit=# |
System Variable | key_cache_division_limit |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 100 |
Minimum Value | 1 |
Maximum Value | 100 |
The division point between the hot and warm sublists of the key cache buffer list. The value is the percentage of the buffer list to use for the warm sublist. Permissible values range from 1 to 100. The default value is 100. See Section 8.10.2, “The MyISAM Key Cache”.
Property | Value |
---|---|
System Variable | large_files_support |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Whether mysqld was compiled with options for large file support.
Property | Value |
---|---|
Command-Line Format | --large-pages |
System Variable | large_pages |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Platform Specific | Linux |
Type | boolean |
Default Value | FALSE |
Whether large page support is enabled (via the
--large-pages
option). See
Section 8.12.3.2, “Enabling Large Page Support”.
Property | Value |
---|---|
System Variable | large_page_size |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 0 |
If large page support is enabled, this shows the size of memory pages. Large memory pages are supported only on Linux; on other platforms, the value of this variable is always 0. See Section 8.12.3.2, “Enabling Large Page Support”.
The value to be returned from
LAST_INSERT_ID()
. This is
stored in the binary log when you use
LAST_INSERT_ID()
in a statement
that updates a table. Setting this variable does not update
the value returned by the
mysql_insert_id()
C API
function.
Property | Value |
---|---|
Command-Line Format | --lc-messages=name |
System Variable | lc_messages |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value | en_US |
The locale to use for error messages. The default is
en_US
. The server converts the argument to
a language name and combines it with the value of
lc_messages_dir
to produce
the location for the error message file. See
Section 10.11, “Setting the Error Message Language”.
Property | Value |
---|---|
Command-Line Format | --lc-messages-dir=dir_name |
System Variable | lc_messages_dir |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | directory name |
The directory where error messages are located. The server
uses the value together with the value of
lc_messages
to produce the
location for the error message file. See
Section 10.11, “Setting the Error Message Language”.
Property | Value |
---|---|
System Variable | lc_time_names |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
This variable specifies the locale that controls the language
used to display day and month names and abbreviations. This
variable affects the output from the
DATE_FORMAT()
,
DAYNAME()
and
MONTHNAME()
functions. Locale
names are POSIX-style values such as
'ja_JP'
or 'pt_BR'
. The
default value is 'en_US'
regardless of your
system's locale setting. For further information, see
Section 10.15, “MySQL Server Locale Support”.
Property | Value |
---|---|
System Variable | license |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | string |
Default Value | GPL |
The type of license the server has.
Property | Value |
---|---|
System Variable | local_infile |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value (>= 8.0.2) | OFF |
Default Value (<= 8.0.1) | ON |
This variable controls server-side LOCAL
capability for LOAD DATA
statements. Depending on the
local_infile
setting, the
server refuses or permits local data loading by clients that
have LOCAL
enabled on the client side.
To explicitly cause the server to refuse or permit
LOAD DATA
LOCAL
statements (regardless of how client programs
and libraries are configured at build time or runtime), start
mysqld with
local_infile
disabled or
enabled, respectively.
local_infile
can also be set
at runtime. For more information, see
Section 6.1.6, “Security Issues with LOAD DATA LOCAL”.
Property | Value |
---|---|
Command-Line Format | --lock-wait-timeout=# |
System Variable | lock_wait_timeout |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
Default Value | 31536000 |
Minimum Value | 1 |
Maximum Value | 31536000 |
This variable specifies the timeout in seconds for attempts to acquire metadata locks. The permissible values range from 1 to 31536000 (1 year). The default is 31536000.
This timeout applies to all statements that use metadata
locks. These include DML and DDL operations on tables, views,
stored procedures, and stored functions, as well as
LOCK TABLES
,
FLUSH TABLES WITH READ LOCK
,
and HANDLER
statements.
This timeout does not apply to implicit accesses to system
tables in the mysql
database, such as grant
tables modified by GRANT
or
REVOKE
statements or table
logging statements. The timeout does apply to system tables
accessed directly, such as with
SELECT
or
UPDATE
.
The timeout value applies separately for each metadata lock
attempt. A given statement can require more than one lock, so
it is possible for the statement to block for longer than the
lock_wait_timeout
value
before reporting a timeout error. When lock timeout occurs,
ER_LOCK_WAIT_TIMEOUT
is
reported.
lock_wait_timeout
also
defines the amount of time that a LOCK
INSTANCE FOR BACKUP
statement waits for a lock
before giving up.
Property | Value |
---|---|
System Variable | locked_in_memory |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Property | Value |
---|---|
Command-Line Format | --log-error[=file_name] |
System Variable | log_error |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | file name |
The default error log destination. If the destination is the
console, the value is stderr
. Otherwise,
the destination is a file and the
log_error
value is the file
name. See Section 5.4.2, “The Error Log”.
Property | Value |
---|---|
Command-Line Format | --log-error-filter-rules |
Introduced | 8.0.2 |
Removed | 8.0.4 |
System Variable | log_error_filter_rules |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value | set by server |
The filter rules for error logging. This variable is unused. It was removed in MySQL 8.0.4.
Property | Value |
---|---|
Command-Line Format | --log-error-services |
Introduced | 8.0.2 |
System Variable | log_error_services |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value | log_filter_internal; log_sink_internal |
The components to enable for error logging. The variable may
contain a list with 0, 1, or many elements. In the latter
case, elements may be delimited by semicolon or (as of MySQL
8.0.12) comma, optionally followed by space. A given setting
cannot use both semicolon and comma separators. Component
order is significant because the server executes components in
the order listed. Any loadable (not built in) component named
in the log_error_services
value must first be installed with
INSTALL COMPONENT
. For more
information, see
Section 5.4.2.1, “Error Log Component Configuration”.
Property | Value |
---|---|
Command-Line Format | --log-error-suppression-list=value |
Introduced | 8.0.13 |
System Variable | log_error_suppression_list |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value | empty string |
This variable enables specifying which diagnostics should not
be written to the error log when they occur with a severity of
WARNING
or INFORMATION
.
For example, if a particular type of warning occurs frequently
but is not of interest (and thus may be considered undesirable
“noise” in the error log), it can be suppressed.
The variable value may be the empty string for no suppression, or a list of one or more comma-separated values indicating the error codes to suppress.
The numeric value of each code to be suppressed must be in a permitted range:
1 up to (but not including) 1000: Global error codes that are shared by the server and clients
10000 and higher: Server error codes intended to be written to the error log (not sent to clients)
Attempts to assign an error code not in a permitted range produce an error and the variable value remains unchanged.
Error codes may be specified in numeric or symbolic form. A
numeric code may be specified with or without the
MY-
prefix. Leading zeros in the numeric
part are not significant. Examples of permitted code formats:
31 00031 MY-31 MY-00031 ER_SERVER_SHUTDOWN_COMPLETE
For a list of error codes and symbols, see Section B.3, “Server Error Codes and Messages”.
The server can generate messages for a given error code at
differing severities, so suppression for a message associated
with an error code listed in
log_error_suppression_list
depends on its severity. Suppose that the variable has a value
of '10000,10001,MY-10002'
. Messages for
those codes are not written to the error log if generated with
a severity of WARNING
or
INFORMATION
. Messages generated with a
severity of ERROR
or
SYSTEM
are not suppressed and are written
to the error log.
The effect of
log_error_suppression_list
combines with that of
log_error_verbosity
. Consider
a server started with these settings:
[mysqld] log_error_verbosity=2 # error and warning messages only log_error_suppression_list='10000,10001,MY-10002'
In this case,
log_error_verbosity
discards
all messages with INFORMATION
severity. Of
the remaining messages,
log_error_suppression_list
discards messages with WARNING
severity and
any of the named error codes.
The log_error_verbosity
value shown in the example (2) is also its default value, so
its effect on suppression of all
INFORMATION
messages is by default as
just described. You must set
log_error_verbosity
to 3 if
you want
log_error_suppression_list
to affect messages with INFORMATION
severity.
Consider a server started with this setting:
[mysqld] log_error_verbosity=1 # error messages only
In this case,
log_error_verbosity
discards
all messages with WARNING
or
INFORMATION
severity. Setting
log_error_suppression_list
has no effect because all error codes it might suppress are
already discarded due to the
log_error_verbosity
setting.
log_error_suppression_list
(like log_error_verbosity
)
affects the log_filter_internal
error log
filter, which is enabled by default. If that filter is
disabled, error code suppression does not occur and must be
modeled using whatever filter service is used instead where
desired (for example, with individual filter rules when using
log_filter_dragnet
). For information about
filter configuration, see
Section 5.4.2.1, “Error Log Component Configuration”.
Property | Value |
---|---|
Command-Line Format | --log-error-verbosity=# |
System Variable | log_error_verbosity |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value (>= 8.0.4) | 2 |
Default Value (<= 8.0.3) | 3 |
Minimum Value | 1 |
Maximum Value | 3 |
The verbosity for handling events intended for the error log,
as filtered by the log_filter_internal
error log filter component, which is enabled by default. If
log_filter_internal
is disabled,
log_error_verbosity
has no
effect.
The following table shows the permitted verbosity values.
Desired Log Filtering | log_error_verbosity Value |
---|---|
Error messages | 1 |
Error and warning messages | 2 |
Error, warning, and information messages | 3 |
Selected important system messages about non-error situations
are printed to the error log regardless of the
log_error_verbosity
value.
These messages include startup and shutdown messages, and some
significant changes to settings.
The effect of
log_error_verbosity
combines
with that of
log_error_suppression_list
.
See the description of the latter for examples.
For additional information, see Section 5.4.2.5, “Error Log Filtering”, and Section 5.5.1, “Error Log Components”.
Property | Value |
---|---|
Command-Line Format | --log-output=name |
System Variable | log_output |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | set |
Default Value | FILE |
Valid Values |
|
The destination for general query log and slow query log
output. The value can be a comma-separated list of one or more
of the words TABLE
(log to tables),
FILE
(log to files), or
NONE
(do not log to tables or files). The
default value is FILE
.
NONE
, if present, takes precedence over any
other specifiers. If the value is NONE
log
entries are not written even if the logs are enabled. If the
logs are not enabled, no logging occurs even if the value of
log_output
is not
NONE
. For more information, see
Section 5.4.1, “Selecting General Query and Slow Query Log Output Destinations”.
Property | Value |
---|---|
Command-Line Format | --log-queries-not-using-indexes |
System Variable | log_queries_not_using_indexes |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
Whether queries that do not use indexes are logged to the slow query log. See Section 5.4.5, “The Slow Query Log”.
Property | Value |
---|---|
System Variable | log_slow_admin_statements |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
Include slow administrative statements in the statements
written to the slow query log. Administrative statements
include ALTER TABLE
,
ANALYZE TABLE
,
CHECK TABLE
,
CREATE INDEX
,
DROP INDEX
,
OPTIMIZE TABLE
, and
REPAIR TABLE
.
Property | Value |
---|---|
Command-Line Format | --log-syslog[={0|1}] |
Deprecated | 8.0.2 (removed in 8.0.13) |
System Variable | log_syslog |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value (Windows, <= 8.0.1) | ON |
Default Value (Unix, <= 8.0.1) | OFF |
Default Value (>= 8.0.2) | ON (when error logging to system log is enabled) |
Prior to MySQL 8.0, this variable controlled
whether to perform error logging to the system log (the Event
Log on Windows, and syslog
on Unix and
Unix-like systems).
In MySQL 8.0, the
log_sink_syseventlog
log component
implements error logging to the system log (see
Section 5.4.2.3, “Error Logging to the System Log”), and
log_syslog
is removed. (Prior
to MySQL 8.0.13, log_syslog
exists but is deprecated and has no effect.)
Property | Value |
---|---|
Command-Line Format | --log-syslog-facility=value |
Removed | 8.0.13 |
System Variable | log_syslog_facility |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value | daemon |
This variable was removed in MySQL 8.0.13 and replaced by
syseventlog.facility
.
Property | Value |
---|---|
Command-Line Format | --log-syslog-include-pid[={0|1}] |
Removed | 8.0.13 |
System Variable | log_syslog_include_pid |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | ON |
This variable was removed in MySQL 8.0.13 and replaced by
syseventlog.include_pid
.
Property | Value |
---|---|
Command-Line Format | --log-syslog-tag=tag |
Removed | 8.0.13 |
System Variable | log_syslog_tag |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value | empty string |
This variable was removed in MySQL 8.0.13 and replaced by
syseventlog.tag
.
Property | Value |
---|---|
Command-Line Format | --log-timestamps=# |
System Variable | log_timestamps |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value | UTC |
Valid Values |
|
This variable controls the time zone of timestamps in messages
written to the error log, and in general query log and slow
query log messages written to files. It does not affect the
time zone of general query log and slow query log messages
written to tables (mysql.general_log
,
mysql.slow_log
). Rows retrieved from those
tables can be converted from the local system time zone to any
desired time zone with
CONVERT_TZ()
or by setting the
session time_zone
system
variable.
Permitted log_timestamps
values are UTC
(the default) and
SYSTEM
(local system time zone).
Timestamps are written using ISO 8601 / RFC 3339 format:
YYYY-MM-DDThh:mm:ss.uuuuuu
plus a tail
value of Z
signifying Zulu time (UTC) or
±hh:mm
(an offset from UTC).
log_throttle_queries_not_using_indexes
Property | Value |
---|---|
System Variable | log_throttle_queries_not_using_indexes |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 0 |
If
log_queries_not_using_indexes
is enabled, the
log_throttle_queries_not_using_indexes
variable limits the number of such queries per minute that can
be written to the slow query log. A value of 0 (the default)
means “no limit”. For more information, see
Section 5.4.5, “The Slow Query Log”.
Property | Value |
---|---|
Command-Line Format | --log-warnings[=#] |
Deprecated | Yes (removed in 8.0.3) |
System Variable | log_warnings |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 2 |
Minimum Value | 0 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
This system variable was removed in MySQL 8.0.3. Use the
log_error_verbosity
system
variable instead.
Property | Value |
---|---|
Command-Line Format | --long-query-time=# |
System Variable | long_query_time |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | numeric |
Default Value | 10 |
Minimum Value | 0 |
If a query takes longer than this many seconds, the server
increments the Slow_queries
status variable. If the slow query log is enabled, the query
is logged to the slow query log file. This value is measured
in real time, not CPU time, so a query that is under the
threshold on a lightly loaded system might be above the
threshold on a heavily loaded one. The minimum and default
values of long_query_time
are
0 and 10, respectively. The value can be specified to a
resolution of microseconds. For logging to a file, times are
written including the microseconds part. For logging to
tables, only integer times are written; the microseconds part
is ignored. See Section 5.4.5, “The Slow Query Log”.
Property | Value |
---|---|
Command-Line Format | --low-priority-updates |
System Variable | low_priority_updates |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | FALSE |
If set to 1
, all
INSERT
,
UPDATE
,
DELETE
, and LOCK TABLE
WRITE
statements wait until there is no pending
SELECT
or LOCK TABLE
READ
on the affected table. This affects only
storage engines that use only table-level locking (such as
MyISAM
, MEMORY
, and
MERGE
).
Property | Value |
---|---|
System Variable | lower_case_file_system |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | boolean |
This variable describes the case sensitivity of file names on
the file system where the data directory is located.
OFF
means file names are case-sensitive,
ON
means they are not case-sensitive. This
variable is read only because it reflects a file system
attribute and setting it would have no effect on the file
system.
Property | Value |
---|---|
Command-Line Format | --lower-case-table-names[=#] |
System Variable | lower_case_table_names |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 0 |
Minimum Value | 0 |
Maximum Value | 2 |
If set to 0, table names are stored as specified and comparisons are case-sensitive. If set to 1, table names are stored in lowercase on disk and comparisons are not case sensitive. If set to 2, table names are stored as given but compared in lowercase. This option also applies to database names and table aliases. For additional details, see Section 9.2.2, “Identifier Case Sensitivity”.
On Windows the default value is 1. On macOS, the default value is 2.
You should not set
lower_case_table_names
to 0
if you are running MySQL on a system where the data directory
resides on a case-insensitive file system (such as on Windows
or macOS). It is an unsupported combination that could result
in a hang condition when running an INSERT INTO ...
SELECT ... FROM
operation with the wrong tbl_name
tbl_name
letter case. With MyISAM
, accessing table
names using different letter cases could cause index
corruption.
An error message is printed and the server exits if you
attempt to start the server with
--lower_case_table_names=0
on
a case-insensitive file system.
If you are using InnoDB
tables, you should
set this variable to 1 on all platforms to force names to be
converted to lowercase.
The setting of this variable in MySQL 8.0 affects the behavior of replication filtering options with regard to case sensitivity. (Bug #51639) See Section 17.2.5, “How Servers Evaluate Replication Filtering Rules”, for more information.
It is prohibited to start the server with a
lower_case_table_names
setting that is different from the setting used when the
server was initialized. The restriction is necessary because
collations used by various data dictionary table fields are
based on the setting defined when the server is initialized,
and restarting the server with a different setting would
introduce inconsistencies with respect to how identifiers are
ordered and compared.
Property | Value |
---|---|
Command-Line Format | --mandatory-roles=value |
Introduced | 8.0.2 |
System Variable | mandatory_roles |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value | empty string |
Roles the server should treat as mandatory. In effect, these
roles are automatically granted to every user, although
setting mandatory_roles
does
not actually change any user accounts, and the granted roles
are not visible in the mysql.role_edges
system table.
The variable value is a comma-separated list of role names. Example:
SET PERSIST mandatory_roles = '`role1`@`%`,`role2`,role3,role4@localhost';
Setting mandatory_roles
requires the ROLE_ADMIN
privilege, in addition to the
SYSTEM_VARIABLES_ADMIN
or
SUPER
privilege normally
required to set a global system variable.
Role names consist of a user part and host part in
format. The host part, if omitted, defaults to
user_name
@host_name
%
. For additional information, see
Section 6.2.5, “Specifying Role Names”.
User names and host names, if quoted, must be written in a fashion permitted for quoting within quoted strings.
Roles named in the value of
mandatory_roles
cannot be
revoked with REVOKE
or dropped
with DROP ROLE
or
DROP USER
.
Mandatory roles, like explicitly granted roles, do not take
effect until activated (see
Activating Roles). At login time, role
activation occurs for all granted roles if the
activate_all_roles_on_login
system variable is enabled, or only for roles that are set as
default roles otherwise. At runtime, SET
ROLE
activates roles.
Roles that do not exist when assigned to
mandatory_roles
but are created later may
require special treatment to be considered mandatory. For
details, see Defining Mandatory Roles.
SHOW GRANTS
displays mandatory
roles according to the rules described in
Section 13.7.6.21, “SHOW GRANTS Syntax”.
Property | Value |
---|---|
Command-Line Format | --max-allowed-packet=# |
System Variable | max_allowed_packet |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value (>= 8.0.3) | 67108864 |
Default Value (<= 8.0.2) | 4194304 |
Minimum Value | 1024 |
Maximum Value | 1073741824 |
The maximum size of one packet or any generated/intermediate
string, or any parameter sent by the
mysql_stmt_send_long_data()
C
API function. The default is 64MB.
The packet message buffer is initialized to
net_buffer_length
bytes, but
can grow up to
max_allowed_packet
bytes when
needed. This value by default is small, to catch large
(possibly incorrect) packets.
You must increase this value if you are using large
BLOB
columns or long strings.
It should be as big as the largest
BLOB
you want to use. The
protocol limit for
max_allowed_packet
is 1GB.
The value should be a multiple of 1024; nonmultiples are
rounded down to the nearest multiple.
When you change the message buffer size by changing the value
of the max_allowed_packet
variable, you should also change the buffer size on the client
side if your client program permits it. The default
max_allowed_packet
value
built in to the client library is 1GB, but individual client
programs might override this. For example,
mysql and mysqldump have
defaults of 16MB and 24MB, respectively. They also enable you
to change the client-side value by setting
max_allowed_packet
on the
command line or in an option file.
The session value of this variable is read only. The client
can receive up to as many bytes as the session value. However,
the server will not send to the client more bytes than the
current global
max_allowed_packet
value.
(The global value could be less than the session value if the
global value is changed after the client connects.)
Property | Value |
---|---|
Command-Line Format | --max-connect-errors=# |
System Variable | max_connect_errors |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 100 |
Minimum Value | 1 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
If more than this many successive connection requests from a
host are interrupted without a successful connection, the
server blocks that host from further connections. You can
unblock blocked hosts by flushing the host cache. To do so,
issue a FLUSH HOSTS
statement
or execute a mysqladmin flush-hosts
command. If a connection is established successfully within
fewer than max_connect_errors
attempts after a previous connection was interrupted, the
error count for the host is cleared to zero. However, once a
host is blocked, flushing the host cache is the only way to
unblock it. The default is 100.
Property | Value |
---|---|
Command-Line Format | --max-connections=# |
System Variable | max_connections |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 151 |
Minimum Value | 1 |
Maximum Value | 100000 |
The maximum permitted number of simultaneous client connections. By default, this is 151. See Section B.5.2.6, “Too many connections”, for more information.
Increasing this value increases the number of file descriptors
that mysqld requires. If the required
number of descriptors are not available, the server reduces
the value of max_connections
.
See Section 8.4.3.1, “How MySQL Opens and Closes Tables”, for comments on file
descriptor limits.
mysqld actually permits
max_connections+1
clients to connect. The extra connection is reserved for use
by accounts that have the
CONNECTION_ADMIN
or
SUPER
privilege. By granting
the SUPER
privilege to
administrators and not to normal users (who should not need
it), an administrator can connect to the server and use
SHOW PROCESSLIST
to diagnose
problems even if the maximum number of unprivileged clients
are connected. See Section 13.7.6.29, “SHOW PROCESSLIST Syntax”.
Connections refused because the
max_connections
limit is
reached increment the
Connection_errors_max_connections
status variable.
Property | Value |
---|---|
Command-Line Format | --max-delayed-threads=# |
Deprecated | Yes |
System Variable | max_delayed_threads |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 20 |
Minimum Value | 0 |
Maximum Value | 16384 |
This system variable is deprecated (because
DELAYED
inserts are not supported), and
will be removed in a future release.
Property | Value |
---|---|
Command-Line Format | --max-digest-length=# |
System Variable | max_digest_length |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 1024 |
Minimum Value | 0 |
Maximum Value | 1048576 |
The maximum number of bytes available for computing normalized statement digests. Once that amount of space is used during digest computation, truncation occurs: no further tokens from a parsed statement are collected or figure into its digest value. Statements that differ only after that many bytes of parsed tokens produce the same normalized statement digest and are considered identical if compared or if aggregated for digest statistics.
Decreasing the
max_digest_length
value
reduces memory use but causes the digest value of more
statements to become indistinguishable if they differ only at
the end. Increasing the value permits longer statements to be
distinguished but increases memory use, particularly for
workloads that involve large numbers of simultaneous sessions
(the server allocates
max_digest_length
bytes per
session).
The parser uses this system variable as a limit on the maximum
length of normalized statement digests that it computes. The
Performance Schema, if it tracks statement digests, makes a
copy of the digest value, using the
performance_schema_max_digest_length
.
system variable as a limit on the maximum length of digests
that it stores. Consequently, if
performance_schema_max_digest_length
is less than
max_digest_length
, digest
values stored in the Performance Schema are truncated relative
to the original digest values.
For more information about statement digesting, see Section 25.9, “Performance Schema Statement Digests and Sampling”.
Property | Value |
---|---|
Command-Line Format | --max-error-count=# |
System Variable | max_error_count |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
Default Value (>= 8.0.3) | 1024 |
Default Value (<= 8.0.2) | 64 |
Minimum Value | 0 |
Maximum Value | 65535 |
The maximum number of error, warning, and information messages
to be stored for display by the SHOW
ERRORS
and SHOW
WARNINGS
statements. This is the same as the number
of condition areas in the diagnostics area, and thus the
number of conditions that can be inspected by
GET DIAGNOSTICS
.
Property | Value |
---|---|
Command-Line Format | --max-execution-time=# |
System Variable | max_execution_time |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
Default Value | 0 |
The execution timeout for
SELECT
statements, in
milliseconds. If the value is 0, timeouts are not enabled.
max_execution_time
applies as
follows:
The global
max_execution_time
value
provides the default for the session value for new
connections. The session value applies to
SELECT
executions executed within the
session that include no
MAX_EXECUTION_TIME(
optimizer hint or for which N
)N
is 0.
max_execution_time
applies to read-only SELECT
statements. Statements that are not read only are those
that invoke a stored function that modifies data as a side
effect.
max_execution_time
is
ignored for SELECT
statements in stored programs.
Property | Value |
---|---|
Command-Line Format | --max-heap-table-size=# |
System Variable | max_heap_table_size |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
Default Value | 16777216 |
Minimum Value | 16384 |
Maximum Value (64-bit platforms) | 1844674407370954752 |
Maximum Value (32-bit platforms) | 4294967295 |
This variable sets the maximum size to which user-created
MEMORY
tables are permitted to grow. The
value of the variable is used to calculate
MEMORY
table MAX_ROWS
values. Setting this variable has no effect on any existing
MEMORY
table, unless the table is
re-created with a statement such as
CREATE TABLE
or altered with
ALTER TABLE
or
TRUNCATE TABLE
. A server
restart also sets the maximum size of existing
MEMORY
tables to the global
max_heap_table_size
value.
This variable is also used in conjunction with
tmp_table_size
to limit the
size of internal in-memory tables. See
Section 8.4.4, “Internal Temporary Table Use in MySQL”.
max_heap_table_size
is not replicated. See
Section 17.4.1.21, “Replication and MEMORY Tables”, and
Section 17.4.1.39, “Replication and Variables”, for more
information.
Property | Value |
---|---|
Deprecated | Yes |
System Variable | max_insert_delayed_threads |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
This variable is a synonym for
max_delayed_threads
.
This system variable is deprecated (because
DELAYED
inserts are not supported), and
will be removed in a future release.
Property | Value |
---|---|
Command-Line Format | --max-join-size=# |
System Variable | max_join_size |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
Default Value | 18446744073709551615 |
Minimum Value | 1 |
Maximum Value | 18446744073709551615 |
Do not permit statements that probably need to examine more
than max_join_size
rows (for
single-table statements) or row combinations (for
multiple-table statements) or that are likely to do more than
max_join_size
disk seeks. By
setting this value, you can catch statements where keys are
not used properly and that would probably take a long time.
Set it if your users tend to perform joins that lack a
WHERE
clause, that take a long time, or
that return millions of rows.
Setting this variable to a value other than
DEFAULT
resets the value of
sql_big_selects
to
0
. If you set the
sql_big_selects
value again,
the max_join_size
variable is
ignored.
Property | Value |
---|---|
Command-Line Format | --max-length-for-sort-data=# |
System Variable | max_length_for_sort_data |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
Default Value (>= 8.0.1) | 4096 |
Default Value (8.0.0) | 1024 |
Minimum Value | 4 |
Maximum Value | 8388608 |
The cutoff on the size of index values that determines which
filesort
algorithm to use. See
Section 8.2.1.14, “ORDER BY Optimization”.
Property | Value |
---|---|
Command-Line Format | --max-points-in-geometry=integer |
System Variable | max_points_in_geometry |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
Default Value | 65536 |
Minimum Value | 3 |
Maximum Value | 1048576 |
The maximum value of the
points_per_circle
argument to the
ST_Buffer_Strategy()
function.
Property | Value |
---|---|
Command-Line Format | --max-prepared-stmt-count=# |
System Variable | max_prepared_stmt_count |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 16382 |
Minimum Value | 0 |
Maximum Value | 1048576 |
This variable limits the total number of prepared statements in the server. It can be used in environments where there is the potential for denial-of-service attacks based on running the server out of memory by preparing huge numbers of statements. If the value is set lower than the current number of prepared statements, existing statements are not affected and can be used, but no new statements can be prepared until the current number drops below the limit. The default value is 16,382. The permissible range of values is from 0 to 1 million. Setting the value to 0 disables prepared statements.
Property | Value |
---|---|
Command-Line Format | --max-seeks-for-key=# |
System Variable | max_seeks_for_key |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
Default Value (64-bit platforms) | 18446744073709551615 |
Default Value (32-bit platforms) | 4294967295 |
Minimum Value | 1 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
Limit the assumed maximum number of seeks when looking up rows based on a key. The MySQL optimizer assumes that no more than this number of key seeks are required when searching for matching rows in a table by scanning an index, regardless of the actual cardinality of the index (see Section 13.7.6.22, “SHOW INDEX Syntax”). By setting this to a low value (say, 100), you can force MySQL to prefer indexes instead of table scans.
Property | Value |
---|---|
Command-Line Format | --max-sort-length=# |
System Variable | max_sort_length |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
Default Value | 1024 |
Minimum Value | 4 |
Maximum Value | 8388608 |
The number of bytes to use when sorting data values. The
server uses only the first
max_sort_length
bytes of each
value and ignores the rest. Consequently, values that differ
only after the first
max_sort_length
bytes compare
as equal for GROUP BY
, ORDER
BY
, and DISTINCT
operations.
Increasing the value of
max_sort_length
may require
increasing the value of
sort_buffer_size
as well. For
details, see Section 8.2.1.14, “ORDER BY Optimization”
Property | Value |
---|---|
Command-Line Format | --max-sp-recursion-depth[=#] |
System Variable | max_sp_recursion_depth |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 0 |
Maximum Value | 255 |
The number of times that any given stored procedure may be called recursively. The default value for this option is 0, which completely disables recursion in stored procedures. The maximum value is 255.
Stored procedure recursion increases the demand on thread
stack space. If you increase the value of
max_sp_recursion_depth
, it
may be necessary to increase thread stack size by increasing
the value of thread_stack
at
server startup.
This system variable was removed in MySQL 8.0.3.
Property | Value |
---|---|
Command-Line Format | --max-user-connections=# |
System Variable | max_user_connections |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 0 |
Minimum Value | 0 |
Maximum Value | 4294967295 |
The maximum number of simultaneous connections permitted to any given MySQL user account. A value of 0 (the default) means “no limit.”
This variable has a global value that can be set at server startup or runtime. It also has a read-only session value that indicates the effective simultaneous-connection limit that applies to the account associated with the current session. The session value is initialized as follows:
If the user account has a nonzero
MAX_USER_CONNECTIONS
resource limit,
the session
max_user_connections
value is set to that limit.
Otherwise, the session
max_user_connections
value is set to the global value.
Account resource limits are specified using the
CREATE USER
or
ALTER USER
statement. See
Section 6.3.6, “Setting Account Resource Limits”.
Property | Value |
---|---|
Command-Line Format | --max-write-lock-count=# |
System Variable | max_write_lock_count |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value (64-bit platforms) | 18446744073709551615 |
Default Value (32-bit platforms) | 4294967295 |
Minimum Value | 1 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
After this many write locks, permit some pending read lock requests to be processed in between.
Property | Value |
---|---|
Command-Line Format | --mecab-rc-file |
System Variable | mecab_rc_file |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | directory name |
The mecab_rc_file
option is used when
setting up the MeCab full-text parser.
The mecab_rc_file
option defines the path
to the mecabrc
configuration file, which
is the configuration file for MeCab. The option is read-only
and can only be set at startup. The
mecabrc
configuration file is required to
initialize MeCab.
For information about the MeCab full-text parser, see Section 12.9.9, “MeCab Full-Text Parser Plugin”.
For information about options that can be specified in the
MeCab mecabrc
configuration file, refer
to the
MeCab
Documentation on the
Google
Developers site.
Property | Value |
---|---|
Deprecated | Yes (removed in 8.0.13) |
System Variable | metadata_locks_cache_size |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 1024 |
Minimum Value | 1 |
Maximum Value | 1048576 |
This system variable was removed in MySQL 8.0.13.
Property | Value |
---|---|
Deprecated | Yes (removed in 8.0.13) |
System Variable | metadata_locks_hash_instances |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 8 |
Minimum Value | 1 |
Maximum Value | 1024 |
This system variable was removed in MySQL 8.0.13.
Property | Value |
---|---|
Command-Line Format | --min-examined-row-limit=# |
System Variable | min_examined_row_limit |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 0 |
Minimum Value | 0 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
Queries that examine fewer than this number of rows are not logged to the slow query log.
Property | Value |
---|---|
Command-Line Format | --multi-range-count=# |
Deprecated | Yes (removed in 8.0.3) |
System Variable | multi_range_count |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 256 |
Minimum Value | 1 |
Maximum Value | 4294967295 |
This system variable was removed in MySQL 8.0.3.
Property | Value |
---|---|
Command-Line Format | --myisam-data-pointer-size=# |
System Variable | myisam_data_pointer_size |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 6 |
Minimum Value | 2 |
Maximum Value | 7 |
The default pointer size in bytes, to be used by
CREATE TABLE
for
MyISAM
tables when no
MAX_ROWS
option is specified. This variable
cannot be less than 2 or larger than 7. The default value is
6. See Section B.5.2.11, “The table is full”.
Property | Value |
---|---|
Command-Line Format | --myisam-max-sort-file-size=# |
System Variable | myisam_max_sort_file_size |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value (64-bit platforms) | 9223372036854775807 |
Default Value (32-bit platforms) | 2147483648 |
The maximum size of the temporary file that MySQL is permitted
to use while re-creating a MyISAM
index
(during REPAIR TABLE
,
ALTER TABLE
, or
LOAD DATA
INFILE
). If the file size would be larger than this
value, the index is created using the key cache instead, which
is slower. The value is given in bytes.
If MyISAM
index files exceed this size and
disk space is available, increasing the value may help
performance. The space must be available in the file system
containing the directory where the original index file is
located.
Property | Value |
---|---|
Command-Line Format | --myisam-mmap-size=# |
System Variable | myisam_mmap_size |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | integer |
Default Value (64-bit platforms) | 18446744073709551615 |
Default Value (32-bit platforms) | 4294967295 |
Minimum Value | 7 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
The maximum amount of memory to use for memory mapping
compressed MyISAM
files. If many
compressed MyISAM
tables are used, the
value can be decreased to reduce the likelihood of
memory-swapping problems.
Property | Value |
---|---|
System Variable | myisam_recover_options |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
The value of the
--myisam-recover-options
option. See Section 5.1.6, “Server Command Options”.
Property | Value |
---|---|
Command-Line Format | --myisam-repair-threads=# |
System Variable | myisam_repair_threads |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 1 |
Minimum Value | 1 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
If this value is greater than 1, MyISAM
table indexes are created in parallel (each index in its own
thread) during the Repair by sorting
process. The default value is 1.
Multithreaded repair is still beta-quality code.
Property | Value |
---|---|
Command-Line Format | --myisam-sort-buffer-size=# |
System Variable | myisam_sort_buffer_size |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 8388608 |
Minimum Value | 4096 |
Maximum Value (Other, 64-bit platforms) | 18446744073709551615 |
Maximum Value (Other, 32-bit platforms) | 4294967295 |
Maximum Value (Windows, 64-bit platforms) | 18446744073709551615 |
Maximum Value (Windows, 32-bit platforms) | 4294967295 |
The size of the buffer that is allocated when sorting
MyISAM
indexes during a
REPAIR TABLE
or when creating
indexes with CREATE INDEX
or
ALTER TABLE
.
Property | Value |
---|---|
Command-Line Format | --myisam-stats-method=name |
System Variable | myisam_stats_method |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value | nulls_unequal |
Valid Values |
|
How the server treats NULL
values when
collecting statistics about the distribution of index values
for MyISAM
tables. This variable has three
possible values, nulls_equal
,
nulls_unequal
, and
nulls_ignored
. For
nulls_equal
, all NULL
index values are considered equal and form a single value
group that has a size equal to the number of
NULL
values. For
nulls_unequal
, NULL
values are considered unequal, and each
NULL
forms a distinct value group of size
1. For nulls_ignored
,
NULL
values are ignored.
The method that is used for generating table statistics influences how the optimizer chooses indexes for query execution, as described in Section 8.3.8, “InnoDB and MyISAM Index Statistics Collection”.
Property | Value |
---|---|
Command-Line Format | --myisam-use-mmap |
System Variable | myisam_use_mmap |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
Use memory mapping for reading and writing
MyISAM
tables.
mysql_native_password_proxy_users
Property | Value |
---|---|
Command-Line Format | --mysql-native-password-proxy-users=[={OFF|ON}] |
System Variable | mysql_native_password_proxy_users |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
This variable controls whether the
mysql_native_password
built-in
authentication plugin supports proxy users. It has no effect
unless the check_proxy_users
system variable is enabled. For information about user
proxying, see Section 6.3.11, “Proxy Users”.
Property | Value |
---|---|
System Variable | named_pipe |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Platform Specific | Windows |
Type | boolean |
Default Value | OFF |
(Windows only.) Indicates whether the server supports connections over named pipes.
Property | Value |
---|---|
Command-Line Format | --net-buffer-length=# |
System Variable | net_buffer_length |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 16384 |
Minimum Value | 1024 |
Maximum Value | 1048576 |
Each client thread is associated with a connection buffer and
result buffer. Both begin with a size given by
net_buffer_length
but are
dynamically enlarged up to
max_allowed_packet
bytes as
needed. The result buffer shrinks to
net_buffer_length
after each
SQL statement.
This variable should not normally be changed, but if you have
very little memory, you can set it to the expected length of
statements sent by clients. If statements exceed this length,
the connection buffer is automatically enlarged. The maximum
value to which
net_buffer_length
can be set
is 1MB.
The session value of this variable is read only.
Property | Value |
---|---|
Command-Line Format | --net-read-timeout=# |
System Variable | net_read_timeout |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 30 |
Minimum Value | 1 |
The number of seconds to wait for more data from a connection
before aborting the read. When the server is reading from the
client, net_read_timeout
is
the timeout value controlling when to abort. When the server
is writing to the client,
net_write_timeout
is the
timeout value controlling when to abort. See also
slave_net_timeout
.
Property | Value |
---|---|
Command-Line Format | --net-retry-count=# |
System Variable | net_retry_count |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 10 |
Minimum Value | 1 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
If a read or write on a communication port is interrupted, retry this many times before giving up. This value should be set quite high on FreeBSD because internal interrupts are sent to all threads.
Property | Value |
---|---|
Command-Line Format | --net-write-timeout=# |
System Variable | net_write_timeout |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 60 |
Minimum Value | 1 |
The number of seconds to wait for a block to be written to a
connection before aborting the write. See also
net_read_timeout
.
Property | Value |
---|---|
Command-Line Format | --new |
System Variable | new |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Disabled by | skip-new |
Type | boolean |
Default Value | FALSE |
This variable was used in MySQL 4.0 to turn on some 4.1
behaviors, and is retained for backward compatibility. Its
value is always OFF
.
Property | Value |
---|---|
Command-Line Format | --ngram-token-size |
System Variable | ngram_token_size |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 2 |
Minimum Value | 1 |
Maximum Value | 10 |
Defines the n-gram token size for the n-gram full-text parser.
The ngram_token_size
option is read-only
and can only be modified at startup. The default value is 2
(bigram). The maximum value is 10.
For more information about how to configure this variable, see Section 12.9.8, “ngram Full-Text Parser”.
Property | Value |
---|---|
Command-Line Format | --offline-mode=val |
System Variable | offline_mode |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
Whether the server is in “offline mode”, which has these characteristics:
Connected client users who do not have the
CONNECTION_ADMIN
or
SUPER
privilege are
disconnected on the next request, with an appropriate
error. Disconnection includes terminating running
statements and releasing locks. Such clients also cannot
initiate new connections, and receive an appropriate
error.
Connected client users who have the
CONNECTION_ADMIN
or
SUPER
privilege are not
disconnected, and can initiate new connections to manage
the server.
Replication slave threads are permitted to keep applying data to the server.
Only users who have the
SYSTEM_VARIABLES_ADMIN
or
SUPER
privilege can control
offline mode. To put a server in offline mode, change the
value of the offline_mode
system variable from OFF
to
ON
. To resume normal operations, change
offline_mode
from
ON
to OFF
. In offline
mode, clients that are refused access receive an
ER_SERVER_OFFLINE_MODE
error.
Property | Value |
---|---|
Command-Line Format | --old |
System Variable | old |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
old
is a compatibility
variable. It is disabled by default, but can be enabled at
startup to revert the server to behaviors present in older
versions.
When old
is enabled, it
changes the default scope of index hints to that used prior to
MySQL 5.1.17. That is, index hints with no
FOR
clause apply only to how indexes are
used for row retrieval and not to resolution of ORDER
BY
or GROUP BY
clauses. (See
Section 8.9.4, “Index Hints”.) Take care about enabling this
in a replication setup. With statement-based binary logging,
having different modes for the master and slaves might lead to
replication errors.
Property | Value |
---|---|
Command-Line Format | --old-alter-table |
System Variable | old_alter_table |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
When this variable is enabled, the server does not use the
optimized method of processing an ALTER
TABLE
operation. It reverts to using a temporary
table, copying over the data, and then renaming the temporary
table to the original, as used by MySQL 5.0 and earlier. For
more information on the operation of
ALTER TABLE
, see
Section 13.1.8, “ALTER TABLE Syntax”.
ALTER TABLE ... DROP PARTITION
with
old_alter_table=ON
rebuilds
the partitioned table and attempts to move data from the
dropped partition to another partition with a compatible
PARTITION ... VALUES
definition. Data that
cannot be moved to another partition is deleted. In earlier
releases, ALTER TABLE ... DROP PARTITION
with old_alter_table=ON
deletes data stored in the partition and drops the partition.
Property | Value |
---|---|
Deprecated | Yes (removed in 8.0.11) |
System Variable | old_passwords |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value | 0 |
Valid Values |
|
This system variable was removed in MySQL 8.0.11.
Property | Value |
---|---|
Command-Line Format | --open-files-limit=# |
System Variable | open_files_limit |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 5000, with possible adjustment |
Minimum Value | 0 |
Maximum Value | platform dependent |
The number of files that the operating system permits mysqld to open. The value of this variable at runtime is the real value permitted by the system and might be different from the value you specify at server startup. The value is 0 on systems where MySQL cannot change the number of open files.
The effective
open_files_limit
value is
based on the value specified at system startup (if any) and
the values of max_connections
and table_open_cache
, using
these formulas:
1) 10 + max_connections + (table_open_cache * 2) 2) max_connections * 5 3) operating system limit if positive 4) if operating system limit is Infinity: open_files_limit value specified at startup, 5000 if none
The server attempts to obtain the number of file descriptors using the maximum of those three values. If that many descriptors cannot be obtained, the server attempts to obtain as many as the system will permit.
Property | Value |
---|---|
Command-Line Format | --optimizer-prune-level[=#] |
System Variable | optimizer_prune_level |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | boolean |
Default Value | 1 |
Controls the heuristics applied during query optimization to prune less-promising partial plans from the optimizer search space. A value of 0 disables heuristics so that the optimizer performs an exhaustive search. A value of 1 causes the optimizer to prune plans based on the number of rows retrieved by intermediate plans.
Property | Value |
---|---|
Command-Line Format | --optimizer-search-depth[=#] |
System Variable | optimizer_search_depth |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
Default Value | 62 |
Minimum Value | 0 |
Maximum Value | 62 |
The maximum depth of search performed by the query optimizer. Values larger than the number of relations in a query result in better query plans, but take longer to generate an execution plan for a query. Values smaller than the number of relations in a query return an execution plan quicker, but the resulting plan may be far from being optimal. If set to 0, the system automatically picks a reasonable value.
Property | Value |
---|---|
Command-Line Format | --optimizer-switch=value |
System Variable | optimizer_switch |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | set |
Valid Values (>= 8.0.13) |
|
Valid Values (>= 8.0.3, <= 8.0.12) |
|
Valid Values (<= 8.0.2) |
|
The optimizer_switch
system
variable enables control over optimizer behavior. The value of
this variable is a set of flags, each of which has a value of
on
or off
to indicate
whether the corresponding optimizer behavior is enabled or
disabled. This variable has global and session values and can
be changed at runtime. The global default can be set at server
startup.
To see the current set of optimizer flags, select the variable value:
mysql> SELECT @@optimizer_switch\G
*************************** 1. row ***************************
@@optimizer_switch: index_merge=on,index_merge_union=on,
index_merge_sort_union=on,
index_merge_intersection=on,
engine_condition_pushdown=on,
index_condition_pushdown=on,
mrr=on,mrr_cost_based=on,
block_nested_loop=on,batched_key_access=off,
materialization=on,semijoin=on,loosescan=on,
firstmatch=on,duplicateweedout=on,
subquery_materialization_cost_based=on,
use_index_extensions=on,
condition_fanout_filter=on,derived_merge=on,
use_invisible_indexes=off,skip_scan=on
For more information about the syntax of this variable and the optimizer behaviors that it controls, see Section 8.9.3, “Switchable Optimizations”.
Property | Value |
---|---|
System Variable | optimizer_trace |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
This variable controls optimizer tracing. For details, see MySQL Internals: Tracing the Optimizer.
Property | Value |
---|---|
System Variable | optimizer_trace_features |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
This variable enables or disables selected optimizer tracing features. For details, see MySQL Internals: Tracing the Optimizer.
Property | Value |
---|---|
System Variable | optimizer_trace_limit |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 1 |
The maximum number of optimizer traces to display. For details, see MySQL Internals: Tracing the Optimizer.
Property | Value |
---|---|
System Variable | optimizer_trace_max_mem_size |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
Default Value (>= 8.0.4) | 1048576 |
Default Value (<= 8.0.3) | 16384 |
The maximum cumulative size of stored optimizer traces. For details, see MySQL Internals: Tracing the Optimizer.
Property | Value |
---|---|
System Variable | optimizer_trace_offset |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | -1 |
The offset of optimizer traces to display. For details, see MySQL Internals: Tracing the Optimizer.
performance_schema_
xxx
Performance Schema system variables are listed in Section 25.14, “Performance Schema System Variables”. These variables may be used to configure Performance Schema operation.
Property | Value |
---|---|
Command-Line Format | --parser-max-mem-size=N |
System Variable | parser_max_mem_size |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value (64-bit platforms) | 18446744073709551615 |
Default Value (32-bit platforms) | 4294967295 |
Minimum Value | 10000000 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
The maximum amount of memory available to the parser. The default value places no limit on memory available. The value can be reduced to protect against out-of-memory situations caused by parsing long or complex SQL statements.
Property | Value |
---|---|
Command-Line Format | --password-history=# |
Introduced | 8.0.3 |
System Variable | password_history |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 0 |
Minimum Value | 0 |
Maximum Value | 4294967295 |
This variable defines the global policy for controlling reuse of previous passwords based on required minimum number of password changes. For an account password used previously, this variable indicates the number of subsequent account password changes that must occur before the password can be reused. If the value is 0 (the default), there is no reuse restriction based on number of password changes.
Changes to this variable apply immediately to all accounts
defined with the PASSWORD HISTORY DEFAULT
option.
The global number-of-changes password reuse policy can be
overridden as desired for individual accounts using the
PASSWORD HISTORY
option of the
CREATE USER
and
ALTER USER
statements. See
Section 6.3.8, “Password Management”.
Property | Value |
---|---|
Command-Line Format | --password-require-current[={OFF|ON}] |
Introduced | 8.0.13 |
System Variable | password_require_current |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
This variable defines the global policy for controlling whether attempts to change an account password must specify the current password to be replaced.
Changes to this variable apply immediately to all accounts
defined with the PASSWORD REQUIRE CURRENT
DEFAULT
option.
The global verification-required policy can be overridden as
desired for individual accounts using the PASSWORD
REQUIRE
option of the CREATE
USER
and ALTER USER
statements. See Section 6.3.8, “Password Management”.
Property | Value |
---|---|
Command-Line Format | --password-reuse-interval=# |
Introduced | 8.0.3 |
System Variable | password_reuse_interval |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 0 |
Minimum Value | 0 |
Maximum Value | 4294967295 |
This variable defines the global policy for controlling reuse of previous passwords based on time elapsed. For an account password used previously, this variable indicates the number of days that must pass before the password can be reused. If the value is 0 (the default), there is no reuse restriction based on time elapsed.
Changes to this variable apply immediately to all accounts
defined with the PASSWORD REUSE INTERVAL
DEFAULT
option.
The global time-elapsed password reuse policy can be
overridden as desired for individual accounts using the
PASSWORD REUSE INTERVAL
option of the
CREATE USER
and
ALTER USER
statements. See
Section 6.3.8, “Password Management”.
Property | Value |
---|---|
Command-Line Format | --persisted-globals-load[=ON|OFF] |
System Variable | persisted_globals_load |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | ON |
Whether to load persisted configuration settings from the
mysqld-auto.cnf
file in the data
directory. The server normally processes this file at startup
after all other option files (see
Section 4.2.6, “Using Option Files”). Disabling
persisted_globals_load
causes
the server startup sequence to skip
mysqld-auto.cnf
.
To modify the contents of
mysqld-auto.cnf
, use the
SET
PERSIST
or PERSIST_ONLY
statement, or the RESET PERSIST
statement. See Section 13.7.5.1, “SET Syntax for Variable Assignment”.
Property | Value |
---|---|
Command-Line Format | --pid-file=file_name |
System Variable | pid_file |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | file name |
The path name of the process ID file. This variable can be set
with the --pid-file
option. The
server creates the file in the data directory unless an
absolute path name is given to specify a different directory.
If you specify the --pid-file
option, you must specify a value. If you do not specify the
--pid-file
option, MySQL uses a
default value of
,
where host_name
.pidhost_name
is the name of the
host machine.
The process ID file is used by other programs such as mysqld_safe to determine the server's process ID. On Windows, this variable also affects the default error log file name. See Section 5.4.2, “The Error Log”.
Property | Value |
---|---|
Command-Line Format | --plugin-dir=dir_name |
System Variable | plugin_dir |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | directory name |
Default Value | BASEDIR/lib/plugin |
The path name of the plugin directory.
If the plugin directory is writable by the server, it may be
possible for a user to write executable code to a file in the
directory using SELECT
... INTO DUMPFILE
. This can be prevented by making
plugin_dir
read only to the
server or by setting
--secure-file-priv
to a
directory where SELECT
writes
can be made safely.
Property | Value |
---|---|
Command-Line Format | --port=# |
System Variable | port |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 3306 |
Minimum Value | 0 |
Maximum Value | 65535 |
The number of the port on which the server listens for TCP/IP
connections. This variable can be set with the
--port
option.
Property | Value |
---|---|
Command-Line Format | --preload-buffer-size=# |
System Variable | preload_buffer_size |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 32768 |
Minimum Value | 1024 |
Maximum Value | 1073741824 |
The size of the buffer that is allocated when preloading indexes.
If set to 0 or OFF
(the default), statement
profiling is disabled. If set to 1 or ON
,
statement profiling is enabled and the
SHOW PROFILE
and
SHOW PROFILES
statements
provide access to profiling information. See
Section 13.7.6.31, “SHOW PROFILES Syntax”.
This variable is deprecated and will be removed in a future MySQL release.
The number of statements for which to maintain profiling
information if profiling
is
enabled. The default value is 15. The maximum value is 100.
Setting the value to 0 effectively disables profiling. See
Section 13.7.6.31, “SHOW PROFILES Syntax”.
This variable is deprecated and will be removed in a future MySQL release.
Property | Value |
---|---|
System Variable | protocol_version |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | integer |
The version of the client/server protocol used by the MySQL server.
Property | Value |
---|---|
System Variable | proxy_user |
Scope | Session |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | string |
If the current client is a proxy for another user, this
variable is the proxy user account name. Otherwise, this
variable is NULL
. See
Section 6.3.11, “Proxy Users”.
Property | Value |
---|---|
System Variable | pseudo_slave_mode |
Scope | Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
This variable is for internal server use.
Property | Value |
---|---|
System Variable | pseudo_thread_id |
Scope | Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
This variable is for internal server use.
Property | Value |
---|---|
Command-Line Format | --query-alloc-block-size=# |
System Variable | query_alloc_block_size |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 8192 |
Minimum Value | 1024 |
Maximum Value | 4294967295 |
Block Size | 1024 |
The allocation size of memory blocks that are allocated for objects created during statement parsing and execution. If you have problems with memory fragmentation, it might help to increase this parameter.
Property | Value |
---|---|
Command-Line Format | --query-cache-limit=# |
Deprecated | Yes (removed in 8.0.3) |
System Variable | query_cache_limit |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 1048576 |
Minimum Value | 0 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
This system variable was removed in MySQL 8.0.3.
Property | Value |
---|---|
Command-Line Format | --query-cache-min-res-unit=# |
Deprecated | Yes (removed in 8.0.3) |
System Variable | query_cache_min_res_unit |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 4096 |
Minimum Value | 512 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
This system variable was removed in MySQL 8.0.3.
Property | Value |
---|---|
Command-Line Format | --query-cache-size=# |
Deprecated | Yes (removed in 8.0.3) |
System Variable | query_cache_size |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value (64-bit platforms, >= 8.0.1) | 0 |
Default Value (64-bit platforms, 8.0.0) | 1048576 |
Default Value (32-bit platforms, >= 8.0.1) | 0 |
Default Value (32-bit platforms, 8.0.0) | 1048576 |
Minimum Value | 0 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
This system variable was removed in MySQL 8.0.3.
Property | Value |
---|---|
Command-Line Format | --query-cache-type=# |
Deprecated | Yes (removed in 8.0.3) |
System Variable | query_cache_type |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value | 0 |
Valid Values |
|
This system variable was removed in MySQL 8.0.3.
Property | Value |
---|---|
Command-Line Format | --query-cache-wlock-invalidate |
Deprecated | Yes (removed in 8.0.3) |
System Variable | query_cache_wlock_invalidate |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | FALSE |
This system variable was removed in MySQL 8.0.3.
Property | Value |
---|---|
Command-Line Format | --query-prealloc-size=# |
System Variable | query_prealloc_size |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 8192 |
Minimum Value | 8192 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
Block Size | 1024 |
The size of the persistent buffer used for statement parsing
and execution. This buffer is not freed between statements. If
you are running complex queries, a larger
query_prealloc_size
value
might be helpful in improving performance, because it can
reduce the need for the server to perform memory allocation
during query execution operations.
The rand_seed1
and
rand_seed2
variables exist as
session variables only, and can be set but not read. The
variables—but not their values—are shown in the
output of SHOW VARIABLES
.
The purpose of these variables is to support replication of
the RAND()
function. For
statements that invoke RAND()
,
the master passes two values to the slave, where they are used
to seed the random number generator. The slave uses these
values to set the session variables
rand_seed1
and
rand_seed2
so that
RAND()
on the slave generates
the same value as on the master.
See the description for
rand_seed1
.
Property | Value |
---|---|
Command-Line Format | --range-alloc-block-size=# |
System Variable | range_alloc_block_size |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
Default Value | 4096 |
Minimum Value | 4096 |
Maximum Value (64-bit platforms) | 18446744073709547520 |
Maximum Value | 4294967295 |
Block Size | 1024 |
The size of blocks that are allocated when doing range optimization.
Property | Value |
---|---|
Command-Line Format | --range-optimizer-max-mem-size=N |
System Variable | range_optimizer_max_mem_size |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 8388608 |
Minimum Value | 0 |
Maximum Value | 18446744073709551615 |
The limit on memory consumption for the range optimizer. A value of 0 means “no limit.” If an execution plan considered by the optimizer uses the range access method but the optimizer estimates that the amount of memory needed for this method would exceed the limit, it abandons the plan and considers other plans. For more information, see Limiting Memory Use for Range Optimization.
Property | Value |
---|---|
System Variable | rbr_exec_mode |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value | STRICT |
Valid Values |
|
For internal use by mysqlbinlog. This
variable switches the server between
IDEMPOTENT
mode and
STRICT
mode. IDEMPOTENT
mode causes suppression of duplicate-key and no-key-found
errors in BINLOG
statements
generated by mysqlbinlog. This mode is
useful when replaying a row-based binary log on a server that
causes conflicts with existing data.
mysqlbinlog sets this mode when you specify
the --idempotent
option by
writing the following to the output:
SET SESSION RBR_EXEC_MODE=IDEMPOTENT;
Property | Value |
---|---|
Command-Line Format | --read-buffer-size=# |
System Variable | read_buffer_size |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
Default Value | 131072 |
Minimum Value | 8200 |
Maximum Value | 2147479552 |
Each thread that does a sequential scan for a
MyISAM
table allocates a buffer of this
size (in bytes) for each table it scans. If you do many
sequential scans, you might want to increase this value, which
defaults to 131072. The value of this variable should be a
multiple of 4KB. If it is set to a value that is not a
multiple of 4KB, its value will be rounded down to the nearest
multiple of 4KB.
This option is also used in the following context for all storage engines:
For caching the indexes in a temporary file (not a
temporary table), when sorting rows for ORDER
BY
.
For bulk insert into partitions.
For caching results of nested queries.
read_buffer_size
is also used
in one other storage engine-specific way: to determine the
memory block size for MEMORY
tables.
For more information about memory use during different operations, see Section 8.12.3.1, “How MySQL Uses Memory”.
Property | Value |
---|---|
Command-Line Format | --read-only |
System Variable | read_only |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
When the read_only
system
variable is enabled, the server permits no client updates
except from users who have the
CONNECTION_ADMIN
or
SUPER
privilege. This variable
is disabled by default.
The server also supports a
super_read_only
system
variable (disabled by default), which has these effects:
If super_read_only
is
enabled, the server prohibits client updates, even from
users who have the SUPER
privilege.
Setting super_read_only
to ON
implicitly forces
read_only
to
ON
.
Setting read_only
to
OFF
implicitly forces
super_read_only
to
OFF
.
Even with read_only
enabled,
the server permits these operations:
Updates performed by slave threads, if the server is a
replication slave. In replication setups, it can be useful
to enable read_only
on
slave servers to ensure that slaves accept updates only
from the master server and not from clients.
Use of ANALYZE TABLE
or
OPTIMIZE TABLE
statements.
The purpose of read-only mode is to prevent changes to
table structure or contents. Analysis and optimization do
not qualify as such changes. This means, for example, that
consistency checks on read-only replication slaves can be
performed with mysqlcheck --all-databases
--analyze.
Operations on TEMPORARY
tables.
Inserts into the log tables
(mysql.general_log
and
mysql.slow_log
); see
Section 5.4.1, “Selecting General Query and Slow Query Log Output Destinations”.
Updates to Performance Schema tables, such as
UPDATE
or
TRUNCATE TABLE
operations.
Changes to read_only
on a
master server are not replicated to slave servers. The value
can be set on a slave server independent of the setting on the
master.
The following conditions apply to attempts to enable
read_only
(including implicit
attempts resulting from enabling
super_read_only
):
The attempt fails and an error occurs if you have any
explicit locks (acquired with LOCK
TABLES
) or have a pending transaction.
The attempt blocks while other clients hold explicit table
locks or have pending transactions, until the locks are
released and the transactions end. While the attempt to
enable read_only
is
pending, requests by other clients for table locks or to
begin transactions also block until
read_only
has been set.
The attempt blocks if there are active transactions that hold metadata locks, until those transactions end.
read_only
can be enabled
while you hold a global read lock (acquired with
FLUSH TABLES WITH READ
LOCK
) because that does not involve table locks.
Property | Value |
---|---|
Command-Line Format | --read-rnd-buffer-size=# |
System Variable | read_rnd_buffer_size |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
Default Value | 262144 |
Minimum Value | 1 |
Maximum Value | 2147483647 |
This variable is used for reads from MyISAM
tables, and, for any storage engine, for Multi-Range Read
optimization.
When reading rows from a MyISAM
table in
sorted order following a key-sorting operation, the rows are
read through this buffer to avoid disk seeks. See
Section 8.2.1.14, “ORDER BY Optimization”. Setting the variable
to a large value can improve ORDER BY
performance by a lot. However, this is a buffer allocated for
each client, so you should not set the global variable to a
large value. Instead, change the session variable only from
within those clients that need to run large queries.
For more information about memory use during different operations, see Section 8.12.3.1, “How MySQL Uses Memory”. For information about Multi-Range Read optimization, see Section 8.2.1.10, “Multi-Range Read Optimization”.
Property | Value |
---|---|
Command-Line Format | --regexp-stack-limit=# |
Introduced | 8.0.4 |
System Variable | regexp_stack_limit |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 8000000 |
Minimum Value | 0 |
Maximum Value | 2147483647 |
The maximum available memory in bytes for the internal stack
used for regular expression matching operations performed by
REGEXP_LIKE()
and similar
functions (see Section 12.5.2, “Regular Expressions”).
Property | Value |
---|---|
Command-Line Format | --regexp-time-limit=# |
Introduced | 8.0.4 |
System Variable | regexp_time_limit |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 32 |
Minimum Value | 0 |
Maximum Value | 2147483647 |
The time limit for regular expression matching operations
performed by REGEXP_LIKE()
and
similar functions (see Section 12.5.2, “Regular Expressions”). This limit
is expressed as the maximum permitted number of steps
performed by the match engine, and thus affects execution time
only indirectly. Typically, it is on the order of
milliseconds.
Property | Value |
---|---|
Command-Line Format | --require-secure-transport[={OFF|ON}] |
System Variable | require_secure_transport |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
Whether client connections to the server are required to use
some form of secure transport. When this variable is enabled,
the server permits only TCP/IP connections that use SSL, or
connections that use a socket file (on Unix) or shared memory
(on Windows). The server rejects nonsecure connection
attempts, which fail with an
ER_SECURE_TRANSPORT_REQUIRED
error.
This capability supplements per-account SSL requirements,
which take precedence. For example, if an account is defined
with REQUIRE SSL
, enabling
require_secure_transport
does
not make it possible to use the account to connect using a
Unix socket file.
It is possible for a server to have no secure transports
available. For example, a server on Windows supports no secure
transports if started without specifying any SSL certificate
or key files and with the
shared_memory
system variable
disabled. Under these conditions, attempts to enable
require_secure_transport
at
startup cause the server to write a message to the error log
and exit. Attempts to enable the variable at runtime fail with
an
ER_NO_SECURE_TRANSPORTS_CONFIGURED
error.
Property | Value |
---|---|
Introduced | 8.0.3 |
System Variable | resultset_metadata |
Scope | Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value | FULL |
Valid Values |
|
For connections for which metadata transfer is optional, the
client sets the
resultset_metadata
system
variable to control whether the server returns result set
metadata. Permitted values are FULL
(return
all metadata; this is the default) and NONE
(return no metadata).
For connections that are not metadata-optional, setting
resultset_metadata
to
NONE
produces an error.
For details about managing result set metadata transfer, see Section 27.7.23, “C API Optional Result Set Metadata”.
Property | Value |
---|---|
Command-Line Format | --schema-definition-cache=N |
System Variable | schema_definition_cache |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 256 |
Minimum Value | 256 |
Maximum Value | 524288 |
Defines a limit for the number of schema definition objects, both used and unused, that can be kept in the dictionary object cache.
Unused schema definition objects are only kept in the
dictionary object cache when the number in use is less than
the capacity defined by
schema_definition_cache
.
A setting of 0
means that schema definition
objects are only kept in the dictionary object cache while
they are in use.
For more information, see Section 14.4, “Dictionary Object Cache”.
Property | Value |
---|---|
Command-Line Format | --secure-auth |
Deprecated | Yes (removed in 8.0.3) |
System Variable | secure_auth |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | ON |
Valid Values | ON |
This system variable was removed in MySQL 8.0.3.
Property | Value |
---|---|
Command-Line Format | --secure-file-priv=dir_name |
System Variable | secure_file_priv |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | string |
Default Value | platform specific |
Valid Values |
|
This variable is used to limit the effect of data import and
export operations, such as those performed by the
LOAD DATA
and
SELECT ... INTO
OUTFILE
statements and the
LOAD_FILE()
function. These
operations are permitted only to users who have the
FILE
privilege.
secure_file_priv
may be set
as follows:
If empty, the variable has no effect. This is not a secure setting.
If set to the name of a directory, the server limits import and export operations to work only with files in that directory. The directory must exist; the server will not create it.
If set to NULL
, the server disables
import and export operations.
The default value is platform specific and depends on the
value of the INSTALL_LAYOUT
CMake option, as shown in the following
table. To specify the default
secure_file_priv
value
explicitly if you are building from source, use the
INSTALL_SECURE_FILE_PRIVDIR
CMake option.
INSTALL_LAYOUT Value |
Default secure_file_priv Value |
---|---|
STANDALONE , WIN |
empty |
DEB , RPM , SLES ,
SVR4 |
/var/lib/mysql-files |
Otherwise | mysql-files under the
CMAKE_INSTALL_PREFIX value |
The server checks the value of
secure_file_priv
at startup
and writes a warning to the error log if the value is
insecure. A non-NULL
value is considered
insecure if it is empty, or the value is the data directory or
a subdirectory of it, or a directory that is accessible by all
users. If secure_file_priv
is
set to a nonexistent path, the server writes an error message
to the error log and exits.
Property | Value |
---|---|
Command-Line Format | --server-id=# |
System Variable | server_id |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value (>= 8.0.3) | 1 |
Default Value (<= 8.0.2) | 0 |
Minimum Value | 0 |
Maximum Value | 4294967295 |
Specifies the server ID. This variable is set by the
--server-id
option. The
server_id
system variable is set to 1 by
default. The server can be started with this default ID, but
when binary logging is enabled, an informational message is
issued if you did not specify a server ID explicitly using the
--server-id
option.
For servers that are used in a replication topology, you must specify a unique server ID for each replication server, in the range from 1 to 232 − 1. “Unique” means that each ID must be different from every other ID in use by any other replication master or slave. For additional information, see Section 17.1.6.2, “Replication Master Options and Variables”, and Section 17.1.6.3, “Replication Slave Options and Variables”.
If the server ID is set to 0, binary logging takes place, but a master with a server ID of 0 refuses any connections from slaves, and a slave with a server ID of 0 refuses to connect to a master. Note that although you can change the server ID dynamically to a nonzero value, doing so does not enable replication to start immediately. You must change the server ID and then restart the server to initialize the replication slave.
For more information, see Section 17.1.2.2, “Setting the Replication Slave Configuration”.
Property | Value |
---|---|
Command-Line Format | --session-track-gtids=[value] |
System Variable | session_track_gtids |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value | OFF |
Valid Values |
|
Controls whether the server tracks GTIDs within the current
session and returns them to the client. Depending on the
variable value, at the end of executing each transaction, the
server GTIDs are captured by the tracker and returned to the
client. These
session_track_gtids
values
are permitted:
OFF
: The tracker collects no GTIDs.
This is the default.
OWN_GTID
: The tracker collects GTIDs
generated by successfully committed read/write
transactions.
ALL_GTIDS
: The tracker collects all
GTIDs in the gtid_executed
system
variable at the time the current transaction commits,
regardless of whether the transaction is read/write or
read only.
session_track_gtids
cannot be
set within transactional context.
For more information about session state tracking, see Section 5.1.13, “Server Tracking of Client Session State Changes”.
Property | Value |
---|---|
Command-Line Format | --session-track-schema=# |
System Variable | session_track_schema |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | ON |
Controls whether the server tracks when the default schema (database) is set within the current session and notifies the client to make the schema name available.
If the schema name tracker is enabled, name notification occurs each time the default schema is set, even if the new schema name is the same as the old.
For more information about session state tracking, see Section 5.1.13, “Server Tracking of Client Session State Changes”.
Property | Value |
---|---|
Command-Line Format | --session-track-state-change=# |
System Variable | session_track_state_change |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
Controls whether the server tracks changes to the state of the current session and notifies the client when state changes occur. Changes can be reported for these attributes of client session state:
The default schema (database).
Session-specific values for system variables.
User-defined variables.
Temporary tables.
Prepared statements.
If the session state tracker is enabled, notification occurs for each change that involves tracked session attributes, even if the new attribute values are the same as the old. For example, setting a user-defined variable to its current value results in a notification.
The
session_track_state_change
variable controls only notification of when changes occur, not
what the changes are. For example, state-change notifications
occur when the default schema is set or tracked session system
variables are assigned, but the notification does not include
the schema name or variable values. To receive notification of
the schema name or session system variable values, use the
session_track_schema
or
session_track_system_variables
system variable, respectively.
Assigning a value to
session_track_state_change
itself is not considered a state change and is not reported
as such. However, if its name listed in the value of
session_track_system_variables
,
any assignments to it do result in notification of the new
value.
For more information about session state tracking, see Section 5.1.13, “Server Tracking of Client Session State Changes”.
session_track_system_variables
Property | Value |
---|---|
Command-Line Format | --session-track-system-variables=# |
System Variable | session_track_system_variables |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value | time_zone, autocommit, character_set_client, character_set_results, character_set_connection |
Controls whether the server tracks assignments to session
system variables and notifies the client of the name and value
of each assigned variable. The variable value is a
comma-separated list of variables for which to track
assignments. By default, notification is enabled for
time_zone
,
autocommit
,
character_set_client
,
character_set_results
, and
character_set_connection
.
(The latter three variables are those affected by
SET NAMES
.)
The special value *
causes the server to
track assignments to all session variables. If given, this
value must be specified by itself without specific system
variable names.
To disable notification of session variable assignments, set
session_track_system_variables
to the empty string.
If session system variable tracking is enabled, notification occurs for all assignments to tracked session variables, even if the new values are the same as the old.
For more information about session state tracking, see Section 5.1.13, “Server Tracking of Client Session State Changes”.
session_track_transaction_info
Property | Value |
---|---|
Command-Line Format | --session-track-transaction-info=value |
System Variable | session_track_transaction_info |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value | OFF |
Valid Values |
|
Controls whether the server tracks the state and
characteristics of transactions within the current session and
notifies the client to make this information available. These
session_track_transaction_info
values are permitted:
OFF
: Disable transaction state
tracking. This is the default.
STATE
: Enable transaction state
tracking without characteristics tracking. State tracking
enables the client to determine whether a transaction is
in progress and whether it could be moved to a different
session without being rolled back.
CHARACTERISTICS
: Enable transaction
state tracking, including characteristics tracking.
Characteristics tracking enables the client to determine
how to restart a transaction in another session so that it
has the same characteristics as in the original session.
The following characteristics are relevant for this
purpose:
READ ONLY READ WRITE ISOLATION LEVEL WITH CONSISTENT SNAPSHOT
For a client to safely relocate a transaction to another
session, it must track not only transaction state but also
transaction characteristics. In addition, the client must
track the
transaction_read_only
and
transaction_isolation
system
variables to correctly determine the session defaults. (To
track these variables, list them in the value of the
session_track_system_variables
system variable.)
For more information about session state tracking, see Section 5.1.13, “Server Tracking of Client Session State Changes”.
sha256_password_auto_generate_rsa_keys
Property | Value |
---|---|
Command-Line Format | --sha256-password-auto-generate-rsa-keys[={OFF|ON}] |
System Variable | sha256_password_auto_generate_rsa_keys |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | ON |
This variable is available if the server was compiled using OpenSSL (see Section 6.4.4, “OpenSSL Versus wolfSSL”). The server uses it to determine whether to autogenerate RSA private/public key-pair files in the data directory if they do not already exist.
At startup, the server automatically generates RSA
private/public key-pair files in the data directory if all of
these conditions are true: The
sha256_password_auto_generate_rsa_keys
or
caching_sha2_password_auto_generate_rsa_keys
system variable is enabled; no RSA options are specified; the
RSA files are missing from the data directory. These key-pair
files enable secure password exchange using RSA over
unencrypted connections for accounts authenticated by the
sha256_password
or
caching_sha2_password
plugin; see
Section 6.5.1.2, “SHA-256 Pluggable Authentication”, and
Section 6.5.1.3, “Caching SHA-2 Pluggable Authentication”.
For more information about RSA file autogeneration, including file names and characteristics, see Section 6.4.3.1, “Creating SSL and RSA Certificates and Keys using MySQL”
The auto_generate_certs
system variable is related but controls autogeneration of SSL
certificate and key files needed for secure connections using
SSL.
sha256_password_private_key_path
Property | Value |
---|---|
Command-Line Format | --sha256-password-private-key-path=file_name |
System Variable | sha256_password_private_key_path |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | file name |
Default Value | private_key.pem |
This variable is available if MySQL was compiled using OpenSSL
(see Section 6.4.4, “OpenSSL Versus wolfSSL”). Its value is the path
name of the RSA private key file for the
sha256_password
authentication plugin. If
the file is named as a relative path, it is interpreted
relative to the server data directory. The file must be in PEM
format.
Because this file stores a private key, its access mode should be restricted so that only the MySQL server can read it.
For information about sha256_password
, see
Section 6.5.1.2, “SHA-256 Pluggable Authentication”.
Property | Value |
---|---|
Command-Line Format | --sha256-password-proxy-users=[={OFF|ON}] |
System Variable | sha256_password_proxy_users |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
This variable controls whether the
sha256_password
built-in authentication
plugin supports proxy users. It has no effect unless the
check_proxy_users
system
variable is enabled. For information about user proxying, see
Section 6.3.11, “Proxy Users”.
sha256_password_public_key_path
Property | Value |
---|---|
Command-Line Format | --sha256-password-public-key-path=file_name |
System Variable | sha256_password_public_key_path |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | file name |
Default Value | public_key.pem |
This variable is available if MySQL was compiled using OpenSSL
(see Section 6.4.4, “OpenSSL Versus wolfSSL”). Its value is the path
name of the RSA public key file for the
sha256_password
authentication plugin. If
the file is named as a relative path, it is interpreted
relative to the server data directory. The file must be in PEM
format. Because this file stores a public key, copies can be
freely distributed to client users. (Clients that explicitly
specify a public key when connecting to the server using RSA
password encryption must use the same public key as that used
by the server.)
For information about sha256_password
,
including information about how clients specify the RSA public
key, see Section 6.5.1.2, “SHA-256 Pluggable Authentication”.
Property | Value |
---|---|
Command-Line Format | --shared-memory[={0,1}] |
System Variable | shared_memory |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Platform Specific | Windows |
Type | boolean |
Default Value | FALSE |
(Windows only.) Whether the server permits shared-memory connections.
Property | Value |
---|---|
Command-Line Format | --shared-memory-base-name=name |
System Variable | shared_memory_base_name |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Platform Specific | Windows |
Type | string |
Default Value | MYSQL |
(Windows only.) The name of shared memory to use for
shared-memory connections. This is useful when running
multiple MySQL instances on a single physical machine. The
default name is MYSQL
. The name is case
sensitive.
Property | Value |
---|---|
Command-Line Format | --show-compatibility-56[={OFF|ON}] |
Deprecated | Yes (removed in 8.0.1) |
System Variable | show_compatibility_56 |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
This variable was used in the transition period during which
system and status variable information in
INFORMATION_SCHEMA
tables was moved to
Performance Schema tables. That transition period ended in
MySQL 8.0.1, at which time this variable was removed. For
advice on migrating away from the
INFORMATION_SCHEMA
tables to the
Performance Schema tables, see
Migrating to Performance Schema System and Status Variable Tables.
Property | Value |
---|---|
Command-Line Format | --show-create-table-verbosity |
Introduced | 8.0.11 |
System Variable | show_create_table_verbosity |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
SHOW CREATE TABLE
normally does
not show the ROW_FORMAT
table option if the
row format is the default format. Enabling this variable
causes SHOW CREATE TABLE
to
display ROW_FORMAT
regardless of whether it
is the default format.
Property | Value |
---|---|
Command-Line Format | --show-old-temporals={OFF|ON} |
Deprecated | Yes |
System Variable | show_old_temporals |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
Whether SHOW CREATE TABLE
output includes comments to flag temporal columns found to be
in pre-5.6.4 format (TIME
,
DATETIME
, and
TIMESTAMP
columns without
support for fractional seconds precision). This variable is
disabled by default. If enabled, SHOW
CREATE TABLE
output looks like this:
CREATE TABLE `mytbl` ( `ts` timestamp /* 5.5 binary format */ NOT NULL DEFAULT CURRENT_TIMESTAMP, `dt` datetime /* 5.5 binary format */ DEFAULT NULL, `t` time /* 5.5 binary format */ DEFAULT NULL ) DEFAULT CHARSET=utf8mb4
Output for the COLUMN_TYPE
column of the
INFORMATION_SCHEMA.COLUMNS
table
is affected similarly.
This variable is deprecated and will be removed in a future MySQL release.
Property | Value |
---|---|
Command-Line Format | --skip-external-locking |
System Variable | skip_external_locking |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | ON |
This is OFF
if mysqld
uses external locking (system locking), ON
if external locking is disabled. This affects only
MyISAM
table access.
This variable is set by the
--external-locking
or
--skip-external-locking
option. External locking is disabled by default.
External locking affects only
MyISAM
table access. For more
information, including conditions under which it can and
cannot be used, see Section 8.11.5, “External Locking”.
Property | Value |
---|---|
Command-Line Format | --skip-name-resolve |
System Variable | skip_name_resolve |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
This variable is set from the value of the
--skip-name-resolve
option. If
it is OFF
, mysqld
resolves host names when checking client connections. If it is
ON
, mysqld uses only IP
numbers; in this case, all Host
column
values in the grant tables must be IP addresses or
localhost
. See
Section 8.12.4.2, “DNS Lookup Optimization and the Host Cache”.
Property | Value |
---|---|
Command-Line Format | --skip-networking |
System Variable | skip_networking |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
This is ON
if the server permits only local
(non-TCP/IP) connections. On Unix, local connections use a
Unix socket file. On Windows, local connections use a named
pipe or shared memory. This variable can be set to
ON
with the
--skip-networking
option.
Property | Value |
---|---|
Command-Line Format | --skip-show-database |
System Variable | skip_show_database |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
This prevents people from using the SHOW
DATABASES
statement if they do not have the
SHOW DATABASES
privilege. This
can improve security if you have concerns about users being
able to see databases belonging to other users. Its effect
depends on the SHOW DATABASES
privilege: If the variable value is ON
, the
SHOW DATABASES
statement is
permitted only to users who have the SHOW
DATABASES
privilege, and the statement displays all
database names. If the value is OFF
,
SHOW DATABASES
is permitted to
all users, but displays the names of only those databases for
which the user has the SHOW
DATABASES
or other privilege. (Note that
any global privilege is considered a
privilege for the database.)
Property | Value |
---|---|
Command-Line Format | --slow-launch-time=# |
System Variable | slow_launch_time |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 2 |
If creating a thread takes longer than this many seconds, the
server increments the
Slow_launch_threads
status
variable.
Property | Value |
---|---|
Command-Line Format | --slow-query-log |
System Variable | slow_query_log |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
Whether the slow query log is enabled. The value can be 0 (or
OFF
) to disable the log or 1 (or
ON
) to enable the log. The default value
depends on whether the
--slow_query_log
option is
given. The destination for log output is controlled by the
log_output
system variable;
if that value is NONE
, no log entries are
written even if the log is enabled.
“Slow” is determined by the value of the
long_query_time
variable. See
Section 5.4.5, “The Slow Query Log”.
Property | Value |
---|---|
Command-Line Format | --slow-query-log-file=file_name |
System Variable | slow_query_log_file |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | file name |
Default Value | host_name-slow.log |
The name of the slow query log file. The default value is
,
but the initial value can be changed with the
host_name
-slow.log--slow_query_log_file
option.
Property | Value |
---|---|
Command-Line Format | --socket={file_name|pipe_name} |
System Variable | socket |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | string |
Default Value (Other) | /tmp/mysql.sock |
Default Value (Windows) | MySQL |
On Unix platforms, this variable is the name of the socket
file that is used for local client connections. The default is
/tmp/mysql.sock
. (For some distribution
formats, the directory might be different, such as
/var/lib/mysql
for RPMs.)
On Windows, this variable is the name of the named pipe that
is used for local client connections. The default value is
MySQL
(not case-sensitive).
Property | Value |
---|---|
Command-Line Format | --sort-buffer-size=# |
System Variable | sort_buffer_size |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
Default Value | 262144 |
Minimum Value | 32768 |
Maximum Value (Other, 64-bit platforms) | 18446744073709551615 |
Maximum Value (Other, 32-bit platforms) | 4294967295 |
Maximum Value (Windows) | 4294967295 |
Each session that must perform a sort allocates a buffer of
this size. sort_buffer_size
is not specific to any storage engine and applies in a general
manner for optimization. At minimum the
sort_buffer_size
value must
be large enough to accommodate fifteen tuples in the sort
buffer. Also, increasing the value of
max_sort_length
may require
increasing the value of
sort_buffer_size
. For more
information, see Section 8.2.1.14, “ORDER BY Optimization”
If you see many
Sort_merge_passes
per second
in SHOW GLOBAL
STATUS
output, you can consider increasing the
sort_buffer_size
value to
speed up ORDER BY
or GROUP
BY
operations that cannot be improved with query
optimization or improved indexing.
The optimizer tries to work out how much space is needed but can allocate more, up to the limit. Setting it larger than required globally will slow down most queries that sort. It is best to increase it as a session setting, and only for the sessions that need a larger size. On Linux, there are thresholds of 256KB and 2MB where larger values may significantly slow down memory allocation, so you should consider staying below one of those values. Experiment to find the best value for your workload. See Section B.5.3.5, “Where MySQL Stores Temporary Files”.
The maximum permissible setting for
sort_buffer_size
is
4GB−1. Larger values are permitted for 64-bit platforms
(except 64-bit Windows, for which large values are truncated
to 4GB−1 with a warning).
Property | Value |
---|---|
System Variable | sql_auto_is_null |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | boolean |
Default Value | 0 |
If this variable is set to 1, then after a statement that
successfully inserts an automatically generated
AUTO_INCREMENT
value, you can find that
value by issuing a statement of the following form:
SELECT * FROMtbl_name
WHEREauto_col
IS NULL
If the statement returns a row, the value returned is the same
as if you invoked the
LAST_INSERT_ID()
function. For
details, including the return value after a multiple-row
insert, see Section 12.14, “Information Functions”. If no
AUTO_INCREMENT
value was successfully
inserted, the SELECT
statement
returns no row.
The behavior of retrieving an
AUTO_INCREMENT
value by using an
IS NULL
comparison is used by
some ODBC programs, such as Access. See
Obtaining Auto-Increment Values.
This behavior can be disabled by setting
sql_auto_is_null
to 0.
The default value of
sql_auto_is_null
is 0.
Property | Value |
---|---|
System Variable | sql_big_selects |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | boolean |
Default Value | 1 |
If set to 0, MySQL aborts
SELECT
statements that are
likely to take a very long time to execute (that is,
statements for which the optimizer estimates that the number
of examined rows exceeds the value of
max_join_size
). This is
useful when an inadvisable WHERE
statement
has been issued. The default value for a new connection is 1,
which permits all SELECT
statements.
If you set the max_join_size
system variable to a value other than
DEFAULT
,
sql_big_selects
is set to 0.
Property | Value |
---|---|
System Variable | sql_buffer_result |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | boolean |
Default Value | 0 |
If set to 1,
sql_buffer_result
forces
results from SELECT
statements
to be put into temporary tables. This helps MySQL free the
table locks early and can be beneficial in cases where it
takes a long time to send results to the client. The default
value is 0.
Property | Value |
---|---|
System Variable | sql_log_off |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | 0 |
This variable controls whether logging to the general query
log is done. The default value is 0 (do logging). To change
logging for the current session, change the session value of
this variable. The session user must have the
SYSTEM_VARIABLES_ADMIN
or
SUPER
privilege to set this
variable. The default value is 0.
Property | Value |
---|---|
Command-Line Format | --sql-mode=name |
System Variable | sql_mode |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | set |
Default Value (>= 8.0.11) | ONLY_FULL_GROUP_BY STRICT_TRANS_TABLES NO_ZERO_IN_DATE NO_ZERO_DATE ERROR_FOR_DIVISION_BY_ZERO NO_ENGINE_SUBSTITUTION |
Default Value (<= 8.0.4) | ONLY_FULL_GROUP_BY STRICT_TRANS_TABLES NO_ZERO_IN_DATE NO_ZERO_DATE ERROR_FOR_DIVISION_BY_ZERO NO_AUTO_CREATE_USER NO_ENGINE_SUBSTITUTION |
Valid Values (>= 8.0.11) |
|
Valid Values (>= 8.0.1, <= 8.0.4) |
|
Valid Values (8.0.0) |
|
The current server SQL mode, which can be set dynamically. For details, see Section 5.1.10, “Server SQL Modes”.
MySQL installation programs may configure the SQL mode during the installation process.
If the SQL mode differs from the default or from what you expect, check for a setting in an option file that the server reads at startup.
If set to 1 (the default), warnings of Note
level increment warning_count
and the
server records them. If set to 0, Note
warnings do not increment
warning_count
and the server
does not record them. mysqldump includes
output to set this variable to 0 so that reloading the dump
file does not produce warnings for events that do not affect
the integrity of the reload operation.
If set to 1 (the default), the server quotes identifiers for
SHOW CREATE TABLE
and
SHOW CREATE DATABASE
statements. If set to 0, quoting is disabled. This option is
enabled by default so that replication works for identifiers
that require quoting. See Section 13.7.6.10, “SHOW CREATE TABLE Syntax”,
and Section 13.7.6.6, “SHOW CREATE DATABASE Syntax”.
Property | Value |
---|---|
Command-Line Format | --sql-require-primary-key[={OFF|ON}] |
Introduced | 8.0.13 |
System Variable | sql_require_primary_key |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | boolean |
Default Value | OFF |
Whether statements that create new tables or alter the
structure of existing tables enforce the requirement that
tables have a primary key. The
SYSTEM_VARIABLES_ADMIN
or
SUPER
privilege is required to
set either the global or session value of this variable.
Enabling this variable helps avoid performance problems in row-based replication that can occur when tables have no primary key. Suppose that a table has no primary key and an update or delete modifies multiple rows. On the master server, this operation can be performed using a single table scan but, when replicated using row-based replication, results in a table scan for each row to be modified on the slave. With a primary key, these table scans do not occur.
sql_require_primary_key
applies to both base tables and TEMPORARY
tables, and changes to its value are replicated to slave
servers.
When enabled,
sql_require_primary_key
has
these effects:
Attempts to create a new table with no primary key fail
with an error. This includes CREATE TABLE ...
LIKE
. It also includes CREATE TABLE ...
SELECT
, unless the CREATE
TABLE
part includes a primary key definition.
Attempts to drop the primary key from an existing table
fail with an error, with the exception that dropping the
primary key and adding a primary key in the same
ALTER TABLE
statement is permitted.
Dropping the primary key fails even if the table also
contains a UNIQUE NOT NULL
index.
Attempts to import a table with no primary key fail with an error.
If set to 1, MySQL aborts
UPDATE
or
DELETE
statements that do not
use a key in the WHERE
clause or a
LIMIT
clause. (Specifically,
UPDATE
statements must have a
WHERE
clause that uses a key or a
LIMIT
clause, or both.
DELETE
statements must have
both.) This makes it possible to catch
UPDATE
or
DELETE
statements where keys
are not used properly and that would probably change or delete
a large number of rows. The default value is 0.
Property | Value |
---|---|
System Variable | sql_select_limit |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
The maximum number of rows to return from
SELECT
statements. The default
value for a new connection is the maximum number of rows that
the server permits per table. Typical default values are
(232)−1 or
(264)−1. If you have changed
the limit, the default value can be restored by assigning a
value of DEFAULT
.
If a SELECT
has a
LIMIT
clause, the LIMIT
takes precedence over the value of
sql_select_limit
.
This variable controls whether single-row
INSERT
statements produce an
information string if warnings occur. The default is 0. Set
the value to 1 to produce an information string.
Property | Value |
---|---|
Command-Line Format | --ssl-ca=file_name |
System Variable | ssl_ca |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | file name |
The path to a file with a list of trusted SSL Certificate Authorities.
Property | Value |
---|---|
Command-Line Format | --ssl-capath=dir_name |
System Variable | ssl_capath |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | directory name |
The path to a directory that contains trusted SSL CA certificates in PEM format.
Property | Value |
---|---|
Command-Line Format | --ssl-cert=file_name |
System Variable | ssl_cert |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | file name |
The name of the SSL certificate file to use for establishing a secure connection.
Property | Value |
---|---|
Command-Line Format | --ssl-cipher=name |
System Variable | ssl_cipher |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | string |
The list of permitted ciphers for SSL encryption.
Property | Value |
---|---|
Command-Line Format | --ssl-crl=file_name |
System Variable | ssl_crl |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | file name |
The path to a file containing certificate revocation lists in PEM format. Revocation lists work for MySQL distributions compiled using OpenSSL (but not wolfSSL). See Section 6.4.4, “OpenSSL Versus wolfSSL”.
Property | Value |
---|---|
Command-Line Format | --ssl-crlpath=dir_name |
System Variable | ssl_crlpath |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | directory name |
The path to a directory that contains files containing certificate revocation lists in PEM format. Revocation lists work for MySQL distributions compiled using OpenSSL (but not wolfSSL). See Section 6.4.4, “OpenSSL Versus wolfSSL”.
Property | Value |
---|---|
Command-Line Format | --ssl-fips-mode={OFF|ON|STRICT} |
Introduced | 8.0.11 |
System Variable | ssl_fips_mode |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value | OFF |
Valid Values |
|
Controls whether to enable FIPS mode on the server side. The
ssl_fips_mode
system variable
differs from other
--ssl-
options
in that it is not used to control whether the server permits
encrypted connections, but rather to affect which
cryptographic operations are permitted. See
Section 6.6, “FIPS Support”.
xxx
These ssl_fips_mode
values
are permitted:
OFF
(or 0): Disable FIPS mode.
ON
(or 1): Enable FIPS mode.
STRICT
(or 2): Enable
“strict” FIPS mode.
If the OpenSSL FIPS Object Module is not available, the only
permitted value for
ssl_fips_mode
is
OFF
. In this case, setting
ssl_fips_mode
to
ON
or STRICT
at
startup causes the server to produce an error message and
exit.
Property | Value |
---|---|
Command-Line Format | --ssl-key=file_name |
System Variable | ssl_key |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | file name |
The name of the SSL key file to use for establishing a secure connection.
Property | Value |
---|---|
Command-Line Format | --stored-program-cache=# |
System Variable | stored_program_cache |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 256 |
Minimum Value | 16 |
Maximum Value | 524288 |
Sets a soft upper limit for the number of cached stored routines per connection. The value of this variable is specified in terms of the number of stored routines held in each of the two caches maintained by the MySQL Server for, respectively, stored procedures and stored functions.
Whenever a stored routine is executed this cache size is checked before the first or top-level statement in the routine is parsed; if the number of routines of the same type (stored procedures or stored functions according to which is being executed) exceeds the limit specified by this variable, the corresponding cache is flushed and memory previously allocated for cached objects is freed. This allows the cache to be flushed safely, even when there are dependencies between stored routines.
The stored procedure and stored function caches exists in parallel with the stored program definition cache partition of the dictionary object cache. The stored procedure and stored function caches are per connection, while the stored program definition cache is shared. The existence of objects in the stored procedure and stored function caches have no dependence on the existence of objects in the stored program definition cache, and vice versa. For more information, see Section 14.4, “Dictionary Object Cache”.
stored_program_definition_cache
Property | Value |
---|---|
Command-Line Format | --stored-program-definition-cache=N |
System Variable | stored_program_definition_cache |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 256 |
Minimum Value | 256 |
Maximum Value | 524288 |
Defines a limit for the number of stored program definition objects, both used and unused, that can be kept in the dictionary object cache.
Unused stored program definition objects are only kept in the
dictionary object cache when the number in use is less than
the capacity defined by
stored_program_definition_cache
.
A setting of 0 means that stored program definition objects are only kept in the dictionary object cache while they are in use.
The stored program definition cache partition exists in
parallel with the stored procedure and stored function caches
that are configured using the
stored_program_cache
option.
The stored_program_cache
option sets a soft upper limit for the number of cached stored
procedures or functions per connection, and the limit is
checked each time a connection executes a stored procedure or
function. The stored program definition cache partition, on
the other hand, is a shared cache that stores stored program
definition objects for other purposes. The existence of
objects in the stored program definition cache partition has
no dependence on the existence of objects in the stored
procedure cache or stored function cache, and vice versa.
For related information, see Section 14.4, “Dictionary Object Cache”.
Property | Value |
---|---|
Command-Line Format | --super-read-only[={OFF|ON}] |
System Variable | super_read_only |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
If the read_only
system
variable is enabled, the server permits client updates only
from users who have the SUPER
privilege. If the
super_read_only
system
variable is also enabled, the server prohibits client updates
even from users who have SUPER
.
See the description of the
read_only
system variable for
a description of read-only mode and information about how
read_only
and
super_read_only
interact.
Changes to super_read_only
on
a master server are not replicated to slave servers. The value
can be set on a slave server independent of the setting on the
master.
Property | Value |
---|---|
Command-Line Format | --syseventlog.facility=value |
Introduced | 8.0.13 |
System Variable | syseventlog.facility |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value | daemon |
The facility for error log output written to
syslog
(what type of program is sending the
message). This variable is unavailable unless the
log_sink_syseventlog
error log component is
installed. See Section 5.4.2.3, “Error Logging to the System Log”.
The permitted values can vary per operating system; consult
your system syslog
documentation.
This variable does not exist on Windows.
Property | Value |
---|---|
Command-Line Format | --syseventlog.include-pid[={0|1}] |
Introduced | 8.0.13 |
System Variable | syseventlog.include_pid |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | ON |
Whether to include the server process ID in each line of error
log output written to syslog
. This variable
is unavailable unless the
log_sink_syseventlog
error log component is
installed. See Section 5.4.2.3, “Error Logging to the System Log”.
This variable does not exist on Windows.
Property | Value |
---|---|
Command-Line Format | --syseventlog.tag=tag |
Introduced | 8.0.13 |
System Variable | syseventlog.tag |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value | empty string |
The tag to be added to the server identifier in error log
output written to syslog
. This variable is
unavailable unless the log_sink_syseventlog
error log component is installed. See
Section 5.4.2.3, “Error Logging to the System Log”.
By default, the server identifier is mysqld
with no tag. If a tag value of tag
is specified, it is appended to the server identifier with a
leading hyphen, resulting in an identifier of
mysqld-
.
tag
On Windows, to use a tag that does not already exist, the server must be run from an account with Administrator privileges, to permit creation of a registry entry for the tag. Elevated privileges are not required if the tag already exists.
Property | Value |
---|---|
System Variable | system_time_zone |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | string |
The server system time zone. When the server begins executing,
it inherits a time zone setting from the machine defaults,
possibly modified by the environment of the account used for
running the server or the startup script. The value is used to
set system_time_zone
.
Typically the time zone is specified by the
TZ
environment variable. It also can be
specified using the
--timezone
option of the
mysqld_safe script.
The system_time_zone
variable
differs from time_zone
.
Although they might have the same value, the latter variable
is used to initialize the time zone for each client that
connects. See Section 5.1.12, “MySQL Server Time Zone Support”.
Property | Value |
---|---|
System Variable | table_definition_cache |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | -1 (signifies autosizing; do not assign this literal value) |
Minimum Value | 400 |
Maximum Value | 524288 |
The number of table definitions that can be stored in the definition cache. If you use a large number of tables, you can create a large table definition cache to speed up opening of tables. The table definition cache takes less space and does not use file descriptors, unlike the normal table cache. The minimum value is 400. The default value is based on the following formula, capped to a limit of 2000:
MIN(400 + table_open_cache / 2, 2000)
For InnoDB
,
table_definition_cache
acts
as a soft limit for the number of open table instances in the
InnoDB
data dictionary cache. If the number
of open table instances exceeds the
table_definition_cache
setting, the LRU mechanism begins to mark table instances for
eviction and eventually removes them from the data dictionary
cache. The limit helps address situations in which significant
amounts of memory would be used to cache rarely used table
instances until the next server restart. The number of table
instances with cached metadata could be higher than the limit
defined by
table_definition_cache
,
because parent and child table instances with foreign key
relationships are not placed on the LRU list and are not
subject to eviction from memory.
Additionally,
table_definition_cache
defines a soft limit for the number of
InnoDB
file-per-table tablespaces
that can be open at one time, which is also controlled by
innodb_open_files
. If both
table_definition_cache
and
innodb_open_files
are set,
the highest setting is used. If neither variable is set,
table_definition_cache
, which
has a higher default value, is used. If the number of open
tablespace file handles exceeds the limit defined by
table_definition_cache
or
innodb_open_files
, the LRU
mechanism searches the tablespace file LRU list for files that
are fully flushed and are not currently being extended. This
process is performed each time a new tablespace is opened. If
there are no “inactive” tablespaces, no
tablespace files are closed.
The table definition cache exists in parallel with the table definition cache partition of the dictionary object cache. Both caches store table definitions but serve different parts of the MySQL server. Objects in one cache have no dependence on the existence objects in the other. For more information, see Section 14.4, “Dictionary Object Cache”.
Property | Value |
---|---|
System Variable | table_open_cache |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value (>= 8.0.4) | 4000 |
Default Value (<= 8.0.3) | 2000 |
Minimum Value | 1 |
Maximum Value | 524288 |
The number of open tables for all threads. Increasing this
value increases the number of file descriptors that
mysqld requires. You can check whether you
need to increase the table cache by checking the
Opened_tables
status
variable. See Section 5.1.9, “Server Status Variables”. If
the value of Opened_tables
is large and you do not use FLUSH
TABLES
often (which just forces all tables to be
closed and reopened), then you should increase the value of
the table_open_cache
variable. For more information about the table cache, see
Section 8.4.3.1, “How MySQL Opens and Closes Tables”.
Property | Value |
---|---|
System Variable | table_open_cache_instances |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 16 |
Minimum Value | 1 |
Maximum Value | 64 |
The number of open tables cache instances. To improve
scalability by reducing contention among sessions, the open
tables cache can be partitioned into several smaller cache
instances of size
table_open_cache
/
table_open_cache_instances
.
A session needs to lock only one instance to access it for DML
statements. This segments cache access among instances,
permitting higher performance for operations that use the
cache when there are many sessions accessing tables. (DDL
statements still require a lock on the entire cache, but such
statements are much less frequent than DML statements.)
A value of 8 or 16 is recommended on systems that routinely use 16 or more cores.
Property | Value |
---|---|
Command-Line Format | --temptable-max-ram=# |
Introduced | 8.0.2 |
System Variable | temptable_max_ram |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 1073741824 |
Minimum Value | 2097152 |
Maximum Value | 2^64-1 |
Defines the maximum amount of memory that can be occupied by
the TempTable
storage engine before it
starts storing data on disk. The default value is 1073741824
bytes (1GiB). For more information, see
Section 8.4.4, “Internal Temporary Table Use in MySQL”.
Property | Value |
---|---|
Command-Line Format | --thread-cache-size=# |
System Variable | thread_cache_size |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | -1 (signifies autosizing; do not assign this literal value) |
Minimum Value | 0 |
Maximum Value | 16384 |
How many threads the server should cache for reuse. When a
client disconnects, the client's threads are put in the cache
if there are fewer than
thread_cache_size
threads
there. Requests for threads are satisfied by reusing threads
taken from the cache if possible, and only when the cache is
empty is a new thread created. This variable can be increased
to improve performance if you have a lot of new connections.
Normally, this does not provide a notable performance
improvement if you have a good thread implementation. However,
if your server sees hundreds of connections per second you
should normally set
thread_cache_size
high enough
so that most new connections use cached threads. By examining
the difference between the
Connections
and
Threads_created
status
variables, you can see how efficient the thread cache is. For
details, see Section 5.1.9, “Server Status Variables”.
The default value is based on the following formula, capped to a limit of 100:
8 + (max_connections / 100)
Property | Value |
---|---|
Command-Line Format | --thread-handling=name |
System Variable | thread_handling |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value | one-thread-per-connection |
Valid Values |
|
The thread-handling model used by the server for connection
threads. The permissible values are
no-threads
(the server uses a single thread
to handle one connection) and
one-thread-per-connection
(the server uses
one thread to handle each client connection).
no-threads
is useful for debugging under
Linux; see Section 28.5, “Debugging and Porting MySQL”.
Property | Value |
---|---|
Command-Line Format | --thread-pool-algorithm=# |
Introduced | 8.0.11 |
System Variable | thread_pool_algorithm |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 0 |
Minimum Value | 0 |
Maximum Value | 1 |
This variable controls which algorithm the thread pool plugin uses:
A value of 0 (the default) uses a conservative low-concurrency algorithm which is most well tested and is known to produce very good results.
A value of 1 increases the concurrency and uses a more aggressive algorithm which at times has been known to perform 5–10% better on optimal thread counts, but has degrading performance as the number of connections increases. Its use should be considered as experimental and not supported.
This variable is available only if the thread pool plugin is enabled. See Section 5.6.3, “MySQL Enterprise Thread Pool”
thread_pool_high_priority_connection
Property | Value |
---|---|
Command-Line Format | --thread-pool-high-priority-connection=# |
Introduced | 8.0.11 |
System Variable | thread_pool_high_priority_connection |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 0 |
Minimum Value | 0 |
Maximum Value | 1 |
This variable affects queuing of new statements prior to execution. If the value is 0 (false, the default), statement queuing uses both the low-priority and high-priority queues. If the value is 1 (true), queued statements always go to the high-priority queue.
This variable is available only if the thread pool plugin is enabled. See Section 5.6.3, “MySQL Enterprise Thread Pool”
thread_pool_max_unused_threads
Property | Value |
---|---|
Command-Line Format | --thread-pool-max-unused-threads=# |
Introduced | 8.0.11 |
System Variable | thread_pool_max_unused_threads |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 0 |
Minimum Value | 0 |
Maximum Value | 4096 |
The maximum permitted number of unused threads in the thread pool. This variable makes it possible to limit the amount of memory used by sleeping threads.
A value of 0 (the default) means no limit on the number of
sleeping threads. A value of N
where N
is greater than 0 means 1
consumer thread and N
−1
reserve threads. In this case, if a thread is ready to sleep
but the number of sleeping threads is already at the maximum,
the thread exits rather than going to sleep.
A sleeping thread is either sleeping as a consumer thread or a reserve thread. The thread pool permits one thread to be the consumer thread when sleeping. If a thread goes to sleep and there is no existing consumer thread, it will sleep as a consumer thread. When a thread must be woken up, a consumer thread is selected if there is one. A reserve thread is selected only when there is no consumer thread to wake up.
This variable is available only if the thread pool plugin is enabled. See Section 5.6.3, “MySQL Enterprise Thread Pool”
Property | Value |
---|---|
Command-Line Format | --thread-pool-prio-kickup-timer=# |
Introduced | 8.0.11 |
System Variable | thread_pool_prio_kickup_timer |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 1000 |
Minimum Value | 0 |
Maximum Value | 4294967294 |
This variable affects statements waiting for execution in the low-priority queue. The value is the number of milliseconds before a waiting statement is moved to the high-priority queue. The default is 1000 (1 second). The range of values is 0 to 232 − 2.
This variable is available only if the thread pool plugin is enabled. See Section 5.6.3, “MySQL Enterprise Thread Pool”
Property | Value |
---|---|
Command-Line Format | --thread-pool-size=# |
Introduced | 8.0.11 |
System Variable | thread_pool_size |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 16 |
Minimum Value | 1 |
Maximum Value | 64 |
The number of thread groups in the thread pool. This is the most important parameter controlling thread pool performance. It affects how many statements can execute simultaneously. The default value is 16, with a range from 1 to 64 of permissible values. If a value outside this range is specified, the thread pool plugin does not load and the server writes a message to the error log.
This variable is available only if the thread pool plugin is enabled. See Section 5.6.3, “MySQL Enterprise Thread Pool”
Property | Value |
---|---|
Command-Line Format | --thread-pool-stall-limit=# |
Introduced | 8.0.11 |
System Variable | thread_pool_stall_limit |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 6 |
Minimum Value | 4 |
Maximum Value | 600 |
This variable affects executing statements. The value is the amount of time a statement has to finish after starting to execute before it becomes defined as stalled, at which point the thread pool permits the thread group to begin executing another statement. The value is measured in 10 millisecond units, so a value of 6 (the default) means 60ms. The range of values is 4 to 600 (40ms to 6s). Short wait values permit threads to start more quickly. Short values are also better for avoiding deadlock situations. Long wait values are useful for workloads that include long-running statements, to avoid starting too many new statements while the current ones execute.
This variable is available only if the thread pool plugin is enabled. See Section 5.6.3, “MySQL Enterprise Thread Pool”
Property | Value |
---|---|
Command-Line Format | --thread-stack=# |
System Variable | thread_stack |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | integer |
Default Value (64-bit platforms) | 262144 |
Default Value (32-bit platforms) | 196608 |
Minimum Value | 131072 |
Maximum Value (64-bit platforms) | 18446744073709551615 |
Maximum Value (32-bit platforms) | 4294967295 |
Block Size | 1024 |
The stack size for each thread. The default of 192KB (256KB for 64-bit systems) is large enough for normal operation. If the thread stack size is too small, it limits the complexity of the SQL statements that the server can handle, the recursion depth of stored procedures, and other memory-consuming actions.
This system variable was removed in MySQL 8.0.3.
Property | Value |
---|---|
System Variable | time_zone |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
The current time zone. This variable is used to initialize the
time zone for each client that connects. By default, the
initial value of this is 'SYSTEM'
(which
means, “use the value of
system_time_zone
”).
The value can be specified explicitly at server startup with
the --default-time-zone
option.
See Section 5.1.12, “MySQL Server Time Zone Support”.
If set to SYSTEM
, every MySQL function
call that requires a timezone calculation makes a system
library call to determine the current system timezone. This
call may be protected by a global mutex, resulting in
contention.
Property | Value |
---|---|
System Variable | timestamp |
Scope | Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | numeric |
Set the time for this client. This is used to get the original
timestamp if you use the binary log to restore rows.
timestamp_value
should be a Unix
epoch timestamp (a value like that returned by
UNIX_TIMESTAMP()
, not a value
in 'YYYY-MM-DD hh:mm:ss'
format) or
DEFAULT
.
Setting timestamp
to a
constant value causes it to retain that value until it is
changed again. Setting
timestamp
to
DEFAULT
causes its value to be the current
date and time as of the time it is accessed.
In MySQL 8.0,
timestamp
is a
DOUBLE
rather than
BIGINT
because its value includes a
microseconds part.
SET timestamp
affects the value returned by
NOW()
but not by
SYSDATE()
. This means that
timestamp settings in the binary log have no effect on
invocations of SYSDATE()
. The
server can be started with the
--sysdate-is-now
option to
cause SYSDATE()
to be an alias
for NOW()
, in which case
SET timestamp
affects both functions.
Property | Value |
---|---|
Command-Line Format | --tls-version=protocol_list |
System Variable | tls_version |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | string |
Default Value (>= 8.0.11) | TLSv1,TLSv1.1,TLSv1.2 |
Default Value (<= 8.0.4) |
|
The protocols permitted by the server for encrypted connections. The value is a comma-separated list containing one or more protocol names. The protocols that can be named for this variable depend on the SSL library used to compile MySQL. For details, see Section 6.4.6, “Encrypted Connection Protocols and Ciphers”.
Property | Value |
---|---|
Command-Line Format | --tmp-table-size=# |
System Variable | tmp_table_size |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | integer |
Default Value | 16777216 |
Minimum Value | 1024 |
Maximum Value | 18446744073709551615 |
The maximum size of internal in-memory temporary tables. This
variable does not apply to user-created
MEMORY
tables.
The actual limit is determined from whichever of the values of
tmp_table_size
and
max_heap_table_size
is
smaller. If an in-memory temporary table exceeds the limit,
MySQL automatically converts it to an on-disk temporary table.
The
internal_tmp_disk_storage_engine
option defines the storage engine used for on-disk temporary
tables.
Increase the value of
tmp_table_size
(and
max_heap_table_size
if
necessary) if you do many advanced GROUP BY
queries and you have lots of memory.
You can compare the number of internal on-disk temporary
tables created to the total number of internal temporary
tables created by comparing the values of the
Created_tmp_disk_tables
and
Created_tmp_tables
variables.
See also Section 8.4.4, “Internal Temporary Table Use in MySQL”.
Property | Value |
---|---|
Command-Line Format | --tmpdir=dir_name |
System Variable | tmpdir |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | directory name |
The directory used for temporary files and temporary tables.
This variable can be set to a list of several paths that are
used in round-robin fashion. Paths should be separated by
colon characters (:
) on Unix and semicolon
characters (;
) on Windows.
The multiple-directory feature can be used to spread the load
between several physical disks. If the MySQL server is acting
as a replication slave, you should not set
tmpdir
to point to a
directory on a memory-based file system or to a directory that
is cleared when the server host restarts. A replication slave
needs some of its temporary files to survive a machine restart
so that it can replicate temporary tables or
LOAD DATA
INFILE
operations. If files in the temporary file
directory are lost when the server restarts, replication
fails. You can set the slave's temporary directory using the
slave_load_tmpdir
variable.
In that case, the slave will not use the general
tmpdir
value and you can set
tmpdir
to a nonpermanent
location.
Property | Value |
---|---|
Command-Line Format | --transaction-alloc-block-size=# |
System Variable | transaction_alloc_block_size |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 8192 |
Minimum Value | 1024 |
Maximum Value | 131072 |
Block Size | 1024 |
The amount in bytes by which to increase a per-transaction
memory pool which needs memory. See the description of
transaction_prealloc_size
.
Property | Value |
---|---|
Command-Line Format | --transaction-isolation=name |
System Variable | transaction_isolation |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value | REPEATABLE-READ |
Valid Values |
|
The default transaction isolation level. Defaults to
REPEATABLE-READ
.
This variable can be set directly, or indirectly using the
SET TRANSACTION
statement. See
Section 13.3.7, “SET TRANSACTION Syntax”. If you set
transaction_isolation
directly to an isolation level name that contains a space, the
name should be enclosed within quotation marks, with the space
replaced by a dash. For example:
SET transaction_isolation = 'READ-COMMITTED';
Any unique prefix of a valid value may be used to set the value of this variable.
The default transaction isolation level can also be set at
startup using the
--transaction-isolation
server
option.
This variable has nonstandard semantics for runtime changes to
the session value made using the
SET
statement. For most session system variables, these statements
are equivalent:
SET @@var_name
=value
; SET @@session.var_name
=value
;
For transaction_isolation
,
these semantics apply instead:
SET @@transaction_isolation =
value
Not permitted within transactions.
Sets the value only for the next single transaction within the session.
SET @@session.transaction_isolation =
value
Permitted within transactions.
Sets the value for all subsequent transactions within the session.
Does not affect the current ongoing transaction.
If executed between transactions, overrides any
preceding SET
@@transaction_isolation
statement to set the
value for the next transaction.
Property | Value |
---|---|
Command-Line Format | --transaction-prealloc-size=# |
System Variable | transaction_prealloc_size |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 4096 |
Minimum Value | 1024 |
Maximum Value | 131072 |
Block Size | 1024 |
There is a per-transaction memory pool from which various
transaction-related allocations take memory. The initial size
of the pool in bytes is
transaction_prealloc_size
.
For every allocation that cannot be satisfied from the pool
because it has insufficient memory available, the pool is
increased by
transaction_alloc_block_size
bytes. When the transaction ends, the pool is truncated to
transaction_prealloc_size
bytes.
By making
transaction_prealloc_size
sufficiently large to contain all statements within a single
transaction, you can avoid many malloc()
calls.
Property | Value |
---|---|
Command-Line Format | --transaction-read-only |
System Variable | transaction_read_only |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
The default transaction access mode. The value can be
OFF
(read/write, the default) or
ON
(read only).
This variable can be set directly, or indirectly using the
SET TRANSACTION
statement. See
Section 13.3.7, “SET TRANSACTION Syntax”.
To set the default transaction access mode at startup, use the
--transaction-read-only
server
option.
This variable has nonstandard semantics for runtime changes to
the session value made using the
SET
statement. For most session system variables, these statements
are equivalent:
SET @@var_name
=value
; SET @@session.var_name
=value
;
For transaction_read_only
,
these semantics apply instead:
SET @@transaction_read_only =
value
Not permitted within transactions.
Sets the value only for the next single transaction within the session.
SET @@session.transaction_read_only =
value
Permitted within transactions.
Sets the value for all subsequent transactions within the session.
Does not affect the current ongoing transaction.
If executed between transactions, overrides any
preceding SET
@@transaction_read_only
statement to set the
value for the next transaction.
Property | Value |
---|---|
Deprecated | Yes (removed in 8.0.3) |
System Variable | tx_isolation |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | enumeration |
Default Value | REPEATABLE-READ |
Valid Values |
|
This system variable was removed in MySQL 8.0.3. Use
transaction_isolation
instead.
Property | Value |
---|---|
Deprecated | Yes (removed in 8.0.3) |
System Variable | tx_read_only |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | OFF |
This system variable was removed in MySQL 8.0.3. Use
transaction_read_only
instead.
Property | Value |
---|---|
System Variable | unique_checks |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | boolean |
Default Value | 1 |
If set to 1 (the default), uniqueness checks for secondary
indexes in InnoDB
tables are performed. If
set to 0, storage engines are permitted to assume that
duplicate keys are not present in input data. If you know for
certain that your data does not contain uniqueness violations,
you can set this to 0 to speed up large table imports to
InnoDB
.
Setting this variable to 0 does not require storage engines to ignore duplicate keys. An engine is still permitted to check for them and issue duplicate-key errors if it detects them.
Property | Value |
---|---|
Command-Line Format | --updatable-views-with-limit=# |
System Variable | updatable_views_with_limit |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | boolean |
Default Value | 1 |
This variable controls whether updates to a view can be made
when the view does not contain all columns of the primary key
defined in the underlying table, if the update statement
contains a LIMIT
clause. (Such updates
often are generated by GUI tools.) An update is an
UPDATE
or
DELETE
statement. Primary key
here means a PRIMARY KEY
, or a
UNIQUE
index in which no column can contain
NULL
.
The variable can have two values:
1
or YES
: Issue a
warning only (not an error message). This is the default
value.
0
or NO
: Prohibit
the update.
Property | Value |
---|---|
Introduced | 8.0.13 |
System Variable | use_secondary_engine |
Scope | Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | enumeration |
Default Value | OFF |
Valid Values |
|
For future use.
validate_password.
xxx
The validate_password
component implements
a set of system variables having names of the form
validate_password.
.
These variables affect password testing by that component; see
Section 6.5.3.2, “Password Validation Options and Variables”.
xxx
Property | Value |
---|---|
System Variable | validate_user_plugins |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | ON |
If this variable is enabled (the default), the server checks each user account and produces a warning if conditions are found that would make the account unusable:
The account requires an authentication plugin that is not loaded.
The account requires the
sha256_password
or
caching_sha2_password
authentication
plugin but the server was started with neither SSL nor RSA
enabled as required by the plugin.
Enabling validate_user_plugins
slows down
server initialization and FLUSH PRIVILEGES
.
If you do not require the additional checking, you can disable
this variable at startup to avoid the performance decrement.
The version number for the server. The value might also
include a suffix indicating server build or configuration
information. -debug
indicates that the server
was built with debugging support enabled.
Property | Value |
---|---|
System Variable | version_comment |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | string |
The CMake configuration program has a
COMPILATION_COMMENT
option that
permits a comment to be specified when building MySQL. This
variable contains the value of that comment. See
Section 2.8.4, “MySQL Source-Configuration Options”.
Property | Value |
---|---|
System Variable | version_compile_machine |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | string |
The type of the server binary.
Property | Value |
---|---|
System Variable | version_compile_os |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | string |
The type of operating system on which MySQL was built.
Property | Value |
---|---|
Introduced | 8.0.11 |
System Variable | version_compile_zlib |
Scope | Global |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | string |
The version of the compiled-in zlib
library.
Property | Value |
---|---|
Command-Line Format | --wait-timeout=# |
System Variable | wait_timeout |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 28800 |
Minimum Value | 1 |
Maximum Value (Other) | 31536000 |
Maximum Value (Windows) | 2147483 |
The number of seconds the server waits for activity on a noninteractive connection before closing it.
On thread startup, the session
wait_timeout
value is
initialized from the global
wait_timeout
value or from
the global
interactive_timeout
value,
depending on the type of client (as defined by the
CLIENT_INTERACTIVE
connect option to
mysql_real_connect()
). See
also interactive_timeout
.
The number of errors, warnings, and notes that resulted from the last statement that generated messages. This variable is read only. See Section 13.7.6.40, “SHOW WARNINGS Syntax”.
Property | Value |
---|---|
Command-Line Format | --windowing-use-high-precision=# |
Introduced | 8.0.2 |
System Variable | windowing_use_high_precision |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | Yes |
Type | boolean |
Default Value | ON |
Whether to compute window operations without loss of precision. See Section 8.2.1.19, “Window Function Optimization”.
The MySQL server maintains many system variables that indicate how
it is configured. Section 5.1.7, “Server System Variables”,
describes the meaning of these variables. Each system variable has
a default value. System variables can be set at server startup
using options on the command line or in an option file. Most of
them can be changed dynamically while the server is running by
means of the
SET
statement, which enables you to modify operation of the server
without having to stop and restart it. You can also use system
variable values in expressions.
System variables implemented by a server component are exposed
when the component is installed and have names that begin with a
component-specific prefix. For example, the
log_filter_dragnet
error log filter component
implements a system variable named
log_error_filter_rules
, the full name of which
is
dragnet.log_error_filter_rules
.
To refer to this variable, use the full name.
There are two scopes in which system variables exist. Global variables affect the overall operation of the server. Session variables affect its operation for individual client connections. A given system variable can have both a global and a session value. Global and session system variables are related as follows:
When the server starts, it initializes each global variable to its default value. These defaults can be changed by options specified on the command line or in an option file. (See Section 4.2.3, “Specifying Program Options”.)
The server also maintains a set of session variables for each
client that connects. The client's session variables are
initialized at connect time using the current values of the
corresponding global variables. For example, a client's SQL
mode is controlled by the session
sql_mode
value, which is
initialized when the client connects to the value of the
global sql_mode
value.
For some system variables, the session value is not initialized from the corresponding global value; if so, that is indicated in the variable description.
System variable values can be set globally at server startup by
using options on the command line or in an option file. When you
use a startup option to set a variable that takes a numeric value,
the value can be given with a suffix of K
,
M
, or G
(either uppercase or
lowercase) to indicate a multiplier of 1024,
10242 or
10243; that is, units of kilobytes,
megabytes, or gigabytes, respectively. Thus, the following command
starts the server with an InnoDB
log file size
of 16 megabytes and a maximum packet size of one gigabyte:
mysqld --innodb_log_file_size=16M --max_allowed_packet=1G
Within an option file, those variables are set like this:
[mysqld] innodb_log_file_size=16M max_allowed_packet=1G
The lettercase of suffix letters does not matter;
16M
and 16m
are equivalent,
as are 1G
and 1g
.
To restrict the maximum value to which a system variable can be
set at runtime with the
SET
statement, specify this maximum by using an option of the form
--maximum-
at server startup. For example, to prevent the value of
var_name
=value
innodb_log_file_size
from being
increased to more than 32MB at runtime, use the option
--maximum-innodb_log_file_size=32M
.
Many system variables are dynamic and can be changed at runtime by
using the
SET
statement. For a list, see
Section 5.1.8.3, “Dynamic System Variables”. To change a system
variable with
SET
, refer
to it by name, optionally preceded by a modifier:
To indicate that a variable is a global variable, precede its
name by the GLOBAL
keyword or the
@@global.
qualifier:
SET GLOBAL max_connections = 1000; SET @@global.max_connections = 1000;
The SYSTEM_VARIABLES_ADMIN
or
SUPER
privilege is required to
set global variables.
Another way to set a global variable is to precede its name by
the PERSIST
keyword or the
@@persist.
qualifier:
SET PERSIST max_connections = 1000; SET @@persist.max_connections = 1000;
This SET
syntax enables you to make
configuration changes at runtime that also persist across
server restarts. Like
SET
GLOBAL
,
SET
PERSIST
changes the runtime variable value, but also
writes the variable setting to an option file named
mysqld-auto.cnf
in the data directory
(replacing any existing variable setting if there is one). At
startup, the server processes this file after all other option
files. The
SYSTEM_VARIABLES_ADMIN
or
SUPER
privilege is required to
persist global variables.
For a list of system variables that cannot be persisted, see Section 5.1.8.1, “Nonpersistent System Variables”
Management of the mysqld-auto.cnf
file
should be left to the server and not performed manually:
Removal of the file results in a loss of all persisted settings at the next server startup. (This is permissible if your intent is to reconfigure the server without these settings.) To remove all settings in the file without removing the file itself, use this statement:
RESET PERSIST;
Manual changes to the file may result in a parse error
at server startup. In this case, the server reports an
error and exits. If this issue occurs, start the server
with the
persisted_globals_load
system variable disabled or with the
--no-defaults
option. Alternatively,
remove the mysqld-auto.cnf
file,
but, as noted previously, removing this file results in
a loss of all persisted settings.
A plugin variable can be persisted if the plugin is installed
when SET
PERSIST
is executed. Assignment of the persisted
plugin variable takes effect for subsequent server restarts if
the plugin is still installed. If the plugin is no longer
installed, the plugin variable will not exist when the server
reads the mysqld-auto.cnf
file. In this
case, the server writes a warning to the error log and
continues:
currently unknown variable 'var_name
'
was read from the persisted config file
The PERSIST_ONLY
keyword or
@@persist_only.
qualifier is similar to
PERSIST
:
SET PERSIST_ONLY back_log = 1000; SET @@persist_only.back_log = 1000;
Like PERSIST
,
PERSIST_ONLY
writes the variable setting to
mysqld-auto.cnf
. However, unlike
PERSIST
, PERSIST_ONLY
does not modify the runtime global system variable value,
making it suitable for configuring read-only system variables
that can be set only at server startup. The
PERSIST_RO_VARIABLES_ADMIN
privilege is required to use PERSIST_ONLY
.
The mysqld-auto.cnf
file uses a format
like this (slightly reformatted):
{ "Version": 1, "mysql_server": { "max_connections": { "Value": "152", "Metadata": { "Timestamp": 1.519921356e+15, "User": "root", "Host": "localhost" } }, "transaction_isolation": { "Value": "READ-COMMITTED", "Metadata": { "Timestamp": 1.519921553e+15, "User": "root", "Host": "localhost" } }, "mysql_server_static_options": { "innodb_api_enable_mdl": { "Value": "0", "Metadata": { "Timestamp": 1.519921573e+15, "User": "root", "Host": "localhost" } }, "log_slave_updates": { "Value": "1", "Metadata": { "Timestamp": 1.519921582e+15, "User": "root", "Host": "localhost" } } } } }
Only read only variables persisted using
PERSIST_ONLY
are written to the
"mysql_server_static_options"
section. All
variables present inside the
"mysql_server_static_options"
section are
appended to the command line when the server is started. All
remaining persisted variables are set by executing a
SET
GLOBAL
statement.
To indicate that a variable is a session variable, precede its
name by the SESSION
keyword or either the
@@session.
or @@
qualifier:
SET SESSION sql_mode = 'TRADITIONAL'; SET @@session.sql_mode = 'TRADITIONAL'; SET @@sql_mode = 'TRADITIONAL';
Setting a session variable normally requires no special
privilege, although there are exceptions that require the
SYSTEM_VARIABLES_ADMIN
or
SUPER
privilege (such as
sql_log_bin
). A client can
change its own session variables, but not those of any other
client.
Session-only system variables cannot be persisted. They cannot
be set at server startup, so there is no reason to list them
in mysqld-auto.cnf
.
LOCAL
and @@local.
are
synonyms for SESSION
and
@@session.
.
If no modifier is present,
SET
changes the session variable.
An error occurs under these circumstances:
Use of SET
GLOBAL
(or @@global.
),
SET
PERSIST
(or @@persist.
), or
SET
PERSIST_ONLY
(or
@@persist_only.
), when setting a
variable that has only a session value:
mysql> SET GLOBAL sql_log_bin = ON;
ERROR 1228 (HY000): Variable 'sql_log_bin' is a SESSION
variable and can't be used with SET GLOBAL
Omission of GLOBAL
(or
@@global.
), PERSIST
(or @@persist.
), or
PERSIST_ONLY
(or
@@persist_only.
) when setting a
variable that has only a global value:
mysql> SET max_connections = 1000;
ERROR 1229 (HY000): Variable 'max_connections' is a
GLOBAL variable and should be set with SET GLOBAL
Use of SET
PERSIST
(or @@persist.
), or
SET
PERSIST_ONLY
(or
@@persist_only.
), when setting a
variable that cannot be persisted:
mysql>SET PERSIST port = 3307;
ERROR 1238 (HY000): Variable 'port' is a read only variable mysql>SET PERSIST_ONLY port = 3307;
ERROR 1238 (HY000): Variable 'port' is a non persistent read only variable
Use of SET
SESSION
(or @@SESSION.
) when
setting a variable that has only a global value:
mysql> SET SESSION max_connections = 1000;
ERROR 1229 (HY000): Variable 'max_connections' is a
GLOBAL variable and should be set with SET GLOBAL
The preceding modifiers apply only to system variables. An error occurs for attempts to apply them to user-defined variables, stored procedure or function parameters, or stored program local variables.
A SET
statement can contain multiple variable assignments, separated by
commas. This statement assigns values to a user-defined variable
and a system variable:
SET @x = 1, SESSION sql_mode = '';
If you set multiple system variables, the most recent
GLOBAL
, PERSIST
,
PERSIST_ONLY
, or SESSION
modifier in the statement is used for following assignments that
have no modifier specified.
Examples of multiple-variable assignment:
SET GLOBAL sort_buffer_size = 1000000, SESSION sort_buffer_size = 1000000; SET @@global.sort_buffer_size = 1000000, @@local.sort_buffer_size = 1000000; SET GLOBAL max_connections = 1000, sort_buffer_size = 1000000;
If any variable assignment in a
SET
statement fails, the entire statement fails and no variables are
changed, nor is the mysqld-auto.cnf
file
changed.
If you change a session system variable, the value remains in effect within your session until you change the variable to a different value or the session ends. The change has no effect on other sessions.
If you change a global system variable, the value is remembered
and used for new sessions until you change the variable to a
different value or the server exits. The change is visible to any
client that accesses the global variable. However, the change
affects the corresponding session variable only for clients that
connect after the change. The global variable change does not
affect the session variable for any current client sessions (not
even the session within which the
SET GLOBAL
statement occurred).
To make a global system variable setting permanent so that it
applies across server restarts, modify it with
SET
PERSIST
or PERSIST_ONLY
to record it
in the mysqld-auto.cnf
file. It is also
possible to use SET
GLOBAL
and manually modify a my.cnf
file, but that is more cumbersome, and an error in a manually
entered setting might not be discovered until much later.
SET
PERSIST
or PERSIST_ONLY
is more
convenient and avoids the possibility of malformed settings.
The Performance Schema
persisted_variables
table provides an
SQL interface to the mysqld-auto.cnf
file,
enabling its contents to be inspected at runtime using
SELECT
statements. See
Section 25.11.13.1, “Performance Schema persisted_variables Table”.
The Performance Schema variables_info
table contains information showing when and by which user each
system variable was most recently set. See
Section 25.11.13.2, “Performance Schema variables_info Table”.
To set a GLOBAL
value to the compiled-in MySQL
default value or a SESSION
variable to the
current corresponding GLOBAL
value, set the
variable to the value DEFAULT
. For example, the
following two statements are identical in setting the session
value of max_join_size
to the
current global value:
SET @@session.max_join_size=DEFAULT; SET @@session.max_join_size=@@global.max_join_size;
Not all system variables can be set to DEFAULT
.
In such cases, assigning DEFAULT
results in an
error.
With SET
PERSIST
(or @@persist.
), setting a
global variable to DEFAULT
or to its literal
default value assigns the variable its default value and adds a
setting for the variable to mysqld-auto.cnf
.
To remove the variable from the file, use
RESET PERSIST
.
An error occurs for attempts to assign DEFAULT
to user-defined variables, stored procedure or function
parameters, or stored program local variables.
To refer to the value of a system variable in expressions, use one
of the @@
-modifiers (except
@@persist.
, which is not permitted in
expressions). For example, you can retrieve values in a
SELECT
statement like this:
SELECT @@global.sql_mode, @@session.sql_mode, @@sql_mode;
For a reference to a system variable in an expression as
@@
(rather
than with var_name
@@global.
or
@@session.
), MySQL returns the session value if
it exists and the global value otherwise. This differs from
SET @@
, which always refers to
the session value.
var_name
=
expr
Suffixes for specifying a value multiplier can be used when
setting a variable at server startup, but not to set the value
with SET
at runtime. On the other hand, with
SET
you
can assign a variable's value using an expression, which is not
true when you set a variable at server startup. For example, the
first of the following lines is legal at server startup, but the
second is not:
shell>mysql --max_allowed_packet=16M
shell>mysql --max_allowed_packet=16*1024*1024
Conversely, the second of the following lines is legal at runtime, but the first is not:
mysql>SET GLOBAL max_allowed_packet=16M;
mysql>SET GLOBAL max_allowed_packet=16*1024*1024;
Some system variables can be enabled with the
SET
statement by setting them to ON
or
1
, or disabled by setting them to
OFF
or 0
. However, to set
such a variable on the command line or in an option file, you
must set it to 1
or 0
;
setting it to ON
or OFF
will not work. For example, on the command line,
--delay_key_write=1
works but
--delay_key_write=ON
does not.
To display system variable names and values, use the
SHOW VARIABLES
statement:
mysql> SHOW VARIABLES;
+---------------------------------+-----------------------------------+
| Variable_name | Value |
+---------------------------------+-----------------------------------+
| auto_increment_increment | 1 |
| auto_increment_offset | 1 |
| automatic_sp_privileges | ON |
| back_log | 151 |
| basedir | /home/mysql/ |
| binlog_cache_size | 32768 |
| bulk_insert_buffer_size | 8388608 |
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8mb4 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | utf8mb4 |
| character_set_system | utf8 |
| character_sets_dir | /home/mysql/share/mysql/charsets/ |
| collation_connection | utf8_general_ci |
| collation_database | utf8mb4_0900_ai_ci |
| collation_server | utf8mb4_0900_ai_ci |
...
| innodb_autoextend_increment | 8 |
| innodb_buffer_pool_size | 8388608 |
| innodb_commit_concurrency | 0 |
| innodb_concurrency_tickets | 500 |
| innodb_data_file_path | ibdata1:10M:autoextend |
| innodb_data_home_dir | |
...
| version | 8.0.1-dmr-log |
| version_comment | Source distribution |
| version_compile_machine | i686 |
| version_compile_os | suse-linux |
| wait_timeout | 28800 |
+---------------------------------+-----------------------------------+
With a LIKE
clause, the statement
displays only those variables that match the pattern. To obtain a
specific variable name, use a LIKE
clause as shown:
SHOW VARIABLES LIKE 'max_join_size'; SHOW SESSION VARIABLES LIKE 'max_join_size';
To get a list of variables whose name match a pattern, use the
%
wildcard character in a
LIKE
clause:
SHOW VARIABLES LIKE '%size%'; SHOW GLOBAL VARIABLES LIKE '%size%';
Wildcard characters can be used in any position within the pattern
to be matched. Strictly speaking, because _
is
a wildcard that matches any single character, you should escape it
as \_
to match it literally. In practice, this
is rarely necessary.
For SHOW VARIABLES
, if you specify
neither GLOBAL
nor SESSION
,
MySQL returns SESSION
values.
The reason for requiring the GLOBAL
keyword
when setting GLOBAL
-only variables but not when
retrieving them is to prevent problems in the future:
Were we to remove a SESSION
variable that
has the same name as a GLOBAL
variable, a
client with the
SYSTEM_VARIABLES_ADMIN
or
SUPER
privilege might
accidentally change the GLOBAL
variable
rather than just the SESSION
variable for
its own connection.
Were we to add a SESSION
variable with the
same name as a GLOBAL
variable, a client
that intends to change the GLOBAL
variable
might find only its own SESSION
variable
changed.
SET
PERSIST
and
SET
PERSIST_ONLY
enable system variables to be persisted
to the mysqld-auto.cnf
option file in the
data directory (see Section 13.7.5.1, “SET Syntax for Variable Assignment”). However,
not all system variables can be persisted:
These system variables cannot be persisted:
auto_generate_certs basedir bind_address character_set_system character_sets_dir core_file datadir default_authentication_plugin ft_stopword_file have_statement_timeout have_symlink hostname init_file keyring_operations large_files_support large_page_size lc_messages_dir license locked_in_memory log_bin log_bin_basename log_bin_index log_bin_use_v1_row_events log_error lower_case_file_system named_pipe persisted_globals_load pid_file plugin_dir port protocol_version relay_log relay_log_basename relay_log_index relay_log_info_file secure_file_priv server_uuid shared_memory shared_memory_base_name skip_external_locking skip_networking slave_load_tmpdir socket ssl_ca ssl_capath ssl_cert ssl_crl ssl_crlpath ssl_key system_time_zone tmpdir version_comment version_compile_machine version_compile_os version_compile_zlib
These plugin system variables cannot be persisted:
audit_log_current_session audit_log_file audit_log_filter_id audit_log_format caching_sha2_password_auto_generate_rsa_keys caching_sha2_password_private_key_path caching_sha2_password_public_key_path daemon_memcached_engine_lib_name daemon_memcached_engine_lib_path daemon_memcached_option innodb_buffer_pool_load_at_startup innodb_data_file_path innodb_data_home_dir innodb_dedicated_server innodb_directories innodb_force_load_corrupted innodb_log_group_home_dir innodb_page_size innodb_read_only innodb_temp_data_file_path innodb_undo_directory innodb_undo_tablespaces innodb_version keyring_encrypted_file_data keyring_encrypted_file_password mecab_rc_file sha256_password_auto_generate_rsa_keys sha256_password_private_key_path sha256_password_public_key_path version_tokens_session
A structured variable differs from a regular system variable in two respects:
Its value is a structure with components that specify server parameters considered to be closely related.
There might be several instances of a given type of structured variable. Each one has a different name and refers to a different resource maintained by the server.
MySQL supports one structured variable type, which specifies parameters governing the operation of key caches. A key cache structured variable has these components:
This section describes the syntax for referring to structured variables. Key cache variables are used for syntax examples, but specific details about how key caches operate are found elsewhere, in Section 8.10.2, “The MyISAM Key Cache”.
To refer to a component of a structured variable instance, you
can use a compound name in
instance_name.component_name
format.
Examples:
hot_cache.key_buffer_size hot_cache.key_cache_block_size cold_cache.key_cache_block_size
For each structured system variable, an instance with the name
of default
is always predefined. If you refer
to a component of a structured variable without any instance
name, the default
instance is used. Thus,
default.key_buffer_size
and
key_buffer_size
both refer to
the same system variable.
Structured variable instances and components follow these naming rules:
For a given type of structured variable, each instance must
have a name that is unique within
variables of that type. However, instance names need not be
unique across structured variable
types. For example, each structured variable has an instance
named default
, so
default
is not unique across variable
types.
The names of the components of each structured variable type must be unique across all system variable names. If this were not true (that is, if two different types of structured variables could share component member names), it would not be clear which default structured variable to use for references to member names that are not qualified by an instance name.
If a structured variable instance name is not legal as an
unquoted identifier, refer to it as a quoted identifier
using backticks. For example, hot-cache
is not legal, but `hot-cache`
is.
global
, session
, and
local
are not legal instance names. This
avoids a conflict with notation such as
@@global.
for referring to nonstructured system variables.
var_name
Currently, the first two rules have no possibility of being violated because the only structured variable type is the one for key caches. These rules will assume greater significance if some other type of structured variable is created in the future.
With one exception, you can refer to structured variable components using compound names in any context where simple variable names can occur. For example, you can assign a value to a structured variable using a command-line option:
shell> mysqld --hot_cache.key_buffer_size=64K
In an option file, use this syntax:
[mysqld] hot_cache.key_buffer_size=64K
If you start the server with this option, it creates a key cache
named hot_cache
with a size of 64KB in
addition to the default key cache that has a default size of
8MB.
Suppose that you start the server as follows:
shell>mysqld --key_buffer_size=256K \
--extra_cache.key_buffer_size=128K \
--extra_cache.key_cache_block_size=2048
In this case, the server sets the size of the default key cache
to 256KB. (You could also have written
--default.key_buffer_size=256K
.) In addition,
the server creates a second key cache named
extra_cache
that has a size of 128KB, with
the size of block buffers for caching table index blocks set to
2048 bytes.
The following example starts the server with three different key caches having sizes in a 3:1:1 ratio:
shell>mysqld --key_buffer_size=6M \
--hot_cache.key_buffer_size=2M \
--cold_cache.key_buffer_size=2M
Structured variable values may be set and retrieved at runtime
as well. For example, to set a key cache named
hot_cache
to a size of 10MB, use either of
these statements:
mysql>SET GLOBAL hot_cache.key_buffer_size = 10*1024*1024;
mysql>SET @@global.hot_cache.key_buffer_size = 10*1024*1024;
To retrieve the cache size, do this:
mysql> SELECT @@global.hot_cache.key_buffer_size;
However, the following statement does not work. The variable is
not interpreted as a compound name, but as a simple string for a
LIKE
pattern-matching operation:
mysql> SHOW GLOBAL VARIABLES LIKE 'hot_cache.key_buffer_size';
This is the exception to being able to use structured variable names anywhere a simple variable name may occur.
Many server system variables are dynamic and can be set at
runtime using SET
GLOBAL
or
SET
SESSION
. You can also obtain their values using
SELECT
. See
Section 5.1.8, “Using System Variables”.
The following table shows the full list of all dynamic system
variables. The last column indicates for each variable whether
GLOBAL
or SESSION
(or
both) apply. The table also lists session options that can be
set with the
SET
statement. Section 5.1.7, “Server System Variables”, discusses
these options.
Variables that have a type of “string” take a
string value. Variables that have a type of
“numeric” take a numeric value. Variables that have
a type of “boolean” can be set to 0, 1,
ON
or OFF
. Variables that
are marked as “enumeration” normally should be set
to one of the available values for the variable, but can also be
set to the number that corresponds to the desired enumeration
value. For enumerated system variables, the first enumeration
value corresponds to 0. This differs from
ENUM
columns, for which the first
enumeration value corresponds to 1.
Table 5.4 Dynamic Variable Summary
The MySQL server maintains many status variables that provide
information about its operation. You can view these variables and
their values by using the SHOW [GLOBAL | SESSION]
STATUS
statement (see Section 13.7.6.35, “SHOW STATUS Syntax”).
The optional GLOBAL
keyword aggregates the
values over all connections, and SESSION
shows
the values for the current connection.
mysql> SHOW GLOBAL STATUS;
+-----------------------------------+------------+
| Variable_name | Value |
+-----------------------------------+------------+
| Aborted_clients | 0 |
| Aborted_connects | 0 |
| Bytes_received | 155372598 |
| Bytes_sent | 1176560426 |
...
| Connections | 30023 |
| Created_tmp_disk_tables | 0 |
| Created_tmp_files | 3 |
| Created_tmp_tables | 2 |
...
| Threads_created | 217 |
| Threads_running | 88 |
| Uptime | 1389872 |
+-----------------------------------+------------+
Several status variables provide statement counts. To determine the number of statements executed, use these relationships:
SUM(Com_xxx) = Questions + statements executed within stored programs = Queries
Many status variables are reset to 0 by the
FLUSH STATUS
statement.
This section provides a description of each status variable. For a status variable summary, see Section 5.1.5, “Server Status Variable Reference”.
The status variables have the following meanings.
The number of connections that were aborted because the client died without closing the connection properly. See Section B.5.2.10, “Communication Errors and Aborted Connections”.
The number of failed attempts to connect to the MySQL server. See Section B.5.2.10, “Communication Errors and Aborted Connections”.
For additional connection-related information, check the
Connection_errors_
status variables and the
xxx
host_cache
table.
The number of transactions that used the temporary binary log
cache but that exceeded the value of
binlog_cache_size
and used a
temporary file to store statements from the transaction.
The number of nontransactional statements that caused the
binary log transaction cache to be written to disk is tracked
separately in the
Binlog_stmt_cache_disk_use
status variable.
The number of cached privilege objects. Each object is the privilege combination of a user and its active roles.
The number of transactions that used the binary log cache.
The number of nontransaction statements that used the binary
log statement cache but that exceeded the value of
binlog_stmt_cache_size
and
used a temporary file to store those statements.
The number of nontransactional statements that used the binary log statement cache.
The number of bytes received from all clients.
The number of bytes sent to all clients.
Caching_sha2_password_rsa_public_key
The public key used by the
caching_sha2_password
authentication plugin
for RSA key pair-based password exchange. The value is
nonempty only if the server successfully initializes the
private and public keys in the files named by the
caching_sha2_password_private_key_path
and
caching_sha2_password_public_key_path
system variables. The value of
Caching_sha2_password_rsa_public_key
comes from the latter file.
The Com_
statement counter variables indicate the number of times each
xxx
xxx
statement has been executed.
There is one status variable for each type of statement. For
example, Com_delete
and
Com_update
count
DELETE
and
UPDATE
statements,
respectively. Com_delete_multi
and
Com_update_multi
are similar but apply to
DELETE
and
UPDATE
statements that use
multiple-table syntax.
The discussion at the beginning of this section indicates how to relate these statement-counting status variables to other such variables.
All of the
Com_stmt_
variables are increased even if a prepared statement argument
is unknown or an error occurred during execution. In other
words, their values correspond to the number of requests
issued, not to the number of requests successfully completed.
xxx
The Com_stmt_
status variables are as follows:
xxx
Com_stmt_prepare
Com_stmt_execute
Com_stmt_fetch
Com_stmt_send_long_data
Com_stmt_reset
Com_stmt_close
Those variables stand for prepared statement commands. Their
names refer to the
COM_
command
set used in the network layer. In other words, their values
increase whenever prepared statement API calls such as
mysql_stmt_prepare(),
mysql_stmt_execute(), and so forth are
executed. However, xxx
Com_stmt_prepare
,
Com_stmt_execute
and
Com_stmt_close
also increase for
PREPARE
,
EXECUTE
, or
DEALLOCATE PREPARE
,
respectively. Additionally, the values of the older statement
counter variables Com_prepare_sql
,
Com_execute_sql
, and
Com_dealloc_sql
increase for the
PREPARE
,
EXECUTE
, and
DEALLOCATE PREPARE
statements.
Com_stmt_fetch
stands for the total number
of network round-trips issued when fetching from cursors.
Com_stmt_reprepare
indicates the number of
times statements were automatically reprepared by the server
after metadata changes to tables or views referred to by the
statement. A reprepare operation increments
Com_stmt_reprepare
, and also
Com_stmt_prepare
.
Com_explain_other
indicates the number of
EXPLAIN FOR
CONNECTION
statements executed. See
Section 8.8.4, “Obtaining Execution Plan Information for a Named Connection”.
Com_change_repl_filter
indicates the number
of CHANGE REPLICATION FILTER
statements executed.
Whether the client connection uses compression in the client/server protocol.
These variables provide information about errors that occur during the client connection process. They are global only and represent error counts aggregated across connections from all hosts. These variables track errors not accounted for by the host cache (see Section 8.12.4.2, “DNS Lookup Optimization and the Host Cache”), such as errors that are not associated with TCP connections, occur very early in the connection process (even before an IP address is known), or are not specific to any particular IP address (such as out-of-memory conditions).
The number of errors that occurred during calls to
accept()
on the listening port.
The number of connections refused due to internal errors in the server, such as failure to start a new thread or an out-of-memory condition.
Connection_errors_max_connections
The number of connections refused because the server
max_connections
limit was
reached.
Connection_errors_peer_address
The number of errors that occurred while searching for connecting client IP addresses.
The number of errors that occurred during calls to
select()
or poll()
on the listening port. (Failure of this operation does not
necessarily means a client connection was rejected.)
The number of connections refused by the
libwrap
library.
The number of connection attempts (successful or not) to the MySQL server.
The number of internal on-disk temporary tables created by the server while executing statements.
If an internal temporary table is created initially as an
in-memory table but becomes too large, MySQL automatically
converts it to an on-disk table. The maximum size for
in-memory temporary tables is the minimum of the
tmp_table_size
and
max_heap_table_size
values.
If Created_tmp_disk_tables
is large, you may want to increase the
tmp_table_size
or
max_heap_table_size
value to
lessen the likelihood that internal temporary tables in memory
will be converted to on-disk tables.
You can compare the number of internal on-disk temporary
tables created to the total number of internal temporary
tables created by comparing the values of the
Created_tmp_disk_tables
and
Created_tmp_tables
variables.
See also Section 8.4.4, “Internal Temporary Table Use in MySQL”.
How many temporary files mysqld has created.
The number of internal temporary tables created by the server while executing statements.
You can compare the number of internal on-disk temporary
tables created to the total number of internal temporary
tables created by comparing the values of the
Created_tmp_disk_tables
and
Created_tmp_tables
variables.
See also Section 8.4.4, “Internal Temporary Table Use in MySQL”.
Each invocation of the SHOW
STATUS
statement uses an internal temporary table
and increments the global
Created_tmp_tables
value.
This status variable is deprecated (because
DELAYED
inserts are not supported), and
will be removed in a future release.
This status variable is deprecated (because
DELAYED
inserts are not supported), and
will be removed in a future release.
This status variable is deprecated (because
DELAYED
inserts are not supported), and
will be removed in a future release.
The result of the most recent assignment to the
dragnet.log_error_filter_rules
system variable, empty if no such assignment has occurred.
This variable was added in MySQL 8.0.12.
The number of times the server flushes tables, whether because
a user executed a FLUSH TABLES
statement or due to internal server operation. It is also
incremented by receipt of a COM_REFRESH
packet. This is in contrast to
Com_flush
,
which indicates how many FLUSH
statements
have been executed, whether FLUSH
TABLES
, FLUSH LOGS
,
and so forth.
group_replication_primary_member
Shows the primary member's UUID when the group is operating in single-primary mode. If the group is operating in multi-primary mode, shows an empty string.
The group_replication_primary_member
status
variable has been deprecated and is scheduled to be removed in
a future version.
The number of internal COMMIT
statements.
The number of times that rows have been deleted from tables.
The server increments this variable for each call to its
external_lock()
function, which generally
occurs at the beginning and end of access to a table instance.
There might be differences among storage engines. This
variable can be used, for example, to discover for a statement
that accesses a partitioned table how many partitions were
pruned before locking occurred: Check how much the counter
increased for the statement, subtract 2 (2 calls for the table
itself), then divide by 2 to get the number of partitions
locked.
The number of times the server uses a storage engine's own Multi-Range Read implementation for table access.
A counter for the prepare phase of two-phase commit operations.
The number of times the first entry in an index was read. If
this value is high, it suggests that the server is doing a lot
of full index scans; for example, SELECT col1 FROM
foo
, assuming that col1
is
indexed.
The number of requests to read a row based on a key. If this value is high, it is a good indication that your tables are properly indexed for your queries.
The number of requests to read the last key in an index. With
ORDER BY
, the server will issue a first-key
request followed by several next-key requests, whereas with
ORDER BY DESC
, the server will issue a
last-key request followed by several previous-key requests.
The number of requests to read the next row in key order. This value is incremented if you are querying an index column with a range constraint or if you are doing an index scan.
The number of requests to read the previous row in key order.
This read method is mainly used to optimize ORDER BY
... DESC
.
The number of requests to read a row based on a fixed position. This value is high if you are doing a lot of queries that require sorting of the result. You probably have a lot of queries that require MySQL to scan entire tables or you have joins that do not use keys properly.
The number of requests to read the next row in the data file. This value is high if you are doing a lot of table scans. Generally this suggests that your tables are not properly indexed or that your queries are not written to take advantage of the indexes you have.
The number of requests for a storage engine to perform a rollback operation.
The number of requests for a storage engine to place a savepoint.
The number of requests for a storage engine to roll back to a savepoint.
The number of requests to update a row in a table.
The number of requests to insert a row in a table.
Innodb_available_undo_logs
was removed in
MySQL 8.0.2. The number of available rollback segments per
tablespace may be retrieved using SHOW VARIABLES LIKE
'innodb_rollback_segments';
Innodb_buffer_pool_dump_status
The progress of an operation to record the
pages held in the
InnoDB
buffer pool, triggered
by the setting of
innodb_buffer_pool_dump_at_shutdown
or
innodb_buffer_pool_dump_now
.
For related information and examples, see Section 15.6.3.8, “Saving and Restoring the Buffer Pool State”.
Innodb_buffer_pool_load_status
The progress of an operation to
warm up the
InnoDB
buffer pool by reading
in a set of pages
corresponding to an earlier point in time, triggered by the
setting of
innodb_buffer_pool_load_at_startup
or
innodb_buffer_pool_load_now
.
If the operation introduces too much overhead, you can cancel
it by setting
innodb_buffer_pool_load_abort
.
For related information and examples, see Section 15.6.3.8, “Saving and Restoring the Buffer Pool State”.
The total number of bytes in the InnoDB
buffer pool containing
data. The number includes both
dirty and clean pages.
For more accurate memory usage calculations than with
Innodb_buffer_pool_pages_data
,
when compressed tables
cause the buffer pool to hold pages of different sizes.
The number of pages in the
InnoDB
buffer pool containing
data. The number includes both
dirty and clean pages.
When using compressed
tables, the reported
Innodb_buffer_pool_pages_data
value may be larger than
Innodb_buffer_pool_pages_total
(Bug #59550).
Innodb_buffer_pool_bytes_dirty
The total current number of bytes held in
dirty pages in the
InnoDB
buffer pool. For more
accurate memory usage calculations than with
Innodb_buffer_pool_pages_dirty
,
when compressed tables
cause the buffer pool to hold pages of different sizes.
Innodb_buffer_pool_pages_dirty
The current number of dirty
pages in the InnoDB
buffer pool.
Innodb_buffer_pool_pages_flushed
The number of requests to
flush
pages from the
InnoDB
buffer pool.
The number of free pages in
the InnoDB
buffer pool.
Innodb_buffer_pool_pages_latched
The number of latched pages
in the InnoDB
buffer pool. These are
pages currently being read or written, or that cannot be
flushed or removed for some
other reason. Calculation of this variable is expensive, so it
is available only when the UNIV_DEBUG
system is defined at server build time.
The number of pages in the
InnoDB
buffer pool that are
busy because they have been allocated for administrative
overhead, such as row
locks or the
adaptive hash
index. This value can also be calculated as
Innodb_buffer_pool_pages_total
−
Innodb_buffer_pool_pages_free
−
Innodb_buffer_pool_pages_data
.
When using compressed
tables,
Innodb_buffer_pool_pages_misc
may report an out-of-bounds value (Bug #59550).
Innodb_buffer_pool_pages_total
The total size of the InnoDB
buffer pool, in
pages. When using
compressed
tables, the reported
Innodb_buffer_pool_pages_data
value may be larger than
Innodb_buffer_pool_pages_total
(Bug #59550)
The number of pages read into
the InnoDB
buffer pool by the
read-ahead background
thread.
Innodb_buffer_pool_read_ahead_evicted
The number of pages read into
the InnoDB
buffer pool by the
read-ahead background
thread that were subsequently
evicted without having
been accessed by queries.
Innodb_buffer_pool_read_ahead_rnd
The number of “random” read-aheads initiated by
InnoDB
. This happens when a query scans a
large portion of a table but in random order.
Innodb_buffer_pool_read_requests
The number of logical read requests.
The number of logical reads that InnoDB
could not satisfy from the
buffer pool, and had
to read directly from disk.
Innodb_buffer_pool_resize_status
The status of an operation to resize the
InnoDB
buffer pool
dynamically, triggered by setting the
innodb_buffer_pool_size
parameter dynamically. The
innodb_buffer_pool_size
parameter is dynamic, which allows you to resize the buffer
pool without restarting the server. See
Configuring InnoDB Buffer Pool Size Online for related
information.
Normally, writes to the InnoDB
buffer pool happen in
the background. When InnoDB
needs to read
or create a page and no clean
pages are available, InnoDB
flushes some
dirty pages first and
waits for that operation to finish. This counter counts
instances of these waits. If
innodb_buffer_pool_size
has
been set properly, this value should be small.
Innodb_buffer_pool_write_requests
The number of writes done to the InnoDB
buffer pool.
The number of fsync()
operations so far.
The frequency of fsync()
calls is
influenced by the setting of the
innodb_flush_method
configuration option.
The current number of pending fsync()
operations. The frequency of fsync()
calls
is influenced by the setting of the
innodb_flush_method
configuration option.
The current number of pending reads.
The current number of pending writes.
The amount of data read since the server was started (in bytes).
The total number of data reads (OS file reads).
The total number of data writes.
The amount of data written so far, in bytes.
The number of pages that have been written to the doublewrite buffer. See Section 15.11.1, “InnoDB Disk I/O”.
The number of doublewrite operations that have been performed. See Section 15.11.1, “InnoDB Disk I/O”.
Indicates whether the server was built with atomic instructions.
The number of times that the log buffer was too small and a wait was required for it to be flushed before continuing.
The number of write requests for the InnoDB
redo log.
The number of physical writes to the InnoDB
redo log file.
The number of files InnoDB
currently holds
open.
The number of fsync()
writes done to the
InnoDB
redo
log files.
The number of pending fsync()
operations
for the InnoDB
redo log files.
The number of pending writes to the InnoDB
redo log files.
The number of bytes written to the InnoDB
redo log files.
InnoDB
page size (default 16KB). Many
values are counted in pages; the page size enables them to be
easily converted to bytes.
The number of pages created by operations on
InnoDB
tables.
The number of pages read from the InnoDB
buffer pool by operations on InnoDB
tables.
The number of pages written by operations on
InnoDB
tables.
The number of row locks
currently being waited for by operations on
InnoDB
tables.
The total time spent in acquiring
row locks for
InnoDB
tables, in milliseconds.
The average time to acquire a
row lock for
InnoDB
tables, in milliseconds.
The maximum time to acquire a
row lock for
InnoDB
tables, in milliseconds.
The number of times operations on InnoDB
tables had to wait for a row
lock.
The number of rows deleted from InnoDB
tables.
The number of rows inserted into InnoDB
tables.
The number of rows read from InnoDB
tables.
The number of rows updated in InnoDB
tables.
Innodb_truncated_status_writes
The number of times output from the SHOW ENGINE
INNODB STATUS
statement has been truncated.
The number of key blocks in the MyISAM
key
cache that have changed but have not yet been flushed to disk.
The number of unused blocks in the MyISAM
key cache. You can use this value to determine how much of the
key cache is in use; see the discussion of
key_buffer_size
in
Section 5.1.7, “Server System Variables”.
The number of used blocks in the MyISAM
key
cache. This value is a high-water mark that indicates the
maximum number of blocks that have ever been in use at one
time.
The number of requests to read a key block from the
MyISAM
key cache.
The number of physical reads of a key block from disk into the
MyISAM
key cache. If
Key_reads
is large, then
your key_buffer_size
value is
probably too small. The cache miss rate can be calculated as
Key_reads
/Key_read_requests
.
The number of requests to write a key block to the
MyISAM
key cache.
The number of physical writes of a key block from the
MyISAM
key cache to disk.
The total cost of the last compiled query as computed by the
query optimizer. This is useful for comparing the cost of
different query plans for the same query. The default value of
0 means that no query has been compiled yet. The default value
is 0. Last_query_cost
has
session scope.
The Last_query_cost
value
can be computed accurately only for simple “flat”
queries, not complex queries such as those with subqueries or
UNION
. For the latter, the
value is set to 0.
The number of iterations the query optimizer made in execution
plan construction for the previous query.
Last_query_cost
has session
scope.
The number of attempts to connect to locked user accounts. For information about account locking and unlocking, see Section 6.3.12, “User Account Locking”.
The number of SELECT
statements
for which the execution timeout was exceeded.
The number of SELECT
statements
for which a nonzero execution timeout was set. This includes
statements that include a nonzero
MAX_EXECUTION_TIME
optimizer hint, and
statements that include no such hint but execute while the
timeout indicated by the
max_execution_time
system
variable is nonzero.
The number of SELECT
statements
for which the attempt to set an execution timeout failed.
The maximum number of connections that have been in use simultaneously since the server started.
The time at which
Max_used_connections
reached
its current value.
This status variable is deprecated (because
DELAYED
inserts are not supported), and
will be removed in a future release.
The character set currently used by the MeCab full-text parser plugin. For related information, see Section 12.9.9, “MeCab Full-Text Parser Plugin”.
Ongoing_anonymous_transaction_count
Shows the number of ongoing transactions which have been marked as anonymous. This can be used to ensure that no further transactions are waiting to be processed.
Ongoing_anonymous_gtid_violating_transaction_count
This status variable is only available in debug builds. Shows
the number of ongoing transactions which use
gtid_next=ANONYMOUS
and that
violate GTID consistency.
Ongoing_automatic_gtid_violating_transaction_count
This status variable is only available in debug builds. Shows
the number of ongoing transactions which use
gtid_next=AUTOMATIC
and that
violate GTID consistency.
The number of files that are open. This count includes regular files opened by the server. It does not include other types of files such as sockets or pipes. Also, the count does not include files that storage engines open using their own internal functions rather than asking the server level to do so.
The number of streams that are open (used mainly for logging).
The number of cached table definitions.
The number of tables that are open.
The number of files that have been opened with
my_open()
(a mysys
library function). Parts of the server that open files without
using this function do not increment the count.
The number of table definitions that have been cached.
The number of tables that have been opened. If
Opened_tables
is big, your
table_open_cache
value is
probably too small.
Performance_schema_
xxx
Performance Schema status variables are listed in Section 25.15, “Performance Schema Status Variables”. These variables provide information about instrumentation that could not be loaded or created due to memory constraints.
The current number of prepared statements. (The maximum number
of statements is given by the
max_prepared_stmt_count
system variable.)
This status variable was removed in MySQL 8.0.3.
This status variable was removed in MySQL 8.0.3.
This status variable was removed in MySQL 8.0.3.
This status variable was removed in MySQL 8.0.3.
This status variable was removed in MySQL 8.0.3.
This status variable was removed in MySQL 8.0.3.
This status variable was removed in MySQL 8.0.3.
This status variable was removed in MySQL 8.0.3.
The number of statements executed by the server. This variable
includes statements executed within stored programs, unlike
the Questions
variable. It
does not count COM_PING
or
COM_STATISTICS
commands.
The discussion at the beginning of this section indicates how to relate this statement-counting status variable to other such variables.
The number of statements executed by the server. This includes
only statements sent to the server by clients and not
statements executed within stored programs, unlike the
Queries
variable. This
variable does not count COM_PING
,
COM_STATISTICS
,
COM_STMT_PREPARE
,
COM_STMT_CLOSE
, or
COM_STMT_RESET
commands.
The discussion at the beginning of this section indicates how to relate this statement-counting status variable to other such variables.
The number of semisynchronous slaves.
This variable is available only if the master-side semisynchronous replication plugin is installed.
Rpl_semi_sync_master_net_avg_wait_time
The average time in microseconds the master waited for a slave
reply. This variable is always 0
, is
deprecated and it will be removed in a future version.
This variable is available only if the master-side semisynchronous replication plugin is installed.
Rpl_semi_sync_master_net_wait_time
The total time in microseconds the master waited for slave
replies. This variable is always 0
, is
deprecated and it will be removed in a future version.
This variable is available only if the master-side semisynchronous replication plugin is installed.
Rpl_semi_sync_master_net_waits
The total number of times the master waited for slave replies.
This variable is available only if the master-side semisynchronous replication plugin is installed.
The number of times the master turned off semisynchronous replication.
This variable is available only if the master-side semisynchronous replication plugin is installed.
The number of commits that were not acknowledged successfully by a slave.
This variable is available only if the master-side semisynchronous replication plugin is installed.
Whether semisynchronous replication currently is operational
on the master. The value is ON
if the
plugin has been enabled and a commit acknowledgment has
occurred. It is OFF
if the plugin is not
enabled or the master has fallen back to asynchronous
replication due to commit acknowledgment timeout.
This variable is available only if the master-side semisynchronous replication plugin is installed.
Rpl_semi_sync_master_timefunc_failures
The number of times the master failed when calling time
functions such as gettimeofday()
.
This variable is available only if the master-side semisynchronous replication plugin is installed.
Rpl_semi_sync_master_tx_avg_wait_time
The average time in microseconds the master waited for each transaction.
This variable is available only if the master-side semisynchronous replication plugin is installed.
Rpl_semi_sync_master_tx_wait_time
The total time in microseconds the master waited for transactions.
This variable is available only if the master-side semisynchronous replication plugin is installed.
The total number of times the master waited for transactions.
This variable is available only if the master-side semisynchronous replication plugin is installed.
Rpl_semi_sync_master_wait_pos_backtraverse
The total number of times the master waited for an event with binary coordinates lower than events waited for previously. This can occur when the order in which transactions start waiting for a reply is different from the order in which their binary log events are written.
This variable is available only if the master-side semisynchronous replication plugin is installed.
Rpl_semi_sync_master_wait_sessions
The number of sessions currently waiting for slave replies.
This variable is available only if the master-side semisynchronous replication plugin is installed.
The number of commits that were acknowledged successfully by a slave.
This variable is available only if the master-side semisynchronous replication plugin is installed.
Whether semisynchronous replication currently is operational
on the slave. This is ON
if the plugin has
been enabled and the slave I/O thread is running,
OFF
otherwise.
This variable is available only if the slave-side semisynchronous replication plugin is installed.
This variable is available if MySQL was compiled using OpenSSL
(see Section 6.4.4, “OpenSSL Versus wolfSSL”). Its value is the public
key used by the sha256_password
authentication plugin for RSA key pair-based password
exchange. The value is nonempty only if the server
successfully initializes the private and public keys in the
files named by the
sha256_password_private_key_path
and
sha256_password_public_key_path
system variables. The value of
Rsa_public_key
comes from
the latter file.
For information about sha256_password
, see
Section 6.5.1.2, “SHA-256 Pluggable Authentication”.
Secondary_engine_execution_count
For future use. This variable was added in MySQL 8.0.13.
The number of joins that perform table scans because they do not use indexes. If this value is not 0, you should carefully check the indexes of your tables.
The number of joins that used a range search on a reference table.
The number of joins that used ranges on the first table. This is normally not a critical issue even if the value is quite large.
The number of joins without keys that check for key usage after each row. If this is not 0, you should carefully check the indexes of your tables.
The number of joins that did a full scan of the first table.
This variable is obsolete and was removed in MySQL 8.0.1.
Instead, use the HEARTBEAT_INTERVAL
column
of the
replication_connection_configuration
table.
This variable is obsolete and was removed in MySQL 8.0.1.
Instead, use the LAST_HEARTBEAT_TIMESTAMP
column of the
replication_connection_status
table.
The number of temporary tables that the slave SQL thread currently has open. If the value is greater than zero, it is not safe to shut down the slave; see Section 17.4.1.31, “Replication and Temporary Tables”. This variable reports the total count of open temporary tables for all replication channels.
This variable is obsolete and was removed in MySQL 8.0.1.
Instead, use the COUNT_RECEIVED_HEARTBEATS
column of the
replication_connection_status
table.
This variable is obsolete and was removed in MySQL 8.0.1.
Instead, use the COUNT_TRANSACTIONS_RETRIES
column of the
replication_applier_status
table.
Slave_rows_last_search_algorithm_used
The search algorithm that was most recently used by this slave to locate rows for row-based replication. The result shows whether the slave used indexes, a table scan, or hashing as the search algorithm for the last transaction executed on any channel.
The method used depends on the setting for the
slave_rows_search_algorithms
system variable, and the keys that are available on the
relevant table.
This variable is available only for debug builds of MySQL.
This variable is obsolete and was removed in MySQL 8.0.1.
Instead, use the SERVICE_STATE
column of
the replication_connection_status
and replication_applier_status
tables.
The number of threads that have taken more than
slow_launch_time
seconds to
create.
The number of queries that have taken more than
long_query_time
seconds. This
counter increments regardless of whether the slow query log is
enabled. For information about that log, see
Section 5.4.5, “The Slow Query Log”.
The number of merge passes that the sort algorithm has had to
do. If this value is large, you should consider increasing the
value of the sort_buffer_size
system variable.
The number of sorts that were done using ranges.
The number of sorted rows.
The number of sorts that were done by scanning the table.
The number of negotiates needed to establish the connection.
The number of accepted SSL connections.
The number of callback cache hits.
The current encryption cipher (empty for unencrypted connections).
The list of possible SSL ciphers (empty for non-SSL connections).
The number of SSL connection attempts to an SSL-enabled master.
The number of negotiates needed to establish the connection to an SSL-enabled master.
The SSL context verification depth (how many certificates in the chain are tested).
The SSL context verification mode.
The default SSL timeout.
The number of successful SSL connections to the server.
The number of successful slave connections to an SSL-enabled master.
The last date for which the SSL certificate is valid. To check SSL certificate expiration information, use this statement:
mysql> SHOW STATUS LIKE 'Ssl_server_not%';
+-----------------------+--------------------------+
| Variable_name | Value |
+-----------------------+--------------------------+
| Ssl_server_not_after | Apr 28 14:16:39 2025 GMT |
| Ssl_server_not_before | May 1 14:16:39 2015 GMT |
+-----------------------+--------------------------+
The first date for which the SSL certificate is valid.
The number of SSL session cache hits.
The number of SSL session cache misses.
The SSL session cache mode.
The number of SSL session cache overflows.
The SSL session cache size.
The number of SSL session cache timeouts.
How many SSL connections were reused from the cache.
Ssl_used_session_cache_entries
How many SSL session cache entries were used.
The verification depth for replication SSL connections.
The verification mode used by the server for a connection that
uses SSL. The value is a bitmask; bits are defined in the
openssl/ssl.h
header file:
# define SSL_VERIFY_NONE 0x00 # define SSL_VERIFY_PEER 0x01 # define SSL_VERIFY_FAIL_IF_NO_PEER_CERT 0x02 # define SSL_VERIFY_CLIENT_ONCE 0x04
SSL_VERIFY_PEER
indicates that the server
asks for a client certificate. If the client supplies one, the
server performs verification and proceeds only if verification
is successful. SSL_VERIFY_CLIENT_ONCE
indicates that a request for the client certificate will be
done only in the initial handshake.
The SSL protocol version of the connection; for example, TLSv1. If the connection is not encrypted, the value is empty.
The number of times that a request for a table lock could be granted immediately.
The number of times that a request for a table lock could not be granted immediately and a wait was needed. If this is high and you have performance problems, you should first optimize your queries, and then either split your table or tables or use replication.
The number of hits for open tables cache lookups.
The number of misses for open tables cache lookups.
The number of overflows for the open tables cache. This is the
number of times, after a table is opened or closed, a cache
instance has an unused entry and the size of the instance is
larger than table_open_cache
/ table_open_cache_instances
.
Property | Value |
---|---|
Command-Line Format | --tablespace-definition-cache=N |
System Variable | tablespace_definition_cache |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 256 |
Minimum Value | 256 |
Maximum Value | 524288 |
Defines a limit for the number of tablespace definition objects, both used and unused, that can be kept in the dictionary object cache.
Unused tablespace definition objects are only kept in the
dictionary object cache when the number in use is less than
the capacity defined by
tablespace_definition_cache
.
A setting of 0
means that tablespace
definition objects are only kept in the dictionary object
cache while they are in use.
For more information, see Section 14.4, “Dictionary Object Cache”.
For the memory-mapped implementation of the log that is used
by mysqld when it acts as the transaction
coordinator for recovery of internal XA transactions, this
variable indicates the largest number of pages used for the
log since the server started. If the product of
Tc_log_max_pages_used
and
Tc_log_page_size
is always
significantly less than the log size, the size is larger than
necessary and can be reduced. (The size is set by the
--log-tc-size
option. This
variable is unused: It is unneeded for binary log-based
recovery, and the memory-mapped recovery log method is not
used unless the number of storage engines that are capable of
two-phase commit and that support XA transactions is greater
than one. (InnoDB
is the only applicable
engine.)
The page size used for the memory-mapped implementation of the
XA recovery log. The default value is determined using
getpagesize()
. This variable is unused for
the same reasons as described for
Tc_log_max_pages_used
.
For the memory-mapped implementation of the recovery log, this
variable increments each time the server was not able to
commit a transaction and had to wait for a free page in the
log. If this value is large, you might want to increase the
log size (with the
--log-tc-size
option). For
binary log-based recovery, this variable increments each time
the binary log cannot be closed because there are two-phase
commits in progress. (The close operation waits until all such
transactions are finished.)
The number of threads in the thread cache.
The number of currently open connections.
The number of threads created to handle connections. If
Threads_created
is big, you
may want to increase the
thread_cache_size
value. The
cache miss rate can be calculated as
Threads_created
/Connections
.
The number of threads that are not sleeping.
The number of seconds that the server has been up.
The number of seconds since the most recent FLUSH
STATUS
statement.
The MySQL server can operate in different SQL modes, and can apply
these modes differently for different clients, depending on the
value of the sql_mode
system
variable. DBAs can set the global SQL mode to match site server
operating requirements, and each application can set its session
SQL mode to its own requirements.
Modes affect the SQL syntax MySQL supports and the data validation checks it performs. This makes it easier to use MySQL in different environments and to use MySQL together with other database servers.
For answers to questions often asked about server SQL modes in MySQL, see Section A.3, “MySQL 8.0 FAQ: Server SQL Mode”.
When working with InnoDB
tables, consider also
the innodb_strict_mode
system
variable. It enables additional error checks for
InnoDB
tables.
The default SQL mode in MySQL 8.0 includes these
modes: ONLY_FULL_GROUP_BY
,
STRICT_TRANS_TABLES
,
NO_ZERO_IN_DATE
,
NO_ZERO_DATE
,
ERROR_FOR_DIVISION_BY_ZERO
,
and NO_ENGINE_SUBSTITUTION
.
To set the SQL mode at server startup, use the
--sql-mode="
option on the command line, or
modes
"sql-mode="
in an option file such as modes
"my.cnf
(Unix
operating systems) or my.ini
(Windows).
modes
is a list of different modes
separated by commas. To clear the SQL mode explicitly, set it to
an empty string using
--sql-mode=""
on the command
line, or sql-mode=""
in an option
file.
MySQL installation programs may configure the SQL mode during the installation process.
If the SQL mode differs from the default or from what you expect, check for a setting in an option file that the server reads at startup.
To change the SQL mode at runtime, set the global or session
sql_mode
system variable using
a SET
statement:
SET GLOBAL sql_mode = 'modes
'; SET SESSION sql_mode = 'modes
';
Setting the GLOBAL
variable requires the
SYSTEM_VARIABLES_ADMIN
or
SUPER
privilege and affects the
operation of all clients that connect from that time on. Setting
the SESSION
variable affects only the current
client. Each client can change its session
sql_mode
value at any time.
To determine the current global or session
sql_mode
setting, select its
value:
SELECT @@GLOBAL.sql_mode; SELECT @@SESSION.sql_mode;
SQL mode and user-defined partitioning. Changing the server SQL mode after creating and inserting data into partitioned tables can cause major changes in the behavior of such tables, and could lead to loss or corruption of data. It is strongly recommended that you never change the SQL mode once you have created tables employing user-defined partitioning.
When replicating partitioned tables, differing SQL modes on the master and slave can also lead to problems. For best results, you should always use the same server SQL mode on the master and slave.
For more information, see Section 22.6, “Restrictions and Limitations on Partitioning”.
The most important sql_mode
values are probably these:
This mode changes syntax and behavior to conform more closely to standard SQL. It is one of the special combination modes listed at the end of this section.
If a value could not be inserted as given into a transactional table, abort the statement. For a nontransactional table, abort the statement if the value occurs in a single-row statement or the first row of a multiple-row statement. More details are given later in this section.
Make MySQL behave like a “traditional” SQL database system. A simple description of this mode is “give an error instead of a warning” when inserting an incorrect value into a column. It is one of the special combination modes listed at the end of this section.
With TRADITIONAL
mode
enabled, an INSERT
or
UPDATE
aborts as soon as an
error occurs. If you are using a nontransactional storage
engine, this may not be what you want because data changes
made prior to the error may not be rolled back, resulting
in a “partially done” update.
When this manual refers to “strict mode,” it means
a mode with either or both
STRICT_TRANS_TABLES
or
STRICT_ALL_TABLES
enabled.
The following list describes all supported SQL modes:
Do not perform full checking of dates. Check only that the
month is in the range from 1 to 12 and the day is in the
range from 1 to 31. This may be useful for Web applications
that obtain year, month, and day in three different fields
and store exactly what the user inserted, without date
validation. This mode applies to
DATE
and
DATETIME
columns. It does not
apply TIMESTAMP
columns,
which always require a valid date.
With ALLOW_INVALID_DATES
enabled, the server requires that month and day values be
legal, and not merely in the range 1 to 12 and 1 to 31,
respectively. With strict mode disabled, invalid dates such
as '2004-04-31'
are converted to
'0000-00-00'
and a warning is generated.
With strict mode enabled, invalid dates generate an error.
To permit such dates, enable
ALLOW_INVALID_DATES
.
Treat "
as an identifier quote character
(like the `
quote character) and not as a
string quote character. You can still use
`
to quote identifiers with this mode
enabled. With ANSI_QUOTES
enabled, you cannot use double quotation marks to quote
literal strings because they are interpreted as identifiers.
The
ERROR_FOR_DIVISION_BY_ZERO
mode affects handling of division by zero, which includes
MOD(
.
For data-change operations
(N
,0)INSERT
,
UPDATE
), its effect also
depends on whether strict SQL mode is enabled.
If this mode is not enabled, division by zero inserts
NULL
and produces no warning.
If this mode is enabled, division by zero inserts
NULL
and produces a warning.
If this mode and strict mode are enabled, division by
zero produces an error, unless IGNORE
is given as well. For INSERT IGNORE
and UPDATE IGNORE
, division by zero
inserts NULL
and produces a warning.
For SELECT
, division by zero
returns NULL
. Enabling
ERROR_FOR_DIVISION_BY_ZERO
causes a warning to be produced as well, regardless of
whether strict mode is enabled.
ERROR_FOR_DIVISION_BY_ZERO
is deprecated.
ERROR_FOR_DIVISION_BY_ZERO
is not part of strict mode, but should be used in
conjunction with strict mode and is enabled by default. A
warning occurs if
ERROR_FOR_DIVISION_BY_ZERO
is enabled without also enabling strict mode or vice versa.
Because
ERROR_FOR_DIVISION_BY_ZERO
is deprecated, it will be removed in a future MySQL release
as a separate mode name and its effect included in the
effects of strict SQL mode.
The precedence of the NOT
operator is such that expressions such as NOT a
BETWEEN b AND c
are parsed as NOT (a
BETWEEN b AND c)
. In some older versions of MySQL,
the expression was parsed as (NOT a) BETWEEN b AND
c
. The old higher-precedence behavior can be
obtained by enabling the
HIGH_NOT_PRECEDENCE
SQL
mode.
mysql>SET sql_mode = '';
mysql>SELECT NOT 1 BETWEEN -5 AND 5;
-> 0 mysql>SET sql_mode = 'HIGH_NOT_PRECEDENCE';
mysql>SELECT NOT 1 BETWEEN -5 AND 5;
-> 1
Permit spaces between a function name and the
(
character. This causes built-in
function names to be treated as reserved words. As a result,
identifiers that are the same as function names must be
quoted as described in Section 9.2, “Schema Object Names”. For
example, because there is a
COUNT()
function, the use of
count
as a table name in the following
statement causes an error:
mysql> CREATE TABLE count (i INT);
ERROR 1064 (42000): You have an error in your SQL syntax
The table name should be quoted:
mysql> CREATE TABLE `count` (i INT);
Query OK, 0 rows affected (0.00 sec)
The IGNORE_SPACE
SQL mode
applies to built-in functions, not to user-defined functions
or stored functions. It is always permissible to have spaces
after a UDF or stored function name, regardless of whether
IGNORE_SPACE
is enabled.
For further discussion of
IGNORE_SPACE
, see
Section 9.2.4, “Function Name Parsing and Resolution”.
NO_AUTO_VALUE_ON_ZERO
affects handling of AUTO_INCREMENT
columns. Normally, you generate the next sequence number for
the column by inserting either NULL
or
0
into it.
NO_AUTO_VALUE_ON_ZERO
suppresses this behavior for 0
so that
only NULL
generates the next sequence
number.
This mode can be useful if 0
has been
stored in a table's AUTO_INCREMENT
column. (Storing 0
is not a recommended
practice, by the way.) For example, if you dump the table
with mysqldump and then reload it, MySQL
normally generates new sequence numbers when it encounters
the 0
values, resulting in a table with
contents different from the one that was dumped. Enabling
NO_AUTO_VALUE_ON_ZERO
before reloading the dump file solves this problem. For this
reason, mysqldump automatically includes
in its output a statement that enables
NO_AUTO_VALUE_ON_ZERO
.
Disable the use of the backslash character
(\
) as an escape character within
strings. With this mode enabled, backslash becomes an
ordinary character like any other.
When creating a table, ignore all INDEX
DIRECTORY
and DATA DIRECTORY
directives. This option is useful on slave replication
servers.
Control automatic substitution of the default storage engine
when a statement such as CREATE
TABLE
or ALTER
TABLE
specifies a storage engine that is disabled
or not compiled in.
By default,
NO_ENGINE_SUBSTITUTION
is
enabled.
Because storage engines can be pluggable at runtime, unavailable engines are treated the same way:
With
NO_ENGINE_SUBSTITUTION
disabled, for CREATE TABLE
the default engine is used and a warning occurs if the
desired engine is unavailable. For
ALTER TABLE
, a warning occurs
and the table is not altered.
With
NO_ENGINE_SUBSTITUTION
enabled, an error occurs and the table is not created or
altered if the desired engine is unavailable.
Subtraction between integer values, where one is of type
UNSIGNED
, produces an unsigned result by
default. If the result would otherwise have been negative,
an error results:
mysql>SET sql_mode = '';
Query OK, 0 rows affected (0.00 sec) mysql>SELECT CAST(0 AS UNSIGNED) - 1;
ERROR 1690 (22003): BIGINT UNSIGNED value is out of range in '(cast(0 as unsigned) - 1)'
If the
NO_UNSIGNED_SUBTRACTION
SQL mode is enabled, the result is negative:
mysql>SET sql_mode = 'NO_UNSIGNED_SUBTRACTION';
mysql>SELECT CAST(0 AS UNSIGNED) - 1;
+-------------------------+ | CAST(0 AS UNSIGNED) - 1 | +-------------------------+ | -1 | +-------------------------+
If the result of such an operation is used to update an
UNSIGNED
integer column, the result is
clipped to the maximum value for the column type, or clipped
to 0 if
NO_UNSIGNED_SUBTRACTION
is
enabled. With strict SQL mode enabled, an error occurs and
the column remains unchanged.
When
NO_UNSIGNED_SUBTRACTION
is
enabled, the subtraction result is signed, even if
any operand is unsigned. For example, compare the
type of column c2
in table
t1
with that of column
c2
in table t2
:
mysql>SET sql_mode='';
mysql>CREATE TABLE test (c1 BIGINT UNSIGNED NOT NULL);
mysql>CREATE TABLE t1 SELECT c1 - 1 AS c2 FROM test;
mysql>DESCRIBE t1;
+-------+---------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+---------------------+------+-----+---------+-------+ | c2 | bigint(21) unsigned | NO | | 0 | | +-------+---------------------+------+-----+---------+-------+ mysql>SET sql_mode='NO_UNSIGNED_SUBTRACTION';
mysql>CREATE TABLE t2 SELECT c1 - 1 AS c2 FROM test;
mysql>DESCRIBE t2;
+-------+------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+------------+------+-----+---------+-------+ | c2 | bigint(21) | NO | | 0 | | +-------+------------+------+-----+---------+-------+
This means that BIGINT UNSIGNED
is not
100% usable in all contexts. See
Section 12.10, “Cast Functions and Operators”.
The NO_ZERO_DATE
mode
affects whether the server permits
'0000-00-00'
as a valid date. Its effect
also depends on whether strict SQL mode is enabled.
If this mode is not enabled,
'0000-00-00'
is permitted and inserts
produce no warning.
If this mode is enabled, '0000-00-00'
is permitted and inserts produce a warning.
If this mode and strict mode are enabled,
'0000-00-00'
is not permitted and
inserts produce an error, unless
IGNORE
is given as well. For
INSERT IGNORE
and UPDATE
IGNORE
, '0000-00-00'
is
permitted and inserts produce a warning.
NO_ZERO_DATE
is
deprecated. NO_ZERO_DATE
is not part of strict mode, but should be used in
conjunction with strict mode and is enabled by default. A
warning occurs if
NO_ZERO_DATE
is enabled
without also enabling strict mode or vice versa.
Because NO_ZERO_DATE
is
deprecated, it will be removed in a future MySQL release as
a separate mode name and its effect included in the effects
of strict SQL mode.
The NO_ZERO_IN_DATE
mode
affects whether the server permits dates in which the year
part is nonzero but the month or day part is 0. (This mode
affects dates such as '2010-00-01'
or
'2010-01-00'
, but not
'0000-00-00'
. To control whether the
server permits '0000-00-00'
, use the
NO_ZERO_DATE
mode.) The
effect of NO_ZERO_IN_DATE
also depends on whether strict SQL mode is enabled.
If this mode is not enabled, dates with zero parts are permitted and inserts produce no warning.
If this mode is enabled, dates with zero parts are
inserted as '0000-00-00'
and produce
a warning.
If this mode and strict mode are enabled, dates with
zero parts are not permitted and inserts produce an
error, unless IGNORE
is given as
well. For INSERT IGNORE
and
UPDATE IGNORE
, dates with zero parts
are inserted as '0000-00-00'
and
produce a warning.
NO_ZERO_IN_DATE
is
deprecated.
NO_ZERO_IN_DATE
is not
part of strict mode, but should be used in conjunction with
strict mode and is enabled by default. A warning occurs if
NO_ZERO_IN_DATE
is enabled
without also enabling strict mode or vice versa.
Because NO_ZERO_IN_DATE
is
deprecated, it will be removed in a future MySQL release as
a separate mode name and its effect included in the effects
of strict SQL mode.
Reject queries for which the select list,
HAVING
condition, or ORDER
BY
list refer to nonaggregated columns that are
neither named in the GROUP BY
clause nor
are functionally dependent on (uniquely determined by)
GROUP BY
columns.
A MySQL extension to standard SQL permits references in the
HAVING
clause to aliased expressions in
the select list. The HAVING
clause can
refer to aliases regardless of whether
ONLY_FULL_GROUP_BY
is
enabled.
For additional discussion and examples, see Section 12.19.3, “MySQL Handling of GROUP BY”.
By default, trailing spaces are trimmed from
CHAR
column values on
retrieval. If
PAD_CHAR_TO_FULL_LENGTH
is
enabled, trimming does not occur and retrieved
CHAR
values are padded to
their full length. This mode does not apply to
VARCHAR
columns, for which
trailing spaces are retained on retrieval.
As of MySQL 8.0.13,
PAD_CHAR_TO_FULL_LENGTH
is deprecated. It will be removed in a future version of
MySQL.
mysql>CREATE TABLE t1 (c1 CHAR(10));
Query OK, 0 rows affected (0.37 sec) mysql>INSERT INTO t1 (c1) VALUES('xy');
Query OK, 1 row affected (0.01 sec) mysql>SET sql_mode = '';
Query OK, 0 rows affected (0.00 sec) mysql>SELECT c1, CHAR_LENGTH(c1) FROM t1;
+------+-----------------+ | c1 | CHAR_LENGTH(c1) | +------+-----------------+ | xy | 2 | +------+-----------------+ 1 row in set (0.00 sec) mysql>SET sql_mode = 'PAD_CHAR_TO_FULL_LENGTH';
Query OK, 0 rows affected (0.00 sec) mysql>SELECT c1, CHAR_LENGTH(c1) FROM t1;
+------------+-----------------+ | c1 | CHAR_LENGTH(c1) | +------------+-----------------+ | xy | 10 | +------------+-----------------+ 1 row in set (0.00 sec)
Treat ||
as a
string concatenation operator (same as
CONCAT()
) rather than as a
synonym for OR
.
Treat REAL
as a synonym for
FLOAT
. By default, MySQL
treats REAL
as a synonym for
DOUBLE
.
Enable strict SQL mode for all storage engines. Invalid data values are rejected. For details, see Strict SQL Mode.
Enable strict SQL mode for transactional storage engines, and when possible for nontransactional storage engines. For details, see Strict SQL Mode.
Control whether rounding or truncation occurs when inserting
a TIME
,
DATE
, or
TIMESTAMP
value with a
fractional seconds part into a column having the same type
but fewer fractional digits. The behavior is to use
rounding. If this mode is enabled, truncation occurs
instead. The following sequence of statements illustrates
the difference:
CREATE TABLE t (id INT, tval TIME(1)); SET sql_mode=''; INSERT INTO t (id, tval) VALUES(1, 1.55); SET sql_mode='TIME_TRUNCATE_FRACTIONAL'; INSERT INTO t (id, tval) VALUES(2, 1.55);
The resulting table contents look like this, where the first value has been subject to rounding and the second to truncation:
mysql> SELECT id, tval FROM t ORDER BY id;
+------+------------+
| id | tval |
+------+------------+
| 1 | 00:00:01.6 |
| 2 | 00:00:01.5 |
+------+------------+
The following special modes are provided as shorthand for combinations of mode values from the preceding list.
Equivalent to
REAL_AS_FLOAT
,
PIPES_AS_CONCAT
,
ANSI_QUOTES
,
IGNORE_SPACE
, and
ONLY_FULL_GROUP_BY
.
ANSI
mode also causes the
server to return an error for queries where a set function
S
with an outer reference
cannot be aggregated in the outer query against which the
outer reference has been resolved. This is such a query:
S
(outer_ref
)
SELECT * FROM t1 WHERE t1.a IN (SELECT MAX(t1.b) FROM t2 WHERE ...);
Here, MAX(t1.b)
cannot
aggregated in the outer query because it appears in the
WHERE
clause of that query. Standard SQL
requires an error in this situation. If
ANSI
mode is not enabled,
the server treats
in such queries the same way that it would interpret
S
(outer_ref
)
.
S
(const
)
TRADITIONAL
is equivalent
to STRICT_TRANS_TABLES
,
STRICT_ALL_TABLES
,
NO_ZERO_IN_DATE
,
NO_ZERO_DATE
,
ERROR_FOR_DIVISION_BY_ZERO
,
and
NO_ENGINE_SUBSTITUTION
.
Strict mode controls how MySQL handles invalid or missing values
in data-change statements such as
INSERT
or
UPDATE
. A value can be invalid
for several reasons. For example, it might have the wrong data
type for the column, or it might be out of range. A value is
missing when a new row to be inserted does not contain a value
for a non-NULL
column that has no explicit
DEFAULT
clause in its definition. (For a
NULL
column, NULL
is
inserted if the value is missing.) Strict mode also affects DDL
statements such as CREATE TABLE
.
If strict mode is not in effect, MySQL inserts adjusted values
for invalid or missing values and produces warnings (see
Section 13.7.6.40, “SHOW WARNINGS Syntax”). In strict mode, you can
produce this behavior by using
INSERT IGNORE
or UPDATE
IGNORE
.
For statements such as SELECT
that do not change data, invalid values generate a warning in
strict mode, not an error.
Strict mode produces an error for attempts to create a key that exceeds the maximum key length. When strict mode is not enabled, this results in a warning and truncation of the key to the maximum key length.
Strict mode does not affect whether foreign key constraints are
checked. foreign_key_checks
can
be used for that. (See
Section 5.1.7, “Server System Variables”.)
Strict SQL mode is in effect if either
STRICT_ALL_TABLES
or
STRICT_TRANS_TABLES
is
enabled, although the effects of these modes differ somewhat:
For transactional tables, an error occurs for invalid or
missing values in a data-change statement when either
STRICT_ALL_TABLES
or
STRICT_TRANS_TABLES
is
enabled. The statement is aborted and rolled back.
For nontransactional tables, the behavior is the same for either mode if the bad value occurs in the first row to be inserted or updated: The statement is aborted and the table remains unchanged. If the statement inserts or modifies multiple rows and the bad value occurs in the second or later row, the result depends on which strict mode is enabled:
For STRICT_ALL_TABLES
,
MySQL returns an error and ignores the rest of the rows.
However, because the earlier rows have been inserted or
updated, the result is a partial update. To avoid this,
use single-row statements, which can be aborted without
changing the table.
For
STRICT_TRANS_TABLES
,
MySQL converts an invalid value to the closest valid
value for the column and inserts the adjusted value. If
a value is missing, MySQL inserts the implicit default
value for the column data type. In either case, MySQL
generates a warning rather than an error and continues
processing the statement. Implicit defaults are
described in Section 11.7, “Data Type Default Values”.
Strict mode affects handling of division by zero, zero dates, and zeros in dates as follows:
Strict mode affects handling of division by zero, which
includes
MOD(
:
N
,0)
For data-change operations
(INSERT
,
UPDATE
):
If strict mode is not enabled, division by zero inserts
NULL
and produces no warning.
If strict mode is enabled, division by zero produces an
error, unless IGNORE
is given as
well. For INSERT IGNORE
and
UPDATE IGNORE
, division by zero
inserts NULL
and produces a warning.
For SELECT
, division by zero
returns NULL
. Enabling strict mode causes
a warning to be produced as well.
Strict mode affects whether the server permits
'0000-00-00'
as a valid date:
If strict mode is not enabled,
'0000-00-00'
is permitted and inserts
produce no warning.
If strict mode is enabled,
'0000-00-00'
is not permitted and
inserts produce an error, unless
IGNORE
is given as well. For
INSERT IGNORE
and UPDATE
IGNORE
, '0000-00-00'
is
permitted and inserts produce a warning.
Strict mode affects whether the server permits dates in
which the year part is nonzero but the month or day part is
0 (dates such as '2010-00-01'
or
'2010-01-00'
):
If strict mode is not enabled, dates with zero parts are permitted and inserts produce no warning.
If strict mode is enabled, dates with zero parts are not
permitted and inserts produce an error, unless
IGNORE
is given as well. For
INSERT IGNORE
and UPDATE
IGNORE
, dates with zero parts are inserted as
'0000-00-00'
(which is considered
valid with IGNORE
) and produce a
warning.
For more information about strict mode with respect to
IGNORE
, see
Comparison of the IGNORE Keyword and Strict SQL Mode.
Strict mode affects handling of division by zero, zero dates,
and zeros in dates in conjunction with the
ERROR_FOR_DIVISION_BY_ZERO
,
NO_ZERO_DATE
, and
NO_ZERO_IN_DATE
modes.
This section compares the effect on statement execution of the
IGNORE
keyword (which downgrades errors to
warnings) and strict SQL mode (which upgrades warnings to
errors). It describes which statements they affect, and which
errors they apply to.
The following table presents a summary comparison of statement
behavior when the default is to produce an error versus a
warning. An example of when the default is to produce an error
is inserting a NULL
into a NOT
NULL
column. An example of when the default is to
produce a warning is inserting a value of the wrong data type
into a column (such as inserting the string
'abc'
into an integer column).
Operational Mode | When Statement Default is Error | When Statement Default is Warning |
---|---|---|
Without IGNORE or strict SQL mode |
Error | Warning |
With IGNORE |
Warning | Warning (same as without IGNORE or strict SQL mode) |
With strict SQL mode | Error (same as without IGNORE or strict SQL mode) |
Error |
With IGNORE and strict SQL mode |
Warning | Warning |
One conclusion to draw from the table is that when the
IGNORE
keyword and strict SQL mode are both
in effect, IGNORE
takes precedence. This
means that, although IGNORE
and strict SQL
mode can be considered to have opposite effects on error
handling, they do not cancel when used together.
Several statements in MySQL support an optional
IGNORE
keyword. This keyword causes the
server to downgrade certain types of errors and generate
warnings instead. For a multiple-row statement,
IGNORE
causes the statement to skip to the
next row instead of aborting.
For example, if the table t
has a primary key
column i
, attempting to insert the same value
of i
into multiple rows normally produces a
duplicate-key error:
mysql> INSERT INTO t (i) VALUES(1),(1);
ERROR 1062 (23000): Duplicate entry '1' for key 'PRIMARY'
With IGNORE
, the row containing the duplicate
key still is not inserted, but a warning occurs instead of an
error:
mysql>INSERT IGNORE INTO t (i) VALUES(1),(1);
Query OK, 1 row affected, 1 warning (0.01 sec) Records: 2 Duplicates: 1 Warnings: 1 mysql>SHOW WARNINGS;
+---------+------+---------------------------------------+ | Level | Code | Message | +---------+------+---------------------------------------+ | Warning | 1062 | Duplicate entry '1' for key 'PRIMARY' | +---------+------+---------------------------------------+ 1 row in set (0.00 sec)
These statements support the IGNORE
keyword:
CREATE TABLE
... SELECT
: IGNORE
does not
apply to the CREATE TABLE
or
SELECT
parts of the statement
but to inserts into the table of rows produced by the
SELECT
. Rows that duplicate
an existing row on a unique key value are discarded.
DELETE
:
IGNORE
causes MySQL to ignore errors
during the process of deleting rows.
INSERT
: With
IGNORE
, rows that duplicate an existing
row on a unique key value are discarded. Rows set to values
that would cause data conversion errors are set to the
closest valid values instead.
For partitioned tables where no partition matching a given
value is found, IGNORE
causes the insert
operation to fail silently for rows containing the unmatched
value.
LOAD DATA
,
LOAD XML
: With
IGNORE
, rows that duplicate an existing
row on a unique key value are discarded.
UPDATE
: With
IGNORE
, rows for which duplicate-key
conflicts occur on a unique key value are not updated. Rows
updated to values that would cause data conversion errors
are updated to the closest valid values instead.
The IGNORE
keyword applies to the following
errors:
ER_BAD_NULL_ERROR
ER_DUP_ENTRY
ER_DUP_ENTRY_WITH_KEY_NAME
ER_DUP_KEY
ER_NO_PARTITION_FOR_GIVEN_VALUE
ER_NO_PARTITION_FOR_GIVEN_VALUE_SILENT
ER_NO_REFERENCED_ROW_2
ER_ROW_DOES_NOT_MATCH_GIVEN_PARTITION_SET
ER_ROW_IS_REFERENCED_2
ER_SUBQUERY_NO_1_ROW
ER_VIEW_CHECK_FAILED
The MySQL server can operate in different SQL modes, and can
apply these modes differently for different clients, depending
on the value of the sql_mode
system variable. In “strict” SQL mode, the server
upgrades certain warnings to errors.
For example, in non-strict SQL mode, inserting the string
'abc'
into an integer column results in
conversion of the value to 0 and a warning:
mysql>SET sql_mode = '';
Query OK, 0 rows affected (0.00 sec) mysql>INSERT INTO t (i) VALUES('abc');
Query OK, 1 row affected, 1 warning (0.01 sec) mysql>SHOW WARNINGS;
+---------+------+--------------------------------------------------------+ | Level | Code | Message | +---------+------+--------------------------------------------------------+ | Warning | 1366 | Incorrect integer value: 'abc' for column 'i' at row 1 | +---------+------+--------------------------------------------------------+ 1 row in set (0.00 sec)
In strict SQL mode, the invalid value is rejected with an error:
mysql>SET sql_mode = 'STRICT_ALL_TABLES';
Query OK, 0 rows affected (0.00 sec) mysql>INSERT INTO t (i) VALUES('abc');
ERROR 1366 (HY000): Incorrect integer value: 'abc' for column 'i' at row 1
For more information about possible settings of the
sql_mode
system variable, see
Section 5.1.10, “Server SQL Modes”.
Strict SQL mode applies to the following statements under conditions for which some value might be out of range or an invalid row is inserted into or deleted from a table:
Within stored programs, individual statements of the types just listed execute in strict SQL mode if the program was defined while strict mode was in effect.
Strict SQL mode applies to the following errors, represent a
class of errors in which an input value is either invalid or
missing. A value is invalid if it has the wrong data type for
the column or might be out of range. A value is missing if a new
row to be inserted does not contain a value for a NOT
NULL
column that has no explicit
DEFAULT
clause in its definition.
ER_BAD_NULL_ERROR
ER_CUT_VALUE_GROUP_CONCAT
ER_DATA_TOO_LONG
ER_DATETIME_FUNCTION_OVERFLOW
ER_DIVISION_BY_ZERO
ER_INVALID_ARGUMENT_FOR_LOGARITHM
ER_NO_DEFAULT_FOR_FIELD
ER_NO_DEFAULT_FOR_VIEW_FIELD
ER_TOO_LONG_KEY
ER_TRUNCATED_WRONG_VALUE
ER_TRUNCATED_WRONG_VALUE_FOR_FIELD
ER_WARN_DATA_OUT_OF_RANGE
ER_WARN_NULL_TO_NOTNULL
ER_WARN_TOO_FEW_RECORDS
ER_WRONG_ARGUMENTS
ER_WRONG_VALUE_FOR_TYPE
WARN_DATA_TRUNCATED
Support for IPv6 in MySQL includes these capabilities:
MySQL Server can accept TCP/IP connections from clients connecting over IPv6. For example, this command connects over IPv6 to the MySQL server on the local host:
shell> mysql -h ::1
To use this capability, two things must be true:
Your system must be configured to support IPv6. See Section 5.1.11.1, “Verifying System Support for IPv6”.
The default MySQL server configuration permits IPv6
connections in addition to IPv4 connections. To change the
default configuration, start the server with an
appropriate --bind-address
option. See Section 5.1.7, “Server System Variables”.
MySQL account names permit IPv6 addresses to enable DBAs to
specify privileges for clients that connect to the server over
IPv6. See Section 6.2.4, “Specifying Account Names”. IPv6 addresses can
be specified in account names in statements such as
CREATE USER
,
GRANT
, and
REVOKE
. For example:
mysql>CREATE USER 'bill'@'::1' IDENTIFIED BY 'secret';
mysql>GRANT SELECT ON mydb.* TO 'bill'@'::1';
IPv6 functions enable conversion between string and internal
format IPv6 address formats, and checking whether values
represent valid IPv6 addresses. For example,
INET6_ATON()
and
INET6_NTOA()
are similar to
INET_ATON()
and
INET_NTOA()
, but handle IPv6
addresses in addition to IPv4 addresses. See
Section 12.22, “Miscellaneous Functions”.
The following sections describe how to set up MySQL so that clients can connect to the server over IPv6.
Before MySQL Server can accept IPv6 connections, the operating system on your server host must support IPv6. As a simple test to determine whether that is true, try this command:
shell> ping6 ::1
16 bytes from ::1, icmp_seq=0 hlim=64 time=0.171 ms
16 bytes from ::1, icmp_seq=1 hlim=64 time=0.077 ms
...
To produce a description of your system's network interfaces, invoke ifconfig -a and look for IPv6 addresses in the output.
If your host does not support IPv6, consult your system documentation for instructions on enabling it. It might be that you need only reconfigure an existing network interface to add an IPv6 address. Or a more extensive change might be needed, such as rebuilding the kernel with IPv6 options enabled.
These links may be helpful in setting up IPv6 on various platforms:
The MySQL server listens on a single network socket for TCP/IP
connections. This socket is bound to a single address, but it is
possible for an address to map onto multiple network interfaces.
To specify an address, use the
--bind-address=
option at server startup, where addr
addr
is an IPv4 or IPv6 address or a host name. For details, see the
--bind-address
description in
Section 5.1.6, “Server Command Options”.
The following procedure shows how to configure MySQL to permit
IPv6 connections by clients that connect to the local server
using the ::1
local host address. The
instructions given here assume that your system supports IPv6.
Start the MySQL server with an appropriate
--bind-address
option to
permit it to accept IPv6 connections. For example, put the
following lines in the server option file and restart the
server:
[mysqld] bind-address = *
Alternatively, you can bind the server to
::1
, but that makes the server more
restrictive for TCP/IP connections. It accepts only IPv6
connections for that single address and rejects IPv4
connections. For more information, see the
--bind-address
description in
Section 5.1.6, “Server Command Options”.
As an administrator, connect to the server and create an
account for a local user who will connect from the
::1
local IPv6 host address:
mysql> CREATE USER 'ipv6user'@'::1' IDENTIFIED BY 'ipv6pass';
For the permitted syntax of IPv6 addresses in account names,
see Section 6.2.4, “Specifying Account Names”. In addition to the
CREATE USER
statement, you
can issue GRANT
statements
that give specific privileges to the account, although that
is not necessary for the remaining steps in this procedure.
Invoke the mysql client to connect to the server using the new account:
shell> mysql -h ::1 -u ipv6user -pipv6pass
Try some simple statements that show connection information:
mysql>STATUS
... Connection: ::1 via TCP/IP ... mysql>SELECT CURRENT_USER(), @@bind_address;
+----------------+----------------+ | CURRENT_USER() | @@bind_address | +----------------+----------------+ | ipv6user@::1 | :: | +----------------+----------------+
The following procedure shows how to configure MySQL to permit IPv6 connections by remote clients. It is similar to the preceding procedure for local clients, but the server and client hosts are distinct and each has its own nonlocal IPv6 address. The example uses these addresses:
Server host: 2001:db8:0:f101::1 Client host: 2001:db8:0:f101::2
These addresses are chosen from the nonroutable address range recommended by IANA for documentation purposes and suffice for testing on your local network. To accept IPv6 connections from clients outside the local network, the server host must have a public address. If your network provider assigns you an IPv6 address, you can use that. Otherwise, another way to obtain an address is to use an IPv6 broker; see Section 5.1.11.5, “Obtaining an IPv6 Address from a Broker”.
Start the MySQL server with an appropriate
--bind-address
option to
permit it to accept IPv6 connections. For example, put the
following lines in the server option file and restart the
server:
[mysqld] bind-address = *
Alternatively, you can bind the server to
2001:db8:0:f101::1
, but that makes the
server more restrictive for TCP/IP connections. It accepts
only IPv6 connections for that single address and rejects
IPv4 connections. For more information, see the
--bind-address
description in
Section 5.1.6, “Server Command Options”.
On the server host (2001:db8:0:f101::1
),
create an account for a user who will connect from the
client host (2001:db8:0:f101::2
):
mysql> CREATE USER 'remoteipv6user'@'2001:db8:0:f101::2' IDENTIFIED BY 'remoteipv6pass';
On the client host (2001:db8:0:f101::2
),
invoke the mysql client to connect to the
server using the new account:
shell> mysql -h 2001:db8:0:f101::1 -u remoteipv6user -premoteipv6pass
Try some simple statements that show connection information:
mysql>STATUS
... Connection: 2001:db8:0:f101::1 via TCP/IP ... mysql>SELECT CURRENT_USER(), @@bind_address;
+-----------------------------------+----------------+ | CURRENT_USER() | @@bind_address | +-----------------------------------+----------------+ | remoteipv6user@2001:db8:0:f101::2 | :: | +-----------------------------------+----------------+
If you do not have a public IPv6 address that enables your system to communicate over IPv6 outside your local network, you can obtain one from an IPv6 broker. The Wikipedia IPv6 Tunnel Broker page lists several brokers and their features, such as whether they provide static addresses and the supported routing protocols.
After configuring your server host to use a broker-supplied IPv6
address, start the MySQL server with an appropriate
--bind-address
option to permit
the server to accept IPv6 connections. For example, put the
following lines in the server option file and restart the
server:
[mysqld] bind-address = *
Alternatively, you can bind the server to the specific IPv6
address provided by the broker, but that makes the server more
restrictive for TCP/IP connections. It accepts only IPv6
connections for that single address and rejects IPv4
connections. For more information, see the
--bind-address
description in
Section 5.1.6, “Server Command Options”. In addition, if the broker
allocates dynamic addresses, the address provided for your
system might change the next time you connect to the broker. If
so, any accounts you create that name the original address
become invalid. To bind to a specific address but avoid this
change-of-address problem, you may be able to arrange with the
broker for a static IPv6 address.
The following example shows how to use Freenet6 as the broker and the gogoc IPv6 client package on Gentoo Linux.
Create an account at Freenet6 by visiting this URL and signing up:
http://gogonet.gogo6.com
After creating the account, go to this URL, sign in, and create a user ID and password for the IPv6 broker:
http://gogonet.gogo6.com/page/freenet6-registration
As root
, install
gogoc:
shell> emerge gogoc
Edit /etc/gogoc/gogoc.conf
to set the
userid
and password
values. For example:
userid=gogouser passwd=gogopass
Start gogoc:
shell> /etc/init.d/gogoc start
To start gogoc each time your system boots, execute this command:
shell> rc-update add gogoc default
Use ping6 to try to ping a host:
shell> ping6 ipv6.google.com
To see your IPv6 address:
shell> ifconfig tun
MySQL Server maintains several time zone settings:
The system time zone. When the server starts, it attempts to
determine the time zone of the host machine and uses it to set
the system_time_zone
system
variable. The value does not change thereafter.
You can set the system time zone for MySQL Server at startup
with the
--timezone=
option to mysqld_safe. You can also set it
by setting the timezone_name
TZ
environment variable
before you start mysqld. The permissible
values for --timezone
or
TZ
are system dependent. Consult your
operating system documentation to see what values are
acceptable.
The server's current time zone. The global
time_zone
system variable
indicates the time zone the server currently is operating in.
The initial value for
time_zone
is
'SYSTEM'
, which indicates that the server
time zone is the same as the system time zone.
If set to SYSTEM
, every MySQL function
call that requires a timezone calculation makes a system
library call to determine the current system timezone. This
call may be protected by a global mutex, resulting in
contention.
The initial global server time zone value can be specified
explicitly at startup with the
--default-time-zone=
option on the command line, or you can use the following line
in an option file:
timezone
default-time-zone='timezone
'
If you have the
SYSTEM_VARIABLES_ADMIN
or
SUPER
privilege, you can set
the global server time zone value at runtime with this
statement:
mysql> SET GLOBAL time_zone = timezone
;
Per-connection time zones. Each client that connects has its
own time zone setting, given by the session
time_zone
variable.
Initially, the session variable takes its value from the
global time_zone
variable,
but the client can change its own time zone with this
statement:
mysql> SET time_zone = timezone
;
The current session time zone setting affects display and storage
of time values that are zone-sensitive. This includes the values
displayed by functions such as
NOW()
or
CURTIME()
, and values stored in and
retrieved from TIMESTAMP
columns.
Values for TIMESTAMP
columns are
converted from the current time zone to UTC for storage, and from
UTC to the current time zone for retrieval.
The current time zone setting does not affect values displayed by
functions such as UTC_TIMESTAMP()
or values in DATE
,
TIME
, or
DATETIME
columns. Nor are values in
those data types stored in UTC; the time zone applies for them
only when converting from TIMESTAMP
values. If
you want locale-specific arithmetic for
DATE
,
TIME
, or
DATETIME
values, convert them to
UTC, perform the arithmetic, and then convert back.
The current values of the global and client-specific time zones can be retrieved like this:
mysql> SELECT @@global.time_zone, @@session.time_zone;
timezone
values can be given in several
formats, none of which are case-sensitive:
The value 'SYSTEM'
indicates that the time
zone should be the same as the system time zone.
The value can be given as a string indicating an offset from
UTC, such as '+10:00'
or
'-6:00'
.
The value can be given as a named time zone, such as
'Europe/Helsinki'
,
'US/Eastern'
, or 'MET'
.
Named time zones can be used only if the time zone information
tables in the mysql
database have been
created and populated.
Several tables in the mysql
system database
exist to maintain time zone information (see
Section 5.3, “The mysql System Database”). The MySQL installation
procedure creates the time zone tables, but does not load them.
You must do so manually using the following instructions.
Loading the time zone information is not necessarily a one-time operation because the information changes occasionally. When such changes occur, applications that use the old rules become out of date and you may find it necessary to reload the time zone tables to keep the information used by your MySQL server current. See the notes at the end of this section.
If your system has its own
zoneinfo database (the set
of files describing time zones), you should use the
mysql_tzinfo_to_sql program for filling the
time zone tables. Examples of such systems are Linux, FreeBSD,
Solaris, and macOS. One likely location for these files is the
/usr/share/zoneinfo
directory. If your system
does not have a zoneinfo database, you can use the downloadable
package described later in this section.
The mysql_tzinfo_to_sql program is used to load the time zone tables. On the command line, pass the zoneinfo directory path name to mysql_tzinfo_to_sql and send the output into the mysql program. For example:
shell> mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql
mysql_tzinfo_to_sql reads your system's time zone files and generates SQL statements from them. mysql processes those statements to load the time zone tables.
mysql_tzinfo_to_sql also can be used to load a single time zone file or to generate leap second information:
To load a single time zone file
tz_file
that corresponds to a time
zone name tz_name
, invoke
mysql_tzinfo_to_sql like this:
shell> mysql_tzinfo_to_sql tz_file
tz_name
| mysql -u root mysql
With this approach, you must execute a separate command to load the time zone file for each named zone that the server needs to know about.
If your time zone needs to account for leap seconds,
initialize the leap second information like this, where
tz_file
is the name of your time
zone file:
shell> mysql_tzinfo_to_sql --leap tz_file
| mysql -u root mysql
After running mysql_tzinfo_to_sql, it is best to restart the server so that it does not continue to use any previously cached time zone data.
If your system is one that has no zoneinfo database (for example, Windows), you can use a package that is available for download at the MySQL Developer Zone:
http://dev.mysql.com/downloads/timezones.html
Download a time zone package that contains SQL statements and unpack it, then load the package file contents into the time zone tables:
shell> mysql -u root mysql < file_name
Then restart the server.
Do not use a downloadable package that
contains MyISAM
tables. MySQL uses
InnoDB
for the time zone tables. Trying to
replace them with MyISAM
tables will cause
problems.
Do not use a downloadable package if your system has a zoneinfo database. Use the mysql_tzinfo_to_sql utility instead. Otherwise, you may cause a difference in datetime handling between MySQL and other applications on your system.
For information about time zone settings in replication setup, please see Section 17.4.1, “Replication Features and Issues”.
When time zone rules change, applications that use the old rules become out of date. To stay current, it is necessary to make sure that your system uses current time zone information is used. For MySQL, there are two factors to consider in staying current:
The operating system time affects the value that the MySQL
server uses for times if its time zone is set to
SYSTEM
. Make sure that your operating
system is using the latest time zone information. For most
operating systems, the latest update or service pack
prepares your system for the time changes. Check the website
for your operating system vendor for an update that
addresses the time changes.
If you replace the system's
/etc/localtime
timezone file with a
version that uses rules differing from those in effect at
mysqld startup, you should restart
mysqld so that it uses the updated rules.
Otherwise, mysqld might not notice when
the system changes its time.
If you use named time zones with MySQL, make sure that the
time zone tables in the mysql
database
are up to date. If your system has its own zoneinfo
database, you should reload the MySQL time zone tables
whenever the zoneinfo database is updated. For systems that
do not have their own zoneinfo database, check the MySQL
Developer Zone for updates. When a new update is available,
download it and use it to replace the content of your
current time zone tables. For instructions for both methods,
see Populating the Time Zone Tables.
mysqld caches time zone information that
it looks up, so after updating the time zone tables, you
should restart mysqld to make sure that
it does not continue to serve outdated time zone data.
If you are uncertain whether named time zones are available, for use either as the server's time zone setting or by clients that set their own time zone, check whether your time zone tables are empty. The following query determines whether the table that contains time zone names has any rows:
mysql> SELECT COUNT(*) FROM mysql.time_zone_name;
+----------+
| COUNT(*) |
+----------+
| 0 |
+----------+
A count of zero indicates that the table is empty. In this case, no one can be using named time zones, and you don't need to update the tables. A count greater than zero indicates that the table is not empty and that its contents are available to be used for named time zone support. In this case, you should be sure to reload your time zone tables so that anyone who uses named time zones will get correct query results.
To check whether your MySQL installation is updated properly for a change in Daylight Saving Time rules, use a test like the one following. The example uses values that are appropriate for the 2007 DST 1-hour change that occurs in the United States on March 11 at 2 a.m.
The test uses these two queries:
SELECT CONVERT_TZ('2007-03-11 2:00:00','US/Eastern','US/Central'); SELECT CONVERT_TZ('2007-03-11 3:00:00','US/Eastern','US/Central');
The two time values indicate the times at which the DST change occurs, and the use of named time zones requires that the time zone tables be used. The desired result is that both queries return the same result (the input time, converted to the equivalent value in the 'US/Central' time zone).
Before updating the time zone tables, you would see an incorrect result like this:
mysql>SELECT CONVERT_TZ('2007-03-11 2:00:00','US/Eastern','US/Central');
+------------------------------------------------------------+ | CONVERT_TZ('2007-03-11 2:00:00','US/Eastern','US/Central') | +------------------------------------------------------------+ | 2007-03-11 01:00:00 | +------------------------------------------------------------+ mysql>SELECT CONVERT_TZ('2007-03-11 3:00:00','US/Eastern','US/Central');
+------------------------------------------------------------+ | CONVERT_TZ('2007-03-11 3:00:00','US/Eastern','US/Central') | +------------------------------------------------------------+ | 2007-03-11 02:00:00 | +------------------------------------------------------------+
After updating the tables, you should see the correct result:
mysql>SELECT CONVERT_TZ('2007-03-11 2:00:00','US/Eastern','US/Central');
+------------------------------------------------------------+ | CONVERT_TZ('2007-03-11 2:00:00','US/Eastern','US/Central') | +------------------------------------------------------------+ | 2007-03-11 01:00:00 | +------------------------------------------------------------+ mysql>SELECT CONVERT_TZ('2007-03-11 3:00:00','US/Eastern','US/Central');
+------------------------------------------------------------+ | CONVERT_TZ('2007-03-11 3:00:00','US/Eastern','US/Central') | +------------------------------------------------------------+ | 2007-03-11 01:00:00 | +------------------------------------------------------------+
Leap second values are returned with a time part that ends with
:59:59
. This means that a function such as
NOW()
can return the same value
for two or three consecutive seconds during the leap second. It
remains true that literal temporal values having a time part
that ends with :59:60
or
:59:61
are considered invalid.
If it is necessary to search for
TIMESTAMP
values one second
before the leap second, anomalous results may be obtained if you
use a comparison with 'YYYY-MM-DD hh:mm:ss'
values. The following example demonstrates this. It changes the
local time zone to UTC so there is no difference between
internal values (which are in UTC) and displayed values (which
have time zone correction applied).
mysql>CREATE TABLE t1 (
a INT,
ts TIMESTAMP DEFAULT NOW(),
PRIMARY KEY (ts)
);
Query OK, 0 rows affected (0.01 sec) mysql>-- change to UTC
mysql>SET time_zone = '+00:00';
Query OK, 0 rows affected (0.00 sec) mysql>-- Simulate NOW() = '2008-12-31 23:59:59'
mysql>SET timestamp = 1230767999;
Query OK, 0 rows affected (0.00 sec) mysql>INSERT INTO t1 (a) VALUES (1);
Query OK, 1 row affected (0.00 sec) mysql>-- Simulate NOW() = '2008-12-31 23:59:60'
mysql>SET timestamp = 1230768000;
Query OK, 0 rows affected (0.00 sec) mysql>INSERT INTO t1 (a) VALUES (2);
Query OK, 1 row affected (0.00 sec) mysql>-- values differ internally but display the same
mysql>SELECT a, ts, UNIX_TIMESTAMP(ts) FROM t1;
+------+---------------------+--------------------+ | a | ts | UNIX_TIMESTAMP(ts) | +------+---------------------+--------------------+ | 1 | 2008-12-31 23:59:59 | 1230767999 | | 2 | 2008-12-31 23:59:59 | 1230768000 | +------+---------------------+--------------------+ 2 rows in set (0.00 sec) mysql>-- only the non-leap value matches
mysql>SELECT * FROM t1 WHERE ts = '2008-12-31 23:59:59';
+------+---------------------+ | a | ts | +------+---------------------+ | 1 | 2008-12-31 23:59:59 | +------+---------------------+ 1 row in set (0.00 sec) mysql>-- the leap value with seconds=60 is invalid
mysql>SELECT * FROM t1 WHERE ts = '2008-12-31 23:59:60';
Empty set, 2 warnings (0.00 sec)
To work around this, you can use a comparison based on the UTC value actually stored in column, which has the leap second correction applied:
mysql>-- selecting using UNIX_TIMESTAMP value return leap value
mysql>SELECT * FROM t1 WHERE UNIX_TIMESTAMP(ts) = 1230768000;
+------+---------------------+ | a | ts | +------+---------------------+ | 2 | 2008-12-31 23:59:59 | +------+---------------------+ 1 row in set (0.00 sec)
The MySQL server implements several session state trackers. A client can enable these trackers to receive notification of changes to its session state.
One use for the tracker mechanism is to provide a means for MySQL connectors and client applications to determine whether any session context is available to permit session migration from one server to another. (To change sessions in a load-balanced environment, it is necessary to detect whether there is session state to take into consideration when deciding whether a switch can be made.)
Another use for the tracker mechanism is to permit applications to know when transactions can be moved from one session to another. Transaction state tracking enables this, which is useful for applications that may wish to move transactions from a busy server to one that is less loaded. For example, a load-balancing connector managing a client connection pool could move transactions between available sessions in the pool.
However, session switching cannot be done at arbitrary times. If a session is in the middle of a transaction for which reads or writes have been done, switching to a different session implies a transaction rollback on the original session. A session switch must be done only when a transaction does not yet have any reads or writes performed within it.
Examples of when transactions might reasonably be switched:
Immediately after
START
TRANSACTION
After COMMIT AND
CHAIN
In addition to knowing transaction state, it is useful to know transaction characteristics, so as to use the same characteristics if the transaction is moved to a different session. The following characteristics are relevant for this purpose:
READ ONLY READ WRITE ISOLATION LEVEL WITH CONSISTENT SNAPSHOT
To support the preceding session-switching activities, notification is available for these types of client session state information:
Changes to these attributes of client session state:
The default schema (database).
Session-specific values for system variables.
User-defined variables.
Temporary tables.
Prepared statements.
The
session_track_state_change
system variable controls this tracker.
Changes to the default schema name. The
session_track_schema
system
variable controls this tracker.
Changes to the session values of system variables. The
session_track_system_variables
system variable controls this tracker.
Available GTIDs. The
session_track_gtids
system
variable controls this tracker.
Information about transaction state and characteristics. The
session_track_transaction_info
system variable controls this tracker.
For descriptions of the tracker-related system variables, see Section 5.1.7, “Server System Variables”. Those system variables permit control over which change notifications occur, but do not provide a way to access notification information. Notification occurs in the MySQL client/server protocol, which includes tracker information in OK packets so that session state changes can be detected. To enable client applications to extract state-change information from OK packets returned by the server, the MySQL C API provides a pair of functions:
mysql_session_track_get_first()
fetches the first part of the state-change information
received from the server. See
Section 27.7.7.69, “mysql_session_track_get_first()”.
mysql_session_track_get_next()
fetches any remaining state-change information received from
the server. Following a successful call to
mysql_session_track_get_first()
,
call this function repeatedly as long as it returns success.
See Section 27.7.7.70, “mysql_session_track_get_next()”.
The mysqltest program has
disable_session_track_info
and
enable_session_track_info
commands that control
whether session tracker notifications occur. You can use these
commands to see from the command line what notifications SQL
statements produce. Suppose that a file
testscript
contains the following
mysqltest script:
DROP TABLE IF EXISTS test.t1; CREATE TABLE test.t1 (i INT, f FLOAT); --enable_session_track_info SET @@session.session_track_schema=ON; SET @@session.session_track_system_variables='*'; SET @@session.session_track_state_change=ON; USE information_schema; SET NAMES 'utf8mb4'; SET @@session.session_track_transaction_info='CHARACTERISTICS'; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; SET TRANSACTION READ WRITE; START TRANSACTION; SELECT 1; INSERT INTO test.t1 () VALUES(); INSERT INTO test.t1 () VALUES(1, RAND()); COMMIT;
Run the script as follows to see the information provided by the
enabled trackers. For a description of the
Tracker:
information displayed by
mysqltest for the various trackers, see
Section 27.7.7.69, “mysql_session_track_get_first()”.
shell> mysqltest < testscript
DROP TABLE IF EXISTS test.t1;
CREATE TABLE test.t1 (i INT, f FLOAT);
SET @@session.session_track_schema=ON;
SET @@session.session_track_system_variables='*';
-- Tracker : SESSION_TRACK_SYSTEM_VARIABLES
-- session_track_system_variables
-- *
SET @@session.session_track_state_change=ON;
-- Tracker : SESSION_TRACK_SYSTEM_VARIABLES
-- session_track_state_change
-- ON
USE information_schema;
-- Tracker : SESSION_TRACK_SCHEMA
-- information_schema
-- Tracker : SESSION_TRACK_STATE_CHANGE
-- 1
SET NAMES 'utf8mb4';
-- Tracker : SESSION_TRACK_SYSTEM_VARIABLES
-- character_set_client
-- utf8mb4
-- character_set_connection
-- utf8mb4
-- character_set_results
-- utf8mb4
-- Tracker : SESSION_TRACK_STATE_CHANGE
-- 1
SET @@session.session_track_transaction_info='CHARACTERISTICS';
-- Tracker : SESSION_TRACK_SYSTEM_VARIABLES
-- session_track_transaction_info
-- CHARACTERISTICS
-- Tracker : SESSION_TRACK_STATE_CHANGE
-- 1
-- Tracker : SESSION_TRACK_TRANSACTION_CHARACTERISTICS
--
-- Tracker : SESSION_TRACK_TRANSACTION_STATE
-- ________
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-- Tracker : SESSION_TRACK_TRANSACTION_CHARACTERISTICS
-- SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SET TRANSACTION READ WRITE;
-- Tracker : SESSION_TRACK_TRANSACTION_CHARACTERISTICS
-- SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; SET TRANSACTION READ WRITE;
START TRANSACTION;
-- Tracker : SESSION_TRACK_TRANSACTION_CHARACTERISTICS
-- SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; START TRANSACTION READ WRITE;
-- Tracker : SESSION_TRACK_TRANSACTION_STATE
-- T_______
SELECT 1;
1
1
-- Tracker : SESSION_TRACK_TRANSACTION_STATE
-- T_____S_
INSERT INTO test.t1 () VALUES();
-- Tracker : SESSION_TRACK_TRANSACTION_STATE
-- T___W_S_
INSERT INTO test.t1 () VALUES(1, RAND());
-- Tracker : SESSION_TRACK_TRANSACTION_STATE
-- T___WsS_
COMMIT;
-- Tracker : SESSION_TRACK_TRANSACTION_CHARACTERISTICS
--
-- Tracker : SESSION_TRACK_TRANSACTION_STATE
-- ________
ok
MySQL Server supports a HELP
statement that returns information from the MySQL Reference manual
(see Section 13.8.3, “HELP Syntax”). Several tables in the
mysql
system database contain the information
needed to support this statement (see
Section 5.3, “The mysql System Database”). The proper operation of this
statement requires that these help tables be initialized, which is
done by processing the contents of the
fill_help_tables.sql
script.
If you install MySQL using a binary or source distribution on Unix, help table content initialization occurs when you initialize the data directory (see Section 2.9.1, “Initializing the Data Directory”). For an RPM distribution on Linux or binary distribution on Windows, content initialization occurs as part of the MySQL installation process.
If you upgrade MySQL using a binary distribution, help table
content is not upgraded automatically, but you can upgrade it
manually. Locate the fill_help_tables.sql
file in the share
or
share/mysql
directory. Change location into
that directory and process the file with the
mysql client as follows:
shell> mysql -u root mysql < fill_help_tables.sql
You can also obtain the latest
fill_help_tables.sql
at any time to upgrade
your help tables. Download the proper file for your version of
MySQL from http://dev.mysql.com/doc/index-other.html. After
downloading and uncompressing the file, process it with
mysql as described previously.
If you are working with Git and a MySQL development source tree,
you must use a downloaded copy of the
fill_help_tables.sql
file because the source
tree contains only a “stub” version.
For a server that participates in replication, the help table content upgrade process involves multiple servers. For details, see Section 17.4.1.27, “Replication of Server-Side Help Tables”.
On Unix, signals can be sent to processes. mysqld responds to signals sent to it as follows:
SIGTERM
causes the server to shut down.
SIGHUP
causes the server to reload the
grant tables and to flush tables, logs, the thread cache, and
the host cache. These actions are like various forms of the
FLUSH
statement. The server
also writes a status report to the error log that has this
format:
Status information: Current dir: /var/mysql/data/ Running threads: 0 Stack size: 196608 Current locks: Key caches: default Buffer_size: 8388600 Block_size: 1024 Division_limit: 100 Age_limit: 300 blocks used: 0 not flushed: 0 w_requests: 0 writes: 0 r_requests: 0 reads: 0 handler status: read_key: 0 read_next: 0 read_rnd 0 read_first: 1 write: 0 delete 0 update: 0 Table status: Opened tables: 5 Open tables: 0 Open files: 7 Open streams: 0 Alarm status: Active alarms: 1 Max used alarms: 2 Next alarm time: 67
The server shutdown process takes place as follows:
The shutdown process is initiated.
This can occur initiated several ways. For example, a user
with the SHUTDOWN
privilege can
execute a mysqladmin shutdown command.
mysqladmin can be used on any platform
supported by MySQL. Other operating system-specific shutdown
initiation methods are possible as well: The server shuts down
on Unix when it receives a SIGTERM
signal.
A server running as a service on Windows shuts down when the
services manager tells it to.
The server creates a shutdown thread if necessary.
Depending on how shutdown was initiated, the server might
create a thread to handle the shutdown process. If shutdown
was requested by a client, a shutdown thread is created. If
shutdown is the result of receiving a
SIGTERM
signal, the signal thread might
handle shutdown itself, or it might create a separate thread
to do so. If the server tries to create a shutdown thread and
cannot (for example, if memory is exhausted), it issues a
diagnostic message that appears in the error log:
Error: Can't create thread to kill server
The server stops accepting new connections.
To prevent new activity from being initiated during shutdown, the server stops accepting new client connections by closing the handlers for the network interfaces to which it normally listens for connections: the TCP/IP port, the Unix socket file, the Windows named pipe, and shared memory on Windows.
The server terminates current activity.
For each thread associated with a client connection, the
server breaks the connection to the client and marks the
thread as killed. Threads die when they notice that they are
so marked. Threads for idle connections die quickly. Threads
that currently are processing statements check their state
periodically and take longer to die. For additional
information about thread termination, see
Section 13.7.7.4, “KILL Syntax”, in particular for the instructions
about killed REPAIR TABLE
or
OPTIMIZE TABLE
operations on
MyISAM
tables.
For threads that have an open transaction, the transaction is
rolled back. If a thread is updating a nontransactional table,
an operation such as a multiple-row
UPDATE
or
INSERT
may leave the table
partially updated because the operation can terminate before
completion.
If the server is a master replication server, it treats threads associated with currently connected slaves like other client threads. That is, each one is marked as killed and exits when it next checks its state.
If the server is a slave replication server, it stops the I/O
and SQL threads, if they are active, before marking client
threads as killed. The SQL thread is permitted to finish its
current statement (to avoid causing replication problems), and
then stops. If the SQL thread is in the middle of a
transaction at this point, the server waits until the current
replication event group (if any) has finished executing, or
until the user issues a
KILL QUERY
or
KILL
CONNECTION
statement. See also
Section 13.4.2.7, “STOP SLAVE Syntax”. Since nontransactional
statements cannot be rolled back, in order to guarantee
crash-safe replication, only transactional tables should be
used.
To guarantee crash safety on the slave, you must run the
slave with
--relay-log-recovery
enabled.
See also Section 17.2.4, “Replication Relay and Status Logs”).
The server shuts down or closes storage engines.
At this stage, the server flushes the table cache and closes all open tables.
Each storage engine performs any actions necessary for tables
that it manages.
InnoDB
flushes its buffer pool to disk
(unless innodb_fast_shutdown
is 2), writes the current LSN to the tablespace, and
terminates its own internal threads. MyISAM
flushes any pending index writes for a table.
The server exits.
To provide information to management processes, the server returns one of the exit codes described in the following list. The phrase in parentheses indicates the action taken by systemd in response to the code, for platforms on which systemd is used to manage the server.
0 = successful termination (no restart done)
1 = unsuccessful termination (no restart done)
2 = unsuccessful termination (restart done)
Information managed by the MySQL server is stored under a directory known as the data directory. The following list briefly describes the items typically found in the data directory, with cross references for additional information:
Data directory subdirectories. Each subdirectory of the data directory is a database directory and corresponds to a database managed by the server. All MySQL installations have certain standard databases:
The mysql
directory corresponds to the
mysql
system database, which contains
information required by the MySQL server as it runs. This
database contains data dictionary tables and system
tables. See Section 5.3, “The mysql System Database”.
The performance_schema
directory
corresponds to the Performance Schema, which provides
information used to inspect the internal execution of the
server at runtime. See
Chapter 25, MySQL Performance Schema.
The sys
directory corresponds to the
sys
schema, which provides a set of
objects to help interpret Performance Schema information
more easily. See Chapter 26, MySQL sys Schema.
Other subdirectories correspond to databases created by users or applications.
INFORMATION_SCHEMA
is a
standard database, but its implementation uses no
corresponding database directory.
Log files written by the server. See Section 5.4, “MySQL Server Logs”.
InnoDB
tablespace and log files. See
Chapter 15, The InnoDB Storage Engine.
Default/autogenerated SSL and RSA certificate and key files. See Section 6.4.3, “Creating SSL and RSA Certificates and Keys”.
The server process ID file (while the server is running).
The mysqld-auto.cnf
file that stores
persisted global system variable settings. See
Section 5.1.8, “Using System Variables”.
Some items in the preceding list can be relocated elsewhere by
reconfiguring the server. In addition, the
--datadir
option enables the
location of the data directory itself to be changed. For a given
MySQL installation, check the server configuration to determine
whether items have been moved.
The mysql
database is the system database. It
contains tables that store information required by the MySQL
server as it runs. A broad categorization is that the
mysql
database contains data dictionary tables
that store database object metadata, and system tables used for
other operational purposes. The following discussion further
subdivides the set of system tables into smaller categories.
The remainder of this section enumerates the tables in each
category, with cross references for additional information. Data
dictionary tables and system tables use the
InnoDB
storage engine unless otherwise
indicated.
mysql
system tables and data dictionary tables
reside in a single InnoDB
tablespace file named
mysql.ibd
in the MySQL data directory.
Previously, these tables were created in individual tablespace
files in the mysql
database directory.
These tables comprise the data dictionary, which contains metadata about database objects. For additional information, see Chapter 14, MySQL Data Dictionary.
The data dictionary is new in MySQL 8.0. A data dictionary-enabled server entails some general operational differences compared to previous MySQL releases. For details, see Section 14.7, “Data Dictionary Usage Differences”. Also, for upgrades to MySQL 8.0 from MySQL 5.7, the upgrade procedure differs somewhat from previous MySQL releases and requires that you verify the upgrade readiness of your installation by checking specific prerequisites. For more information, see Section 2.10.1, “Upgrading MySQL”, particularly Verifying Upgrade Prerequisites for Your MySQL 5.7 Installation.
catalogs
: Catalog information.
character_sets
: Information about
available character sets.
collations
: Information about collations
for each character set.
column_statistics
: Histogram statistics
for column values. See
Section 8.9.6, “Optimizer Statistics”.
column_type_elements
: Information about
types used by columns.
columns
: Information about columns in
tables.
dd_properties
: A table that identifies
data dictionary properties, such as its version. The server
uses this to determine whether the data dictionary must be
upgraded to a newer version.
events
: Information about Event Scheduler
events. See Section 23.4, “Using the Event Scheduler”. The server
loads events listed in this table during its startup
sequence, unless started with the
--skip-grant-tables
option.
foreign_keys
,
foreign_key_column_usage
: Information
about foreign keys.
index_column_usage
: Information about
columns used by indexes.
index_partitions
: Information about
partitions used by indexes.
index_stats
: Used to store dynamic index
statistics generated when ANALYZE
TABLE
is executed.
indexes
: Information about table indexes.
innodb_ddl_log
: Stores DDL logs for
crash-safe DDL operations.
parameter_type_elements
: Information
about stored procedure and function parameters, and about
return values for stored functions.
parameters
: Information about stored
procedures and functions. See
Section 23.2, “Using Stored Routines (Procedures and Functions)”.
resource_groups
: Information about
resource groups. See Section 8.12.5, “Resource Groups”
routines
: Information about stored
procedures and functions. See
Section 23.2, “Using Stored Routines (Procedures and Functions)”.
schemata
: Information about schemata. In
MySQL, a schema is a database, so this table provides
information about databases.
st_spatial_reference_systems
: Information
about available spatial reference systems for spatial data.
table_partition_values
: Information about
values used by table partitions.
table_partitions
: Information about
partitions used by tables.
table_stats
: Information about dynamic
table statistics generated when ANALYZE
TABLE
is executed.
tables
: Information about tables in
databases.
tablespace_files
: Information about files
used by tablespaces.
tablespaces
: Information about active
tablespaces.
triggers
: Information about triggers.
view_routine_usage
: Information about
dependencies between views and stored functions used by
them.
view_table_usage
: Used to track
dependencies between views and their underlying tables.
Data dictionary tables are invisible. They cannot be read with
SELECT
, do not appear in the
output of SHOW TABLES
, are not
listed in the INFORMATION_SCHEMA.TABLES
table, and so forth. However, in most cases there are
corresponding INFORMATION_SCHEMA
tables that
can be queried. Conceptually, the
INFORMATION_SCHEMA
provides a view through
which MySQL exposes data dictionary metadata. For example, you
cannot select from the mysql.schemata
table
directly:
mysql> SELECT * FROM mysql.schemata;
ERROR 3554 (HY000): Access to data dictionary table 'mysql.schemata' is rejected.
Instead, select that information from the corresponding
INFORMATION_SCHEMA
table:
mysql> SELECT * FROM INFORMATION_SCHEMA.SCHEMATA\G
*************************** 1. row ***************************
CATALOG_NAME: def
SCHEMA_NAME: mysql
DEFAULT_CHARACTER_SET_NAME: utf8mb4
DEFAULT_COLLATION_NAME: utf8mb4_0900_ai_ci
SQL_PATH: NULL
*************************** 2. row ***************************
CATALOG_NAME: def
SCHEMA_NAME: information_schema
DEFAULT_CHARACTER_SET_NAME: utf8
DEFAULT_COLLATION_NAME: utf8_general_ci
SQL_PATH: NULL
...
There is no INFORMATION_SCHEMA
table that
corresponds exactly to mysql.indexes
, but
INFORMATION_SCHEMA.STATISTICS
contains much of the same information.
As of yet, there are no INFORMATION_SCHEMA
tables that correspond exactly to
mysql.foreign_keys
,
mysql.foreign_key_column_usage
. The standard
SQL way to obtain foreign key information is by using the
INFORMATION_SCHEMA
REFERENTIAL_CONSTRAINTS
and
KEY_COLUMN_USAGE
tables; these
tables are now implemented as views on the
foreign_keys
,
foreign_key_column_usage
, and other data
dictionary tables.
Some system tables from before MySQL 8.0 have been
replaced by data dictionary tables and are no longer present in
the mysql
system database:
The events
data dictionary table
supersedes the event
table from before
MySQL 8.0.
The parameters
and
routines
data dictionary tables together
supersede the proc
table from before
MySQL 8.0.
These system tables contain grant information about user accounts and the privileges held by them. For additional information about the structure, contents, and purpose of the these tables, see Section 6.2.3, “Grant Tables”.
As of MySQL 8.0, the grant tables are InnoDB
(transactional) tables. Previously, these were
MyISAM
(nontransactional) tables. The change
of grant-table storage engine underlies an accompanying change
in MySQL 8.0 to the behavior of account-management statements
such as CREATE USER
and
GRANT
. Previously, an
account-management statement that named multiple users could
succeed for some users and fail for others. The statements are
now transactional and either succeed for all named users or roll
back and have no effect if any error occurs.
If MySQL is upgraded from an older version but the grant
tables have not been upgraded from MyISAM
to InnoDB
, the server considers them read
only and account-management statements produce an error. For
upgrade instructions, see Section 2.10.1, “Upgrading MySQL”.
user
: User accounts, global privileges,
and other non-privilege columns.
global_grants
: Assignments of dynamic
global privileges to users; see
Section 6.2.2, “Static Versus Dynamic Privileges”.
db
: Database-level privileges.
tables_priv
: Table-level privileges.
columns_priv
: Column-level privileges.
procs_priv
: Stored procedure and function
privileges.
proxies_priv
: Proxy-user privileges.
default_roles
: This table lists default
roles to be activated after a user connects and
authenticates, or executes
SET ROLE
DEFAULT
.
role_edges
: This table lists edges for
role subgraphs.
A given user
table row might refer to a
user account or a role. The server can distinquish whether a
row represents a user account, a role, or both by consulting
the role_edges
table for information
about relations between authentication IDs.
password_history
: Information about
password changes.
These system tables contain information about stored programs, components, user-defined functions, and server-side plugins:
component
: The registry for server
components. Any components listed in this table are
installed by a loader service during the server startup
sequence. See Section 5.5, “MySQL Server Components”.
func
: Information about user-defined
functions (UDFs). See Section 28.4, “Adding New Functions to MySQL”.
The server loads UDFs listed in this table during its
startup sequence, unless started with the
--skip-grant-tables
option.
plugin
: Information about server-side
plugins. See Section 5.6.1, “Installing and Uninstalling Plugins”, and
Section 28.2, “The MySQL Plugin API”. The server loads plugins
listed in this table during its startup sequence, unless
started with the
--skip-grant-tables
option.
The server uses these system tables for logging:
Log tables use the CSV
storage engine.
For more information, see Section 5.4, “MySQL Server Logs”.
These system tables contain server-side help information:
For more information, see Section 5.1.14, “Server-Side Help”.
These system tables contain time zone information:
For more information, see Section 5.1.12, “MySQL Server Time Zone Support”.
The server uses these system tables to support replication:
gtid_executed
: Table for storing GTID
values. See
mysql.gtid_executed Table.
ndb_binlog_index
: Binary log information
for MySQL Cluster replication. See
NDB Cluster Replication Schema and Tables.
The ndb_binlog_index
table uses the
MyISAM
storage engine. It is created only
if the server is built with NDB
.
slave_master_info
,
slave_relay_log_info
,
slave_worker_info
: Used to store
replication information on slave servers. See
Section 17.2.4, “Replication Relay and Status Logs”.
These system tables are for use by the optimizer:
innodb_index_stats
,
innodb_table_stats
: Used for
InnoDB
persistent optimizer statistics.
See Section 15.6.11.1, “Configuring Persistent Optimizer Statistics Parameters”.
server_cost
,
engine_cost
: The optimizer cost model
uses tables that contain cost estimate information about
operations that occur during query execution.
server_cost
contains optimizer cost
estimates for general server operations.
engine_cost
contains estimates for
operations specific to particular storage engines. See
Section 8.9.5, “The Optimizer Cost Model”.
Other system tables do not fit the preceding categories:
audit_log_filter
,
audit_log_user
: If MySQL Enterprise Audit is
installed, these tables provide persistent storage of audit
log filter definitions and user accounts. See
Section 6.5.5.8.1, “Audit Log Tables”.
firewall_users
,
firewall_whitelist
: If MySQL Enterprise Firewall is
installed, these tables provide persistent storage for
information used by the firewall. See
Section 6.5.6, “MySQL Enterprise Firewall”.
servers
: Used by the
FEDERATED
storage engine. See
Section 16.8.2.2, “Creating a FEDERATED Table Using CREATE SERVER”.
innodb_dynamic_metadata
: Used by the
InnoDB
storage engine to store
fast-changing table metadata such as auto-increment counter
values and index tree corruption flags. Replaces the data
dictionary buffer table that resided in the
InnoDB
system tablespace.
MySQL Server has several logs that can help you find out what activity is taking place.
Log Type | Information Written to Log |
---|---|
Error log | Problems encountered starting, running, or stopping mysqld |
General query log | Established client connections and statements received from clients |
Binary log | Statements that change data (also used for replication) |
Relay log | Data changes received from a replication master server |
Slow query log | Queries that took more than
long_query_time seconds to
execute |
DDL log (metadata log) | Metadata operations performed by DDL statements |
By default, no logs are enabled, except the error log on Windows. (The DDL log is always created when required, and has no user-configurable options; see Section 5.4.6, “The DDL Log”.) The following log-specific sections provide information about the server options that enable logging.
By default, the server writes files for all enabled logs in the data
directory. You can force the server to close and reopen the log
files (or in some cases switch to a new log file) by flushing the
logs. Log flushing occurs when you issue a
FLUSH LOGS
statement; execute
mysqladmin with a flush-logs
or refresh
argument; or execute
mysqldump with a
--flush-logs
or
--master-data
option. See
Section 13.7.7.3, “FLUSH Syntax”, Section 4.5.2, “mysqladmin — Client for Administering a MySQL Server”, and
Section 4.5.4, “mysqldump — A Database Backup Program”. In addition, the binary log is flushed
when its size reaches the value of the
max_binlog_size
system variable.
You can control the general query and slow query logs during runtime. You can enable or disable logging, or change the log file name. You can tell the server to write general query and slow query entries to log tables, log files, or both. For details, see Section 5.4.1, “Selecting General Query and Slow Query Log Output Destinations”, Section 5.4.3, “The General Query Log”, and Section 5.4.5, “The Slow Query Log”.
The relay log is used only on slave replication servers, to hold data changes from the master server that must also be made on the slave. For discussion of relay log contents and configuration, see Section 17.2.4.1, “The Slave Relay Log”.
For information about log maintenance operations such as expiration of old log files, see Section 5.4.7, “Server Log Maintenance”.
For information about keeping logs secure, see Section 6.1.2.3, “Passwords and Logging”.
MySQL Server provides flexible control over the destination of
output to the general query log and the slow query log, if those
logs are enabled. Possible destinations for log entries are log
files or the general_log
and
slow_log
tables in the mysql
database. Either or both destinations can be selected.
Log control at server startup.
The --log-output
option specifies
the destination for log output. This option does not in itself
enable the logs. Its syntax is
--log-output[=
:
value
,...]
If --log-output
is given with a
value, the value should be a comma-separated list of one or
more of the words TABLE
(log to tables),
FILE
(log to files), or
NONE
(do not log to tables or files).
NONE
, if present, takes precedence over any
other specifiers.
If --log-output
is omitted, the
default logging destination is FILE
.
The general_log
system variable
controls logging to the general query log for the selected log
destinations. If specified at server startup,
general_log
takes an optional
argument of 1 or 0 to enable or disable the log. To specify a file
name other than the default for file logging, set the
general_log_file
variable.
Similarly, the slow_query_log
variable controls logging to the slow query log for the selected
destinations and setting
slow_query_log_file
specifies a
file name for file logging. If either log is enabled, the server
opens the corresponding log file and writes startup messages to
it. However, further logging of queries to the file does not occur
unless the FILE
log destination is selected.
Examples:
To write general query log entries to the log table and the
log file, use
--log-output=TABLE,FILE
to
select both log destinations and
--general_log
to enable the
general query log.
To write general and slow query log entries only to the log
tables, use --log-output=TABLE
to select tables as the log destination and
--general_log
and
--slow_query_log
to enable both
logs.
To write slow query log entries only to the log file, use
--log-output=FILE
to select
files as the log destination and
--slow_query_log
to enable the
slow query log. (In this case, because the default log
destination is FILE
, you could omit the
--log-output
option.)
Log control at runtime. The system variables associated with log tables and files enable runtime control over logging:
The global log_output
system
variable indicates the current logging destination. It can be
modified at runtime to change the destination.
The global general_log
and
slow_query_log
variables
indicate whether the general query log and slow query log are
enabled (ON
) or disabled
(OFF
). You can set these variables at
runtime to control whether the logs are enabled.
The global general_log_file
and slow_query_log_file
variables indicate the names of the general query log and slow
query log files. You can set these variables at server startup
or at runtime to change the names of the log files.
To disable or enable general query logging for the current
connection, set the session
sql_log_off
variable to
ON
or OFF
.
The use of tables for log output offers the following benefits:
Log entries have a standard format. To display the current structure of the log tables, use these statements:
SHOW CREATE TABLE mysql.general_log; SHOW CREATE TABLE mysql.slow_log;
Log contents are accessible through SQL statements. This enables the use of queries that select only those log entries that satisfy specific criteria. For example, to select log contents associated with a particular client (which can be useful for identifying problematic queries from that client), it is easier to do this using a log table than a log file.
Logs are accessible remotely through any client that can connect to the server and issue queries (if the client has the appropriate log table privileges). It is not necessary to log in to the server host and directly access the file system.
The log table implementation has the following characteristics:
In general, the primary purpose of log tables is to provide an interface for users to observe the runtime execution of the server, not to interfere with its runtime execution.
CREATE TABLE
,
ALTER TABLE
, and
DROP TABLE
are valid operations
on a log table. For ALTER TABLE
and DROP TABLE
, the log table
cannot be in use and must be disabled, as described later.
By default, the log tables use the CSV
storage engine that writes data in comma-separated values
format. For users who have access to the
.CSV
files that contain log table data,
the files are easy to import into other programs such as
spreadsheets that can process CSV input.
The log tables can be altered to use the
MyISAM
storage engine. You cannot use
ALTER TABLE
to alter a log
table that is in use. The log must be disabled first. No
engines other than CSV
or
MyISAM
are legal for the log tables.
To disable logging so that you can alter (or drop) a log
table, you can use the following strategy. The example uses
the general query log; the procedure for the slow query log is
similar but uses the slow_log
table and
slow_query_log
system
variable.
SET @old_log_state = @@global.general_log; SET GLOBAL general_log = 'OFF'; ALTER TABLE mysql.general_log ENGINE = MyISAM; SET GLOBAL general_log = @old_log_state;
TRUNCATE TABLE
is a valid
operation on a log table. It can be used to expire log
entries.
RENAME TABLE
is a valid
operation on a log table. You can atomically rename a log
table (to perform log rotation, for example) using the
following strategy:
USE mysql; DROP TABLE IF EXISTS general_log2; CREATE TABLE general_log2 LIKE general_log; RENAME TABLE general_log TO general_log_backup, general_log2 TO general_log;
CHECK TABLE
is a valid
operation on a log table.
LOCK TABLES
cannot be used on a
log table.
INSERT
,
DELETE
, and
UPDATE
cannot be used on a log
table. These operations are permitted only internally to the
server itself.
FLUSH TABLES WITH READ LOCK
and
the state of the read_only
system variable have no effect on log tables. The server can
always write to the log tables.
Entries written to the log tables are not written to the binary log and thus are not replicated to slave servers.
To flush the log tables or log files, use
FLUSH TABLES
or
FLUSH LOGS
, respectively.
Partitioning of log tables is not permitted.
A mysqldump dump includes statements to recreate those tables so that they are not missing after reloading the dump file. Log table contents are not dumped.
This section discusses how to configure the MySQL server for logging of diagnostic messages to the error log. For information about selecting the error message character set or language, see Section 10.6, “Error Message Character Set”, or Section 10.11, “Setting the Error Message Language”.
The error log contains a record of mysqld startup and shutdown times. It also contains diagnostic messages such as errors, warnings, and notes that occur during server startup and shutdown, and while the server is running. For example, if mysqld notices that a table needs to be automatically checked or repaired, it writes a message to the error log.
On some operating systems, the error log contains a stack trace if mysqld exits abnormally. The trace can be used to determine where mysqld exited. See Section 28.5, “Debugging and Porting MySQL”.
If used to start mysqld,
mysqld_safe may write messages to the error
log. For example, when mysqld_safe notices
abnormal mysqld exits, it restarts
mysqld and writes a mysqld
restarted
message to the error log.
The following sections discuss aspects of configuring error logging.
In MySQL 8.0, error logging uses the MySQL component architecture described at Section 5.5, “MySQL Server Components”. The error log subsystem consists of components that perform log event filtering and writing, as well as a system variable that configures which components to enable to achieve the desired logging result.
This section discusses how to select components for error logging. For instructions specific to the system log and JSON log writers, see Section 5.4.2.3, “Error Logging to the System Log”, and Section 5.4.2.4, “Error Logging in JSON Format”. For additional details about all available log components, see Section 5.5.1, “Error Log Components”.
Component-based error logging offers these features:
Log events can be filtered by filter components to affect the information available for writing.
Log events are output by sink (writer) components. Multiple sink components can be enabled, to write error log output to multiple destinations.
Built-in filter and writer components combine to implement the default error logging format.
A loadable writer enables logging to the system log.
A loadable writer enables logging in JSON format.
System variables control which log components to enable and the rules for filtering log events.
The log_error_services
system
variable controls which log components to enable for error
logging. The variable may contain a list with 0, 1, or many
elements. In the latter case, elements may be delimited by
semicolon or (as of MySQL 8.0.12) comma, optionally followed by
space. A given setting cannot use both semicolon and comma
separators. Component order is significant because the server
executes components in the order listed.
By default, log_error_services
has this value:
mysql> SELECT @@global.log_error_services;
+----------------------------------------+
| @@global.log_error_services |
+----------------------------------------+
| log_filter_internal; log_sink_internal |
+----------------------------------------+
That value indicates that log events first pass through the
built-in filter component,
log_filter_internal
, then through the
built-in log writer component,
log_sink_internal
. A filter modifies log
events seen by components named later in the
log_error_services
value. A
sink is a destination for log events. Typically, a sink
processes log events into log messages that have a particular
format and writes these messages to its associated output, such
as a file or the system log.
If log_error_services
is
assigned a value that contains no writer components, no log
output is written from that point.
The final component in the
log_error_services
value
should be a writer. If the final component is a filter, it has
no effect because the filtered events are not sent to any
writer.
The combination of log_filter_internal
and
log_sink_internal
implements the default
error log filtering and output behavior. The action of these
components is affected by other server options and system
variables:
The output destination is determined by the
--log-error
option (and, on
Windows, --pid-file
and
--console
). These determine
whether to write error messages to the console or a file
and, if to a file, the error log file name. See
Section 5.4.2.2, “Default Error Log Destination Configuration”.
The log_error_verbosity
system variable affects which types of log events
log_filter_internal
permits or
suppresses. See Section 5.4.2.5, “Error Log Filtering”.
To change the set of log components used for error logging, load
components as necessary and modify the
log_error_services
value.
Adding or removing log components is subject to these
constraints:
To enable a log component, first load it using
INSTALL COMPONENT
(unless it
is built in or already loaded), then list the component in
the log_error_services
value.
For a component to be permitted in the
log_error_services
value,
it must be known. A component is known if it is built in, or
if it is loadable and has been loaded using
INSTALL COMPONENT
. Attempts
to name an unknown component at server startup cause
log_error_services
to be
set to its default value. Attempts to name an unknown
component at runtime produce an error and the
log_error_services
value
remains unchanged.
To disable a log component, remove it from the
log_error_services
value.
Then, if the component is loadable and you also want to
unload it, use UNINSTALL
COMPONENT
.
Attempts to use UNINSTALL
COMPONENT
to unload a loadable component that is
still named in the
log_error_services
value
produce an error.
For example, to use the system log writer
(log_sink_syseventlog
) instead of the default
writer (log_sink_internal
), first load the
writer component, then modify the
log_error_services
value:
INSTALL COMPONENT 'file://component_log_sink_syseventlog'; SET GLOBAL log_error_services = 'log_filter_internal; log_sink_syseventlog';
The URN to use for loading a log component with
INSTALL COMPONENT
is the
component name prefixed with
file://component_
. For example, for the
log_sink_syseventlog
component, the
corresponding URN is
file://component_log_sink_syseventlog
.
It is possible to configure multiple log writers to send output
to multiple destinations. To enable the system log writer in
addition to (rather than instead of) the default writer, set the
log_error_services
value like
this:
SET GLOBAL log_error_services = 'log_filter_internal; log_sink_internal; log_sink_syseventlog';
To revert to using only the default writer and unload the system log writer, execute these statements:
SET GLOBAL log_error_services = 'log_filter_internal; log_sink_internal; UNINSTALL COMPONENT 'file://component_log_sink_syseventlog';
To configure a log component to be enabled at each server startup, use this procedure:
If the component is loadable, load it using
INSTALL COMPONENT
. Loading
the component registers it in the
mysql.component
system table so that the
server loads it automatically for subsequent startups.
Set the log_error_services
value at startup to include the component name. Set the
value either in the server my.cnf
file,
or use SET
PERSIST
, which sets the value for the running
MySQL instance and also saves the value to be used for
subsequent server restarts; see
Section 13.7.5.1, “SET Syntax for Variable Assignment”. A value set in
my.cnf
takes effect at the next
restart. A value set using
SET
PERSIST
takes effect immediately, and for
subsequent restarts.
Suppose that you want to configure, for every server startup,
use of the JSON log writer (log_sink_json
) in
addition to the built-in log filter and writer
(log_filter_internal
,
log_sink_internal
). First load the JSON
writer if it is not loaded:
INSTALL COMPONENT 'file://component_log_sink_json';
Then set log_error_services
to
take effect at server startup. You can set it in
my.cnf
:
[mysqld] log_error_services='log_filter_internal; log_sink_internal; log_sink_json'
Or you can set it using
SET
PERSIST
:
SET PERSIST log_error_services = 'log_filter_internal; log_sink_internal; log_sink_json';
The order of components named in
log_error_services
is
significant, particularly with respect to the relative order of
filters and writers. Consider this
log_error_services
value:
log_filter_internal; log_sink_1; log_sink_2
In this case, log events pass to the built-in filter, then to the first writer, then to the second writer. Both writers receive filtered log events.
Compare that to this
log_error_services
value:
log_sink_1; log_filter_internal; log_sink_2
In this case, log events pass to the first writer, then to the built-in filter, then to the second writer. The first writer receives unfiltered events. The second writer receives filtered events. You might configure error logging this way if you want one log that contains messages for all log events, and another containing messages only for a subset of log events.
This section discusses which server options configure the default error log destination, which can be the console or a named file. It also indicates which log writer components base their own output destination on the default destination.
In this discussion, “console” means
stderr
, the standard error output. This is
your terminal or console window unless the standard error output
has been redirected to a different destination.
The server interprets options that determine the default error log destination somewhat differently for Windows and Unix systems. Be sure to configure the destination using the information appropriate to your platform:
For Windows, see Default Error Log Destination on Windows.
For Unix and Unix-like systems, see Default Error Log Destination on Unix and Unix-Like Systems.
After the server interprets the default error log destination
options, it sets the log_error
system variable to indicate the default destination, which
affects where several log writer components write error
messages. See
How the Default Error Log Destination Affects Log Writers.
On Windows, mysqld uses the
--log-error
,
--pid-file
, and
--console
options to determine
whether the default error log destination is the console or a
file, and, if a file, the file name:
If --console
is given, the
default destination is the console.
(--console
takes precedence
over --log-error
if both
are given, and the following items regarding
--log-error
do not apply.)
If --log-error
is not
given, or is given without naming a file, the default
destination is a file named
in the data directory, unless the
host_name
.err--pid-file
option is
specified. In that case, the file name is the PID file
base name with a suffix of .err
in
the data directory.
If --log-error
is given to
name a file, the default destination is that file (with an
.err
suffix added if the name has no
suffix), located under the data directory unless an
absolute path name is given to specify a different
location.
If the default error log destination is the console, the
server sets the log_error
system variable to stderr
. Otherwise, the
default destination is a file and the server sets
log_error
to the file name.
On Unix and Unix-like systems, mysqld uses
the --log-error
option to
determine whether the default error log destination is the
console or a file, and, if a file, the file name:
If --log-error
is not
given, the default destination is the console.
If --log-error
is given
without naming a file, the default destination is a file
named
in the data directory.
host_name
.err
If --log-error
is given to
name a file, the default destination is that file (with an
.err
suffix added if the name has no
suffix), located under the data directory unless an
absolute path name is given to specify a different
location.
If --log-error
is given in
an option file in a [mysqld]
,
[server]
, or
[mysqld_safe]
section,
mysqld_safe finds and uses the option,
and passes it to mysqld.
It is common for Yum or APT package installations to
configure an error log file location under
/var/log
with an option like
log-error=/var/log/mysqld.log
in a server
configuration file. Removing the file name from the option
causes the
file in the data directory to be used.
host_name
.err
If the default error log destination is the console, the
server sets the log_error
system variable to stderr
. Otherwise, the
default destination is a file and the server sets
log_error
to the file name.
After the server interprets the error log destination
configuration options, it sets the
log_error
system variable to
indicate the default error log destination. Log writer
components may base their own output destination on the
log_error
value, or determine
their destination independently of
log_error
If log_error
is
stderr
, the default error log destination
is the console, and log writers that base their output
destination on the default destination also write to the
console:
log_sink_internal
,
log_sink_json
,
log_sink_test
: These writers write to
the console. This is true even for writers such as
log_sink_json
that can be enabled
multiple times; all instances write to the console.
log_sink_syseventlog
: This writer
writes to the system log, regardless of the
log_error
value.
If log_error
is not
stderr
, the default error log destination
is a file and log_error
indicates the file name. Log writers that base their output
destination on the default destination base output file naming
on that file name. (A writer might use exactly that name, or
it might use some variant thereof.) Suppose that the
log_error
value
file_name
. Then log writers use the
name like this:
log_sink_internal
,
log_sink_test
: These writers write to
file_name
.
log_sink_json
: Successive instances of
this writer named in the
log_error_services
value
write to files named file_name
plus a numbered
.
suffix:
NN
.json
,
file_name
.00.json
,
and so forth.
file_name
.01.json
log_sink_syseventlog
: This writer
writes to the system log, regardless of the
log_error
value.
It is possible to have mysqld write the error
log to the system log (the Event Log on Windows, and
syslog
on Unix and Unix-like systems).
This section describes how to configure error logging using the
built-in filter, log_filter_internal
, and the
system log writer, log_sink_syseventlog
, to
take effect immediately and for subsequent server startups. For
general information about configuring error logging, see
Section 5.4.2.1, “Error Log Component Configuration”.
To enable the system log writer, first load the writer
component, then modify the
log_error_services
value:
INSTALL COMPONENT 'file://component_log_sink_syseventlog'; SET GLOBAL log_error_services = 'log_filter_internal; log_sink_syseventlog';
To set log_error_services
to
take effect at server startup, use the instructions at
Section 5.4.2.1, “Error Log Component Configuration”. Those
instructions apply to other error-logging system variables as
well.
For MySQL 8.0 configuration, you must enable error logging to the system log explicitly. This differs from MySQL 5.7 and earlier, for which error logging to the system log is enabled by default on Windows, and on all platforms requires no component loading.
Error logging to the system log may require additional system configuration. Consult the system log documentation for your platform.
On Windows, error messages written to the Event Log within the Application log have these characteristics:
Entries marked as Error
,
Warning
, and Note
are
written to the Event Log, but not messages such as
information statements from individual storage engines.
Event Log entries have a source of MySQL
.
On Unix and Unix-like systems, logging to the system log uses
syslog
. The following system variables affect
syslog
messages:
syseventlog.facility
: The
default facility for syslog
messages is
daemon
. Set this variable to specify a
different facility.
syseventlog.include_pid
:
Whether to include the server process ID in each line of
syslog
output.
syseventlog.tag
: This
variable defines a tag to add to the server identifier
(mysqld
) in syslog
messages. If defined, the tag is appended to the identifier
with a leading hyphen.
Prior to MySQL 8.0.13, use the
log_syslog_facility
,
log_syslog_include_pid
, and
log_syslog_tag
system
variables rather than the
syseventlog.
variables.
xxx
MySQL uses the custom label “System” for important
system messages about non-error situations, such as startup,
shutdown, and some significant changes to settings. In logs that
do not support custom labels, including the Event Log on
Windows, and syslog
on Unix and Unix-like
systems, system messages are assigned the label used for the
information level of severity. However, these messages are
printed to the log even if the MySQL
log_error_verbosity
setting
would normally exclude messages at the information level.
When a log writer must fall back to a label of
“Information” instead of “System” in
this way, and the log event is further processed outside of the
MySQL server (for example, filtered or forwarded by a
syslog
configuration), these events may by
default be processed by the secondary application as being of
“Information” severity rather than
“System” severity.
This section describes how to configure error logging using the
built-in filter, log_filter_internal
, and the
JSON writer, log_sink_json
, to take effect
immediately and for subsequent server startups. For general
information about configuring error logging, see
Section 5.4.2.1, “Error Log Component Configuration”.
To enable the JSON writer, first load the writer component, then
modify the log_error_services
value:
INSTALL COMPONENT 'file://component_log_sink_json'; SET GLOBAL log_error_services = 'log_filter_internal; log_sink_json';
To set log_error_services
to
take effect at server startup, use the instructions at
Section 5.4.2.1, “Error Log Component Configuration”. Those
instructions apply to other error-logging system variables as
well.
It is permitted to name log_sink_json
multiple times in the
log_error_services
value. For
example, to write unfiltered events with one instance and
filtered events with another instance, you could set
log_error_services
like this:
SET GLOBAL log_error_services = 'log_sink_json; log_filter_internal; log_sink_json';
The JSON log writer determines its output destination based on
the default error log destination, which is given by the
log_error
system variable. If
log_error
names a file, the
JSON writer bases output file naming on that file name, plus a
numbered
.
suffix,
with NN
.jsonNN
starting at 00. For example,
if log_error
is
file_name
, successive instances of
log_sink_json
named in the
log_error_services
value write
to
,
file_name
.00.json
,
and so forth.
file_name
.01.json
If log_error
is
stderr
, the JSON writer writes to the
console. If log_json_writer
is named multiple
times in the log_error_services
value, they all write to the console, which is likely not
useful.
Error log configuration normally includes one log filter component and one or more log writer component. For error log filtering, MySQL offers a choice of components:
log_filter_internal
: This filter
component provides error log filtering based on log event
priority, in combination with the
log_error_verbosity
system
variable. log_filter_internal
is built in
and enabled by default. See
log_filter_internal: Priority-Based Error Log Filtering.
log_filter_dragnet
: This filter component
provides error log filtering based on user-supplied rules,
in combination with the
dragnet.log_error_filter_rules
system variable. See
log_filter_dragnet: Rule-Based Error Log Filtering.
Error log verbosity control is a simple form of log filtering
based on error event priority. It is implemented by the
log_filter_internal
log filter component.
To affect how log_filter_internal
permits
or suppresses error, warning, and information events intended
for the error log, set the
log_error_verbosity
system
variable. log_filter_internal
is built in
and enabled by default, but if disabled, changes to
log_error_verbosity
have no
effect.
Permitted log_error_verbosity
values are 1 (errors only), 2 (errors and warnings), 3
(errors, warnings, and notes).
If log_error_verbosity
is set
to 2 or greater, the server logs messages about statements
that are unsafe for statement-based logging. If the value is
3, the server logs aborted connections and access-denied
errors for new connection attempts. See
Section B.5.2.10, “Communication Errors and Aborted Connections”.
If you use replication, setting
log_error_verbosity
to 2 or
greater is recommended, to get more information about what is
happening, such as messages about network failures and
reconnections.
If a slave server has
log_error_verbosity
set to 2
or greater, the slave prints messages to the error log to
provide information about its status, such as the binary log
and relay log coordinates where it starts its job, when it is
switching to another relay log, when it reconnects after a
disconnect, and so forth.
Selected important system messages about non-error situations
are printed to the error log regardless of the
log_error_verbosity
value.
These messages include startup and shutdown messages, and some
significant changes to settings.
In the MySQL error log, system messages are labeled as “System”. Other log writers might or might not follow the same convention, and in the resulting logs, system messages might be assigned the label used for the information level of severity, such as “Note” or “Information”. If you apply any additional filtering or redirection for logging based on the labeling of messages, system messages do not override your filter, but are handled by it in the same way as other messages.
The log_filter_dragnet
log filter component
enables log filtering based on user-defined rules. To define
the applicable rules, set the
dragnet.log_error_filter_rules
system variable.
To enable the log_filter_dragnet
filter,
first load the filter component, then modify the
log_error_services
value. The
following example enables
log_filter_dragnet
in combination with the
built-in log writer:
INSTALL COMPONENT 'file://component_log_filter_dragnet'; SET GLOBAL log_error_services = 'log_filter_dragnet; log_sink_internal';
To set log_error_services
to
take effect at server startup, use the instructions at
Section 5.4.2.1, “Error Log Component Configuration”. Those
instructions apply to other error-logging system variables as
well.
With log_filter_dragnet
enabled, define its
filter rules by setting the
dragnet.log_error_filter_rules
system variable. A rule set consists of zero or more rules,
where each rule is an IF
statement
terminated by a period (.
) character. If
the variable value is empty (zero rules), no filtering occurs.
Example 1. This rule set drops information events, and, for
other events, removes the source_line
field:
SET GLOBAL dragnet.log_error_filter_rules = 'IF prio>=INFORMATION THEN drop. IF EXISTS source_line THEN unset source_line.';
The effect is similar to the filtering performed by the
log_sink_internal
filter with a setting of
log_error_verbosity=2
.
Example 2: This rule limits information events to no more than one per 60 seconds:
SET GLOBAL dragnet.log_error_filter_rules = 'IF prio>=INFORMATION THEN throttle 1/60.';
Once you have the filtering configuration set up as you
desire, consider assigning
dragnet.log_error_filter_rules
using SET
PERSIST
rather than
SET
GLOBAL
to make the setting persist across server
restarts. Alternatively, add the setting to the server option
file.
To stop using the filtering language, first remove it from the set of error logging components. Usually this means using a different filter component rather than no filter component. For example:
SET GLOBAL log_error_services = 'log_filter_internal; log_sink_internal';
Again, consider using using
SET
PERSIST
rather than
SET
GLOBAL
to make the setting persist across server
restarts.
Then uninstall the filter
log_filter_dragnet
component:
UNINSTALL COMPONENT 'file://component_log_filter_dragnet';
The following sections describe aspects of
log_filter_dragnet
operation in more
detail:
The following grammar defines the language for
log_filter_dragnet
filter rules. Each rule
is an IF
statement terminated by a period
(.
) character. The language is not case
sensitive.
rule
: IFcondition
THENaction
[ELSEIFcondition
THENaction
] ... [ELSEaction
] .condition
: {field
comparator
value
| [NOT] EXISTSfield
|condition
{AND | OR}condition
}action
: { drop | throttle {count
|count
/window_size
} | setfield
[:= | =]value
| unset [field
] }field
: {core_field
|optional_field
|user_defined_field
}core_field
: { time | msg | prio | label | err_code | err_symbol | SQL_state | subsystem }optional_field
: { OS_errno | OS_errmsg | user | host | thread | query_id | source_file | source_line | function }user_defined_field
:sequence of characters in [a-zA-Z0-9_] class
comparator
: {== | != | <> | >= | => | <= | =< | < | >}value
: {string_literal
|integer_literal
|float_literal
|error_symbol
|severity
}count
:integer_literal
window_size
:integer_literal
string_literal
:sequence of characters quoted as '...' or "..."
integer_literal
:sequence of characters in [0-9] class
float_literal
:integer_literal
[.integer_literal
]error_symbol
:valid MySQL error symbol such as ER_ACCESS_DENIED_ERROR or ER_STARTUP
severity
: { ERROR | WARNING | INFORMATION }
Simple conditions compare a field to a value or test field
existence. To construct more complex conditions, use the
AND
and OR
operators.
Both operators have the same precedence and evaluate left to
right.
To escape a character within a string, precede it by a
backslash (\
). A backslash is required to
include backslash itself or the string-quoting character,
optional for other characters.
For convenience, log_filter_dragnet
supports symbolic names for comparisons to certain fields.
Where applicable, symbols are preferable to numeric values for
readability and portability.
Event severity values 1, 2, and 3 can be specified as
ERROR
, WARNING
, and
INFORMATION
. Severity symbols are
recognized only in comparisons with the
prio
field. These comparisons are
equivalent:
IF prio == INFORMATION THEN ... IF prio == 3 THEN ...
Error codes can be specified in numeric form or as the
corresponding error symbol. For example,
ER_STARTUP
is the symbolic
name for error 1408
. For a list of
error code numbers and symbols, see
Section B.3, “Server Error Codes and Messages”. Error symbols are
recognized only in comparisons with the
err_code
field and user-defined fields.
These comparisons are equivalent:
IF err_code == ER_STARTUP THEN ... IF err_code == 1408 THEN ...
Symbolic names can be specified as quoted strings for
comparison with string fields, but in such cases the names are
strings that have no special meaning and
log_filter_dragnet
does not resolve them to
the corresponding numeric value. Also, typos may go
undetected, whereas an error is thrown immediately on
SET
for attempts to use an unquoted symbol
unknown to the server.
log_filter_dragnet
supports these actions
in filter rules:
drop
: Drop the current log event (do
not log it).
throttle
: Apply rate limiting to reduce
log verbosity for events matching particular conditions.
The argument indicates a rate, in the form
count
or
count
/window_size
.
The count
value indicates the
permitted number of events to log per time window. The
window_size
value is the time
window in seconds; if omitted, the default window is 60
seconds. Both values must be integer literals.
This rule throttles plugin-shutdown messages to 5 per 60 seconds:
IF err_code == ER_PLUGIN_SHUTTING_DOWN_PLUGIN THEN throttle 5.
This rule throttles errors and warnings to 1000 per hour and information messages to 100 per hour:
IF prio <= INFORMATION THEN throttle 1000/3600 ELSE throttle 100/3600.
set
: Assign a value to a field (and
cause the field to exist if it did not already). In
subsequent rules, EXISTS
tests against
the field name are true, and the new value can be tested
by comparison conditions.
unset
: Discard a field. In subsequent
rules, EXISTS
tests against the field
name are false, and comparisons of the field against any
value are false.
In the special case that the condition refers to exactly
one field name, the field name following
unset
is optional and
unset
discards the named field. These
rules are equivalent:
IF myfield == 2 THEN unset myfield. IF myfield == 2 THEN unset.
log_filter_dragnet
supports core, optional,
and user-defined fields in rules:
A core field is set up automatically for error events. However, its presence in the event is not guaranteed because a core field, like any type of field, may be unset by filter rules. If so, the field will be found missing by later rules within the rule set and by components that execute after the filter (such as log writers).
An optional field is normally absent but may be present for certain event types. When present, an optional field provides additional event information as appropriate and available.
A user-defined field is any field with a name that is not
already defined as a core or optional field. A
user-defined field does not exist until created with the
set
action.
As implied by the preceding description, any given field may be absent, either because it was not present in the first place, or was discarded by a filtering rule. For log writers, the effect of field absence is writer specific. For example, a writer might omit the field from the log message, indicate that the field is missing, or substitute a default. When in doubt, use a filter rule to unset the field, then check what the log writer does with it.
These fields are core fields:
time
The event timestamp.
msg
The event message string.
prio
The event priority, to indicate error, warning, or
note/information event. This field corresponds to severity
in syslog
.
In comparisons, each priority can be specified as a
symbolic severity name or an integer literal. Severity
symbols are recognized only in comparisons with the
prio
field. These comparisons are
equivalent:
IF prio == INFORMATION THEN ... IF prio == 3 THEN ...
The following table shows the permitted priority levels.
Event Type | Priority Symbol | Numeric Priority |
---|---|---|
Error events | ERROR |
1 |
Warning events | WARNING |
2 |
Note/information events | INFORMATION |
3 |
Priority values follow the principle that higher
priorities have lower values, and vice versa. Priority
values begin at 1 for the most severe events (errors) and
increase for events with decreasing severity. For example,
to discard events with lower priority than warnings, test
for priority values higher than
WARNING
:
IF prio > WARNING THEN drop.
The following examples show the
log_filter_dragnet
rules to achieve an
effect similar to each
log_error_verbosity
value
permitted by the log_filter_internal
filter:
Errors only
(log_error_verbosity=1
):
IF prio > ERROR THEN drop.
Errors and warnings
(log_error_verbosity=2
):
IF prio > WARNING THEN drop.
Errors, warnings, and notes
(log_error_verbosity=3
):
IF prio > INFORMATION THEN drop.
This rule can actually be omitted because there are no
prio
values greater than
INFORMATION
, so effectively it
drops nothing.
err_code
The numeric event error code. In comparisons, the value to
test can be specified as a symbolic error name or an
integer literal. Error symbols are recognized only in
comparisons with the err_code
field and
user-defined fields. These comparisons are equivalent:
IF err_code == ER_ACCESS_DENIED_ERROR THEN ... IF err_code == 1045 THEN ...
err_symbol
The event error symbol, as a string; for example,
'ER_DUP_KEY'
.
err_symbol
values are intended more for
identifying particular lines in log output than for use in
filter rule comparisons because
log_filter_dragnet
does not resolve
comparison values specified as strings to the equivalent
numeric error code.
SQL_state
The event SQLSTATE value, as a string; for example
'23000'
.
subsystem
The subsystem in which the event occurred. Possible values
are InnoDB
(the
InnoDB
storage engine),
Repl
(the replication subsystem),
Server
(otherwise).
Optional fields fall into the following categories:
Additional information about the error, such as the error signaled by the operating system or the error lable:
OS_errno
The operating system error number.
OS_errmsg
The operating system error message.
label
The label corresponding to the prio
value, as a string. Filter rules can change the label for
log writers that support custom labels.
label
values are intended more for
identifying particular lines in log output than for use in
filter rule comparisons because
log_filter_dragnet
does not resolve
comparison values specified as strings to the equivalent
numeric priority.
Identification of the client for which the event occurred:
user
The client user.
host
The client host.
thread
The thread ID.
query_id
The query ID.
Debugging information:
source_file
The source file in which the event occurred. The file name
should omit any leading path. For example, to test for the
sql/gis/distance.cc
file, write the
comparison like this:
IF source_file == "distance.cc" THEN ...
source_line
The line within the source file at which the event occurred.
function
The function in which the event occurred.
component
The component or plugin in which the event occurred.
Each error log sink (writer) component has a characteristic output format it uses to write messages to its destination, but other factors may influence the content of the messages:
The information available to the log writer. If a log filter component executed prior to execution of the writer component removes a log event attribute, that attribute is not available for writing. For information about log filtering, see Section 5.4.2.5, “Error Log Filtering”.
System variables may affect log writers. See System Variables That Affect Error Log Format.
For all log writers, the ID included in error log messages is that of the thread within mysqld responsible for writing the message. This indicates which part of the server produced the message, and is consistent with general query log and slow query log messages, which include the connection thread ID.
This log writer produces the traditional error log output. It writes messages using this format:
timestamp
thread_id
[severity
] [err_code
] [subsystem
]message
The [
and ]
square
bracket characters are literal characters in the message
format. They do not indicate that fields are optional.
The [
and err_code
][
fields were added in MySQL 8.0.4 and 8.0.5, respectively. They
will be missing from logs generated by older servers. Log
parsers can treat these fields as parts of the message text
that will be present only for logs written by servers recent
enough to include them. Parsers must treat the
subsystem
]err_code
part of
[
indicators as a string value.
err_code
]
Examples:
2018-03-22T12:35:47.538083Z 0 [Note] [MY-012487] [InnoDB] InnoDB: DDL log recovery : begin 2018-03-22T12:35:47.550565Z 0 [Warning] [MY-010068] [Server] CA certificate /var/mysql/sslinfo/cacert.pem is self signed. 2018-03-22T12:35:47.669397Z 4 [Note] [MY-010051] [Server] Event Scheduler: scheduler thread started with id 4 2018-03-22T12:35:47.550939Z 0 [Note] [MY-010253] [Server] IPv6 is available.
The JSON-format log writer produces messages as JSON objects that contain key/value pairs. For example:
{ "prio": 3, "err_code": 10051, "subsystem": "Server", "source_file": "event_scheduler.cc", "function": "run", "msg": "Event Scheduler: scheduler thread started with id 4", "time": "2018-03-22T12:35:47.669397Z", "thread": 4, "err_symbol": "ER_SCHEDULER_STARTED", "SQL_state": "HY000", "label": "Note" }
The system log writer produces output that conforms to the system log format used on the local platform.
The log_timestamps
system
variable controls the time zone of timestamps in messages
written to the error log (as well as to general query log and
slow query log files). Permitted values are
UTC
(the default) and
SYSTEM
(local system time zone).
If you flush the error log using FLUSH
ERROR LOGS
, FLUSH LOGS
,
or mysqladmin flush-logs, the server closes
and reopens any error log file to which it is writing. To rename
an error log file, do so manually before flushing. Flushing the
logs then opens a new file with the original file name. For
example, assuming a log file name of
,
to rename the file and create a new one, use the following
commands:
host_name
.err
mvhost_name
.errhost_name
.err-old mysqladmin flush-logs mvhost_name
.err-oldbackup-directory
On Windows, use rename rather than mv.
If the location of an error log file is not writable by the
server, the log-flushing operation fails to create a new log
file. For example, on Linux, the server might write the error
log to the /var/log/mysqld.log
file, where
the /var/log
directory is owned by
root
and is not writable by
mysqld. For information about handling this
case, see Section 5.4.7, “Server Log Maintenance”.
If the server is not writing to a named error log file, no error log file renaming occurs when the error log is flushed.
The general query log is a general record of what mysqld is doing. The server writes information to this log when clients connect or disconnect, and it logs each SQL statement received from clients. The general query log can be very useful when you suspect an error in a client and want to know exactly what the client sent to mysqld.
Each line that shows when a client connects also includes
using
to indicate
the protocol used to establish the connection.
connection_type
connection_type
is one of
TCP/IP
(TCP/IP connection established without
SSL), SSL/TLS
(TCP/IP connection established
with SSL), Socket
(Unix socket file
connection), Named Pipe
(Windows named pipe
connection), or Shared Memory
(Windows shared
memory connection).
mysqld writes statements to the query log in the order that it receives them, which might differ from the order in which they are executed. This logging order is in contrast with that of the binary log, for which statements are written after they are executed but before any locks are released. In addition, the query log may contain statements that only select data while such statements are never written to the binary log.
When using statement-based binary logging on a replication master server, statements received by its slaves are written to the query log of each slave. Statements are written to the query log of the master server if a client reads events with the mysqlbinlog utility and passes them to the server.
However, when using row-based binary logging, updates are sent as
row changes rather than SQL statements, and thus these statements
are never written to the query log when
binlog_format
is
ROW
. A given update also might not be written
to the query log when this variable is set to
MIXED
, depending on the statement used. See
Section 17.2.1.1, “Advantages and Disadvantages of Statement-Based and Row-Based
Replication”, for more information.
By default, the general query log is disabled. To specify the
initial general query log state explicitly, use
--general_log[={0|1}]
. With no
argument or an argument of 1,
--general_log
enables the log. With
an argument of 0, this option disables the log. To specify a log
file name, use
--general_log_file=
.
To specify the log destination, use
file_name
--log-output
(as described in
Section 5.4.1, “Selecting General Query and Slow Query Log Output Destinations”).
If you specify no name for the general query log file, the default
name is
. The
server creates the file in the data directory unless an absolute
path name is given to specify a different directory.
host_name
.log
To disable or enable the general query log or change the log file
name at runtime, use the global
general_log
and
general_log_file
system
variables. Set general_log
to 0
(or OFF
) to disable the log or to 1 (or
ON
) to enable it. Set
general_log_file
to specify the
name of the log file. If a log file already is open, it is closed
and the new file is opened.
When the general query log is enabled, the server writes output to
any destinations specified by the
--log-output
option or
log_output
system variable. If
you enable the log, the server opens the log file and writes
startup messages to it. However, further logging of queries to the
file does not occur unless the FILE
log
destination is selected. If the destination is
NONE
, the server writes no queries even if the
general log is enabled. Setting the log file name has no effect on
logging if the log destination value does not contain
FILE
.
Server restarts and log flushing do not cause a new general query log file to be generated (although flushing closes and reopens it). To rename the file and create a new one, use the following commands:
shell>mv
shell>host_name
.loghost_name
-old.logmysqladmin flush-logs
shell>mv
host_name
-old.logbackup-directory
On Windows, use rename rather than mv.
You can also rename the general query log file at runtime by disabling the log:
SET GLOBAL general_log = 'OFF';
With the log disabled, rename the log file externally; for example, from the command line. Then enable the log again:
SET GLOBAL general_log = 'ON';
This method works on any platform and does not require a server restart.
The session sql_log_off
variable
can be set to ON
or OFF
to
disable or enable general query logging for the current
connection.
Passwords in statements written to the general query log are
rewritten by the server not to occur literally in plain text.
Password rewriting can be suppressed for the general query log by
starting the server with the
--log-raw
option. This option may
be useful for diagnostic purposes, to see the exact text of
statements as received by the server, but for security reasons is
not recommended for production use. See also
Section 6.1.2.3, “Passwords and Logging”.
An implication of password rewriting is that statements that
cannot be parsed (due, for example, to syntax errors) are not
written to the general query log because they cannot be known to
be password free. Use cases that require logging of all statements
including those with errors should use the
--log-raw
option, bearing in mind
that this also bypasses password rewriting.
Password rewriting occurs only when plain text passwords are expected. For statements with syntax that expect a password hash value, no rewriting occurs. If a plain text password is supplied erroneously for such syntax, the password is logged as given, without rewriting.
The log_timestamps
system
variable controls the time zone of timestamps in messages written
to the general query log file (as well as to the slow query log
file and the error log). It does not affect the time zone of
general query log and slow query log messages written to log
tables, but rows retrieved from those tables can be converted from
the local system time zone to any desired time zone with
CONVERT_TZ()
or by setting the
session time_zone
system
variable.
The binary log contains “events” that describe
database changes such as table creation operations or changes to
table data. It also contains events for statements that
potentially could have made changes (for example, a
DELETE
which matched no rows),
unless row-based logging is used. The binary log also contains
information about how long each statement took that updated data.
The binary log has two important purposes:
For replication, the binary log on a master replication server provides a record of the data changes to be sent to slave servers. The master server sends the events contained in its binary log to its slaves, which execute those events to make the same data changes that were made on the master. See Section 17.2, “Replication Implementation”.
Certain data recovery operations require use of the binary log. After a backup has been restored, the events in the binary log that were recorded after the backup was made are re-executed. These events bring databases up to date from the point of the backup. See Section 7.5, “Point-in-Time (Incremental) Recovery Using the Binary Log”.
The binary log is not used for statements such as
SELECT
or
SHOW
that do not modify data. To
log all statements (for example, to identify a problem query), use
the general query log. See Section 5.4.3, “The General Query Log”.
Running a server with binary logging enabled makes performance slightly slower. However, the benefits of the binary log in enabling you to set up replication and for restore operations generally outweigh this minor performance decrement.
The binary log is resilient to unexpected halts. Only complete events or transactions are logged or read back.
Passwords in statements written to the binary log are rewritten by the server not to occur literally in plain text. See also Section 6.1.2.3, “Passwords and Logging”.
The following discussion describes some of the server options and variables that affect the operation of binary logging. For a complete list, see Section 17.1.6.4, “Binary Logging Options and Variables”.
Binary logging is enabled by default (the
log_bin
system variable is set to
ON). The exception is if you use mysqld to
initialize the data directory manually by invoking it with the
--initialize
or
--initialize-insecure
option, when
binary logging is disabled by default, but can be enabled by
specifying the --log-bin
option.
To disable binary logging, you can specify the
--skip-log-bin
or
--disable-log-bin
option at startup. If either of these options is specified and
--log-bin
is also specified, the
option specified later takes precedence.
The --log-slave-updates
and
--slave-preserve-commit-order
options require binary logging. If you disable binary logging,
either omit these options, or specify
--skip-log-slave-updates
and
--skip-slave-preserve-commit-order
.
MySQL disables these options by default when
--skip-log-bin
or
--disable-log-bin
is specified. If you specify
--log-slave-updates
or
--slave-preserve-commit-order
together with
--skip-log-bin
or
--disable-log-bin
,
a warning or error message is issued.
The
--log-bin[=
option is used to specify the base name for binary log files. If
you do not supply the base_name
]--log-bin
option, MySQL
uses binlog
as the default base name for the
binary log files. For compatibility with earlier releases, if you
supply the --log-bin
option with no string or
with an empty string, the base name defaults to
,
using the name of the host machine. It is recommended that you
specify a base name, so that if the host name changes, you can
easily continue to use the same binary log file names (see
Section B.5.7, “Known Issues in MySQL”). If you supply an extension in the log
name (for example,
host_name
-bin--log-bin=
),
the extension is silently removed and ignored.
base_name.extension
mysqld appends a numeric extension to the
binary log base name to generate binary log file names. The number
increases each time the server creates a new log file, thus
creating an ordered series of files. The server creates a new file
in the series each time it starts or flushes the logs. The server
also creates a new binary log file automatically after the current
log's size reaches
max_binlog_size
. A binary log
file may become larger than
max_binlog_size
if you are using
large transactions because a transaction is written to the file in
one piece, never split between files.
To keep track of which binary log files have been used,
mysqld also creates a binary log index file
that contains the names of all used binary log files. By default,
this has the same base name as the binary log file, with the
extension '.index'
. You can change the name of
the binary log index file with the
--log-bin-index[=
option. You should not manually edit this file while
mysqld is running; doing so would confuse
mysqld.
file_name
]
The term “binary log file” generally denotes an individual numbered file containing database events. The term “binary log” collectively denotes the set of numbered binary log files plus the index file.
The default location for binary log files and the binary log index
file is the data directory. You can use the
--log-bin
option to specify an
alternative location, by adding a leading absolute path name to
the base name to specify a different directory. When the server
reads an entry from the binary log index file, which tracks the
binary log files that have been used, it checks whether the entry
contains a relative path. If it does, the relative part of the
path is replaced with the absolute path set using the
--log-bin
option. An absolute path
recorded in the binary log index file remains unchanged; in such a
case, the index file must be edited manually to enable a new path
or paths to be used. The binary log file base name and any
specified path are available as the
log_bin_basename
system variable.
In MySQL 5.7, a server ID had to be specified when binary logging
was enabled, or the server would not start. In MySQL
8.0, the server_id
system variable is set to 1 by default. The server can be started
with this default ID when binary logging is enabled, but an
informational message is issued if you do not specify a server ID
explicitly using the --server-id
option. For servers that are used in a replication topology, you
must specify a unique nonzero server ID for each server.
A client that has the
SYSTEM_VARIABLES_ADMIN
or
SUPER
privilege can disable binary
logging of its own statements by using a SET
sql_log_bin=0
statement. See
Section 5.1.7, “Server System Variables”.
By default, the server logs the length of the event as well as the
event itself and uses this to verify that the event was written
correctly. You can also cause the server to write checksums for
the events by setting the
binlog_checksum
system variable.
When reading back from the binary log, the master uses the event
length by default, but can be made to use checksums if available
by enabling the
master_verify_checksum
system
variable. The slave I/O thread also verifies events received from
the master. You can cause the slave SQL thread to use checksums if
available when reading from the relay log by enabling the
slave_sql_verify_checksum
system
variable.
The format of the events recorded in the binary log is dependent on the binary logging format. Three format types are supported: row-based logging, statement-based logging and mixed-base logging. The binary logging format used depends on the MySQL version. For general descriptions of the logging formats, see Section 5.4.4.1, “Binary Logging Formats”. For detailed information about the format of the binary log, see MySQL Internals: The Binary Log.
The server evaluates the
--binlog-do-db
and
--binlog-ignore-db
options in the
same way as it does the
--replicate-do-db
and
--replicate-ignore-db
options. For
information about how this is done, see
Section 17.2.5.1, “Evaluation of Database-Level Replication and Binary Logging Options”.
A replication slave server is started with the
--log-slave-updates
setting enabled
by default, meaning that the slave writes to its own binary log
any data modifications that are received from the replication
master. The binary log must be enabled for this setting to work
(see Section 17.1.6.3, “Replication Slave Options and Variables”). This setting
enables the slave to act as a master to other slaves in chained
replication.
You can delete all binary log files with the
RESET MASTER
statement, or a subset
of them with PURGE BINARY LOGS
. See
Section 13.7.7.6, “RESET Syntax”, and Section 13.4.1.1, “PURGE BINARY LOGS Syntax”.
If you are using replication, you should not delete old binary log
files on the master until you are sure that no slave still needs
to use them. For example, if your slaves never run more than three
days behind, once a day you can execute mysqladmin
flush-logs on the master and then remove any logs that
are more than three days old. You can remove the files manually,
but it is preferable to use PURGE BINARY
LOGS
, which also safely updates the binary log index
file for you (and which can take a date argument). See
Section 13.4.1.1, “PURGE BINARY LOGS Syntax”.
You can display the contents of binary log files with the mysqlbinlog utility. This can be useful when you want to reprocess statements in the log for a recovery operation. For example, you can update a MySQL server from the binary log as follows:
shell> mysqlbinlog log_file
| mysql -h server_name
mysqlbinlog also can be used to display replication slave relay log file contents because they are written using the same format as binary log files. For more information on the mysqlbinlog utility and how to use it, see Section 4.6.8, “mysqlbinlog — Utility for Processing Binary Log Files”. For more information about the binary log and recovery operations, see Section 7.5, “Point-in-Time (Incremental) Recovery Using the Binary Log”.
Binary logging is done immediately after a statement or transaction completes but before any locks are released or any commit is done. This ensures that the log is logged in commit order.
Updates to nontransactional tables are stored in the binary log immediately after execution.
Within an uncommitted transaction, all updates
(UPDATE
,
DELETE
, or
INSERT
) that change transactional
tables such as InnoDB
tables are cached until a
COMMIT
statement is received by the
server. At that point, mysqld writes the entire
transaction to the binary log before the
COMMIT
is executed.
Modifications to nontransactional tables cannot be rolled back. If
a transaction that is rolled back includes modifications to
nontransactional tables, the entire transaction is logged with a
ROLLBACK
statement at the end to ensure that the modifications to those
tables are replicated.
When a thread that handles the transaction starts, it allocates a
buffer of binlog_cache_size
to
buffer statements. If a statement is bigger than this, the thread
opens a temporary file to store the transaction. The temporary
file is deleted when the thread ends.
The Binlog_cache_use
status
variable shows the number of transactions that used this buffer
(and possibly a temporary file) for storing statements. The
Binlog_cache_disk_use
status
variable shows how many of those transactions actually had to use
a temporary file. These two variables can be used for tuning
binlog_cache_size
to a large
enough value that avoids the use of temporary files.
The max_binlog_cache_size
system
variable (default 4GB, which is also the maximum) can be used to
restrict the total size used to cache a multiple-statement
transaction. If a transaction is larger than this many bytes, it
fails and rolls back. The minimum value is 4096.
If you are using the binary log and row based logging, concurrent
inserts are converted to normal inserts for CREATE ...
SELECT
or
INSERT ...
SELECT
statements. This is done to ensure that you can
re-create an exact copy of your tables by applying the log during
a backup operation. If you are using statement-based logging, the
original statement is written to the log.
The binary log format has some known limitations that can affect recovery from backups. See Section 17.4.1, “Replication Features and Issues”.
Binary logging for stored programs is done as described in Section 23.7, “Binary Logging of Stored Programs”.
Note that the binary log format differs in MySQL 8.0 from previous versions of MySQL, due to enhancements in replication. See Section 17.4.2, “Replication Compatibility Between MySQL Versions”.
Writes to the binary log file and binary log index file are
handled in the same way as writes to MyISAM
tables. See Section B.5.3.4, “How MySQL Handles a Full Disk”.
By default, the binary log is synchronized to disk at each write
(sync_binlog=1
). If
sync_binlog
was not enabled, and
the operating system or machine (not only the MySQL server)
crashed, there is a chance that the last statements of the binary
log could be lost. To prevent this, enable the
sync_binlog
system variable to
synchronize the binary log to disk after every
N
commit groups. See
Section 5.1.7, “Server System Variables”. The safest value for
sync_binlog
is 1 (the default),
but this is also the slowest.
In earlier MySQL releases, there was a chance of inconsistency
between the table content and binary log content if a crash
occurred, even with sync_binlog
set to 1. For example, if you are using InnoDB
tables and the MySQL server processes a
COMMIT
statement, it writes many
prepared transactions to the binary log in sequence, synchronizes
the binary log, and then commits the transaction into
InnoDB
. If the server crashed between those two
operations, the transaction would be rolled back by
InnoDB
at restart but still exist in the binary
log. Such an issue was resolved in previous releases by enabling
InnoDB
support for two-phase commit in XA
transactions. In 5.8.0 and higher, the InnoDB
support for two-phase commit in XA transactions is always enabled.
InnoDB
support for two-phase commit in XA
transactions ensures that the binary log and
InnoDB
data files are synchronized. However,
the MySQL server should also be configured to synchronize the
binary log and the InnoDB
logs to disk before
committing the transaction. The InnoDB
logs are
synchronized by default, and sync_binlog=1
ensures the binary log is synchronized. The effect of implicit
InnoDB
support for two-phase commit in XA
transactions and sync_binlog=1
is that at
restart after a crash, after doing a rollback of transactions, the
MySQL server scans the latest binary log file to collect
transaction xid
values and calculate
the last valid position in the binary log file. The MySQL server
then tells InnoDB
to complete any prepared
transactions that were successfully written to the to the binary
log, and truncates the binary log to the last valid position. This
ensures that the binary log reflects the exact data of
InnoDB
tables, and therefore the slave remains
in synchrony with the master because it does not receive a
statement which has been rolled back.
If the MySQL server discovers at crash recovery that the binary
log is shorter than it should have been, it lacks at least one
successfully committed InnoDB
transaction. This
should not happen if sync_binlog=1
and the
disk/file system do an actual sync when they are requested to
(some do not), so the server prints an error message The
binary log
. In this case, this binary log is not
correct and replication should be restarted from a fresh snapshot
of the master's data.
file_name
is shorter than
its expected size
The session values of the following system variables are written to the binary log and honored by the replication slave when parsing the binary log:
sql_mode
(except that the
NO_DIR_IN_CREATE
mode is not
replicated; see
Section 17.4.1.39, “Replication and Variables”)
The server uses several logging formats to record information in the binary log:
Replication capabilities in MySQL originally were based on
propagation of SQL statements from master to slave. This is
called statement-based logging. You can
cause this format to be used by starting the server with
--binlog-format=STATEMENT
.
In row-based logging (the default), the
master writes events to the binary log that indicate how
individual table rows are affected. You can cause the server
to use row-based logging by starting it with
--binlog-format=ROW
.
A third option is also available: mixed
logging. With mixed logging, statement-based
logging is used by default, but the logging mode switches
automatically to row-based in certain cases as described
below. You can cause MySQL to use mixed logging explicitly
by starting mysqld with the option
--binlog-format=MIXED
.
The logging format can also be set or limited by the storage engine being used. This helps to eliminate issues when replicating certain statements between a master and slave which are using different storage engines.
With statement-based replication, there may be issues with replicating nondeterministic statements. In deciding whether or not a given statement is safe for statement-based replication, MySQL determines whether it can guarantee that the statement can be replicated using statement-based logging. If MySQL cannot make this guarantee, it marks the statement as potentially unreliable and issues the warning, Statement may not be safe to log in statement format.
You can avoid these issues by using MySQL's row-based replication instead.
You can select the binary logging format explicitly by starting
the MySQL server with
--binlog-format=
.
The supported values for type
type
are:
STATEMENT
causes logging to be statement
based.
ROW
causes logging to be row based. This
is the default.
MIXED
causes logging to use mixed format.
The logging format also can be switched at runtime, although
note that there are a number of situations in which you cannot
do this, as discussed later in this section. Set the global
value of the binlog_format
system variable to specify the format for clients that connect
subsequent to the change:
mysql>SET GLOBAL binlog_format = 'STATEMENT';
mysql>SET GLOBAL binlog_format = 'ROW';
mysql>SET GLOBAL binlog_format = 'MIXED';
An individual client can control the logging format for its own
statements by setting the session value of
binlog_format
:
mysql>SET SESSION binlog_format = 'STATEMENT';
mysql>SET SESSION binlog_format = 'ROW';
mysql>SET SESSION binlog_format = 'MIXED';
To change the global or session
binlog_format
value, you must
have the SYSTEM_VARIABLES_ADMIN
or SUPER
privilege.
There are several reasons why a client might want to set binary logging on a per-session basis:
A session that makes many small changes to the database might want to use row-based logging.
A session that performs updates that match many rows in the
WHERE
clause might want to use
statement-based logging because it will be more efficient to
log a few statements than many rows.
Some statements require a lot of execution time on the master, but result in just a few rows being modified. It might therefore be beneficial to replicate them using row-based logging.
There are exceptions when you cannot switch the replication format at runtime:
From within a stored function or a trigger.
If the session is currently in row-based replication mode and has open temporary tables.
From row-based or mixed replication mode to statement-based
replication mode. From MySQL 8.0.4, you cannot perform this
transition, because CREATE TEMPORARY
TABLE
statements might have been omitted from the
binary log.
Trying to switch the format in any of these cases results in an error.
Switching the replication format at runtime is not recommended when any temporary tables exist, because temporary tables are logged only when using statement-based replication, whereas with row-based replication and (from MySQL 8.0.4) mixed replication,they are not logged.
Switching the replication format while replication is ongoing
can also cause issues. Each MySQL Server can set its own and
only its own binary logging format (true whether
binlog_format
is set with
global or session scope). This means that changing the logging
format on a replication master does not cause a slave to change
its logging format to match. When using
STATEMENT
mode, the
binlog_format
system variable
is not replicated. When using MIXED
or
ROW
logging mode, it is replicated but is
ignored by the slave.
A replication slave is not able to convert binary log entries
received in ROW
logging format to
STATEMENT
format for use in its own binary
log. The slave must therefore use ROW
or
MIXED
format if the master does. Changing the
binary logging format on the master from
STATEMENT
to ROW
or
MIXED
while replication is ongoing to a slave
with STATEMENT
format can cause replication
to fail with errors such as Error executing row
event: 'Cannot execute statement: impossible to write to binary
log since statement is in row format and BINLOG_FORMAT =
STATEMENT.' Changing the binary logging format on
the slave to STATEMENT
format when the master
is still using MIXED
or
ROW
format also causes the same type of
replication failure. To change the format safely, you must stop
replication and ensure that the same change is made on both the
master and the slave.
If you are using InnoDB
tables and
the transaction isolation level is READ
COMMITTED
or READ
UNCOMMITTED
, only row-based logging can be used. It is
possible to change the logging format to
STATEMENT
, but doing so at runtime leads very
rapidly to errors because InnoDB
can no
longer perform inserts.
With the binary log format set to ROW
, many
changes are written to the binary log using the row-based
format. Some changes, however, still use the statement-based
format. Examples include all DDL (data definition language)
statements such as CREATE TABLE
,
ALTER TABLE
, or
DROP TABLE
.
The --binlog-row-event-max-size
option is available for servers that are capable of row-based
replication. Rows are stored into the binary log in chunks
having a size in bytes not exceeding the value of this option.
The value must be a multiple of 256. The default value is 8192.
When using statement-based logging for replication, it is possible for the data on the master and slave to become different if a statement is designed in such a way that the data modification is nondeterministic; that is, it is left to the will of the query optimizer. In general, this is not a good practice even outside of replication. For a detailed explanation of this issue, see Section B.5.7, “Known Issues in MySQL”.
For information about logs kept by replication slaves, see Section 17.2.4, “Replication Relay and Status Logs”.
When running in MIXED
logging format, the
server automatically switches from statement-based to row-based
logging under the following conditions:
When a function contains
UUID()
.
When one or more tables with
AUTO_INCREMENT
columns are updated and a
trigger or stored function is invoked. Like all other unsafe
statements, this generates a warning if
binlog_format = STATEMENT
.
For more information, see Section 17.4.1.1, “Replication and AUTO_INCREMENT”.
When the body of a view requires row-based replication, the
statement creating the view also uses it. For example, this
occurs when the statement creating a view uses the
UUID()
function.
When a call to a UDF is involved.
When FOUND_ROWS()
or
ROW_COUNT()
is used. (Bug
#12092, Bug #30244)
When USER()
,
CURRENT_USER()
, or
CURRENT_USER
is used. (Bug
#28086)
When one of the tables involved is a log table in the
mysql
database.
When the LOAD_FILE()
function
is used. (Bug #39701)
When a statement refers to one or more system variables. (Bug #31168)
Exception. The following system variables, when used with session scope (only), do not cause the logging format to switch:
For information about determining system variable scope, see Section 5.1.8, “Using System Variables”.
For information about how replication treats
sql_mode
, see
Section 17.4.1.39, “Replication and Variables”.
In earlier releases, when mixed binary logging format was in use, if a statement was logged by row and the session that executed the statement had any temporary tables, all subsequent statements were treated as unsafe and logged in row-based format until all temporary tables in use by that session were dropped. From MySQL 8.0.4, operations on temporary tables are not logged in mixed binary logging format, and the presence of temporary tables in the session has no impact on the logging mode used for each statement.
A warning is generated if you try to execute a statement using
statement-based logging that should be written using row-based
logging. The warning is shown both in the client (in the
output of SHOW WARNINGS
) and
through the mysqld error log. A warning is
added to the SHOW WARNINGS
table each time such a statement is executed. However, only
the first statement that generated the warning for each client
session is written to the error log to prevent flooding the
log.
In addition to the decisions above, individual engines can also determine the logging format used when information in a table is updated. The logging capabilities of an individual engine can be defined as follows:
If an engine supports row-based logging, the engine is said to be row-logging capable.
If an engine supports statement-based logging, the engine is said to be statement-logging capable.
A given storage engine can support either or both logging formats. The following table lists the formats supported by each engine.
Storage Engine | Row Logging Supported | Statement Logging Supported |
---|---|---|
ARCHIVE |
Yes | Yes |
BLACKHOLE |
Yes | Yes |
CSV |
Yes | Yes |
EXAMPLE |
Yes | No |
FEDERATED |
Yes | Yes |
HEAP |
Yes | Yes |
InnoDB |
Yes | Yes when the transaction isolation level is
REPEATABLE READ or
SERIALIZABLE ; No
otherwise. |
MyISAM |
Yes | Yes |
MERGE |
Yes | Yes |
NDB |
Yes | No |
Whether a statement is to be logged and the logging mode to be
used is determined according to the type of statement (safe,
unsafe, or binary injected), the binary logging format
(STATEMENT
, ROW
, or
MIXED
), and the logging capabilities of the
storage engine (statement capable, row capable, both, or
neither). (Binary injection refers to logging a change that must
be logged using ROW
format.)
Statements may be logged with or without a warning; failed statements are not logged, but generate errors in the log. This is shown in the following decision table. Type, binlog_format, SLC, and RLC columns outline the conditions, and Error / Warning and Logged as columns represent the corresponding actions. SLC stands for “statement-logging capable”, and RLC stands for “row-logging capable”.
Type | binlog_format |
SLC | RLC | Error / Warning | Logged as |
---|---|---|---|---|---|
* | * |
No | No | Error: Cannot execute statement: Binary logging is impossible since at least one engine is involved that is both row-incapable and statement-incapable. | - |
Safe | STATEMENT |
Yes | No | - | STATEMENT |
Safe | MIXED |
Yes | No | - | STATEMENT |
Safe | ROW |
Yes | No | Error: Cannot execute statement: Binary logging
is impossible since BINLOG_FORMAT = ROW
and at least one table uses a storage engine that is not
capable of row-based logging. |
- |
Unsafe | STATEMENT |
Yes | No | Warning: Unsafe statement binlogged in statement
format, since BINLOG_FORMAT =
STATEMENT |
STATEMENT |
Unsafe | MIXED |
Yes | No | Error: Cannot execute statement: Binary logging
of an unsafe statement is impossible when the storage
engine is limited to statement-based logging, even if
BINLOG_FORMAT = MIXED . |
- |
Unsafe | ROW |
Yes | No | Error: Cannot execute statement: Binary logging
is impossible since BINLOG_FORMAT = ROW
and at least one table uses a storage engine that is not
capable of row-based logging. |
- |
Row Injection | STATEMENT |
Yes | No | Error: Cannot execute row injection: Binary logging is not possible since at least one table uses a storage engine that is not capable of row-based logging. | - |
Row Injection | MIXED |
Yes | No | Error: Cannot execute row injection: Binary logging is not possible since at least one table uses a storage engine that is not capable of row-based logging. | - |
Row Injection | ROW |
Yes | No | Error: Cannot execute row injection: Binary logging is not possible since at least one table uses a storage engine that is not capable of row-based logging. | - |
Safe | STATEMENT |
No | Yes | Error: Cannot execute statement: Binary logging
is impossible since BINLOG_FORMAT =
STATEMENT and at least one table uses a storage
engine that is not capable of statement-based logging. |
- |
Safe | MIXED |
No | Yes | - | ROW |
Safe | ROW |
No | Yes | - | ROW |
Unsafe | STATEMENT |
No | Yes | Error: Cannot execute statement: Binary logging
is impossible since BINLOG_FORMAT =
STATEMENT and at least one table uses a storage
engine that is not capable of statement-based logging. |
- |
Unsafe | MIXED |
No | Yes | - | ROW |
Unsafe | ROW |
No | Yes | - | ROW |
Row Injection | STATEMENT |
No | Yes | Error: Cannot execute row injection: Binary
logging is not possible since BINLOG_FORMAT =
STATEMENT . |
- |
Row Injection | MIXED |
No | Yes | - | ROW |
Row Injection | ROW |
No | Yes | - | ROW |
Safe | STATEMENT |
Yes | Yes | - | STATEMENT |
Safe | MIXED |
Yes | Yes | - | STATEMENT |
Safe | ROW |
Yes | Yes | - | ROW |
Unsafe | STATEMENT |
Yes | Yes | Warning: Unsafe statement binlogged in statement
format since BINLOG_FORMAT =
STATEMENT . |
STATEMENT |
Unsafe | MIXED |
Yes | Yes | - | ROW |
Unsafe | ROW |
Yes | Yes | - | ROW |
Row Injection | STATEMENT |
Yes | Yes | Error: Cannot execute row injection: Binary
logging is not possible because BINLOG_FORMAT =
STATEMENT . |
- |
Row Injection | MIXED |
Yes | Yes | - | ROW |
Row Injection | ROW |
Yes | Yes | - | ROW |
When a warning is produced by the determination, a standard
MySQL warning is produced (and is available using
SHOW WARNINGS
). The information
is also written to the mysqld error log. Only
one error for each error instance per client connection is
logged to prevent flooding the log. The log message includes the
SQL statement that was attempted.
If a slave server has
log_error_verbosity
set to
display warnings, the slave prints messages to the error log to
provide information about its status, such as the binary log and
relay log coordinates where it starts its job, when it is
switching to another relay log, when it reconnects after a
disconnect, statements that are unsafe for statement-based
logging, and so forth.
The contents of the grant tables in the mysql
database can be modified directly (for example, with
INSERT
or
DELETE
) or indirectly (for
example, with GRANT
or
CREATE USER
). Statements that
affect mysql
database tables are written to
the binary log using the following rules:
Data manipulation statements that change data in
mysql
database tables directly are logged
according to the setting of the
binlog_format
system
variable. This pertains to statements such as
INSERT
,
UPDATE
,
DELETE
,
REPLACE
,
DO
,
LOAD DATA
INFILE
, SELECT
, and
TRUNCATE TABLE
.
Statements that change the mysql
database
indirectly are logged as statements regardless of the value
of binlog_format
. This
pertains to statements such as
GRANT
,
REVOKE
,
SET PASSWORD
,
RENAME USER
,
CREATE
(all forms except
CREATE TABLE
... SELECT
), ALTER
(all forms),
and DROP
(all forms).
CREATE TABLE ...
SELECT
is a combination of data definition and data
manipulation. The CREATE TABLE
part is logged using statement format and the
SELECT
part is logged according
to the value of binlog_format
.
The slow query log consists of SQL statements that took more than
long_query_time
seconds to
execute and required at least
min_examined_row_limit
rows to be
examined. The minimum and default values of
long_query_time
are 0 and 10,
respectively. The value can be specified to a resolution of
microseconds. For logging to a file, times are written including
the microseconds part. For logging to tables, only integer times
are written; the microseconds part is ignored.
By default, administrative statements are not logged, nor are
queries that do not use indexes for lookups. This behavior can be
changed using
log_slow_admin_statements
and
log_queries_not_using_indexes
, as
described later.
The time to acquire the initial locks is not counted as execution time. mysqld writes a statement to the slow query log after it has been executed and after all locks have been released, so log order might differ from execution order.
By default, the slow query log is disabled. To specify the initial
slow query log state explicitly, use
--slow_query_log[={0|1}]
. With no
argument or an argument of 1,
--slow_query_log
enables the log.
With an argument of 0, this option disables the log. To specify a
log file name, use
--slow_query_log_file=
.
To specify the log destination, use
file_name
--log-output
(as described in
Section 5.4.1, “Selecting General Query and Slow Query Log Output Destinations”).
If you specify no name for the slow query log file, the default
name is
.
The server creates the file in the data directory unless an
absolute path name is given to specify a different directory.
host_name
-slow.log
To disable or enable the slow query log or change the log file
name at runtime, use the global
slow_query_log
and
slow_query_log_file
system
variables. Set slow_query_log
to
0 (or OFF
) to disable the log or to 1 (or
ON
) to enable it. Set
slow_query_log_file
to specify
the name of the log file. If a log file already is open, it is
closed and the new file is opened.
When the slow query log is enabled, the server writes output to
any destinations specified by the
--log-output
option or
log_output
system variable. If
you enable the log, the server opens the log file and writes
startup messages to it. However, further logging of queries to the
file does not occur unless the FILE
log
destination is selected. If the destination is
NONE
, the server writes no queries even if the
slow query log is enabled. Setting the log file name has no effect
on logging if the log destination value does not contain
FILE
.
The server writes less information to the slow query log if you
use the --log-short-format
option.
To include slow administrative statements in the statements
written to the slow query log, use the
log_slow_admin_statements
system
variable. Administrative statements include
ALTER TABLE
,
ANALYZE TABLE
,
CHECK TABLE
,
CREATE INDEX
,
DROP INDEX
,
OPTIMIZE TABLE
, and
REPAIR TABLE
.
To include queries that do not use indexes for row lookups in the
statements written to the slow query log, enable the
log_queries_not_using_indexes
system variable. When such queries are logged, the slow query log
may grow quickly. It is possible to put a rate limit on these
queries by setting the
log_throttle_queries_not_using_indexes
system variable. By default, this variable is 0, which means there
is no limit. Positive values impose a per-minute limit on logging
of queries that do not use indexes. The first such query opens a
60-second window within which the server logs queries up to the
given limit, then suppresses additional queries. If there are
suppressed queries when the window ends, the server logs a summary
that indicates how many there were and the aggregate time spent in
them. The next 60-second window begins when the server logs the
next query that does not use indexes.
The server uses the controlling parameters in the following order to determine whether to write a query to the slow query log:
The query must either not be an administrative statement, or
log_slow_admin_statements
must be enabled.
The query must have taken at least
long_query_time
seconds, or
log_queries_not_using_indexes
must be enabled and the query used no indexes for row lookups.
The query must have examined at least
min_examined_row_limit
rows.
The query must not be suppressed according to the
log_throttle_queries_not_using_indexes
setting.
The log_timestamps
system
variable controls the time zone of timestamps in messages written
to the slow query log file (as well as to the general query log
file and the error log). It does not affect the time zone of
general query log and slow query log messages written to log
tables, but rows retrieved from those tables can be converted from
the local system time zone to any desired time zone with
CONVERT_TZ()
or by setting the
session time_zone
system
variable.
All log lines contain a timestamp.
The server does not write to the slow query log queries that would not benefit from the presence of an index because the table has zero rows or one row.
By default, a replication slave does not write replicated queries
to the slow query log. To change this, use the
log_slow_slave_statements
system
variable.
Passwords in statements written to the slow query log are rewritten by the server not to occur literally in plain text. See also Section 6.1.2.3, “Passwords and Logging”.
The slow query log can be used to find queries that take a long time to execute and are therefore candidates for optimization. However, examining a long slow query log can become a difficult task. To make this easier, you can process a slow query log file using the mysqldumpslow command to summarize the queries that appear in the log. See Section 4.6.9, “mysqldumpslow — Summarize Slow Query Log Files”.
The DDL log, or metadata log, records metadata operations
generated by data definition statements such as
DROP TABLE
and
ALTER TABLE
. MySQL uses this log to
recover from crashes occurring in the middle of a metadata
operation. When executing the statement DROP TABLE t1,
t2
, we need to ensure that both t1
and t2
are dropped, and that each table drop is
complete. Another example of this type of SQL statement is
ALTER
TABLE t3 DROP PARTITION p2
, where we must make certain
that the partition is completely dropped and that its definition
is removed from the list of partitions for table
t3
.
A record of metadata operations such as those just described are
written to the file ddl_log.log
, in the MySQL
data directory. This is a binary file; it is not intended to be
human-readable, and you should not attempt to modify its contents
in any way.
ddl_log.log
is not created until it is
actually needed for recording metadata statements, and is removed
following a successful start of mysqld. Thus,
it is possible for this file not to be present on a MySQL server
that is functioning in a completely normal manner.
Currently, ddl_log.log
can hold up to 1048573
entries, equivalent 4 GB in size. Once this limit is exceeded, you
must rename or remove the file before it is possible to execute
any additional DDL statements. This is a known issue which we are
working to resolve (Bug #83708).
There are no user-configurable server options or variables associated with this file.
As described in Section 5.4, “MySQL Server Logs”, MySQL Server can create several different log files to help you see what activity is taking place. However, you must clean up these files regularly to ensure that the logs do not take up too much disk space.
When using MySQL with logging enabled, you may want to back up and remove old log files from time to time and tell MySQL to start logging to new files. See Section 7.2, “Database Backup Methods”.
On a Linux (Red Hat) installation, you can use the
mysql-log-rotate
script for this. If you
installed MySQL from an RPM distribution, this script should have
been installed automatically. Be careful with this script if you
are using the binary log for replication. You should not remove
binary logs until you are certain that their contents have been
processed by all slaves.
On other systems, you must install a short script yourself that you start from cron (or its equivalent) for handling log files.
Binary log files are automatically removed after the server's
binary log expiration period. Removal of the files can take place
at startup and when the binary log is flushed. The default binary
log expiration period is 30 days. You can specify an alternative
expiration period using the
binlog_expire_logs_seconds
system
variable. If you are using replication, you should specify an
expiration period that is no lower than the maximum amount of time
your slaves might lag behind the master. To remove binary logs on
demand, use the PURGE BINARY LOGS
statement (see Section 13.4.1.1, “PURGE BINARY LOGS Syntax”).
You can force MySQL to start using new log files by flushing the
logs. Log flushing occurs when you issue a
FLUSH LOGS
statement or execute a
mysqladmin flush-logs, mysqladmin
refresh, mysqldump --flush-logs, or
mysqldump --master-data command. See
Section 13.7.7.3, “FLUSH Syntax”, Section 4.5.2, “mysqladmin — Client for Administering a MySQL Server”, and
Section 4.5.4, “mysqldump — A Database Backup Program”. In addition, the binary log is
flushed when its size reaches the value of the
max_binlog_size
system variable.
FLUSH LOGS
supports optional
modifiers to enable selective flushing of individual logs (for
example, FLUSH BINARY LOGS
).
A log-flushing operation does the following:
If general query logging or slow query logging to a log file is enabled, the server closes and reopens the general query log file or slow query log file.
If binary logging is enabled, the server closes the current binary log file and opens a new log file with the next sequence number.
If the server was started with the
--log-error
option to cause the
error log to be written to a file, the server closes and
reopens the log file.
The server creates a new binary log file when you flush the logs.
However, it just closes and reopens the general and slow query log
files. To cause new files to be created on Unix, rename the
current log files before flushing them. At flush time, the server
opens new log files with the original names. For example, if the
general and slow query log files are named
mysql.log
and
mysql-slow.log
, you can use a series of
commands like this:
shell>cd
shell>mysql-data-directory
mv mysql.log mysql.old
shell>mv mysql-slow.log mysql-slow.old
shell>mysqladmin flush-logs
On Windows, use rename rather than mv.
At this point, you can make a backup of
mysql.old
and
mysql-slow.old
and then remove them from
disk.
A similar strategy can be used to back up the error log file, if there is one.
You can rename the general query log or slow query log at runtime by disabling the log:
SET GLOBAL general_log = 'OFF'; SET GLOBAL slow_query_log = 'OFF';
With the logs disabled, rename the log files externally; for example, from the command line. Then enable the logs again:
SET GLOBAL general_log = 'ON'; SET GLOBAL slow_query_log = 'ON';
This method works on any platform and does not require a server restart.
For the server to recreate a given log file after you have
renamed the file externally, the file location must be writable
by the server. This may not always be the case. For example, on
Linux, the server might write the error log as
/var/log/mysqld.log
, where
/var/log
is owned by
root
and not writable by
mysqld. In this case, the log-flushing
operation will fail to create a new log file.
To handle this situation, you must manually create the new log
file with the proper ownershiop after renaming the original log
file. For example, execute these commands as
root
:
shell>mv /var/log/mysqld.log /var/log/mysqld.log.old
shell>install -omysql -gmysql -m0644 /dev/null /var/log/mysqld.log
MySQL Server includes a component-based infrastructure for extending server capabilities:
A component provides services that are available to the server and other components. (With respect to service use, the server is a component, equal to other components.) Components interact with each other only through the services they provide.
The INSTALL COMPONENT
and
UNINSTALL COMPONENT
SQL
statements enable component loading and unloading. For example:
INSTALL COMPONENT 'file://component_validate_password'; UNINSTALL COMPONENT 'file://component_validate_password';
A loader service handles component loading and unloading, and
also lists loaded components in the
mysql.component
system table that serves as a
registry.
The SQL statements for component manipulation affect server
operation and the mysql.component
system table as
follows:
INSTALL COMPONENT
loads
components into the server. The components become active
immediately. The loader service also registers loaded components
in the mysql.component
system table. For
subsequent server restarts, any components listed in
mysql.component
are loaded by the loader
service during the startup sequence. This occurs even if the
server is started with the
--skip-grant-tables
option.
UNINSTALL COMPONENT
deactivates
components and unloads them from the server. The loader service
also unregisters the components from the
mysql.component
system table so that they are
no longer loaded during the startup sequence for subsequent
server restarts.
Compared to the corresponding INSTALL
PLUGIN
statement for server plugins, the
INSTALL COMPONENT
statement for
components offers the significant advantage that it is not necessary
to know any platform-specific file name suffix for naming the
component. This means that a given INSTALL
COMPONENT
statement can be executed uniformly across
platforms.
To see which components are installed, use this statement:
SELECT * FROM mysql.component;
MySQL distributions include several components that implement server extensions:
Components for configuring error logging. See Section 5.4.2, “The Error Log”, and Section 5.5.1, “Error Log Components”.
A component for checking passwords. See Section 6.5.3, “The Password Validation Component”.
System and status variables implemented by a server component are
exposed when the component is installed and have names that begin
with a component-specific prefix. For example, the
log_filter_dragnet
error log filter component
implements a system variable named
log_error_filter_rules
, the full name of which is
dragnet.log_error_filter_rules
. To
refer to this variable, use the full name.
For information about the internal implementation of components, see http://dev.mysql.com/doc/dev/mysql-server/latest/PAGE_EXTENDING.html. For example, if you intend to write your own components, this information is important for understanding how components work.
This section describes the characteristics of individual error log components. For general information about configuring error logging, see Section 5.4.2, “The Error Log”.
A log component can be a filter or a sink:
A filter processes log events, to add, remove, or modify event
fields, or to delete events entirely. The resulting events
pass to the next log component named in the
log_error_services
system
variable value.
A sink is a destination (writer) for log events. Typically, a sink processes log events into log messages that have a particular format and writes these messages to its associated output, such as a file or the system log.
The server executes filters and sinks in the
log_error_services
value in the
order they are named. The rightmost component should therefore be
a sink. If the rightmost component is a filter, any changes it has
on events have no effect on output.
The following sections describe individual log components, grouped by component type:
Component descriptions include these types of information:
The component name and intended purpose.
Whether the component is built in or must be loaded. For a
loadable component, the description specifies the URN to use
to load and unload the component with the
INSTALL COMPONENT
and
UNINSTALL COMPONENT
statements.
Whether the component can be listed multiple times in the
log_error_services
value.
For a sink component, the destination to which the component writes output.
Error log filter components implement filtering of error log events:
If no filter component is enabled, no filtering occurs.
Any enabled filter component affects log events only for
components listed later in the
log_error_services
value.
In particular, for any log sink component listed in
log_error_services
earlier
than any filter component, no log event filtering occurs.
Purpose: Implements filtering based on the
log_error_verbosity
system
variable setting. See Section 5.4.2.5, “Error Log Filtering”.
URN: This component is built in and need not be loaded with
INSTALL COMPONENT
before use.
Multiple uses permitted: No.
Because log_error_verbosity
affects the log_filter_internal
component,
log_error_verbosity
has no
effect on logging if log_filter_internal
is
not enabled.
Purpose: Implements filtering based on the rules defined by
the
dragnet.log_error_filter_rules
system variable setting. See
Section 5.4.2.5, “Error Log Filtering”.
URN: file://component_log_filter_dragnet
Multiple uses permitted: No.
Error log sink components are writers that implement error log output. If no sink component is enabled, no log output occurs.
Some sink component descriptions refer to the default error log
destination. This is the console or a file and is indicated by
the fault of the log_error
system variable, determined as described in
Section 5.4.2.2, “Default Error Log Destination Configuration”.
Purpose: Implements traditional error log message output format.
URN: This component is built in and need not be loaded with
INSTALL COMPONENT
before use.
Multiple uses permitted: No.
Output destination: Writes to the default error log destination.
Purpose: Implements JSON-format error logging.
URN: file://component_log_sink_json
Multiple uses permitted: Yes.
Output destination: The JSON log writer determines its
output destination based on the default error log
destination, which is given by the
log_error
system variable:
If log_error
names a
file, the JSON writer bases output file naming on that
file name, plus a numbered
.
suffix, with NN
.jsonNN
starting at
00. For example, if
log_error
is
file_name
, successive
instances of log_sink_json
named in
the log_error_services
value write to
,
file_name
.00.json
,
and so forth.
file_name
.01.json
If log_error
is
stderr
, the JSON writer writes to the
console. If log_json_writer
is named
multiple times in the
log_error_services
value, they all write to the console, which is likely
not useful.
Purpose: Implements error logging to the system log. This is
the Event Log on Windows, and syslog
on
Unix and Unix-like systems.
URN:
file://component_log_sink_syseventlog
Multiple uses permitted: No.
Output destination: Writes to the system log. Does not use the default error log destination.
Purpose: Intended for internal use in writing test cases. Not intended for production use.
URN: file://component_log_sink_test
Multiple uses permitted: Yes.
Output destination: Writes to the default error log destination.
MySQL supports a plugin API that enables creation of server
components. Plugins can be loaded at server startup, or loaded and
unloaded at runtime without restarting the server. The components
supported by this interface include, but are not limited to, storage
engines, INFORMATION_SCHEMA
tables, full-text
parser plugins, and server extensions.
MySQL distributions include several plugins that implement server extensions:
Plugins for authenticating attempts by clients to connect to MySQL Server. Plugins are available for several authentication protocols. See Section 6.3.10, “Pluggable Authentication”.
A connection-control plugin that enables administrators to introduce an increasing delay after a certain number of consecutive failed client connection attempts. See Section 6.5.2, “The Connection-Control Plugins”.
A password-validation plugin implements password strength policies and assesses the strength of potential passwords. See Section 6.5.3, “The Password Validation Component”.
Semisynchronous replication plugins implement an interface to replication capabilities that permit the master to proceed as long as at least one slave has responded to each transaction. See Section 17.3.10, “Semisynchronous Replication”.
Group Replication enables you to create a highly available distributed MySQL service across a group of MySQL server instances, with data consistency, conflict detection and resolution, and group membership services all built-in. See Chapter 18, Group Replication.
MySQL Enterprise Edition includes a thread pool plugin that manages connection threads to increase server performance by efficiently managing statement execution threads for large numbers of client connections. See Section 5.6.3, “MySQL Enterprise Thread Pool”.
MySQL Enterprise Edition includes an audit plugin for monitoring and logging of connection and query activity. See Section 6.5.5, “MySQL Enterprise Audit”.
MySQL Enterprise Edition includes a firewall plugin that implements an application-level firewall to enable database administrators to permit or deny SQL statement execution based on matching against whitelists of accepted statement patterns. See Section 6.5.6, “MySQL Enterprise Firewall”.
A query rewrite plugin examines statements received by MySQL Server and possibly rewrites them before the server executes them. See Section 5.6.4, “The Rewriter Query Rewrite Plugin”
Version Tokens enables creation of and synchronization around
server tokens that applications can use to prevent accessing
incorrect or out-of-date data. Version Tokens is based on a
plugin library that implements a
version_tokens
plugin and a set of
user-defined functions. See Section 5.6.5, “Version Tokens”.
Keyring plugins provide secure storage for sensitive information. See Section 6.5.4, “The MySQL Keyring”.
X Plugin extends MySQL Server to be able to function as a document store. Running X Plugin enables MySQL Server to communicate with clients using the X Protocol, which is designed to expose the ACID compliant storage abilities of MySQL as a document store. See Section 20.6, “X Plugin”.
Test framework plugins test server services. For information about these plugins, see Plugins for Testing Plugin Services.
The following sections describe how to install and uninstall plugins, and how to determine at runtime which plugins are installed and obtain information about them. For information about writing plugins, see Section 28.2, “The MySQL Plugin API”.
Server plugins must be loaded into the server before they can be used. MySQL supports plugin loading at server startup and runtime. It is also possible to control the activation state of loaded plugins at startup, and to unload them at runtime.
While a plugin is loaded, information about it is available at
runtime from the
INFORMATION_SCHEMA.PLUGINS
table and
the SHOW PLUGINS
statement. See
Section 5.6.2, “Obtaining Server Plugin Information”.
Before a server plugin can be used, it must be installed using
one of the following methods. In the descriptions,
plugin_name
stands for a plugin name
such as innodb
, csv
, or
validate_password
.
Built-in plugins:
A built-in plugin is known by the server automatically.
Normally, the server enables the plugin at startup. Some
built-in plugins permit this to be changed with the
--
option.
plugin_name
[=activation_state
]
Plugins registered in the
mysql.plugin
system table:
The mysql.plugin
table serves as a registry
of plugins (other than built-in plugins, which need not be
registered). At startup, the server loads each plugin listed in
the table. Normally, for a plugin loaded from the
mysql.plugin
table, the server also enables
the plugin. This can be changed with the
--
option.
plugin_name
[=activation_state
]
If the server is started with the
--skip-grant-tables
option, it
does not consult the mysql.plugin
table and
does not load the plugins listed there.
Plugins named with command-line options:
A plugin located in a plugin library file can be loaded at
server startup with the
--plugin-load
,
--plugin-load-add
, or
--early-plugin-load
option.
Normally, for a plugin loaded at startup, the server also
enables the plugin. This can be changed with the
--
option.
plugin_name
[=activation_state
]
The --plugin-load
and
--plugin-load-add
options load
plugins after built-in plugins and storage engines have
initialized during the server startup sequence. The
--early-plugin-load
option is
used to load plugins that must be available prior to
initialization of built-in plugins and storage engines.
The value of each plugin-loading option is a semicolon-separated
list of
name
=
plugin_library
and plugin_library
values. Each
name
is the name of a plugin to load,
and plugin_library
is the name of the
library file that contains the plugin code. If a plugin library
is named without any preceding plugin name, the server loads all
plugins in the library. The server looks for plugin library
files in the directory named by the
plugin_dir
system variable.
Plugin-loading options do not register any plugin in the
mysql.plugin
table. For subsequent restarts,
the server loads the plugin again only if
--plugin-load
,
--plugin-load-add
, or
--early-plugin-load
is given
again. That is, the option produces a one-time
plugin-installation operation that persists for a single server
invocation.
--plugin-load
,
--plugin-load-add
, and
--early-plugin-load
enable
plugins to be loaded even when
--skip-grant-tables
is given
(which causes the server to ignore the
mysql.plugin
table).
--plugin-load
,
--plugin-load-add
, and
--early-plugin-load
also enable
plugins to be loaded at startup that cannot be loaded at
runtime.
The --plugin-load-add
option
complements the --plugin-load
option:
Each instance of
--plugin-load
resets the set
of plugins to load at startup, whereas
--plugin-load-add
adds a
plugin or plugins to the set of plugins to be loaded without
resetting the current set. Consequently, if multiple
instances of --plugin-load
are specified, only the last one takes effect. With multiple
instances of
--plugin-load-add
, all of
them take effect.
The argument format is the same as for
--plugin-load
, but multiple
instances of
--plugin-load-add
can be used
to avoid specifying a large set of plugins as a single long
unwieldy --plugin-load
argument.
--plugin-load-add
can be
given in the absence of
--plugin-load
, but any
instance of --plugin-load-add
that appears before
--plugin-load
has no effect
because --plugin-load
resets
the set of plugins to load.
For example, these options:
--plugin-load=x --plugin-load-add=y
are equivalent to this option:
--plugin-load="x;y"
But these options:
--plugin-load-add=y --plugin-load=x
are equivalent to this option:
--plugin-load=x
Plugins installed with the
INSTALL PLUGIN
statement:
A plugin located in a plugin library file can be loaded at
runtime with the INSTALL PLUGIN
statement. The statement also registers the plugin in the
mysql.plugin
table to cause the server to
load it on subsequent restarts. For this reason,
INSTALL PLUGIN
requires the
INSERT
privilege for the
mysql.plugin
table.
The plugin library file base name depends on your platform.
Common suffixes are .so
for Unix and
Unix-like systems, .dll
for Windows.
Example: The --plugin-load
option
installs a plugin at server startup. To install a plugin named
myplugin
from a plugin library file named
somepluglib.so
, use these lines in a
my.cnf
file:
[mysqld] plugin-load=myplugin=somepluglib.so
In this case, the plugin is not registered in
mysql.plugin
. Restarting the server without
the --plugin-load
option causes
the plugin not to be loaded at startup.
Alternatively, the INSTALL PLUGIN
statement causes the server to load the plugin code from the
library file at runtime:
INSTALL PLUGIN myplugin SONAME 'somepluglib.so';
INSTALL PLUGIN
also causes
“permanent” plugin registration: The plugin is
listed in the mysql.plugin
table to ensure
that the server loads it on subsequent restarts.
Many plugins can be loaded either at server startup or at
runtime. However, if a plugin is designed such that it must be
loaded and initialized during server startup, attempts to load
it at runtime using INSTALL
PLUGIN
produce an error:
mysql> INSTALL PLUGIN myplugin SONAME 'somepluglib.so';
ERROR 1721 (HY000): Plugin 'myplugin' is marked as not dynamically
installable. You have to stop the server to install it.
In this case, you must use
--plugin-load
,
--plugin-load-add
, or
--early-plugin-load
.
If a plugin is named both using a
--plugin-load
,
--plugin-load-add
, or
--early-plugin-load
option and
(as a result of an earlier INSTALL
PLUGIN
statement) in the
mysql.plugin
table, the server starts but
writes these messages to the error log:
[ERROR] Function 'plugin_name
' already exists [Warning] Couldn't load plugin named 'plugin_name
' with soname 'plugin_object_file
'.
If the server knows about a plugin when it starts (for example,
because the plugin is named using a
--plugin-load
option or is
registered in the mysql.plugin
table), the
server loads and enables the plugin by default. It is possible
to control activation state for such a plugin using a
--
startup option, where plugin_name
[=activation_state
]plugin_name
is
the name of the plugin to affect, such as
innodb
, csv
, or
validate_password
. As with other options,
dashes and underscores are interchangeable in option names.
Also, activation state values are not case-sensitive. For
example, --my_plugin=ON
and
--my-plugin=on
are equivalent.
--
plugin_name
=OFF
Tells the server to disable the plugin. This may not be
possible for certain built-in plugins, such as
mysql_native_password
.
--
plugin_name
[=ON]
Tells the server to enable the plugin. (Specifying the
option as
--
without a value has the same effect.) If the plugin fails to
initialize, the server runs with the plugin disabled.
plugin_name
--
plugin_name
=FORCE
Tells the server to enable the plugin, but if plugin initialization fails, the server does not start. In other words, this option forces the server to run with the plugin enabled or not at all.
--
plugin_name
=FORCE_PLUS_PERMANENT
Like FORCE
, but in addition prevents the
plugin from being unloaded at runtime. If a user attempts to
do so with UNINSTALL PLUGIN
,
an error occurs.
Plugin activation states are visible in the
LOAD_OPTION
column of the
INFORMATION_SCHEMA.PLUGINS
table.
Suppose that CSV
,
BLACKHOLE
, and ARCHIVE
are
built-in pluggable storage engines and that you want the server
to load them at startup, subject to these conditions: The server
is permitted to run if CSV
initialization
fails, must require that BLACKHOLE
initialization succeeds, and should disable
ARCHIVE
. To accomplish that, use these lines
in an option file:
[mysqld] csv=ON blackhole=FORCE archive=OFF
The
--enable-
option format is a synonym for
plugin_name
--
.
The
plugin_name
=ON--disable-
and
plugin_name
--skip-
option formats are synonyms for
plugin_name
--
.
plugin_name
=OFF
If a plugin is disabled, either explicitly with
OFF
or implicitly because it was enabled with
ON
but failed to initialize, aspects of
server operation that require the plugin will change. For
example, if the plugin implements a storage engine, existing
tables for the storage engine become inaccessible, and attempts
to create new tables for the storage engine result in tables
that use the default storage engine unless the
NO_ENGINE_SUBSTITUTION
SQL
mode is enabled to cause an error to occur instead.
Disabling a plugin may require adjustment to other options. For
example, if you start the server using
--skip-innodb
to disable InnoDB
, other
innodb_
options likely will need to be omitted at startup. In addition,
because xxx
InnoDB
is the default
storage engine, it will not start unless you specify another
available storage engine with
--default_storage_engine
. You
must also set
--default_tmp_storage_engine
.
At runtime, the UNINSTALL PLUGIN
statement disables and uninstalls a plugin known to the server.
The statement unloads the plugin and removes it from the
mysql.plugin
table, if it is registered
there. For this reason, UNINSTALL
PLUGIN
statement requires the
DELETE
privilege for the
mysql.plugin
table. With the plugin no longer
registered in the table, the server will not load the plugin
automatically for subsequent restarts.
UNINSTALL PLUGIN
can unload a
plugin regardless of whether it was loaded at runtime with
INSTALL PLUGIN
or at startup with
a plugin-loading option, subject to these conditions:
It cannot unload plugins that are built in to the server.
These can be identified as those that have a library name of
NULL
in the output from
INFORMATION_SCHEMA.PLUGINS
or
SHOW PLUGINS
.
It cannot unload plugins for which the server was started
with
--
,
which prevents plugin unloading at runtime. These can be
identified from the plugin_name
=FORCE_PLUS_PERMANENTLOAD_OPTION
column of
the INFORMATION_SCHEMA.PLUGINS
table.
To uninstall a plugin that currently is loaded at server startup with a plugin-loading option, use this procedure.
Remove any options related to the plugin from the
my.cnf
file.
Restart the server.
Plugins normally are installed using either a plugin-loading
option at startup or with INSTALL
PLUGIN
at runtime, but not both. However, removing
options for a plugin from the my.cnf
file may not be sufficient to uninstall it if at some point
INSTALL PLUGIN
has also been
used. If the plugin still appears in the output from
INFORMATION_SCHEMA.PLUGINS
or
SHOW PLUGINS
, use
UNINSTALL PLUGIN
to remove it
from the mysql.plugin
table. Then restart
the server again.
There are several ways to determine which plugins are installed in the server:
The INFORMATION_SCHEMA.PLUGINS
table contains a row for each loaded plugin. Any that have a
PLUGIN_LIBRARY
value of
NULL
are built in and cannot be unloaded.
mysql> SELECT * FROM INFORMATION_SCHEMA.PLUGINS\G
*************************** 1. row ***************************
PLUGIN_NAME: binlog
PLUGIN_VERSION: 1.0
PLUGIN_STATUS: ACTIVE
PLUGIN_TYPE: STORAGE ENGINE
PLUGIN_TYPE_VERSION: 50158.0
PLUGIN_LIBRARY: NULL
PLUGIN_LIBRARY_VERSION: NULL
PLUGIN_AUTHOR: MySQL AB
PLUGIN_DESCRIPTION: This is a pseudo storage engine to represent the binlog in a transaction
PLUGIN_LICENSE: GPL
LOAD_OPTION: FORCE
...
*************************** 10. row ***************************
PLUGIN_NAME: InnoDB
PLUGIN_VERSION: 1.0
PLUGIN_STATUS: ACTIVE
PLUGIN_TYPE: STORAGE ENGINE
PLUGIN_TYPE_VERSION: 50158.0
PLUGIN_LIBRARY: ha_innodb_plugin.so
PLUGIN_LIBRARY_VERSION: 1.0
PLUGIN_AUTHOR: Innobase Oy
PLUGIN_DESCRIPTION: Supports transactions, row-level locking,
and foreign keys
PLUGIN_LICENSE: GPL
LOAD_OPTION: ON
...
The SHOW PLUGINS
statement
displays a row for each loaded plugin. Any that have a
Library
value of NULL
are built in and cannot be unloaded.
mysql> SHOW PLUGINS\G
*************************** 1. row ***************************
Name: binlog
Status: ACTIVE
Type: STORAGE ENGINE
Library: NULL
License: GPL
...
*************************** 10. row ***************************
Name: InnoDB
Status: ACTIVE
Type: STORAGE ENGINE
Library: ha_innodb_plugin.so
License: GPL
...
The mysql.plugin
table shows which plugins
have been registered with INSTALL
PLUGIN
. The table contains only plugin names and
library file names, so it does not provide as much information
as the PLUGINS
table or the
SHOW PLUGINS
statement.
MySQL Enterprise Thread Pool is an extension included in MySQL Enterprise Edition, a commercial product. To learn more about commercial products, http://www.mysql.com/products/.
MySQL Enterprise Edition includes MySQL Enterprise Thread Pool, implemented using a server plugin. The default thread-handling model in MySQL Server executes statements using one thread per client connection. As more clients connect to the server and execute statements, overall performance degrades. The thread pool plugin provides an alternative thread-handling model designed to reduce overhead and improve performance. The plugin implements a thread pool that increases server performance by efficiently managing statement execution threads for large numbers of client connections.
The thread pool addresses several problems of the one thread per connection model:
Too many thread stacks make CPU caches almost useless in highly parallel execution workloads. The thread pool promotes thread stack reuse to minimize the CPU cache footprint.
With too many threads executing in parallel, context switching overhead is high. This also presents a challenging task to the operating system scheduler. The thread pool controls the number of active threads to keep the parallelism within the MySQL server at a level that it can handle and that is appropriate for the server host on which MySQL is executing.
Too many transactions executing in parallel increases resource
contention. In InnoDB
, this
increases the time spent holding central mutexes. The thread
pool controls when transactions start to ensure that not too
many execute in parallel.
The thread pool plugin is included only in MySQL Enterprise Edition. It is not included in MySQL Community Edition.
Section A.14, “MySQL 8.0 FAQ: MySQL Enterprise Thread Pool”
The thread pool feature comprises these components:
A plugin library file implements a plugin for the thread pool code as well as several associated monitoring tables that provide information about thread pool operation.
For a detailed description of how the thread pool works, see Section 5.6.3.3, “Thread Pool Operation”.
The INFORMATION_SCHEMA
tables are named
TP_THREAD_STATE
,
TP_THREAD_GROUP_STATE
, and
TP_THREAD_GROUP_STATS
. These
tables provide information about thread pool operation. For
more information, see
Section 24.37, “INFORMATION_SCHEMA Thread Pool Tables”.
Several system variables are related to the thread pool. The
thread_handling
system
variable has a value of
loaded-dynamically
when the server
successfully loads the thread pool plugin.
The other related variables are implemented by the thread pool plugin; they are not available unless it is enabled:
thread_pool_algorithm
:
The concurrency algorithm to use for scheduling.
thread_pool_high_priority_connection
:
How to schedule statement execution for a session.
thread_pool_prio_kickup_timer
:
How long before the thread pool moves a statement
awaiting execution from the low-priority queue to the
high-priority queue.
thread_pool_max_unused_threads
:
How many sleeping threads to permit.
thread_pool_size
: The
number of thread groups in the thread pool. This is the
most important parameter controlling thread pool
performance.
thread_pool_stall_limit
:
The time before an executing statement is considered to
be stalled.
If any variable implemented by the plugin is set to an illegal value at startup, plugin initialization fails and the plugin does not load.
For information about setting thread pool parameters, see Section 5.6.3.4, “Thread Pool Tuning”.
The Performance Schema has instruments that expose information about the thread pool and may be used to investigate operational performance. To identify them, use this query:
SELECT * FROM performance_schema.setup_instruments WHERE NAME LIKE '%thread_pool%';
For more information, see Chapter 25, MySQL Performance Schema.
This section describes how to install MySQL Enterprise Thread Pool. For general information about installing plugins, see Section 5.6.1, “Installing and Uninstalling Plugins”.
To be usable by the server, the plugin library file must be
located in the MySQL plugin directory (the directory named by
the plugin_dir
system
variable). If necessary, set the value of
plugin_dir
at server startup to
tell the server the plugin directory location.
The plugin library file base name is
thread_pool
. The file name suffix differs per
platform (for example, .so
for Unix and
Unix-like systems, .dll
for Windows).
To enable thread pool capability, load the plugins to be used by
starting the server with the
--plugin-load-add
option. For
example, if you name just the plugin library file, the server
loads all plugins that it contains (that is, the thread pool
plugin and all the INFORMATION_SCHEMA
tables). To do this, put these lines in the server
my.cnf
file (adjust the
.so
suffix for your platform as necessary):
[mysqld] plugin-load-add=thread_pool.so
That is equivalent to loading all thread pool plugins by naming them individually:
[mysqld] plugin-load-add=thread_pool=thread_pool.so plugin-load-add=tp_thread_state=thread_pool.so plugin-load-add=tp_thread_group_state=thread_pool.so plugin-load-add=tp_thread_group_stats=thread_pool.so
If desired, you can load just some of the individual plugins
from the library file. To load the thread pool plugin but not
the INFORMATION_SCHEMA
tables, use an option
like this:
[mysqld] plugin-load-add=thread_pool=thread_pool.so
To load the thread pool plugin and only the
TP_THREAD_STATE
INFORMATION_SCHEMA
table, use options like
this:
[mysqld] plugin-load-add=thread_pool=thread_pool.so plugin-load-add=tp_thread_state=thread_pool.so
If you do not load all the
INFORMATION_SCHEMA
tables, some or all
MySQL Enterprise Monitor thread pool graphs will be empty.
To verify plugin installation, examine the
INFORMATION_SCHEMA.PLUGINS
table or
use the SHOW PLUGINS
statement
(see Section 5.6.2, “Obtaining Server Plugin Information”). For
example:
mysql>SELECT PLUGIN_NAME, PLUGIN_STATUS
FROM INFORMATION_SCHEMA.PLUGINS
WHERE PLUGIN_NAME LIKE 'thread%' OR PLUGIN_NAME LIKE 'tp%';
+-----------------------+---------------+ | PLUGIN_NAME | PLUGIN_STATUS | +-----------------------+---------------+ | thread_pool | ACTIVE | | TP_THREAD_STATE | ACTIVE | | TP_THREAD_GROUP_STATE | ACTIVE | | TP_THREAD_GROUP_STATS | ACTIVE | +-----------------------+---------------+
If a plugin fails to initialize, check the server error log for diagnostic messages.
If the server loads the thread pool plugin successfully, it sets
the thread_handling
system variable to
loaded-dynamically
.
The thread pool consists of a number of thread groups, each of which manages a set of client connections. As connections are established, the thread pool assigns them to thread groups in round-robin fashion.
The number of thread groups is configurable using the
thread_pool_size
system
variable. The default number of groups is 16. For guidelines on
setting this variable, see Section 5.6.3.4, “Thread Pool Tuning”.
The maximum number of threads per group is 4096 (or 4095 on some systems where one thread is used internally).
The thread pool separates connections and threads, so there is no fixed relationship between connections and the threads that execute statements received from those connections. This differs from the default thread-handling model that associates one thread with one connection such that the thread executes all statements from the connection.
The thread pool tries to ensure a maximum of one thread executing in each group at any time, but sometimes permits more threads to execute temporarily for best performance. The algorithm works in the following manner:
Each thread group has a listener thread that listens for incoming statements from the connections assigned to the group. When a statement arrives, the thread group either begins executing it immediately or queues it for later execution:
Immediate execution occurs if the statement is the only one received and no statements are queued or currently executing.
Queuing occurs if the statement cannot begin executing immediately.
If immediate execution occurs, execution is performed by the listener thread. (This means that temporarily no thread in the group is listening.) If the statement finishes quickly, the executing thread returns to listening for statements. Otherwise, the thread pool considers the statement stalled and starts another thread as a listener thread (creating it if necessary). To ensure that no thread group becomes blocked by stalled statements, the thread pool has a background thread that regularly monitors thread group states.
By using the listening thread to execute a statement that can begin immediately, there is no need to create an additional thread if the statement finishes quickly. This ensures the most efficient execution possible in the case of a low number of concurrent threads.
When the thread pool plugin starts, it creates one thread per group (the listener thread), plus the background thread. Additional threads are created as necessary to execute statements.
The value of the
thread_pool_stall_limit
system variable determines the meaning of “finishes
quickly” in the previous item. The default time
before threads are considered stalled is 60ms but can be set
to a maximum of 6s. This parameter is configurable to enable
you to strike a balance appropriate for the server work
load. Short wait values permit threads to start more
quickly. Short values are also better for avoiding deadlock
situations. Long wait values are useful for workloads that
include long-running statements, to avoid starting too many
new statements while the current ones execute.
The thread pool focuses on limiting the number of concurrent short-running statements. Before an executing statement reaches the stall time, it prevents other statements from beginning to execute. If the statement executes past the stall time, it is permitted to continue but no longer prevents other statements from starting. In this way, the thread pool tries to ensure that in each thread group there is never more than one short-running statement, although there might be multiple long-running statements. It is undesirable to let long-running statements prevent other statements from executing because there is no limit on the amount of waiting that might be necessary. For example, on a replication master, a thread that is sending binary log events to a slave effectively runs forever.
A statement becomes blocked if it encounters a disk I/O operation or a user level lock (row lock or table lock). The block would cause the thread group to become unused, so there are callbacks to the thread pool to ensure that the thread pool can immediately start a new thread in this group to execute another statement. When a blocked thread returns, the thread pool permits it to restart immediately.
There are two queues, a high-priority queue and a
low-priority queue. The first statement in a transaction
goes to the low-priority queue. Any following statements for
the transaction go to the high-priority queue if the
transaction is ongoing (statements for it have begun
executing), or to the low-priority queue otherwise. Queue
assignment can be affected by enabling the
thread_pool_high_priority_connection
system variable, which causes all queued statements for a
session to go into the high-priority queue.
Statements for a nontransactional storage engine, or a
transactional engine if
autocommit
is enabled, are
treated as low-priority statements because in this case each
statement is a transaction. Thus, given a mix of statements
for InnoDB
and MyISAM
tables, the thread pool prioritizes those for
InnoDB
over those for
MyISAM
unless
autocommit
is enabled. With
autocommit
enabled, all
statements will be low priority.
When the thread group selects a queued statement for execution, it first looks in the high-priority queue, then in the low-priority queue. If a statement is found, it is removed from its queue and begins to execute.
If a statement stays in the low-priority queue too long, the
thread pool moves to the high-priority queue. The value of
the
thread_pool_prio_kickup_timer
system variable controls the time before movement. For each
thread group, a maximum of one statement per 10ms or 100 per
second will be moved from the low-priority queue to the
high-priority queue.
The thread pool reuses the most active threads to obtain a much better use of CPU caches. This is a small adjustment that has a great impact on performance.
While a thread executes a statement from a user connection, Performance Schema instrumentation accounts thread activity to the user connection. Otherwise, Performance Schema accounts activity to the thread pool.
Here are examples of conditions under which a thread group might have multiple threads started to execute statements:
One thread begins executing a statement, but runs long enough to be considered stalled. The thread group permits another thread to begin executing another statement even through the first thread is still executing.
One thread begins executing a statement, then becomes blocked and reports this back to the thread pool. The thread group permits another thread to begin executing another statement.
One thread begins executing a statement, becomes blocked, but does not report back that it is blocked because the block does not occur in code that has been instrumented with thread pool callbacks. In this case, the thread appears to the thread group to be still running. If the block lasts long enough for the statement to be considered stalled, the group permits another thread to begin executing another statement.
The thread pool is designed to be scalable across an increasing number of connections. It is also designed to avoid deadlocks that can arise from limiting the number of actively executing statements. It is important that threads that do not report back to the thread pool do not prevent other statements from executing and thus cause the thread pool to become deadlocked. Examples of such statements follow:
Long-running statements. These would lead to all resources used by only a few statements and they could prevent all others from accessing the server.
Binary log dump threads that read the binary log and send it to slaves. This is a kind of long-running “statement” that runs for a very long time, and that should not prevent other statements from executing.
Statements blocked on a row lock, table lock, sleep, or any other blocking activity that has not been reported back to the thread pool by MySQL Server or a storage engine.
In each case, to prevent deadlock, the statement is moved to the stalled category when it does not complete quickly, so that the thread group can permit another statement to begin executing. With this design, when a thread executes or becomes blocked for an extended time, the thread pool moves the thread to the stalled category and for the rest of the statement's execution, it does not prevent other statements from executing.
The maximum number of threads that can occur is the sum of
max_connections
and
thread_pool_size
. This can
happen in a situation where all connections are in execution
mode and an extra thread is created per group to listen for more
statements. This is not necessarily a state that happens often,
but it is theoretically possible.
This section provides guidelines on setting thread pool system variables for best performance, measured using a metric such as transactions per second.
thread_pool_size
is the most
important parameter controlling thread pool performance. It can
be set only at server startup. Our experience in testing the
thread pool indicates the following:
If the primary storage engine is InnoDB
,
the optimal
thread_pool_size
setting is
likely to be between 16 and 36, with the most common optimal
values tending to be from 24 to 36. We have not seen any
situation where the setting has been optimal beyond 36.
There may be special cases where a value smaller than 16 is
optimal.
For workloads such as DBT2 and Sysbench, the optimum for
InnoDB
seems to be usually
around 36. For very write-intensive workloads, the optimal
setting can sometimes be lower.
If the primary storage engine is
MyISAM
, the
thread_pool_size
setting
should be fairly low. We tend to get optimal performance for
values from 4 to 8. Higher values tend to have a slightly
negative but not dramatic impact on performance.
Another system variable,
thread_pool_stall_limit
, is
important for handling of blocked and long-running statements.
If all calls that block the MySQL Server are reported to the
thread pool, it would always know when execution threads are
blocked. However, this may not always be true. For example,
blocks could occur in code that has not been instrumented with
thread pool callbacks. For such cases, the thread pool must be
able to identify threads that appear to be blocked. This is done
by means of a timeout, the length of which can be tuned using
the thread_pool_stall_limit
system variable. This parameter ensures that the server does not
become completely blocked. The value of
thread_pool_stall_limit
has an
upper limit of 6 seconds to prevent the risk of a deadlocked
server.
thread_pool_stall_limit
also
enables the thread pool to handle long-running statements. If a
long-running statement was permitted to block a thread group,
all other connections assigned to the group would be blocked and
unable to start execution until the long-running statement
completed. In the worst case, this could take hours or even
days.
The value of
thread_pool_stall_limit
should
be chosen such that statements that execute longer than its
value are considered stalled. Stalled statements generate a lot
of extra overhead since they involve extra context switches and
in some cases even extra thread creations. On the other hand,
setting the
thread_pool_stall_limit
parameter too high means that long-running statements will block
a number of short-running statements for longer than necessary.
Short wait values permit threads to start more quickly. Short
values are also better for avoiding deadlock situations. Long
wait values are useful for workloads that include long-running
statements, to avoid starting too many new statements while the
current ones execute.
Suppose a server executes a workload where 99.9% of the
statements complete within 100ms even when the server is loaded,
and the remaining statements take between 100ms and 2 hours
fairly evenly spread. In this case, it would make sense to set
thread_pool_stall_limit
to 10
(meaning 100ms). The default value of 60ms is okay for servers
that primarily execute very simple statements.
The thread_pool_stall_limit
parameter can be changed at runtime to enable you to strike a
balance appropriate for the server work load. Assuming that the
TP_THREAD_GROUP_STATS
table is enabled, you
can use the following query to determine the fraction of
executed statements that stalled:
SELECT SUM(STALLED_QUERIES_EXECUTED) / SUM(QUERIES_EXECUTED) FROM INFORMATION_SCHEMA.TP_THREAD_GROUP_STATS;
This number should be as low as possible. To decrease the
likelihood of statements stalling, increase the value of
thread_pool_stall_limit
.
When a statement arrives, what is the maximum time it can be delayed before it actually starts executing? Suppose that the following conditions apply:
There are 200 statements queued in the low-priority queue.
There are 10 statements queued in the high-priority queue.
thread_pool_prio_kickup_timer
is set to 10000 (10 seconds).
thread_pool_stall_limit
is
set to 100 (1 second).
In the worst case, the 10 high-priority statements represent 10 transactions that continue executing for a long time. Thus, in the worst case, no statements will be moved to the high-priority queue because it will always already contain statements awaiting execution. After 10 seconds, the new statement is eligible to be moved to the high-priority queue. However, before it can be moved, all the statements before it must be moved as well. This could take another 2 seconds because a maximum of 100 statements per second are moved to the high-priority queue. Now when the statement reaches the high-priority queue, there could potentially be many long-running statements ahead of it. In the worst case, every one of those will become stalled and it will take 1 second for each statement before the next statement is retrieved from the high-priority queue. Thus, in this scenario, it will take 222 seconds before the new statement starts executing.
This example shows a worst case for an application. How to handle it depends on the application. If the application has high requirements for the response time, it should most likely throttle users at a higher level itself. Otherwise, it can use the thread pool configuration parameters to set some kind of a maximum waiting time.
MySQL supports query rewrite plugins that can examine and possibly modify SQL statements received by the server before the server executes them. See Query Rewrite Plugins.
MySQL distributions include a postparse query rewrite plugin named
Rewriter
and scripts for installing the plugin
and its associated components. These components work together to
provide statement-rewriting capability:
A server-side plugin named Rewriter
examines statements and may rewrite them, based on its
in-memory cache of rewrite rules.
These statements are subject to rewriting:
Standalone statements and prepared statements are subject to rewriting. Statements occurring within view definitions or stored programs are not subject to rewriting.
The Rewriter
plugin uses a database named
query_rewrite
containing a table named
rewrite_rules
. The table provides
persistent storage for the rules that the plugin uses to
decide whether to rewrite statements. Users communicate with
the plugin by modifying the set of rules stored in this table.
The plugin communicates with users by setting the
message
column of table rows.
The query_rewrite
database contains a
stored procedure named
flush_rewrite_rules()
that loads the
contents of the rules table into the plugin.
A user-defined function named
load_rewrite_rules()
is used by the
flush_rewrite_rules()
stored procedure.
The Rewriter
plugin exposes system
variables that enable plugin configuration and status
variables that provide runtime operational information.
The following sections describe how to install and use the
Rewriter
plugin, and provide reference
information for its associated components.
If installed, the Rewriter
plugin involves
some overhead even when disabled. To avoid this overhead, do
not install the plugin unless you plan to use it.
To install or uninstall the Rewriter
query
rewrite plugin, choose the approropriate script located in the
share
directory of your MySQL installation:
install_rewriter.sql
: Choose this
script to install the Rewriter
plugin and
its associated components.
uninstall_rewriter.sql
: Choose this
script to uninstall the Rewriter
plugin
and its associated components.
Run the chosen script as follows:
shell>mysql -u root -p < install_rewriter.sql
Enter password:(enter root password here)
The example here uses the
install_rewriter.sql
installation script.
Make the appropriate substitution if you choose a different
script.
Running an installation script should install and enable the plugin. To verify that, connect to the server and execute this statement:
mysql> SHOW GLOBAL VARIABLES LIKE 'rewriter_enabled';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| rewriter_enabled | ON |
+------------------+-------+
For usage instructions, see Section 5.6.4.2, “Using the Rewriter Query Rewrite Plugin”. For reference information, see Section 5.6.4.3, “Rewriter Query Rewrite Plugin Reference”.
To enable or disable the plugin, enable or disable the
rewriter_enabled
system
variable. By default, the Rewriter
plugin is
enabled when you install it (see
Section 5.6.4.1, “Installing or Uninstalling the Rewriter Query Rewrite Plugin”).
To set the initial plugin state explicitly, you can set the
variable at server startup. For example, to enable the plugin in
an option file, use these lines:
[mysqld] rewriter_enabled=ON
It is also possible to enable or disable the plugin at runtime:
SET GLOBAL rewriter_enabled = ON; SET GLOBAL rewriter_enabled = OFF;
Assuming that the Rewriter
plugin is enabled,
it examines and possibly modifies each rewritable statement
received by the server. The plugin determines whether to rewrite
statements based on its in-memory cache of rewriting rules,
which are loaded from the rewrite_rules
table
in the query_rewrite
database.
These statements are subject to rewriting:
Standalone statements and prepared statements are subject to rewriting. Statements occurring within view definitions or stored programs are not subject to rewriting.
To add rules for the Rewriter
plugin, add
rows to the rewrite_rules
table, then
invoke the flush_rewrite_rules()
stored
procedure to load the rules from the table into the plugin.
The following example creates a simple rule to match
statements that select a single literal value:
INSERT INTO query_rewrite.rewrite_rules (pattern, replacement) VALUES('SELECT ?', 'SELECT ? + 1');
The resulting table contents look like this:
mysql> SELECT * FROM query_rewrite.rewrite_rules\G
*************************** 1. row ***************************
id: 1
pattern: SELECT ?
pattern_database: NULL
replacement: SELECT ? + 1
enabled: YES
message: NULL
pattern_digest: NULL
normalized_pattern: NULL
The rule specifies a pattern template indicating which
SELECT
statements to match, and
a replacement template indicating how to rewrite matching
statements. However, adding the rule to the
rewrite_rules
table is not sufficient to
cause the Rewriter
plugin to use the rule.
You must invoke flush_rewrite_rules()
to
load the table contents into the plugin in-memory cache:
mysql> CALL query_rewrite.flush_rewrite_rules();
If your rewrite rules seem not to be working properly, make
sure that you have reloaded the rules table by calling
flush_rewrite_rules()
.
When the plugin reads each rule from the rules table, it
computes a normalized (statement digest) form from the pattern
and a digest hash value, and uses them to update the
normalized_pattern
and
pattern_digest
columns:
mysql> SELECT * FROM query_rewrite.rewrite_rules\G
*************************** 1. row ***************************
id: 1
pattern: SELECT ?
pattern_database: NULL
replacement: SELECT ? + 1
enabled: YES
message: NULL
pattern_digest: d1b44b0c19af710b5a679907e284acd2ddc285201794bc69a2389d77baedddae
normalized_pattern: select ?
For information about statement digesting, normalized statements, and digest hash values, see Section 25.9, “Performance Schema Statement Digests and Sampling”.
If a rule cannot be loaded due to some error, calling
flush_rewrite_rules()
produces an error:
mysql> CALL query_rewrite.flush_rewrite_rules();
ERROR 1644 (45000): Loading of some rule(s) failed.
When this occurs, the plugin writes an error message to the
message
column of the rule row to
communicate the problem. Check the
rewrite_rules
table for rows with
non-NULL
message
column
values to see what problems exist.
Patterns use the same syntax as prepared statements (see
Section 13.5.1, “PREPARE Syntax”). Within a pattern template,
?
characters act as parameter markers that
match data values. Parameter markers can be used only where
data values should appear, not for SQL keywords, identifiers,
and so forth. The ?
characters should not
be enclosed within quotation marks.
Like the pattern, the replacement can contain
?
characters. For a statement that matches
a pattern template, the plugin rewrites it, replacing
?
parameter markers in the replacement
using data values matched by the corresponding markers in the
pattern. The result is a complete statement string. The plugin
asks the server to parse it, and returns the result to the
server as the representation of the rewritten statement.
After adding and loading the rule, check whether rewriting occurs according to whether statements match the rule pattern:
mysql>SELECT PI();
+----------+ | PI() | +----------+ | 3.141593 | +----------+ 1 row in set (0.01 sec) mysql>SELECT 10;
+--------+ | 10 + 1 | +--------+ | 11 | +--------+ 1 row in set, 1 warning (0.00 sec)
No rewriting occurs for the first
SELECT
statement, but does for
the second. The second statement illustrates that when the
Rewriter
plugin rewrites a statement, it
produces a warning message. To view the message, use
SHOW WARNINGS
:
mysql> SHOW WARNINGS\G
*************************** 1. row ***************************
Level: Note
Code: 1105
Message: Query 'SELECT 10' rewritten to 'SELECT 10 + 1' by a query rewrite plugin
A statement need not be rewritten to a statement of the same
type. The following example loads a rule that rewrites
DELETE
statements to
UPDATE
statements:
INSERT INTO query_rewrite.rewrite_rules (pattern, replacement) VALUES('DELETE FROM db1.t1 WHERE col = ?', 'UPDATE db1.t1 SET col = NULL WHERE col = ?'); CALL query_rewrite.flush_rewrite_rules();
To enable or disable an existing rule, modify its
enabled
column and reload the table into
the plugin. To disable rule 1:
UPDATE query_rewrite.rewrite_rules SET enabled = 'NO' WHERE id = 1; CALL query_rewrite.flush_rewrite_rules();
This enables you to deactivate a rule without removing it from the table.
To re-enable rule 1:
UPDATE query_rewrite.rewrite_rules SET enabled = 'YES' WHERE id = 1; CALL query_rewrite.flush_rewrite_rules();
The rewrite_rules
table contains a
pattern_database
column that
Rewriter
uses for matching table names that
are not qualified with a database name:
Qualified table names in statements match qualified names in the pattern if corresponding database and table names are identical.
Unqualified table names in statements match unqualified
names in the pattern only if the default database is the
same as pattern_database
and the table
names are identical.
Suppose that a table named appdb.users
has
a column named id
and that applications are
expected to select rows from the table using a query of one of
these forms, where the second can be used only if
appdb
is the default database:
SELECT * FROM users WHERE appdb.id =id_value
; SELECT * FROM users WHERE id =id_value
;
Suppose also that the id
column is renamed
to user_id
(perhaps the table must be
modified to add another type of ID and it is necessary to
indicate more specifically what type of ID the
id
column represents).
The change means that applications must refer to
user_id
rather than id
in the WHERE
clause. But if there are old
applications that cannot be written to change the
SELECT
queries they generate, they will no
longer work properly. The Rewriter
plugin
can solve this problem. To match and rewrite statements
whether or not they qualify the table name, add the following
two rules and reload the rules table:
INSERT INTO query_rewrite.rewrite_rules (pattern, replacement) VALUES( 'SELECT * FROM appdb.users WHERE id = ?', 'SELECT * FROM appdb.users WHERE user_id = ?' ); INSERT INTO query_rewrite.rewrite_rules (pattern, replacement, pattern_database) VALUES( 'SELECT * FROM users WHERE id = ?', 'SELECT * FROM users WHERE user_id = ?', 'appdb' ); CALL query_rewrite.flush_rewrite_rules();
Rewriter
uses the first rule to match
statements that use the qualified table name. It uses the
second to match statements that used the unqualified name, but
only if the default database is appdb
(the
value in pattern_database
).
The Rewriter
plugin uses statement digests
and digest hash values to match incoming statements against
rewrite rules in stages. The
max_digest_length
system variable
determines the size of the buffer used for computing statement
digests. Larger values enable computation of digests that
distinguish longer statements. Smaller values use less memory
but increase the likelihood of longer statements colliding
with the same digest value.
The plugin matches each statement to the rewrite rules as follows:
Compute the statement digest hash value and compare it to the rule digest hash values. This is subject to false positives, but serves as a quick rejection test.
If the statement digest hash value matches any pattern digest hash values, match the normalized (statement digest) form of the statement to the normalized form of the matching rule patterns.
If the normalized statement matches a rule, compare the
literal values in the statement and the pattern. A
?
character in the pattern matches any
literal value in the statement. If the statement prepares
a statement, ?
in the pattern also
matches ?
in the statement. Otherwise,
corresponding literals must be the same.
If multiple rules match a statement, it is nondeterministic which one the plugin uses to rewrite the statement.
If a pattern contains more markers than the replacement, the
plugin discards excess data values. If a pattern contains
fewer markers than the replacement, it is an error. The plugin
notices this when the rules table is loaded, writes an error
message to the message
column of the rule
row to communicate the problem, and sets the
Rewriter_reload_error
status
variable to ON
.
Prepared statements are rewritten at parse time (that is, when they are prepared), not when they are executed later.
Prepared statements differ from nonprepared statements in that
they may contain ?
characters as parameter
markers. To match a ?
in a prepared
statement, a Rewriter
pattern must contain
?
in the same location. Suppose that a
rewrite rule has this pattern:
SELECT ?, 3
The following table shows several prepared
SELECT
statements and whether
the rule pattern matches them.
Prepared Statement | Whether Pattern Matches Statement |
---|---|
PREPARE s AS 'SELECT 3, 3' |
Yes |
PREPARE s AS 'SELECT ?, 3' |
Yes |
PREPARE s AS 'SELECT 3, ?' |
No |
PREPARE s AS 'SELECT ?, ?' |
No |
The Rewriter
plugin makes information
available about its operation by means of several status
variables:
mysql> SHOW GLOBAL STATUS LIKE 'Rewriter%';
+-----------------------------------+-------+
| Variable_name | Value |
+-----------------------------------+-------+
| Rewriter_number_loaded_rules | 1 |
| Rewriter_number_reloads | 5 |
| Rewriter_number_rewritten_queries | 1 |
| Rewriter_reload_error | ON |
+-----------------------------------+-------+
For descriptions of these variables, see Section 5.6.4.3.4, “Rewriter Query Rewrite Plugin Status Variables”.
When you load the rules table by calling the
flush_rewrite_rules()
stored procedure, if
an error occurs for some rule, the CALL
statement produces an error, and the plugin sets the
Rewriter_reload_error
status variable to
ON
:
mysql>CALL query_rewrite.flush_rewrite_rules();
ERROR 1644 (45000): Loading of some rule(s) failed. mysql>SHOW GLOBAL STATUS LIKE 'Rewriter_reload_error';
+-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | Rewriter_reload_error | ON | +-----------------------+-------+
In this case, check the rewrite_rules
table
for rows with non-NULL
message
column values to see what problems
exist.
When the rewrite_rules
table is loaded into
the Rewriter
plugin, the plugin interprets
statements using the current global value of the
character_set_client
system
variable. If the global
character_set_client
value is
changed subsequently, the rules table must be reloaded.
A client must have a session
character_set_client
value
identical to what the global value was when the rules table
was loaded or rule matching will not work for that client.
The following discussion serves as a reference to these
components associated with the Rewriter
query
rewrite plugin:
The Rewriter
rules table in the
query_rewrite
database
Rewriter
procedures and functions
Rewriter
system and status variables
The rewrite_rules
table in the
query_rewrite
database provides persistent
storage for the rules that the Rewriter
plugin uses to decide whether to rewrite statements.
Users communicate with the plugin by modifying the set of
rules stored in this table. The plugin communicates
information to users by setting the table's
message
column.
The rules table is loaded into the plugin by the
flush_rewrite_rules
stored procedure.
Unless that procedure has been called following the most
recent table modification, the table contents do not
necessarily correspond to the set of rules the plugin is
using.
The rewrite_rules
table has these columns:
id
The rule ID. This column is the table primary key. You can use the ID to uniquely identify any rule.
pattern
The template that indicates the pattern for statements
that the rule matches. Use ?
to
represent parameter markers that match data values.
pattern_database
The database used to match unqualified table names in
statements. Qualified table names in statements match
qualified names in the pattern if corresponding database
and table names are identical. Unqualified table names in
statements match unqualified names in the pattern only if
the default database is the same as
pattern_database
and the table names
are identical.
replacement
The template that indicates how to rewrite statements
matching the pattern
column value. Use
?
to represent parameter markers that
match data values. In rewritten statements, the plugin
replaces ?
parameter markers in
replacement
using data values matched
by the corresponding markers in
pattern
.
enabled
Whether the rule is enabled. Load operations (performed by
invoking the flush_rewrite_rules()
stored procedure) load the rule from the table into the
Rewriter
in-memory cache only if this
column is YES
.
This column makes it possible to deactivate a rule without
removing it: Set the column to a value other than
YES
and reload the table into the
plugin.
message
The plugin uses this column for communicating with users.
If no error occurs when the rules table is loaded into
memory, the plugin sets the message
column to NULL
. A
non-NULL
value indicates an error and
the column contents are the error message. Errors can
occur under these circumstances:
Either the pattern or the replacement is an incorrect SQL statement that produces syntax errors.
The replacement contains more ?
parameter markers than the pattern.
If a load error occurs, the plugin also sets the
Rewriter_reload_error
status variable to ON
.
pattern_digest
This column is used for debugging and diagnostics. If the column exists when the rules table is loaded into memory, the plugin updates it with the pattern digest. This column may be useful if you are trying to determine why some statement fails to be rewritten.
normalized_pattern
This column is used for debugging and diagnostics. If the column exists when the rules table is loaded into memory, the plugin updates it with the normalized form of the pattern. This column may be useful if you are trying to determine why some statement fails to be rewritten.
Rewriter
plugin operation uses a stored
procedure that loads the rules table into its in-memory cache,
and a helper user-defined function (UDF). Under normal
operation, users invoke only the stored procedure. The UDF is
intended to be invoked by the stored procedure, not directly
by users.
flush_rewrite_rules()
This stored procedure uses the
load_rewrite_rules()
UDF to load the
contents of the rewrite_rules
table
into the Rewriter
in-memory cache.
Calling flush_rewrite_rules()
implies
COMMIT
.
Invoke this procedure after you modify the rules table to
cause the plugin to update its cache from the new table
contents. If any errors occur, the plugin sets the
message
column for the appropriate rule
rows in the table and sets the
Rewriter_reload_error
status variable to ON
.
load_rewrite_rules()
This UDF is a helper routine used by the
flush_rewrite_rules()
stored procedure.
The Rewriter
query rewrite plugin supports
the following system variables. These variables are available
only if the plugin is installed (see
Section 5.6.4.1, “Installing or Uninstalling the Rewriter Query Rewrite Plugin”).
Property | Value |
---|---|
System Variable | rewriter_enabled |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | boolean |
Default Value | ON |
Whether the Rewriter
query rewrite
plugin is enabled.
Property | Value |
---|---|
System Variable | rewriter_verbose |
Scope | Global |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | integer |
For internal use.
The Rewriter
query rewrite plugin supports
the following status variables. These variables are available
only if the plugin is installed (see
Section 5.6.4.1, “Installing or Uninstalling the Rewriter Query Rewrite Plugin”).
The number of rewrite plugin rewrite rules successfully
loaded from the rewrite_rules
table
into memory for use by the Rewriter
plugin.
The number of times the rewrite_rules
table has been loaded into the in-memory cache used by the
Rewriter
plugin.
Rewriter_number_rewritten_queries
The number of queries rewritten by the
Rewriter
query rewrite plugin since it
was loaded.
Whether an error occurred the most recent time that the
rewrite_rules
table was loaded into the
in-memory cache used by the Rewriter
plugin. If the value is OFF
, no error
occurred. If the value is ON
, an error
occurred; check the message
column of
the rewriter_rules
table for error
messages.
MySQL includes Version Tokens, a feature that enables creation of and synchronization around server tokens that applications can use to prevent accessing incorrect or out-of-date data.
The Version Tokens interface has these characteristics:
Version tokens are pairs consisting of a name that serves as a key or identifier, plus a value.
Version tokens can be locked. An application can use token locks to indicate to other cooperating applications that tokens are in use and should not be modified.
Version token lists are established per server; for example, to specify the server assignment or operational state. In addition, an application that communicates with a server can register its own list of tokens that indicate the state it requires the server to be in. An SQL statement sent by the application to a server not in the required state produces an error. This is a signal to the application that it should seek a different server in the required state to receive the SQL statement.
The following sections describe the components of Version Tokens, discuss how to install and use it, and provide reference information for its components.
Version Tokens is based on a plugin library that implements these components:
A server-side plugin named version_tokens
holds the list of version tokens associated with the server
and subscribes to notifications for statement execution
events. The version_tokens
plugin uses
the audit plugin
API to monitor incoming statements from clients and
matches each client's session-specific version token list
against the server version token list. If there is a match,
the plugin lets the statement through and the server
continues to process it. Otherwise, the plugin returns an
error to the client and the statement fails.
A set of user-defined functions (UDFs) provides an SQL-level
API for manipulating and inspecting the list of server
version tokens maintained by the plugin. The
VERSION_TOKEN_ADMIN
or
SUPER
privilege is required
to call any of the Version Token UDFs.
When the version_tokens
plugin loads, it
defines the
VERSION_TOKEN_ADMIN
dynamic
privilege. This privilege can be granted to users of the
UDFs.
A system variable enables clients to specify the list of version tokens that register the required server state. If the server has a different state when a client sends a statement, the client receives an error.
If installed, Version Tokens involves some overhead. To avoid this overhead, do not install it unless you plan to use it.
This section describes how to install or uninstall Version Tokens, which is implemented in a plugin library file containing a plugin and user-defined functions. For general information about installing or uninstalling plugins and UDFs, see Section 5.6.1, “Installing and Uninstalling Plugins”, and Section 28.4.2.5, “UDF Compiling and Installing”.
To be usable by the server, the plugin library file must be
located in the MySQL plugin directory (the directory named by
the plugin_dir
system
variable). If necessary, set the value of
plugin_dir
at server startup to
tell the server the plugin directory location.
The plugin library file base name is
version_tokens
. The file name suffix differs
per platform (for example, .so
for Unix and
Unix-like systems, .dll
for Windows).
To install the Version Tokens plugin and UDFs, use the
INSTALL PLUGIN
and
CREATE FUNCTION
statements
(adjust the .so
suffix for your platform as
necessary):
INSTALL PLUGIN version_tokens SONAME 'version_token.so'; CREATE FUNCTION version_tokens_set RETURNS STRING SONAME 'version_token.so'; CREATE FUNCTION version_tokens_show RETURNS STRING SONAME 'version_token.so'; CREATE FUNCTION version_tokens_edit RETURNS STRING SONAME 'version_token.so'; CREATE FUNCTION version_tokens_delete RETURNS STRING SONAME 'version_token.so'; CREATE FUNCTION version_tokens_lock_shared RETURNS INT SONAME 'version_token.so'; CREATE FUNCTION version_tokens_lock_exclusive RETURNS INT SONAME 'version_token.so'; CREATE FUNCTION version_tokens_unlock RETURNS INT SONAME 'version_token.so';
You must install the UDFs to manage the server's version token list, but you must also install the plugin because the UDFs will not work correctly without it.
If the plugin and UDFs are used on a master replication server, install them on all slave servers as well to avoid replication problems.
Once installed as just described, the Version Tokens plugin and
UDFs remain installed until uninstalled. To remove them, use the
UNINSTALL PLUGIN
and
DROP FUNCTION
statements:
UNINSTALL PLUGIN version_tokens; DROP FUNCTION version_tokens_set; DROP FUNCTION version_tokens_show; DROP FUNCTION version_tokens_edit; DROP FUNCTION version_tokens_delete; DROP FUNCTION version_tokens_lock_shared; DROP FUNCTION version_tokens_lock_exclusive; DROP FUNCTION version_tokens_unlock;
Before using Version Tokens, install it according to the instructions provided at Section 5.6.5.2, “Installing or Uninstalling Version Tokens”.
A scenario in which Version Tokens can be useful is a system that accesses a collection of MySQL servers but needs to manage them for load balancing purposes by monitoring them and adjusting server assignments according to load changes. Such a system comprises these components:
The collection of MySQL servers to be managed.
An administrative or management application that communicates with the servers and organizes them into high-availability groups. Groups serve different purposes, and servers within each group may have different assignments. Assignment of a server within a certain group can change at any time.
Client applications that access the servers to retrieve and update data, choosing servers according to the purposes assigned them. For example, a client should not send an update to a read-only server.
Version Tokens permit server access to be managed according to assignment without requiring clients to repeatedly query the servers about their assignments:
The management application performs server assignments and establishes version tokens on each server to reflect its assignment. The application caches this information to provide a central access point to it.
If at some point the management application needs to change a server assignment (for example, to change it from permitting writes to read only), it changes the server's version token list and updates its cache.
To improve performance, client applications obtain cache information from the management application, enabling them to avoid having to retrieve information about server assignments for each statement. Based on the type of statements it will issue (for example, reads versus writes), a client selects an appropriate server and connects to it.
In addition, the client sends to the server its own client-specific version tokens to register the assignment it requires of the server. For each statement sent by the client to the server, the server compares its own token list with the client token list. If the server token list contains all tokens present in the client token list with the same values, there is a match and the server executes the statement.
On the other hand, perhaps the management application has changed the server assignment and its version token list. In this case, the new server assignment may now be incompatible with the client requirements. A token mismatch between the server and client token lists occurs and the server returns an error in reply to the statement. This is an indication to the client to refresh its version token information from the management application cache, and to select a new server to communicate with.
The client-side logic for detecting version token errors and selecting a new server can be implemented different ways:
The client can handle all version token registration, mismatch detection, and connection switching itself.
The logic for those actions can be implemented in a connector that manages connections between clients and MySQL servers. Such a connector might handle mismatch error detection and statement resending itself, or it might pass the error to the application and leave it to the application to resend the statement.
The following example illustrates the preceding discussion in more concrete form.
When Version Tokens initializes on a given server, the server's
version token list is empty. Token list maintenance is performed
by calling user-defined functions (UDFs). The
VERSION_TOKEN_ADMIN
or
SUPER
privilege is required to
call any of the Version Token UDFs, so token list modification
is expected to be done by a management or administrative
application that has that privilege.
Suppose that a management application communicates with a set of
servers that are queried by clients to access employee and
product databases (named emp
and
prod
, respectively). All servers are
permitted to process data retrieval statements, but only some of
them are permitted to make database updates. To handle this on a
database-specific basis, the management application establishes
a list of version tokens on each server. In the token list for a
given server, token names represent database names and token
values are read
or write
depending on whether the database must be used in read-only
fashion or whether it can take reads and writes.
Client applications register a list of version tokens they require the server to match by setting a system variable. Variable setting occurs on a client-specific basis, so different clients can register different requirements. By default, the client token list is empty, which matches any server token list. When a client sets its token list to a nonempty value, matching may succeed or fail, depending on the server version token list.
To define the version token list for a server, the management
application calls the version_token_set()
UDF. (There are also UDFs for modifying and displaying the token
list, described later.) For example, the application might send
these statements to a group of three servers:
Server 1:
mysql> SELECT version_tokens_set('emp=read;prod=read');
+------------------------------------------+
| version_tokens_set('emp=read;prod=read') |
+------------------------------------------+
| 2 version tokens set. |
+------------------------------------------+
Server 2:
mysql> SELECT version_tokens_set('emp=write;prod=read');
+-------------------------------------------+
| version_tokens_set('emp=write;prod=read') |
+-------------------------------------------+
| 2 version tokens set. |
+-------------------------------------------+
Server 3:
mysql> SELECT version_tokens_set('emp=read;prod=write');
+-------------------------------------------+
| version_tokens_set('emp=read;prod=write') |
+-------------------------------------------+
| 2 version tokens set. |
+-------------------------------------------+
The token list in each case is specified as a
semicolon-separated list of
pairs. The resulting token list values result in these server
assingments:
name
=value
Any server accepts reads for either database.
Only server 2 accepts updates for the emp
database.
Only server 3 accepts updates for the
prod
database.
In addition to assigning each server a version token list, the management application also maintains a cache that reflects the server assignments.
Before communicating with the servers, a client application
contacts the management application and retrieves information
about server assignments. Then the client selects a server based
on those assignments. Suppose that a client wants to perform
both reads and writes on the emp
database.
Based on the preceding assignments, only server 2 qualifies. The
client connects to server 2 and registers its server
requirements there by setting its
version_tokens_session
system variable:
mysql> SET @@session.version_tokens_session = 'emp=write';
For subsequent statements sent by the client to server 2, the server compares its own version token list to the client list to check whether they match. If so, statements execute normally:
mysql>UPDATE emp.employee SET salary = salary * 1.1 WHERE id = 4981;
Query OK, 1 row affected (0.07 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql>SELECT last_name, first_name FROM emp.employee WHERE id = 4981;
+-----------+------------+ | last_name | first_name | +-----------+------------+ | Smith | Abe | +-----------+------------+ 1 row in set (0.01 sec)
Discrepancies between the server and client version token lists can occur two ways:
A token name in the
version_tokens_session
value is not present in the server token list. In this case,
an
ER_VTOKEN_PLUGIN_TOKEN_NOT_FOUND
error occurs.
A token value in the
version_tokens_session
value differs from the value of the corresponding token in
the server token list. In this case, an
ER_VTOKEN_PLUGIN_TOKEN_MISMATCH
error occurs.
As long as the assignment of server 2 does not change, the
client continues to use it for reads and writes. But suppose
that the management application wants to change server
assignments so that writes for the emp
database must be sent to server 1 instead of server 2. To do
this, it uses version_tokens_edit()
to modify
the emp
token value on the two servers (and
updates its cache of server assignments):
Server 1:
mysql> SELECT version_tokens_edit('emp=write');
+----------------------------------+
| version_tokens_edit('emp=write') |
+----------------------------------+
| 1 version tokens updated. |
+----------------------------------+
Server 2:
mysql> SELECT version_tokens_edit('emp=read');
+---------------------------------+
| version_tokens_edit('emp=read') |
+---------------------------------+
| 1 version tokens updated. |
+---------------------------------+
version_tokens_edit()
modifies the named
tokens in the server token list and leaves other tokens
unchanged.
The next time the client sends a statement to server 2, its own token list no longer matches the server token list and an error occurs:
mysql> UPDATE emp.employee SET salary = salary * 1.1 WHERE id = 4982;
ERROR 3136 (42000): Version token mismatch for emp. Correct value read
In this case, the client should contact the management application to obtain updated information about server assignments, select a new server, and send the failed statement to the new server.
Each client must cooperate with Version Tokens by sending only
statements in accordance with the token list that it registers
with a given server. For example, if a client registers a
token list of 'emp=read'
, there is nothing
in Version Tokens to prevent the client from sending updates
for the emp
database. The client itself
must refrain from doing so.
For each statement received from a client, the server implicitly uses locking, as follows:
Take a shared lock for each token named in the client token
list (that is, in the
version_tokens_session
value)
Perform the comparison between the server and client token lists
Execute the statement or produce an error depending on the comparison result
Release the locks
The server uses shared locks so that comparisons for multiple sessions can occur without blocking, while preventing changes to the tokens for any session that attempts to acquire an exclusive lock before it manipulates tokens of the same names in the server token list.
The preceding example uses only a few of the user-defined included in the Version Tokens plugin library, but there are others. One set of UDFs permits the server's list of version tokens to be manipulated and inspected. Another set of UDFs permits version tokens to be locked and unlocked.
These UDFs permit the server's list of version tokens to be created, changed, removed, and inspected:
version_tokens_set()
completely replaces
the current list and assigns a new list. The argument is a
semicolon-separated list of
pairs.
name
=value
version_tokens_edit()
enables partial
modifications to the current list. It can add new tokens or
change the values of existing tokens. The argument is a
semicolon-separated list of
pairs.
name
=value
version_tokens_delete()
deletes tokens
from the current list. The argument is a semicolon-separated
list of token names.
version_tokens_show()
displays the
current token list. It takes no argument.
Each of those functions, if successful, returns a binary string indicating what action occurred. The following example establishes the server token list, modifies it by adding a new token, deletes some tokens, and displays the resulting token list:
mysql>SELECT version_tokens_set('tok1=a;tok2=b');
+-------------------------------------+ | version_tokens_set('tok1=a;tok2=b') | +-------------------------------------+ | 2 version tokens set. | +-------------------------------------+ mysql>SELECT version_tokens_edit('tok3=c');
+-------------------------------+ | version_tokens_edit('tok3=c') | +-------------------------------+ | 1 version tokens updated. | +-------------------------------+ mysql>SELECT version_tokens_delete('tok2;tok1');
+------------------------------------+ | version_tokens_delete('tok2;tok1') | +------------------------------------+ | 2 version tokens deleted. | +------------------------------------+ mysql>SELECT version_tokens_show();
+-----------------------+ | version_tokens_show() | +-----------------------+ | tok3=c; | +-----------------------+
Warnings occur if a token list is malformed:
mysql>SELECT version_tokens_set('tok1=a; =c');
+----------------------------------+ | version_tokens_set('tok1=a; =c') | +----------------------------------+ | 1 version tokens set. | +----------------------------------+ 1 row in set, 1 warning (0.00 sec) mysql>SHOW WARNINGS\G
*************************** 1. row *************************** Level: Warning Code: 42000 Message: Invalid version token pair encountered. The list provided is only partially updated. 1 row in set (0.00 sec)
As mentioned previously, version tokens are defined using a
semicolon-separated list of
pairs. Consider this invocation of
name
=value
version_tokens_set()
:
mysql> SELECT version_tokens_set('tok1=b;;; tok2= a = b ; tok1 = 1\'2 3"4')
+---------------------------------------------------------------+
| version_tokens_set('tok1=b;;; tok2= a = b ; tok1 = 1\'2 3"4') |
+---------------------------------------------------------------+
| 3 version tokens set. |
+---------------------------------------------------------------+
Version Tokens interprets the argument as follows:
Whitespace around names and values is ignored. Whitespace
within names and values is permitted. (For
version_tokens_delete()
, which takes a
list of names without values, whitespace around names is
ignored.)
There is no quoting mechanism.
Order of tokens is not significant except that if a token list contains multiple instances of a given token name, the last value takes precedence over earlier values.
Given those rules, the preceding
version_tokens_set()
call results in a token
list with two tokens: tok1
has the value
1'2 3"4
, and tok2
has the
value a = b
. To verify this, call
version_tokens_show()
:
mysql> SELECT version_tokens_show();
+--------------------------+
| version_tokens_show() |
+--------------------------+
| tok2=a = b;tok1=1'2 3"4; |
+--------------------------+
If the token list contains two tokens, why did
version_tokens_set()
return the value
3 version tokens set
? That occurred because
the original token list contained two definitions for
tok1
, and the second definition replaced the
first.
The Version Tokens token-manipulation UDFs place these constraints on token names and values:
Token names cannot contain =
or
;
characters and have a maximum length of
64 characters.
Token values cannot contain ;
characters.
Length of values is constrained by the value of the
max_allowed_packet
system
variable.
Version Tokens treats token names and values as binary strings, so comparisons are case-sensitive.
Version Tokens also includes a set of UDFs enabling tokens to be locked and unlocked:
version_tokens_lock_exclusive()
acquires
exclusive version token locks. It takes a list of one or
more lock names and a timeout value.
version_tokens_lock_shared()
acquires
shared version token locks. It takes a list of one or more
lock names and a timeout value.
version_tokens_unlock()
releases version
token locks (exclusive and shared). It takes no argument.
Each locking function returns nonzero for success. Otherwise, an error occurs:
mysql>SELECT version_tokens_lock_shared('lock1', 'lock2', 0);
+-------------------------------------------------+ | version_tokens_lock_shared('lock1', 'lock2', 0) | +-------------------------------------------------+ | 1 | +-------------------------------------------------+ mysql>SELECT version_tokens_lock_shared(NULL, 0);
ERROR 3131 (42000): Incorrect locking service lock name '(null)'.
Locking using Version Tokens locking functions is advisory; applications must agree to cooperate.
It is possible to lock nonexisting token names. This does not create the tokens.
Version Tokens locking functions are based on the locking
service described at Section 28.3.1, “The Locking Service”, and
thus have the same semantics for shared and exclusive locks.
(Version Tokens uses the locking service routines built into
the server, not the locking service UDF interface, so those
UDFs need not be installed to use Version Tokens.) Locks
acquired by Version Tokens use a locking service namespace of
version_token_locks
. Locking service locks
can be monitored using the Performance Schema, so this is also
true for Version Tokens locks. For details, see
Section 28.3.1.2.3, “Locking Service Monitoring”.
For the Version Tokens locking functions, token name arguments
are used exactly as specified. Surrounding whitespace is not
ignored and =
and ;
characters are permitted. This is because Version Tokens simply
passes the token names to be locked as is to the locking
service.
The following discussion serves as a reference to these Version Tokens components:
The Version Tokens plugin library includes several
user-defined functions. One set of UDFs permits the server's
list of version tokens to be manipulated and inspected.
Another set of UDFs permits version tokens to be locked and
unlocked. The
VERSION_TOKEN_ADMIN
or
SUPER
privilege is required to
invoke any Version Tokens UDF.
The following UDFs permit the server's list of version tokens
to be created, changed, removed, and inspected. Interpretation
of name_list
and
token_list
arguments (including
whitespace handling) occurs as described in
Section 5.6.5.3, “Using Version Tokens”, which provides details
about the syntax for specifying tokens, as well as additional
examples.
version_tokens_delete(
name_list
)
Deletes tokens from the server's list of version tokens
using the name_list
argument
and returns a binary string that indicates the outcome of
the operation. name_list
is a
semicolon-separated list of version token names to delete.
mysql> SELECT version_tokens_delete('tok1;tok3');
+------------------------------------+
| version_tokens_delete('tok1;tok3') |
+------------------------------------+
| 2 version tokens deleted. |
+------------------------------------+
An argument of NULL
is treated as an
empty string, which has no effect on the token list.
version_tokens_delete()
deletes the
tokens named in its argument, if they exist. (It is not an
error to delete nonexisting tokens.) To clear the token
list entirely without knowing which tokens are in the
list, pass NULL
or a string containing
no tokens to version_tokens_set()
:
mysql>SELECT version_tokens_set(NULL);
+------------------------------+ | version_tokens_set(NULL) | +------------------------------+ | Version tokens list cleared. | +------------------------------+ mysql>SELECT version_tokens_set('');
+------------------------------+ | version_tokens_set('') | +------------------------------+ | Version tokens list cleared. | +------------------------------+
version_tokens_edit(
token_list
)
Modifies the server's list of version tokens using the
token_list
argument and returns
a binary string that indicates the outcome of the
operation. token_list
is a
semicolon-separated list of
pairs specifying the name of each token to be defined and
its value. If a token exists, its value is updated with
the given value. If a token does not exist, it is created
with the given value. If the argument is
name
=value
NULL
or a string containing no tokens,
the token list remains unchanged.
mysql>SELECT version_tokens_set('tok1=value1;tok2=value2');
+-----------------------------------------------+ | version_tokens_set('tok1=value1;tok2=value2') | +-----------------------------------------------+ | 2 version tokens set. | +-----------------------------------------------+ mysql>SELECT version_tokens_edit('tok2=new_value2;tok3=new_value3');
+--------------------------------------------------------+ | version_tokens_edit('tok2=new_value2;tok3=new_value3') | +--------------------------------------------------------+ | 2 version tokens updated. | +--------------------------------------------------------+
version_tokens_set(
token_list
)
Replaces the server's list of version tokens with the
tokens defined in the
token_list
argument and returns
a binary string that indicates the outcome of the
operation. token_list
is a
semicolon-separated list of
pairs specifying the name of each token to be defined and
its value. If the argument is name
=value
NULL
or a
string containing no tokens, the token list is cleared.
mysql> SELECT version_tokens_set('tok1=value1;tok2=value2');
+-----------------------------------------------+
| version_tokens_set('tok1=value1;tok2=value2') |
+-----------------------------------------------+
| 2 version tokens set. |
+-----------------------------------------------+
version_tokens_show()
Returns the server's list of version tokens as a binary
string containing a semicolon-separated list of
pairs.
name
=value
mysql> SELECT version_tokens_show();
+--------------------------+
| version_tokens_show() |
+--------------------------+
| tok2=value2;tok1=value1; |
+--------------------------+
The following UDFs permit version tokens to be locked and unlocked:
version_tokens_lock_exclusive(
token_name
[,
token_name
] ...,
timeout
)
Acquires exclusive locks on one or more version tokens, specified by name as strings, timing out with an error if the locks are not acquired within the given timeout value.
mysql> SELECT version_tokens_lock_exclusive('lock1', 'lock2', 10);
+-----------------------------------------------------+
| version_tokens_lock_exclusive('lock1', 'lock2', 10) |
+-----------------------------------------------------+
| 1 |
+-----------------------------------------------------+
version_tokens_lock_shared(
token_name
[,
token_name
] ...,
timeout
)
Acquires shared locks on one or more version tokens, specified by name as strings, timing out with an error if the locks are not acquired within the given timeout value.
mysql> SELECT version_tokens_lock_shared('lock1', 'lock2', 10);
+--------------------------------------------------+
| version_tokens_lock_shared('lock1', 'lock2', 10) |
+--------------------------------------------------+
| 1 |
+--------------------------------------------------+
version_tokens_unlock()
Releases all locks that were acquired within the current
session using
version_tokens_lock_exclusive()
and
version_tokens_lock_shared()
.
mysql> SELECT version_tokens_unlock();
+-------------------------+
| version_tokens_unlock() |
+-------------------------+
| 1 |
+-------------------------+
The locking functions share these characteristics:
The return value is nonzero for success. Otherwise, an error occurs.
Token names are strings.
In contrast to argument handling for the UDFs that
manipulate the server token list, whitespace surrounding
token name arguments is not ignored and
=
and ;
characters
are permitted.
It is possible to lock nonexisting token names. This does not create the tokens.
Timeout values are nonnegative integers representing the time in seconds to wait to acquire locks before timing out with an error. If the timeout is 0, there is no waiting and the function produces an error if locks cannot be acquired immediately.
Version Tokens locking functions are based on the locking service described at Section 28.3.1, “The Locking Service”.
Version Tokens supports the following system variables. These variables are unavailable unless the Version Tokens plugin is installed (see Section 5.6.5.2, “Installing or Uninstalling Version Tokens”).
System variables:
Property | Value |
---|---|
Command-Line Format | --version-tokens-session=value |
System Variable | version_tokens_session |
Scope | Global, Session |
Dynamic | Yes |
SET_VAR Hint Applies | No |
Type | string |
Default Value | NULL |
The session value of this variable specifies the client version token list and indicates the tokens that the client session requires the server version token list to have.
If the
version_tokens_session
variable is NULL
(the default) or has
an empty value, any server version token list matches. (In
effect, an empty value disables matching requirements.)
If the
version_tokens_session
variable has a nonempty value, any mismatch between its
value and the server version token list results in an
error for any statement the session sends to the server. A
mismatch occurs under these conditions:
A token name in the
version_tokens_session
value is not present in the server token list. In this
case, an
ER_VTOKEN_PLUGIN_TOKEN_NOT_FOUND
error occurs.
A token value in the
version_tokens_session
value differs from the value of the corresponding
token in the server token list. In this case, an
ER_VTOKEN_PLUGIN_TOKEN_MISMATCH
error occurs.
It is not a mismatch for the server version token list to
include a token not named in the
version_tokens_session
value.
Suppose that a management application has set the server token list as follows:
mysql> SELECT version_tokens_set('tok1=a;tok2=b;tok3=c');
+--------------------------------------------+
| version_tokens_set('tok1=a;tok2=b;tok3=c') |
+--------------------------------------------+
| 3 version tokens set. |
+--------------------------------------------+
A client registers the tokens it requires the server to
match by setting its
version_tokens_session
value. Then, for each subsequent statement sent by the
client, the server checks its token list against the
client
version_tokens_session
value and produces an error if there is a mismatch:
mysql>SET @@session.version_tokens_session = 'tok1=a;tok2=b';
mysql>SELECT 1;
+---+ | 1 | +---+ | 1 | +---+ mysql>SET @@session.version_tokens_session = 'tok1=b';
mysql>SELECT 1;
ERROR 3136 (42000): Version token mismatch for tok1. Correct value a
The first SELECT
succeeds
because the client tokens tok1
and
tok2
are present in the server token
list and each token has the same value in the server list.
The second SELECT
fails
because, although tok1
is present in
the server token list, it has a different value than
specified by the client.
At this point, any statement sent by the client fails, unless the server token list changes such that it matches again. Suppose that the management application changes the server token list as follows:
mysql>SELECT version_tokens_edit('tok1=b');
+-------------------------------+ | version_tokens_edit('tok1=b') | +-------------------------------+ | 1 version tokens updated. | +-------------------------------+ mysql>SELECT version_tokens_show();
+-----------------------+ | version_tokens_show() | +-----------------------+ | tok3=c;tok1=b;tok2=b; | +-----------------------+
Now the client
version_tokens_session
value matches the server token list and the client can
once again successfully execute statements:
mysql> SELECT 1;
+---+
| 1 |
+---+
| 1 |
+---+
Property | Value |
---|---|
Command-Line Format | --version-tokens-session-number=N |
System Variable | version_tokens_session_number |
Scope | Global, Session |
Dynamic | No |
SET_VAR Hint Applies | No |
Type | integer |
Default Value | 0 |
This variable is for internal use.
In some cases, you might want to run multiple instances of MySQL on a single machine. You might want to test a new MySQL release while leaving an existing production setup undisturbed. Or you might want to give different users access to different mysqld servers that they manage themselves. (For example, you might be an Internet Service Provider that wants to provide independent MySQL installations for different customers.)
It is possible to use a different MySQL server binary per instance, or use the same binary for multiple instances, or any combination of the two approaches. For example, you might run a server from MySQL 5.7 and one from MySQL 8.0, to see how different versions handle a given workload. Or you might run multiple instances of the current production version, each managing a different set of databases.
Whether or not you use distinct server binaries, each instance that
you run must be configured with unique values for several operating
parameters. This eliminates the potential for conflict between
instances. Parameters can be set on the command line, in option
files, or by setting environment variables. See
Section 4.2.3, “Specifying Program Options”. To see the values used by a given
instance, connect to it and execute a SHOW
VARIABLES
statement.
The primary resource managed by a MySQL instance is the data
directory. Each instance should use a different data directory, the
location of which is specified using the
--datadir=
option. For methods of configuring each instance with its own data
directory, and warnings about the dangers of failing to do so, see
Section 5.7.1, “Setting Up Multiple Data Directories”.
dir_name
In addition to using different data directories, several other options must have different values for each server instance:
--port
controls the port number
for TCP/IP connections. Alternatively, if the host has multiple
network addresses, you can use
--bind-address
to cause each
server to listen to a different address.
--socket={
file_name
|pipe_name
}
--socket
controls the Unix socket
file path on Unix or the named pipe name on Windows. On Windows,
it is necessary to specify distinct pipe names only for those
servers configured to permit named-pipe connections.
--shared-memory-base-name=
name
This option is used only on Windows. It designates the shared-memory name used by a Windows server to permit clients to connect using shared memory. It is necessary to specify distinct shared-memory names only for those servers configured to permit shared-memory connections.
This option indicates the path name of the file in which the server writes its process ID.
If you use the following log file options, their values must differ for each server:
For further discussion of log file options, see Section 5.4, “MySQL Server Logs”.
To achieve better performance, you can specify the following option differently for each server, to spread the load between several physical disks:
Having different temporary directories also makes it easier to determine which MySQL server created any given temporary file.
If you have multiple MySQL installations in different locations, you
can specify the base directory for each installation with the
--basedir=
option. This causes each instance to automatically use a different
data directory, log files, and PID file because the default for each
of those parameters is relative to the base directory. In that case,
the only other options you need to specify are the
dir_name
--socket
and
--port
options. Suppose that you
install different versions of MySQL using tar
file binary distributions. These install in different locations, so
you can start the server for each installation using the command
bin/mysqld_safe under its corresponding base
directory. mysqld_safe determines the proper
--basedir
option to pass to
mysqld, and you need specify only the
--socket
and
--port
options to
mysqld_safe.
As discussed in the following sections, it is possible to start
additional servers by specifying appropriate command options or by
setting environment variables. However, if you need to run multiple
servers on a more permanent basis, it is more convenient to use
option files to specify for each server those option values that
must be unique to it. The
--defaults-file
option is useful for
this purpose.
Each MySQL Instance on a machine should have its own data
directory. The location is specified using the
--datadir=
option.
dir_name
There are different methods of setting up a data directory for a new instance:
Create a new data directory.
Copy an existing data directory.
The following discussion provides more detail about each method.
Normally, you should never have two servers that update data in the same databases. This may lead to unpleasant surprises if your operating system does not support fault-free system locking. If (despite this warning) you run multiple servers using the same data directory and they have logging enabled, you must use the appropriate options to specify log file names that are unique to each server. Otherwise, the servers try to log to the same files.
Even when the preceding precautions are observed, this kind of
setup works only with MyISAM
and
MERGE
tables, and not with any of the other
storage engines. Also, this warning against sharing a data
directory among servers always applies in an NFS environment.
Permitting multiple MySQL servers to access a common data
directory over NFS is a very bad idea. The
primary problem is that NFS is the speed bottleneck. It is not
meant for such use. Another risk with NFS is that you must
devise a way to ensure that two or more servers do not interfere
with each other. Usually NFS file locking is handled by the
lockd
daemon, but at the moment there is no
platform that performs locking 100% reliably in every situation.
With this method, the data directory will be in the same state as when you first install MySQL. It will have the default set of MySQL accounts and no user data.
On Unix, initialize the data directory. See Section 2.9, “Postinstallation Setup and Testing”.
On Windows, the data directory is included in the MySQL distribution:
MySQL Zip archive distributions for Windows contain an
unmodified data directory. You can unpack such a distribution
into a temporary location, then copy it
data
directory to where you are setting
up the new instance.
Windows MSI package installers create and set up the data
directory that the installed server will use, but also create
a pristine “template” data directory named
data
under the installation directory.
After an installation has been performed using an MSI package,
the template data directory can be copied to set up additional
MySQL instances.
With this method, any MySQL accounts or user data present in the data directory are carried over to the new data directory.
Stop the existing MySQL instance using the data directory. This must be a clean shutdown so that the instance flushes any pending changes to disk.
Copy the data directory to the location where the new data directory should be.
Copy the my.cnf
or
my.ini
option file used by the existing
instance. This serves as a basis for the new instance.
Modify the new option file so that any pathnames referring to the original data directory refer to the new data directory. Also, modify any other options that must be unique per instance, such as the TCP/IP port number and the log files. For a list of parameters that must be unique per instance, see Section 5.7, “Running Multiple MySQL Instances on One Machine”.
Start the new instance, telling it to use the new option file.
You can run multiple servers on Windows by starting them manually from the command line, each with appropriate operating parameters, or by installing several servers as Windows services and running them that way. General instructions for running MySQL from the command line or as a service are given in Section 2.3, “Installing MySQL on Microsoft Windows”. The following sections describe how to start each server with different values for those options that must be unique per server, such as the data directory. These options are listed in Section 5.7, “Running Multiple MySQL Instances on One Machine”.
The procedure for starting a single MySQL server manually from
the command line is described in
Section 2.3.5.6, “Starting MySQL from the Windows Command Line”. To start multiple
servers this way, you can specify the appropriate options on the
command line or in an option file. It is more convenient to
place the options in an option file, but it is necessary to make
sure that each server gets its own set of options. To do this,
create an option file for each server and tell the server the
file name with a --defaults-file
option when you run it.
Suppose that you want to run one instance of
mysqld on port 3307 with a data directory of
C:\mydata1
, and another instance on port
3308 with a data directory of C:\mydata2
.
Use this procedure:
Make sure that each data directory exists, including its own
copy of the mysql
database that contains
the grant tables.
Create two option files. For example, create one file named
C:\my-opts1.cnf
that looks like this:
[mysqld] datadir = C:/mydata1 port = 3307
Create a second file named
C:\my-opts2.cnf
that looks like this:
[mysqld] datadir = C:/mydata2 port = 3308
Use the --defaults-file
option to start each server with its own option file:
C:\>C:\mysql\bin\mysqld --defaults-file=C:\my-opts1.cnf
C:\>C:\mysql\bin\mysqld --defaults-file=C:\my-opts2.cnf
Each server starts in the foreground (no new prompt appears until the server exits later), so you will need to issue those two commands in separate console windows.
To shut down the servers, connect to each using the appropriate port number:
C:\>C:\mysql\bin\mysqladmin --port=3307 --host=127.0.0.1 --user=root --password shutdown
C:\>C:\mysql\bin\mysqladmin --port=3308 --host=127.0.0.1 --user=root --password shutdown
Servers configured as just described permit clients to connect
over TCP/IP. If your version of Windows supports named pipes and
you also want to permit named-pipe connections, specify options
that enable the named pipe and specify its name. Each server
that supports named-pipe connections must use a unique pipe
name. For example, the C:\my-opts1.cnf
file
might be written like this:
[mysqld] datadir = C:/mydata1 port = 3307 enable-named-pipe socket = mypipe1
Modify C:\my-opts2.cnf
similarly for use by
the second server. Then start the servers as described
previously.
A similar procedure applies for servers that you want to permit
shared-memory connections. Enable such connections with the
--shared-memory
option and
specify a unique shared-memory name for each server with the
--shared-memory-base-name
option.
On Windows, a MySQL server can run as a Windows service. The procedures for installing, controlling, and removing a single MySQL service are described in Section 2.3.5.8, “Starting MySQL as a Windows Service”.
To set up multiple MySQL services, you must make sure that each instance uses a different service name in addition to the other parameters that must be unique per instance.
For the following instructions, suppose that you want to run the
mysqld server from two different versions of
MySQL that are installed at C:\mysql-5.5.9
and C:\mysql-8.0.14
,
respectively. (This might be the case if you are running 5.5.9
as your production server, but also want to conduct tests using
8.0.14.)
To install MySQL as a Windows service, use the
--install
or --install-manual
option. For information about these options, see
Section 2.3.5.8, “Starting MySQL as a Windows Service”.
Based on the preceding information, you have several ways to set up multiple services. The following instructions describe some examples. Before trying any of them, shut down and remove any existing MySQL services.
Approach 1: Specify the
options for all services in one of the standard option
files. To do this, use a different service name for each
server. Suppose that you want to run the 5.5.9
mysqld using the service name of
mysqld1
and the 8.0.14
mysqld using the service name
mysqld2
. In this case, you can use the
[mysqld1]
group for 5.5.9 and the
[mysqld2]
group for 8.0.14.
For example, you can set up C:\my.cnf
like this:
# options for mysqld1 service [mysqld1] basedir = C:/mysql-5.5.9 port = 3307 enable-named-pipe socket = mypipe1 # options for mysqld2 service [mysqld2] basedir = C:/mysql-8.0.14 port = 3308 enable-named-pipe socket = mypipe2
Install the services as follows, using the full server path names to ensure that Windows registers the correct executable program for each service:
C:\>C:\mysql-5.5.9\bin\mysqld --install mysqld1
C:\>C:\mysql-8.0.14\bin\mysqld --install mysqld2
To start the services, use the services manager, or use NET START with the appropriate service names:
C:\>NET START mysqld1
C:\>NET START mysqld2
To stop the services, use the services manager, or use NET STOP with the appropriate service names:
C:\>NET STOP mysqld1
C:\>NET STOP mysqld2
Approach 2: Specify options
for each server in separate files and use
--defaults-file
when you
install the services to tell each server what file to use.
In this case, each file should list options using a
[mysqld]
group.
With this approach, to specify options for the 5.5.9
mysqld, create a file
C:\my-opts1.cnf
that looks like this:
[mysqld] basedir = C:/mysql-5.5.9 port = 3307 enable-named-pipe socket = mypipe1
For the 8.0.14 mysqld, create
a file C:\my-opts2.cnf
that looks like
this:
[mysqld] basedir = C:/mysql-8.0.14 port = 3308 enable-named-pipe socket = mypipe2
Install the services as follows (enter each command on a single line):
C:\>C:\mysql-5.5.9\bin\mysqld --install mysqld1
--defaults-file=C:\my-opts1.cnf
C:\>C:\mysql-8.0.14\bin\mysqld --install mysqld2
--defaults-file=C:\my-opts2.cnf
When you install a MySQL server as a service and use a
--defaults-file
option, the
service name must precede the option.
After installing the services, start and stop them the same way as in the preceding example.
To remove multiple services, use mysqld
--remove for each one, specifying a service name
following the --remove
option. If
the service name is the default (MySQL
), you
can omit it.
The discussion here uses mysqld_safe to launch multiple instances of MySQL. For MySQL installation using an RPM distribution, server startup and shutdown is managed by systemd on several Linux platforms. On these platforms, mysqld_safe is not installed because it is unnecessary. For information about using systemd to handle multiple MySQL instances, see Section 2.5.9, “Managing MySQL Server with systemd”.
One way is to run multiple MySQL instances on Unix is to compile different servers with different default TCP/IP ports and Unix socket files so that each one listens on different network interfaces. Compiling in different base directories for each installation also results automatically in a separate, compiled-in data directory, log file, and PID file location for each server.
Assume that an existing 5.7 server is configured for
the default TCP/IP port number (3306) and Unix socket file
(/tmp/mysql.sock
). To configure a new
8.0.14 server to have different operating parameters,
use a CMake command something like this:
shell>cmake . -DMYSQL_TCP_PORT=
port_number
\-DMYSQL_UNIX_ADDR=
file_name
\-DCMAKE_INSTALL_PREFIX=/usr/local/mysql-8.0.14
Here, port_number
and
file_name
must be different from the
default TCP/IP port number and Unix socket file path name, and the
CMAKE_INSTALL_PREFIX
value should
specify an installation directory different from the one under
which the existing MySQL installation is located.
If you have a MySQL server listening on a given port number, you can use the following command to find out what operating parameters it is using for several important configurable variables, including the base directory and Unix socket file name:
shell> mysqladmin --host=host_name
--port=port_number
variables
With the information displayed by that command, you can tell what option values not to use when configuring an additional server.
If you specify localhost
as the host name,
mysqladmin defaults to using a Unix socket file
connection rather than TCP/IP. To explicitly specify the
connection protocol, use the
--protocol={TCP|SOCKET|PIPE|MEMORY}
option.
You need not compile a new MySQL server just to start with a different Unix socket file and TCP/IP port number. It is also possible to use the same server binary and start each invocation of it with different parameter values at runtime. One way to do so is by using command-line options:
shell> mysqld_safe --socket=file_name
--port=port_number
To start a second server, provide different
--socket
and
--port
option values, and pass a
--datadir=
option to mysqld_safe so that the server uses a
different data directory.
dir_name
Alternatively, put the options for each server in a different
option file, then start each server using a
--defaults-file
option that
specifies the path to the appropriate option file. For example, if
the option files for two server instances are named
/usr/local/mysql/my.cnf
and
/usr/local/mysql/my.cnf2
, start the servers
like this: command:
shell>mysqld_safe --defaults-file=/usr/local/mysql/my.cnf
shell>mysqld_safe --defaults-file=/usr/local/mysql/my.cnf2
Another way to achieve a similar effect is to use environment variables to set the Unix socket file name and TCP/IP port number:
shell>MYSQL_UNIX_PORT=/tmp/mysqld-new.sock
shell>MYSQL_TCP_PORT=3307
shell>export MYSQL_UNIX_PORT MYSQL_TCP_PORT
shell>bin/mysqld --initialize --user=mysql
shell>mysqld_safe --datadir=/path/to/datadir &
This is a quick way of starting a second server to use for testing. The nice thing about this method is that the environment variable settings apply to any client programs that you invoke from the same shell. Thus, connections for those clients are automatically directed to the second server.
Section 4.9, “MySQL Program Environment Variables”, includes a list of other environment variables you can use to affect MySQL programs.
On Unix, the mysqld_multi script provides another way to start multiple servers. See Section 4.3.4, “mysqld_multi — Manage Multiple MySQL Servers”.
To connect with a client program to a MySQL server that is listening to different network interfaces from those compiled into your client, you can use one of the following methods:
Start the client with
--host=
host_name
--port=
to connect using TCP/IP to a remote server, with
port_number
--host=127.0.0.1
--port=
to connect using TCP/IP to a local server, or with
port_number
--host=localhost
--socket=
to connect to a local server using a Unix socket file or a
Windows named pipe.
file_name
Start the client with
--protocol=TCP
to connect
using TCP/IP,
--protocol=SOCKET
to connect
using a Unix socket file,
--protocol=PIPE
to connect
using a named pipe, or
--protocol=MEMORY
to connect
using shared memory. For TCP/IP connections, you may also need
to specify --host
and
--port
options. For the other
types of connections, you may need to specify a
--socket
option to specify a
Unix socket file or Windows named-pipe name, or a
--shared-memory-base-name
option to specify the shared-memory name. Shared-memory
connections are supported only on Windows.
On Unix, set the MYSQL_UNIX_PORT
and
MYSQL_TCP_PORT
environment variables to
point to the Unix socket file and TCP/IP port number before
you start your clients. If you normally use a specific socket
file or port number, you can place commands to set these
environment variables in your .login
file
so that they apply each time you log in. See
Section 4.9, “MySQL Program Environment Variables”.
Specify the default Unix socket file and TCP/IP port number in
the [client]
group of an option file. For
example, you can use C:\my.cnf
on
Windows, or the .my.cnf
file in your home
directory on Unix. See Section 4.2.6, “Using Option Files”.
In a C program, you can specify the socket file or port number
arguments in the
mysql_real_connect()
call. You
can also have the program read option files by calling
mysql_options()
. See
Section 27.7.7, “C API Function Descriptions”.
If you are using the Perl DBD::mysql
module, you can read options from MySQL option files. For
example:
$dsn = "DBI:mysql:test;mysql_read_default_group=client;" . "mysql_read_default_file=/usr/local/mysql/data/my.cnf"; $dbh = DBI->connect($dsn, $user, $password);
See Section 27.9, “MySQL Perl API”.
Other programming interfaces may provide similar capabilities for reading option files.