MySQL：日志管理与配置参数的优化

最新推荐文章于 2024-08-29 09:45:14 发布
最新推荐文章于 2024-08-29 09:45:14 发布
阅读量380 收藏
点赞数
分类专栏： 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zhizhengguan/article/details/86688302
版权

文章目录

最优配置模板

[client]
user=oceanstar
password=88888888

[mysql]
prompt=(\u@\h) [\d]>\_

# 服务器端
[mysqld]
# 设置3306端口
port=3306
user=mysql
character_set_server=utf8mb4
datadir=/home/ocean/workspace/mysql/mysql-data   # 设置mysql数据库的数据的存放目录
# bind_address = 10.166.224.32

########log settings########
expire_logs_days = 30   #设置所有日志的过期参数为30天，MYSQL会自动删除过期的日志。为0表示永远不删除。
log_error = error.log
slow_query_log = 1                 #开启慢查询日志
slow_query_log_file = slow.log     #指定日志文件存放文件
long_query_time = 2                #慢查询日志超时时间
log_timestamps = SYSTEM            # 指定时区为当前系统时区
#log_queries_not_using_indexes = 1  #未使用索引的查询记录到慢查询日志中
#log_throttle_queries_not_using_indexes = 10  #每分钟最多记录10条没有使用索引的SQL
log_slow_admin_statements = 1      -- 记录那些慢的optimize table，analyze table和alter table语句
log_slow_slave_statements = 1    -- --记录由Slave所产生的慢查询
min_examined_row_limit = 1000       --记录那些由于查找了多余1000次而引发的慢查询

每次更新my.cnf时记得必须重启才能生效

$ /etc/init.d/mysql.server restart 
[ ok ] Restarting mysql.server (via systemctl): mysql.server.service.

错误日志

由参数"log_error "指定存储位置。

 $ sudo tail -n 10 error.log  -- 查看错误日志

cat /dev/null > error.log;  //清空错误日志

慢查询日志

  • 建议开启

1、参数

  • slow_query_log
    on表示开启慢查询日志，用long_query_time变量的值来确定“慢查询”。
  • slow_query_log_file
    指定慢查询日志存放位置
  • long_query_time
    超过设定事件就将此记录到慢查询日志中
  • log_timestamps
    控制 error log、slow_log、genera log，等等记录日志的显示时间参数，默认有两个值：UTC 和 SYSTEM。默认UTC，建议配置乘SYSTEM，否则会使得日志中记录的时间比中国这边的慢了 8 个小时
  • log_throttle_queries_not_using_indexes
    用来表示每分钟允许记录到slow log的且未使用索引的SQL语句次数。该值默认为0，表示没有限制。在生产环境下，若没有使用索引，此类SQL语句会频繁地被记录到slow log，从而导致slow log文件的大小不断增加
  • expire_logs_days
    用来控制binlog日志文件保留时间，超过保留时间的binlog日志会被自动删除
  • slow_launch_time
    如果创建线程的时间超过该秒数，服务器增加Slow_launch_threads状态变量。

2、解读慢查询日志

如果想要测试

(root@localhost) [(none)]> select sleep(2);
+----------+
| sleep(2) |
+----------+
|        0 |
+----------+
1 row in set (2.00 sec)

下面是记录的没有生成索引的

# Time: 2019-02-27T02:14:42.318181-08:00
# User@Host: root[root] @ localhost [127.0.0.1]  Id:    14
# Query_time: 0.001154  Lock_time: 0.000069 Rows_sent: 1498  Rows_examined: 1498
use arguse;
SET timestamp=1551262482;
select * from caseall;

第1行，记录慢日志的时间
第2行，很明显不多解释
第3行，是整个语句的query time, Lock time, 返回或者发送了多少行， 执行的行数
第4行，是语句真正发生的时间
第5行，具体语句

通用日志

  • 作用：会记录数据库所有的操作
  • 基本上是不会开启的，开启性能下降明显
  • 可以将日志保存到表mysql.general_log
> show variables like 'gene%';
+------------------+---------------------------------------------------+
| Variable_name    | Value                                             |
+------------------+---------------------------------------------------+
| general_log      | OFF                                               |
| general_log_file | /home/ocean/workspace/mysql/mysql-data/ubuntu.log |
+------------------+---------------------------------------------------+

二进制日志

  • 作用：用于记录所有更改数据的语句。主要用于复制和即时点回复。默认开启
  • 查看二进制日志的工具：mysqlbinlog

1、简介

  • 二进制日志包含了所有更新了数据或者已经潜在更新了的数据(比如，没有匹配任何行的一个delete)的所有语句。语句以"事件"的形式保存，它描述数据更改。二进制日志还包含关于每个更新数据库的语句的执行时间信息。它不包含没有修改任何数据的语句。
  • 二进制日志的主要目的是在数据库存在故障时，恢复时能够最大可能的更新数据库(即时点回复)，因为二进制日志包含备份后进行的所有更新。二进制日志还用于在主复制服务器上记录所有将发送给从服务器的语句。
  • 那么二进制日志是记录执行的语句还是执行后的结果数据？

二进制表的记录时间

  • 对于非事务表的更新执行完毕之后立即保存到二进制日志中。
  • 对于事务表比如Innodb表，所有更改表的更新(INSERT，UPDATE，DELETE)被缓存起来，直到服务器接收到commot语句。在该点，执行完COMMIT之前，mysqld将整个事务写入二进制日志。当处理事务的线程启动时，它为缓冲查询分配binlog_cache_size【使用默认值即可，不要调整这个的值】大小的内存。如果语句大于该值，线程则打开临时文件来保存事务。线程结束之后临时文件被删除。

2、参数

  • log_bin
    默认“ON”，开启二进制日志，
  • log_bin_basename && log_bin_index
    | log_bin_basename | /home/ocean/workspace/mysql/mysql-data/binlog |
    | log_bin_index | /home/ocean/workspace/mysql/mysql-data/binlog.index |
    文件存储路径是：/home/ocean/workspace/mysql/mysql-data，文件名为binlog.000001，binlog.000002等等。
  • sync_binlog
    如果对业务安全性要求极高，请设置为1.
    如果开启了主从，设置为1
    默认情况下，并不是每次写入时都将二进制日志与硬盘同步。因此如果操作系统或者机器崩溃，有可能二进制日志中最后的语句丢失了。要向防止这种情况，可以设置sync_binlog（1是最安全的值，但也是最慢的），使二进制日志在每N次二进制日志写入之后与硬盘同步。
    简单的说，1就是实时写。
    备注：可以分布设置sync_binlog为0或者1，然后对建表，更新数据，然后使用show master status; 命令查询当前正在更新的日志的大小：发现当sync_binlog为1时日志实时改变大小，如果为0则需要commit提交了才能改变大小【实际上日志信息已经被记录到了缓存里面去了，直到commit才写入磁盘】。
  • max_binlog_size
    此参数限制二进制日志的最大尺寸，超过这个尺寸之后进行滚动，滚动时会创建一个新的编号大1的日志用于记录最新的日志，而原日志名字不会被改变。
    每次重启MYSQL服务，日志都会自动滚动一次。
    另外如果需要手动滚动，则使用命令：
mysql>flush logs;
  • binlog_cache_size：
    是global参数，默认32768，即32K，可选范围在[4096，4294967295]
    作用：为每隔session分配内存，在事务过程中用来存储二进制日志的缓存，可以提高记录binlog的效率。
    如何设置：一般不需要更改，具体可以参见 https://blog.csdn.net/lxpbs8851/article/details/38455223

3、解读

命令

(root@localhost) [(none)]> show binary logs;  --有哪些的二进制日志
+---------------+-----------+-----------+
| Log_name      | File_size | Encrypted |
+---------------+-----------+-----------+
| binlog.000001 |     39647 | No        |
| binlog.000002 |    647566 | No        |
| binlog.000003 |      1435 | No        |
| binlog.000004 |       178 | No        |
| binlog.000005 | 194807619 | No        |
| binlog.000006 |       155 | No        |
+---------------+-----------+-----------+


(root@localhost) [(none)]> show master status;  -- 当前正在记录使用的二进制
+---------------+----------+--------------+------------------+-------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+-------------------+
| binlog.000006 |      155 |              |                  |                   |
+---------------+----------+--------------+------------------+-------------------+

(root@localhost) [tpcc]> show binlog events in 'binlog.000006';  -- 查看这个二进制日志的内容
+---------------+-----+----------------+-----------+-------------+-------------------------------------------------------------------------+
| Log_name      | Pos | Event_type     | Server_id | End_log_pos | Info                                                                    |
+---------------+-----+----------------+-----------+-------------+-------------------------------------------------------------------------+
| binlog.000006 |   4 | Format_desc    |         1 |         124 | Server ver: 8.0.15, Binlog ver: 4                                       |
| binlog.000006 | 124 | Previous_gtids |         1 |         155 |                                                                         |
| binlog.000006 | 155 | Anonymous_Gtid |         1 |         232 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'                                    |
| binlog.000006 | 232 | Query          |         1 |         342 | use `tpcc`; create table t1(a int) /* xid=1364003 */                    |
| binlog.000006 | 342 | Anonymous_Gtid |         1 |         421 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'   

(root@localhost) [tpcc]> show binlog events in 'binlog.000006' from 769;  -- 重哪一个位置开始看 ，769为时间位置Pos

二进制日志不能直接删除的，如果使用rm删除，可能会导致数据库的崩溃。必须使用purge删除日志。但是尽量不要去删除二进制日志。

PURGE { BINARY | MASTER } LOGS
{ TO 'log_name' | BEFORE datetime_expr }

用于删除列于在指定的日志或日期之前的日志索引中的所有二进制日志。这些日志也会从记录在日志索引文件中的清单中被删除，这样被给定的日志成为第一个。

例子：

(root@localhost) [tpcc]> PURGE BINARY LOGS TO 'binlog.000004';  -- 删除000004之前的日志
 
(root@localhost) [tpcc]>PURGE BINARY LOGS BEFORE '2018-04-28 23:59:59';  -- 删除2018-04-28 23:59:59之前的日志

mysqlbinlog

binlog.00000x等不是文本文件，不能通过cat命令查看，可以使用mysqlbinlog
mysqlbinlog 是MYSQL自带的一个以用户可视的方式展示出二进制日志中的内容的命令行工具。

在进行恢复的过程中，依然会产生binlog日志，因此，我们需要临时关闭binlog日志

(root@localhost) [tpcc]> set sql_log_bin=0;  #临时关闭binlog日志

sql_log_bin是会话级别的，退出数据库之后就恢复为ON了

~/workspace/mysql/mysql-data$ mysqlbinlog binlog.000001   ## 。可能出现问题1
~/workspace/mysql/mysql-data$ mysqlbinlog binlog.000001 --start-position 39270 --stop-position 39647   ## 查看39270到39647之间发生的事件
~/workspace/mysql/mysql-data$ mysqlbinlog binlog.000001 --start-position 39270 --stop-position 39647 > 1.sql   # 可以将这个事件导出为sql语句。可能出现问题2
(root@localhost) [tpcc]> source 1.sql    -- 数据库中执行sql语句

(root@localhost) [tpcc]> set sql_log_bin=1;       # 开启

备注：
1、如果出现问题:mysqlbinlog: File ‘binlog.000003’ not found (OS errno 13 - Permission denied)
原因：权限问题
解决：

~/workspace/mysql/mysql-data$ sudo chmod +777 binlog.000001

2、出现错误：bash: 1.sql: Permission denied
原因：权限问题
解决：

~/workspace/mysql/mysql-data$ sudo chmod +777 1.sql

配置参数

当MYSQL实例启动时，数据库会先去读一个配置参数文件，用来讯在数据库的各种文件所在位置以及指定某些初始化参数。默认情况下，MYSQL实例会按照一定的顺序在指定的位置进行读取。

1、配置文件在哪里

$ /usr/local/mysql/bin/mysqld --verbose --help| grep -A 1 "Default options"  --查看MYSQL的配置文件
$/usr/local/mysql/bin/mysqld  --help -vv | grep my.cnf --查看MYSQL的配置文件
$ mysql --help --verbose | grep my.cnf  --查看MYSQL的配置文件                 
  order of preference, my.cnf, $MYSQL_TCP_PORT,
 /etc/my.cnf /etc/mysql/my.cnf/usr/local/mysql/etc/my.cnf ~/.my.cnf 
$ mysql --help --verbose | less  查看MYSQL参数默认值MYSQL配置参数

MYSQL默认根据 /etc/my.cnf ，/etc/mysql/my.cnf，/usr/local/mysql/etc/my.cnf ，~/.my.cnf 这四个文件的顺序读取配置值，如果重复的参数，后面的就覆盖前面的。

注意：原生的/etc/或者/etc/mysql/等目录下时没有my.cnf文件的，需要我们手动在/ect/等目录下创建一个my.cnf文件，然后写入配置项

还可以通过defaults-file指定默认配置文件

$ mysqld --help -vv | grep defaults-file
--defaults-file=#       Only read default options from the given file #.

2、如果查看配置参数

mysql> show variables; # 显示当前mysql的所有参数，且无隐藏参数
mysql> show variables like "max_%"; #查以max_开头的变量

不建议将慢查询日志写入表mysql.slow_log，两个原因：性能变慢，如果备份可能会将慢查询日志也一起备份了

3、配置参数的分类

1、从作用域上可以分为global和session

  • 设置全局(GLOBAL)参数
mysql> set global slow_query_log = off; #不加global，会提示错误
                                        #slow_query_log是全局参数

mysql> set slow_query_log = off;  # 下面就报错了，默认是会话参数
ERROR 1229 (HY000): Variable 'slow_query_log' is a GLOBAL variable and should be set with SET GLOBAL

mysql> set global long_query_time = 1.5;  -- 针对全局的参数，对已经创建的链接没有用，对当前会话页没有用，只会对新创建的链接有用
  • •设置会话(SESSION)参数
mysql> set session long_query_time = 1.5;  -- 设置会话级别的参数，针对当前链接的会话有效,session可以省略
mysql> show variables like 'long%time';
mysql> show global variables like 'long%time';

有些参数，即存在于GLOBAL又存在于SESSION, 比如autocommit (PS：MySQL默认是提交的)

•设置会话(SESSION)参数
mysql> set autocommit = 0;  # 当前会话生效
mysql> set session autocommit = 0;  # 当前会话生效
autocommit 只能在会话中进行修改

autocommit同样在GLOBAL中, 也有同样的参数
mysql> set global autocommit = 1; #当前实例，全局生效


注意：如果这个时候/etc/init.d/mysqld restart, 则全局的autocommit的值会变成默认值，或者依赖于my.cnf的设置值。

执行的效果如下：
mysql> show variables like "slow%"; # 原值为ON
+---------------------+----------+
| Variable_name       | Value    |
+---------------------+----------+
| slow_launch_time    | 2        |
| slow_query_log      | OFF      |
| slow_query_log_file | slow.log |
+---------------------+----------+
3 rows in set (0.00 sec)

mysql> select @@session.autocommit; # 等价于 slect @@autocomit;
+----------------------+
| @@session.autocommit |
+----------------------+
|                    0 |
+----------------------+
1 row in set (0.00 sec)

mysql> select @@global.autocommit;       
+---------------------+
| @@global.autocommit |
+---------------------+
|                   1 |
+---------------------+
1 row in set (0.00 sec)

2、从类型上可以分为可修改[动态]和只读[静态]参数

  • 用户可以在线修改非只读参数，只读参数只能通过配置文件修改并重启数据库生效

3、 所有参数的修改都不持久化

  • : 所有的在线修改过的参数(GLOBAL/SESSION)，在重启后，都会丢失，不会写如my.cnf，无法将修改进行持久化
mysql> use performance_schema
mysql> show tables like '%variable%';
+-------------------------------------------+
| Tables_in_performance_schema (%variable%) |
+-------------------------------------------+
| global_variables                          |      
| persisted_variables                       |
| session_variables                         |
| user_variables_by_thread                  |
| variables_by_thread                       |
| variables_info                            |
+-------------------------------------------+
mysql> select * from variables_by_thread where variable_name = "long_query_time";  --查看每个会话的每个变量的值
+-----------+-----------------+----------------+
| THREAD_ID | VARIABLE_NAME   | VARIABLE_VALUE |
+-----------+-----------------+----------------+
|        53 | long_query_time | 1.500000       |  
+-----------+-----------------+----------------+
mysql> SELECT connection_id(); -- 查看当前会话的ID
+-----------------+
| connection_id() |
+-----------------+
|              14 |
+-----------------+
mysql> show processlist;  --查看当前的每个会话正在干什么
+----+-----------------+-----------+--------------------+---------+------+------------------------+------------------+
| Id | User            | Host      | db                 | Command | Time | State                  | Info             |
+----+-----------------+-----------+--------------------+---------+------+------------------------+------------------+
|  4 | event_scheduler | localhost | NULL               | Daemon  | 4774 | Waiting on empty queue | NULL             |
| 14 | root            | localhost | performance_schema | Query   |    0 | starting               | show processlist |
+----+-----------------+-----------+--------------------+---------+------+------------------------+------------------+
> select * from threads where thread_id = 53 \G
*************************** 1. row ***************************
          THREAD_ID: 53
               NAME: thread/sql/one_connection
               TYPE: FOREGROUND
     PROCESSLIST_ID: 14
   PROCESSLIST_USER: root
   PROCESSLIST_HOST: localhost
     PROCESSLIST_DB: performance_schema
PROCESSLIST_COMMAND: Query
   PROCESSLIST_TIME: 0
  PROCESSLIST_STATE: statistics
   PROCESSLIST_INFO: select * from threads where thread_id = 53
   PARENT_THREAD_ID: NULL
               ROLE: NULL
       INSTRUMENTED: YES
            HISTORY: YES
    CONNECTION_TYPE: Socket
       THREAD_OS_ID: 2952
     RESOURCE_GROUP: USR_default

并发连接参数：max_connections

max_connections：允许连接到mysql最大连接数，默认151。

在这里插入图片描述
MySQL 提供了 Threads_connected 指标以记录连接的线程数——每个连接对应一个线程。通过监控该指标与先前设置的连接限制，你可以确保服务器拥有足够的容量处理新的连接。MySQL 还提供了 Threads_running 指标，帮助你分隔在任意时间正在积极处理查询的线程与那些虽然可用但是闲置的连接。

  • Threads_connected：当所有可用连接都被占用时，如果一个客户端试图连接至 MySQL，后者会返回 “Too many connections(连接数过多)”错误，同时将 Connection_errors_max_connections 的值增加。为了防止出现此类情况，你应该监控可用连接的数量，并确保其值保持在 max_connections 限制以内。
mysql> show status like '%Threads_connected%';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 1     |
+-------------------+-------+

mysql> show status like '%Threads_running%';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| Threads_running | 1     |
+-----------------+-------+

如果服务器真的达到 max_connections 限制，它就会开始拒绝新的连接。在这种情况下，Connection_errors_max_connections 指标就会开始增加，同时，追踪所有失败连接尝试的 Aborted_connects 指标也会开始增加。

  • Connection_errors_max_connections 当MySQL的最大并发数大于系统变量（show variables）中max_connections的最大并发数，因此而被拒绝的次数，将会记录在这个变量里。如果Connection_error_max_connections值比较大，则说明当前系统并发比较高，要考虑调大max_connections的值。
  • Aborted_connects：如果该计数器在不断增长，意味着用户尝试连接到数据库的努力全都失败了。此时，应该借助 Connection_errors_max_connections 与 Connection_errors_internal 之类细粒度高的指标调查该问题的根源。
  • Connection_errors_internal：只会在错误源自服务器本身时增加。内部错误可能反映了内存不足状况，或者服务器无法开启新的线程。
mysql> show status like '%Connection_errors_max_connections%';
+-----------------------------------+-------+
| Variable_name                     | Value |
+-----------------------------------+-------+
| Connection_errors_max_connections | 0     |
+-----------------------------------+-------+
1 row in set (0.00 sec)

mysql> show status like '%Aborted_connects%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Aborted_connects | 24    |
+------------------+-------+

mysql> show status like '%Connection_errors_internal%';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| Connection_errors_internal | 0     |
+----------------------------+-------+

怎么调整

监控客户端连接情况相当重要，因为一旦可用连接耗尽，新的客户端连接就会遭到拒绝。

(1) 什么时候应该调整值
如果状态变量connection_errors_max_connections不为零，并且一直在增长，就说明不断有连接请求因数据库连接数量已经到达最大的值而失败，应该考虑max_connections的值。

> show status like 'connection_errors_max_connections';
+-----------------------------------+-------+
| Variable_name                     | Value |
+-----------------------------------+-------+
| Connection_errors_max_connections | 0     |
+-----------------------------------+-------+

MySQL配置文件中max_connections值过小可能会造成”MySQL: ERROR 1040: Too many connections”，这时应该调整max_connections的大小【另一种原因是访问量过高，MySQL服务器抗不住，这个时候就要考虑增加从服务器分散读压力】

> show variables like 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 151   |
+-----------------+-------+
> show status like 'max_used_connections';  --服务器响应的最大连接数:（并发）
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 8     | --最大并发连接数8
+----------------------+-------+

max_used_connections / max_connections * 100% （理想值≈ 85%）
如果max_used_connections跟max_connections相同 那么就是max_connections设置过低或者超过服务器负载上限了，低于10%则设置过大。

  • 增加max_connections参数的值，不会占用太多系统资源。系统资源（CPU、内存）的占用主要取决于查询的密度、效率等；

(2) 注意
每一个session操作MySQL数据库表都需要占用文件描述符，数据库连接本身也要占用文件描述，因此在增大max_connections时，也要考虑open_files_limit的设置是否够用

>  show variables like 'open%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| open_files_limit | 8161  |
+------------------+-------+

open_files_limit 是mysql中的一个全局变量且不可动态修改。它控制着mysqld进程能使用的最大文件描述(FD)符数量。需要注意的是这个变量的值并不一定是你设定的值，mysqld会在系统允许的情况下尽量获取更多的FD数量。

  • MySQL无论如何都会保留一个用于管理员（SUPER）登陆的连接，用于管理员连接数据库进行维护操作，即使当前连接数已经达到max_connections。因此MySQL的实际最大可连接数为max_connections+1；
> show status like 'Connections';  --MySQL服务器的连接尝试次数（成功与否）。
> show processlist;  ##显示当前正在执行的mysql连接

并发线程池参数：thread_cache_size

> show variables like 'thread%';
+-------------------+---------------------------+
| Variable_name     | Value                     |
+-------------------+---------------------------+
| thread_cache_size | 9                         |  服务器的池中最多可以存放32个连接线程
| thread_handling   | one-thread-per-connection |
| thread_stack      | 286720                    | 为每个线程分配280K内存空间
+-------------------+---------------------------+
  • thread_cache_size 设置连接线程缓存的数目。这个缓存相当于MySQL线程的缓存池（thread cache pool）,将空闲的连接线程放入连接池中缓存起来，而非立即销毁。当有新的连接请求时，如果连接池中有空闲的连接，则直接使用。否则要重新创建线程。创建线程是一个不小的系统开销。这个参数和物理内存由关系：
    1G —> 8
    2G —> 16
    3G —> 32
    3G —> 64
  • thread_stack stack 是堆的意思，知道进程和线程都是有唯一的ID的，进程的ID系统会维护，二线程的ID,则由具体的线程库区维护，当进程或者线程休眠的时候，进程的上下文信息要在内存中开辟出一块区域，保存进程的上下文信息，以便于迅速唤醒程序。默认为MySQL的每个线程设置的堆栈大小为：286720 /1024=280K，一般不用动
  • thread_handling 默认值是： one-thread-per-connection 表示为每个连接提供或者创建一个线程来处理请求，直至请求完毕，连接销毁或者存入缓存池。当值是no-threads 时，表示在始终只提供一个线程来处理连接，一般是单机做测试使用的。
>  show status like 'Threads%';  --查看线程状态信息
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_cached    | 2     |   mysql管理的线程池中还有多少可以被复用的资源
| Threads_connected | 6     |  已经打开的连接数，Threads_connected 跟show processlist结果相同
| Threads_created   | 8     |  表示创建过的线程数，如果发现Threads_created值过大的话，表明MySQL服务器一直在创建线程，这也是比较耗资源，可以适当增加配置文件中thread_cache_size值，查询服务器
| Threads_running   | 2     | 正在运行的连接数，这个数值一般远低于connected数值，准确的来说，Threads_running是代表当前并发数
+-------------------+-------+
> show variables like 'thread_cache_size';  --如果我们在MySQL服务器配置文件中设置了thread_cache_size，当客户端断开之后，服务器处理此客户的线程将会缓存起来以响应下一个客户而不是销毁(前提是缓存数未达上限)。
  • thread_cache命中率公式为:这个结果越大越好，最好不要小于90%，如果小了最改动thread_cache_size
>Thread_connected = SHOW GLOBAL STATUS LIKE Thread_created;
> Connections = SHOW GLOBAL STATUS LIKE 'Connections';
Thread_Cache_Hit=(1 - (Threads_created / Connections)) * 100

突发参数之back_log

  • MySQL在很短的时间内，突然收到很多的连接请求时，MySQL会将不能来得及处理的连接请求保存在堆栈中，以便MySQL后续处理。back_log参数设置了堆栈的大小.
  • 如果需要在较短时间内处理大量请求，应该考虑适当增大back_log的值
> show variables like 'back_log';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| back_log      | 151   |
+---------------+-------+


> show status like 'Aborted%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Aborted_clients  | 9     |   --MySQL 客户机被异常关闭的次数。
| Aborted_connects | 2     |   --试图连接到MySQL服务器而失败的连接次数。
----------------------------

$  show status like 'Slow%'; 
Slow_lunch_threads 创建线程的时间过长，超过slow_launch_time的设定值，则会记录。

$ show status like 'Connection_error%';   --来查看连接的错误状态信息：
Connection_errors_peer_address 查找MySQL客户机IP地址是发生的错误数。

参考：https://blog.csdn.net/jiekou0376/article/details/80527046
https://blog.csdn.net/h106140873/article/details/78852185
https://blog.csdn.net/bzfys/article/details/48161021
http://www.gaodaima.com/19263.html
https://segmentfault.com/a/1190000005726466
https://blog.csdn.net/wangpeng198688/article/details/51682732

OceanStar的学习笔记
关注
专栏目录
MySQL管理之日志详解
weixin_33701564的博客
04-01 120
MySQL日志详解错误日志MySQL的错误信息是在data目录下的错误日志本身所定义的内容本身是可以定义的编辑配置文件，定义错误日志：    log-error=/path/to/xx.err       #定义是否启动错误日志的功能    log-warnings={1|0}              #定义是否将警告信息也记录在错误日志中而默认情况下错误日志也记录以下几个方面的消息：1、服务器...
mysql日志记录方式比较
donghaixiaolongwang的博客
03-06 1166
mysql中binlog_format模式与配置详解 www.111cn.net 编辑:kp878 来源:本站整理 mysql复制主要有三种方式：基于SQL语句的复制(statement-based replication, SBR)，基于行的复制(row-based replication, RBR)，混合模式复制(mixed-based replication, MBR)。对应的，
mysql配置文件配置参数详细说明
qq_27233977的博客
08-29 602
很多人对mysql的配置文件怎么配置不了解，windows下配置文件叫my.ini,linux下叫my.cnf,关于配置文件的路径，根据安装方式不同，通常 不一样，windows下可以安装 everything 进行检索（做技术的基本上都知道）,linux下直接有检索命令 find，所以这里对路径不直接给出避免误导。配置文件里一般都带英文解释，大体看看其实还是能看懂的。如果只是自己用，基本上不需要改。
mysql数据库日志binlog保存时效（expire_logs_days）
lihongbao80的专栏
11-23 2万+
一、设置语法 -- mysql8.0以下版本查看当前数据库日志binlog保存时效 以天为单位，默认0 永不过期，最多只能设置99天 show variables like 'expire_logs_days'; set global expire_logs_days=60; -- mysql8.0以上版本通过设置全局参数binlog_expire_logs_seconds修改binlog保存时间 以秒为单位；默认2592000 30天 14400 4小时；86400 1天；259200 3天
二进制日志的保存时间参数binlog_expire_logs_seconds和expire_logs_days的设置
姚远OracleACE的博客
12-15 3499
在MySQL 8.0中，默认的二进制日志的保存时间参数binlog_expire_logs_seconds和expire_logs_days的设置如下 mysql> show variables like '%expire_log%'; +----------------------------+---------+ | Variable_name | Value | +----------------------------+---------+ | binlog_ex
MySql的配置文件
youhebuke225的博客
04-10 4395
用于放置一些可执行文件，如 mysql.exe、mysqld.exe、mysqlshow.exe 等mysqld:这个可执行文件就代表着 MySOL 服务器程序，运行这个可执行文件就可以直接启动一个服务器进程。但这个命令不常用。mysqld_safe:mysqld safe是一个启动脚本，它会间接地调用 mysqld，而且还顺便启动了另外一个监控进程，这个监控进程在服务器进程挂了的时候，可以帮助重启它。
MYSQL配置参数优化详解
09-09
MySQL配置参数优化是数据库性能提升的关键环节，涉及到多个方面，包括连接管理、缓冲区管理和查询缓存等。以下是对这些关键参数的详细说明： 1. **最大连接数**（`max_connections`）：这个参数决定了MySQL可以同时...
MySQL配置文件my.cnf参数优化和中文详解
09-10
总之，MySQL配置文件my.cnf的参数优化是一项涉及多方面考虑的工作，需要综合分析并适时调整，以适应不断变化的业务需求。正确的参数设置能够显著提升MySQL服务器的性能，降低延迟，增强系统的可扩展性。
mysql优化配置参数
09-11
MySQL的优化配置是提高数据库性能的关键步骤，尤其...但要注意，每个配置参数的调整都需要根据实际应用负载和服务器硬件资源来平衡，过度优化可能会带来反效果。建议在调整后进行性能测试，并持续监控MySQL的运行状态。
MySQL：跨平台管理与高级特性的全面指南
最新发布
11-05
本文详细介绍了MySQL数据库的各个方面，包括基础知识、安装与配置、SQL语言基础、数据类型与表设计、用户权限管理、数据库备份与恢复、数据导入与导出、性能优化、存储过程与函数、触发器、视图、事务处理、数据加密...
MySQL DBA教程：Mysql性能优化之缓存参数优化
12-15
本教程将聚焦于MySQL的缓存参数优化，旨在通过调整相关参数，最大化利用内存资源，减少磁盘IO，从而提升数据库性能。 首先，我们关注`query_cache_size`和`query_cache_type`。Query Cache是MySQL为SELECT语句提供...
MySQL配置文件my.ini详解
热门推荐
顺其自然~专栏
05-25 3万+
其实大体可以分为两部分：客户端的参数、服务器参数。其中服务器参数里还包括 InnoDB存储引擎参数。
Mysql 配置篇
右见小栈
12-03 1万+
13.《配置文件》 mysql允许远程链接 mysql默认使用的端口是3306，，默认root的权限是本地连接 所以第一步 将 端口 开放；第二步 将root权限开放； 这里重点介绍 将root权限开放 修改 配置文件 的 默认本地链接 项 sudo vim /etc/mysql/mysql.conf.d/mysqld.cnf 将bind-address = 127.0.0.1注销(前面加#号)​ 开放root权限 mysql -u root -p <回车> update
了解MySQL配置文件：位置、结构和选项
qq_28245087的博客
06-25 6022
MySQL配置文件是一个关键工具，用于管理和配置MySQL服务器。通过了解配置文件的位置、结构和常用选项，您可以根据特定需求调整服务器的行为和属性。在配置MySQL服务器时，务必熟悉配置文件的各个方面。
MySQL配置文件配置
m0_67401660的博客
06-08 599
本文主要介绍MySQL配置文件（my.cnf）虚拟机环境：VirtualBox 6.0.24 操作系统：Oracle Linux Server release 6.5 x86_64 MySQL版本：5.7.33确定MySQL的配置文件路径 my.cnf配置文件说明 默认配置文件查看： [mysqld]、[client]，这些中括号代表的是组。“组”是要为其设置选项的程序或组的名称。在组行之后，任何选项设置行都将应用于命名组，直到选项文件的末尾或给出另一个组行。选项组名不区分大小写。[mysqld]和[m
【八】MySQL-配置文件详解
作者：大头兵（kit）
04-22 2024
2.如果要配置bind-address的话，这个localhost不能修改，否则在初始化数据库(执行/opt/cloudera/cm/schema/scm_prepare_database.sh mysql cm cm password)时便会报错，如果/etc/my.cnf中配置了bind-address=localhost 的话，那么在CDH的安装页面中，配置连接数据库的主机名称必须为localhost。# 跳过客户端域名解析；当新的客户连接mysqld时，mysqld创建一个新的线程来处理请求。
my.cnf mysql配置文件
【轰炸机】的博客
04-22 5551
my.cnfmy.cnf 文件基础参数 character_set 乱码 忘记密码 my.cnf文件 [mysqld] port=3306 basedir=/usr/local/mysql datadir=/mydata/mysql/data socket=/mydata/mysql/mysql.sock pid-file=/mydata/mysql/mysql.pid log-error=/mydata/...
mysql数据库配置(my.ini|my.cnf)文件参数详细介绍
睡不醒的每天
05-10 1998
【代码】mysql数据库配置(my.ini|my.cnf)文件参数详细介绍。
MySQL 解压版/免安装版配置
weixin_34194317的博客
08-14 467
建立my.ini [mysqld] # 设置mysql的安装目录 basedir=F:\\Program Files\\MySQL # 设置mysql数据库的数据的存放目录，必须是data，或者是\\xxx-data datadir=F:\\Program Files\\MySQL\\data # 设置mysql服务器的字符集，默认编码 default-characte...
MySQL服务器参数优化：核心配置与建议
MySQL服务器端参数详解和优化是数据库管理中的关键环节，这些参数直接影响着数据库的性能、稳定性和安全性。以下是对部分核心参数的详细说明和优化建议： 1. `lower_case_table_names`： 这个参数决定了MySQL如何...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值