MySQL-四大类日志

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介: MySQL-四大类日志

     MySQL日志记录了MySQL数据库日常操作和错误信息。MySQL有不同类型的日志文件(各自存储了不同类型的日志),从日志当中可以查询到MySQL数据库的运行情况、用户的操作、错误的信息等。

MySQL日志分为4大类

  1. 错误日志:记录mysql服务的启动,运行或停止mysql服务时出现的问题
  2. 查询日志:记录建立的客户端的连接和执行的语句
  3. 二进制日志:记录所有更改数据的语句,可以用于数据的复制
  4. 慢查询日志:记录所有执行的时间超过long_query_time的所有查询或不使用索引的查询默认情况下,所有日志创建与MySQL数据目录中,通过刷新日志,可以强制MySQL关闭和重新打开日志文件,Flush logs刷新日志或者执行mysqladmin flush-logs 如果正使用MySQL复制功能,在复制服务器上可以维护更多日志文件,这种日志我们称为接替日志。启动日志功能会降低MySQL数据库的性能。

错误日志

       在mysql数据库中,错误日志功能是默认开启的。默认情况下,错误日志存储在mysql数据库的数据目录中。错误日志文件通常的名称为hostname.err。其中,hostname表示服务器主机名。 错误日志信息可以自己进行配置的,错误日志所记录的信息是可以通过log-error和log-warnings来定义的,其中log-error是定义是否启用错误日志的功能和错误日志的存储位置,log-warnings是定义是否将警告信息也定义至错误日志中。

       默认情况下错误日志大概记录以下几个方面的信息:服务器启动和关闭过程中的信息(未必是错误信息,如mysql如何启动InnoDB的表空间文件的、如何初始化自己的存储引擎的等等)、服务器运行过程中的错误信息、事件调度器运行一个事件时产生的信息、在从服务器上启动服务器进程时产生的信息 注1:MySQL有很多系统变量可以设置,系统变量设置不同,会导致系统运行状态的不同。因此mysql提供两组命令,分别查看系统设置和运行状态。

1、查看系统设置:

1. SHOW [GLOBAL | SESSION] VARIABLES [like_or_where] 
2. SHOW VARIABLES: shows the values of MySQL system variables.

2、运行状态:

1. SHOW [GLOBAL | SESSION] STATUS [like_or_where] 
2. SHOW STATUS: provides server status information.

修改系统配置

方法1:配置文件设置my.cnf 如:binlog_cache_size = 1M

方法2:set global binlog_cache_size = 1048576;

注:查看mysql的版本

1. [root@localhost ~]# mysql -V
2. mysql  Ver 14.14 Distrib 5.7.40, for linux-glibc2.12 (x86_64) using  EditLine wrapper

1. mysql> status;
2. --------------
3. mysql  Ver 14.14 Distrib 5.7.40, for linux-glibc2.12 (x86_64) using  EditLine wrapper
4. 
5. Connection id:      11
6. Current database:   
7. Current user:       root@localhost
8. SSL:            Not in use
9. Current pager:      stdout
10. Using outfile:      ''
11. Using delimiter:    ;
12. Server version:     5.7.40 MySQL Community Server (GPL)
13. Protocol version:   10
14. Connection:     Localhost via UNIX socket
15. Server characterset:    latin1
16. Db     characterset:    latin1
17. Client characterset:    utf8
18. Conn.  characterset:    utf8
19. UNIX socket:        /tmp/mysql.sock
20. Uptime:         87 days 2 hours 22 min 4 sec
21. 
22. Threads: 1  Questions: 61  Slow queries: 0  Opens: 114  Flush tables: 1  Open tables: 107  Queries per second avg: 0.000
23. --------------

1. mysql> select version();
2. +-----------+
3. | version() |
4. +-----------+
5. | 5.7.40    |
6. +-----------+
7. 1 row in set (0.00 sec)

一般而言,日志级别的定义没有会话变量都只是在全局级别下进行定义 错误日志的状态:

1. mysql> show global variables like '%log_error%';
2. +---------------------+---------------------------------+
3. | Variable_name       | Value                           |
4. +---------------------+---------------------------------+
5. | binlog_error_action | ABORT_SERVER                    |
6. | log_error           | /usr/local/mysql/data/mysql.log |
7. | log_error_verbosity | 3                               |
8. +---------------------+---------------------------------+
9. 3 rows in set (0.00 sec)

其中 log_error定义为错误日志文件路径 log_error_verbosity:

verbosity value message types logged
1 errors only
2 errors and warnings
3 errors,warinigs,and notes(default)

更改错误日志位置可以使用log-error来设置形式如下

1. [root@localhost ~]# vim /etc/my.cnf
2. log-error = /usr/local/mysql/data/mysqld.err

查看mysql错误日志

[root@localhost ~]# tail /usr/local/mysql/data/mysqld.err

       为了方便维护需要,有时候会希望将错误日志中的内容做备份并重新开始记录,这时候就可以利用MySQL 的FLUSH LOGS 命令来告诉MySQL 备份旧日志文件并生成新的日志文件。备份文件名以“.old”结尾。

删除错误日志:

       在mysql5.5.7之前:数据库管理员可以删除很长时间之前的错误日志,以保证mysql服务器上的硬盘空间。mysql数据库中,可以使用mysqladmin命令开启新的错误日志。mysqladmin命令的语法如下:mysqladmin –uroot –p flush-logs也可以登录mysql数据库中使用FLUSH LOGS语句来开启新的错误日志。

       在mysql5.5.7之后:服务器将关闭此项功能。只能使用重命名原来的错误日志文件,手动冲洗日志创建一个新的:方式如下:

1. [root@localhost ~]# cd /usr/local/mysql/data/
2. [root@localhost data]# mv mysqld.err mysql.bak
3. [root@localhost data]# mysqladmin -uroot -p flush-logs
4. Enter password:    #输入root密码

更多信息请查阅官方文档:

MySQL :: MySQL 8.0 Reference Manual :: 5.4.2 The Error Log

MySQL :: MySQL 8.0 Reference Manual :: 5.4.2 The Error Log

MySQL :: MySQL 5.7 Reference Manual :: 5.4.2 The Error Log

二进制日志

       主要记录MySQL数据库的变化,二进制日志以一种有效的格式,并且是事务安全的方式包含更新日志中可用的信息。二进制日志包含了所有更新了数据或者已经潜在更新了数据。二进制日志还包含关于每个更新数据库的语句的执行时间,它不包含没有修改任何数据的语句。使用二进制日志的主要目的是最大可能地恢复数据库。启动二进制日志,默认情况下二进制日志是关闭的 编辑配置文件My.ini 或my.cnf

1. [root@localhost ~]# vim /etc/my.cnf
2. [mysqld]
3. log_bin=my-bin       //二进制日志[路径[指定日志文件的名字]]
4. Expire_logs_days = 10                  //清除日志的天数
5. Max_binlog_size = 100M                   //单个日志文件的大小限制,超出会新建一个默认为1GB
6. server_id=1                        //mysql5.7版本以后需要添加serverid
7. [root@localhost ~]# service mysqld restart

Show variables 或show variables like 'log_%'; 语句来查询日志设置

1. mysql> show variables like 'log_bin%';
2. +---------------------------------+------------------------------------+
3. | Variable_name                   | Value                              |
4. +---------------------------------+------------------------------------+
5. | log_bin                         | ON                                 |
6. | log_bin_basename                | /usr/local/mysql/data/my-bin       |
7. | log_bin_index                   | /usr/local/mysql/data/my-bin.index |
8. | log_bin_trust_function_creators | OFF                                |
9. | log_bin_use_v1_row_events       | OFF                                |
10. +---------------------------------+------------------------------------+
11. 5 rows in set (0.00 sec)

查看二进制日志

       MySQL二进制日志存储了所有的变更信息,MySQL二进制日志经常使用。当MySQL创建二进制日志文件时,首先创建一个以’filename’为名称,以’.index’为后缀的文件;在创建一个以’filename’为名称,以’.000001’为后缀的文件。当MySQL服务重启一次,以’.000001’为后缀的文件会增加一个,并且后缀名加1递增。如果日志长度超过max_binlog_size的上限,也会创建一个新的日志。 Show binary logs;可以查看当前的二进制日志文件个数及其文件名。二进制日志并不能直接查看,如果想要查看日志内容,可以通过mysqlbinlog命令查看。

1. mysql> show binary logs;
2. +---------------+-----------+
3. | Log_name      | File_size |
4. +---------------+-----------+
5. | my-bin.000001 |       154 |
6. +---------------+-----------+
7. 1 row in set (0.00 sec)

或者

1. mysql> show master logs;
2. +---------------+-----------+
3. | Log_name      | File_size |
4. +---------------+-----------+
5. | my-bin.000001 |       154 |
6. +---------------+-----------+
7. 1 row in set (0.00 sec)

查看二制日志的内容 退出mysql在命令行

1. [root@mysql ~]# mysqlbinlog myusql-bin.000001
2. /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
3. /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
4. DELIMITER /*!*/;
5. mysqlbinlog: File 'myusql-bin.000001' not found (Errcode: 2 - No such file or directory)
6. SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
7. DELIMITER ;
8. # End of log file
9. /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
10. /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

删除二进制日志

       MySQL的二进制文件可以配置自动删除,同时MySQL提供了手动删除二进制文件的方法:

       RESET MASTER 删除所有的二进制日志文件;PURGE MASTER LOGS只删除部分二进制日志文件。 Resetmaster; 删除所有二进制日志 Purge master logs to ‘二进制名’ 删除单个二进制日志之前的

语法格式:

1. PURGE { BINARY | MASTER } LOGS {
2.     TO 'log_name'
3.   | BEFORE datetime_expr
4. }

例:

1. mysql> purge master logs to 'my-bin.000001';
2. Query OK, 0 rows affected (0.02 sec)
3. 
4. mysql> purge master logs before '20230101';      #删除指定日期之前的日志
5. Query OK, 0 rows affected, 1 warning (0.02 sec)

暂时停止二进制日志的功能

       如果MySQL的配置文件已经启动了二进制日志,MySQL会一直记录二进制日志,修改配置文件,可以停止二进制日志,但是需要重启MySQL数据库。MySQL提供了暂时停止二进制日志的功能,通过SET SQL_LOG_BIN语句可以使MySQL暂时停止二进制

1. mysql> set sql_log_bin=1;      #0暂停 1恢复
2. Query OK, 0 rows affected (0.00 sec)

事务日志(或称redo日志)

       事务日志(InnoDB特有的日志)可以帮助提高事务的效率。使用事务日志,存储引擎在修改表的数据时只需要修改其内存拷贝,再把修改行为记录到持久在硬盘上的事务日志中,而不用每次都将修改的数据本身持久到磁盘。事务日志采用追加的方式,因此写日志的操作是磁盘上一小块区域内的顺序I/O,而不像随机I/O需要在磁盘的多个地方移动磁头,所以采用事务日志的方式相对来说要快得多。事务日志持久以后,内存中被修改的数据在后台可以慢慢的刷回到磁盘。目前大多数的存储引擎都是这样实现的。 如果数据的修改已经记录到事务日志并持久化,但数据本身还没有写回磁盘,此时系统崩溃,存储引擎在重启时能够自动恢复这部分修改的数据。具有的恢复方式则视存储引擎而定。

查看事务日志的定义:

1. mysql> show global variables like '%log%';
2. #省略部分内容
3. | innodb_flush_log_at_timeout                | 1 
4. | innodb_flush_log_at_trx_commit             | 1 
5. | innodb_locks_unsafe_for_binlog             | OFF                  
6. | innodb_log_buffer_size                     | 16777216            
7. | innodb_log_checksums                       | ON                  
8. | innodb_log_compressed_pages                | ON                  
9. | innodb_log_file_size                       | 50331648          #日志文件大小  
10. | innodb_log_files_in_group                  | 2                 # DB中设置几组事务日志,默认是2   
11. | innodb_log_group_home_dir                  | ./        #定义innodb事务日志组的位置,此位置设置默认为MySQL的datadir
12. #省略部分内容
13. 每个事务日志都是大小为50兆的文件(不同版本的mysql有差异): 在mysql中默认以ib_logfile0,ib_logfile1名称存在

       innodb_flush_log_at_trx_commit # 在事务提交时innodb是否同步日志从缓冲区到文件中,当这个值为1(默认值)之时,在每个事务提交时,日志缓冲被写到日志文件,对日志文件做到磁盘操作的刷新,性能会很差造成大量的磁盘I/O但这种方式最安全;如果设为2,每次提交事务都会写日志,但并不会执行刷的操作。每秒定时会刷到日志文件。要注意的是,并不能保证100%每秒一定都会刷到磁盘,这要取决于进程的调度。每次事务提交的时候将数据写入事务日志,而这里的写入仅是调用了文件系统的写入操作,而文件系统是有 缓存的,所以这个写入并不能保证数据已经写入到物理磁盘。设置为0,日志缓冲每秒一次地被写到日志文件,并且对日志文件做到磁盘操作的刷新,但是在一个事务提交不做任何操作。

注:刷写的概念

       刷写其实是两个操作,刷(flush)和写(write),区分这两个概念是很重要的。在大多数的操作系统中,把Innodb的log buffer(内存)写入日志(调用系统调用write),只是简单的把数据移到操作系统缓存中,操作系统缓存同样指的是内存。并没有实际的持久化数据。所以,通常设为0和2的时候,在崩溃或断电的时候会丢失最后一秒的数据,因为这个时候数据只是存在于操作系统缓存。之所以说“通常”,可能会有丢失不只1秒的数据的情况,比如说执行flush操作的时候阻塞了。

总结

       设为1当然是最安全的,但性能页是最差的(相对其他两个参数而言,但不是不能接受)。如果对数据一致性和完整性要求不高,完全可以设为2,如果只最求性能,例如高并发写的日志服务器,设为0来获得更高性能

慢查询日志:slow query log

       顾名思义,慢查询日志中记录的是执行时间较长的query,也就是我们常说的slow query。 慢查询日志采用的是简单的文本格式,可以通过各种文本编辑器查看其中的内容。其中 记录了语句执行的时刻,执行所消耗的时间,执行用户,连接主机等相关信息。 慢查询日志的作用: 慢查询日志是用来记录执行时间超过指定时间的查询语句。通过慢查询日志,可以查找出哪些查询语句的执行效率很低,以便进行优化。一般建议开启,它对服务器性能的影响微乎其微,但是可以记录mysql服务器上执行了很长时间的查询语句。可以帮助我们定位性能问题的。MySQL 还提供了专门用来分析满查询日志的工具程序mysqldumpslow,用来帮助数据库管理人员解决可能存在的性能问题。

查看慢查询日志的定义:

1. mysql> show global variables like '%slow_query_log%';
2. +---------------------+--------------------------------------+
3. | Variable_name       | Value                                |
4. +---------------------+--------------------------------------+
5. | slow_query_log      | OFF                                  |
6. | slow_query_log_file | /usr/local/mysql/data/mysql-slow.log |
7. +---------------------+--------------------------------------+
8. 2 rows in set (0.01 sec)
9. 
10. mysql> show global variables like '%long%';
11. +----------------------------------------------------------+-----------+
12. | Variable_name                                            | Value     |
13. +----------------------------------------------------------+-----------+
14. | long_query_time                                          | 10.000000 |
15. | performance_schema_events_stages_history_long_size       | 10000     |
16. | performance_schema_events_statements_history_long_size   | 10000     |
17. | performance_schema_events_transactions_history_long_size | 10000     |
18. | performance_schema_events_waits_history_long_size        | 10000     |
19. +----------------------------------------------------------+-----------+
20. 5 rows in set (0.00 sec)

启动和设置慢查询日志:

方法1:通过配置文件my.cnf开启慢查询日志:

注:在不同的mysql版本中,开启慢查询日志参数不太一样,不过都可以通过 show variables like "%slow%" 和show variables like "%long%"查看出来。

1. mysql> show global variables like '%slow%';
2. +---------------------------+--------------------------------------+
3. | Variable_name             | Value                                |
4. +---------------------------+--------------------------------------+
5. | log_slow_admin_statements | OFF                                  |
6. | log_slow_slave_statements | OFF                                  |
7. | slow_launch_time          | 2                                    |
8. | slow_query_log            | OFF                                  |
9. | slow_query_log_file       | /usr/local/mysql/data/mysql-slow.log |
10. +---------------------------+--------------------------------------+
11. 5 rows in set (0.00 sec)

       其中: slow_query_log: off关闭状态 on开启状态 slow_query_log_file 慢查询日志存放地点 long_query_time选项来设置一个时间值,时间以秒为单位,可以精确到微秒。如果查询时间超过了这个时间值(默认为10秒),这个查询语句将被记录到慢查询日志中, 设置为0的话表示记录所有的查询。 slow_launch_time 表示如果建立线程花费了比这个值更长的时间,slow_launch_threads 计数器将增加 注:如果不指定存储路径,慢查询日志默认存储到mysql数据库的数据文件下,如果不指定文件名,默认文件名为hostname-slow.log 修改my.cnf文件:

1. [mysqld]
2. slow_query_log=1
3. slow_query_log_file=/usr/local/mysql/data/mysql-slow.log
4. long_query_time=1
5. slow_launch_time=1
6. #重启mysqld服务 再次查询慢查询日志定义

方法2:通过登录mysql服务器直接定义,方式如下:

1. mysql> set global slow_query_log=1;    #开启慢查询日志
2. Query OK, 0 rows affected (0.00 sec)
3. 
4. mysql> set session long_query_time=0.0001;   #更改时间(当前session中,退出则重置)
5. 
6. 
7. Query OK, 0 rows affected (0.00 sec)
8. 
9. mysql> set global long_query_time=0.0001;    #更改时间(全局中,重启服务则重置)
10. Query OK, 0 rows affected (0.00 sec)
11. 
12. mysql> show variables like 'long%';     #查询定义时间
13. +-----------------+----------+
14. | Variable_name   | Value    |
15. +-----------------+----------+
16. | long_query_time | 0.000100 |
17. +-----------------+----------+
18. 1 row in set (0.00 sec)

查看慢查询日志

[root@mysql ~]# cat /usr/local/mysql/data/mysql-slow.log

       用系统查看文件内容命令如cat直接查看慢日志文件第一行表示记录日志时的时间。其格式是 YYYY-MM-DD HH:MM:SS。我们可以看出上面的查询记录于 2016 年8 月 29 日下午 15:47:24 - 注意:这个是服务器时间. MySql 用户、服务器以及主机名第三行表示总的查询时间、锁定时间、"发送"或者返回的行数 Query_time: 0.000304 表示用了0.000304秒 Lock_time: 0.000128 表示锁了0.000128秒 Rows_sent: 4 表示返回4行 Rows_examined: 4 表示一共查了4行 SET timestamp=UNIXTIME; 这是查询实际发生的时间 何将其变成一个有用的时间,将 Unix 时间转成一个可读的时间,可以使用 date –d@日志中的时间戳以看到查询进行的同时记录了该日志 ,但是对于一台超负载的服务器常常并非如此。因此记住:SETtimestamp= value 才是实际的查询的执行时间。

       慢查询分析mysqldumpslow 们可以通过打开log文件查看得知哪些SQL执行效率低下。从日志中,可以发现查询时间超过long_query_time时间的query为慢查询,而小于long_query_time时间的没有出现在此日志中。 如果慢查询日志中记录内容很多,可以使用mysqldumpslow工具(MySQL客户端安装自带)来对慢查询日志进行分类汇总。mysqldumpslow对日志文件进行了分类汇总,显示汇总后摘要结果 进入log的存放目录,运行

[root@mysql ~]# mysqldumpslow /usr/local/mysql/data/mysql-slow.log

       注: mysqldumpslow -s c -t 10 /database/mysql/slow-query.log 这会输出记录次数最多的10条SQL语句,其中: -s, 是表示按照何种方式排序,c、t、l、r分别是按照记录次数、时间、查询时间、返回的记录数来排序,ac、at、al、ar,表示相应的倒序; -t, 是top n的意思,即为返回前面多少条的数据; -g, 后边可以写一个正则匹配模式,大小写不敏感的;

       例如: /path/mysqldumpslow -s r -t 10/database/mysql/slow-log 得到返回记录集最多的10个查询。/path/mysqldumpslow -s t -t 10 -g “left join” /database/mysql/slow-log 得到按照时间排序的前10条里面含有左连接的查询语句。


相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
25天前
|
存储 缓存 关系型数据库
MySQL事务日志-Redo Log工作原理分析
事务的隔离性和原子性分别通过锁和事务日志实现,而持久性则依赖于事务日志中的`Redo Log`。在MySQL中,`Redo Log`确保已提交事务的数据能持久保存,即使系统崩溃也能通过重做日志恢复数据。其工作原理是记录数据在内存中的更改,待事务提交时写入磁盘。此外,`Redo Log`采用简单的物理日志格式和高效的顺序IO,确保快速提交。通过不同的落盘策略,可在性能和安全性之间做出权衡。
1599 14
|
27天前
|
SQL 存储 关系型数据库
Mysql主从同步 清理二进制日志的技巧
Mysql主从同步 清理二进制日志的技巧
22 1
|
29天前
|
关系型数据库 MySQL 数据库
DZ社区 mysql日志清理 Discuz! X3.5数据库可以做定期常规清理的表
很多站长在网站日常维护中忽略了比较重要的一个环节,就是对于数据库的清理工作,造成数据库使用量增加必须多的原因一般有2个:后台站点功能开启了家园,此功能现在很少有论坛会用到,但是灌水机会灌入大量垃圾信息致使站长长时间未能发觉;再有就是程序默认的一些通知类表单会存放大量的、对于网站日常运行并无意义的通知信息。
49 2
|
12天前
|
存储 关系型数据库 MySQL
MySQL中的Redo Log、Undo Log和Binlog:深入解析
【10月更文挑战第21天】在数据库管理系统中,日志是保障数据一致性和完整性的关键机制。MySQL作为一种广泛使用的关系型数据库管理系统,提供了多种日志类型来满足不同的需求。本文将详细介绍MySQL中的Redo Log、Undo Log和Binlog,从背景、业务场景、功能、底层实现原理、使用措施等方面进行详细分析,并通过Java代码示例展示如何与这些日志进行交互。
15 0
|
2月前
|
关系型数据库 MySQL Python
mysql之python客户端封装类
mysql之python客户端封装类
|
2月前
|
设计模式 SQL 安全
PHP中的设计模式:单例模式的深入探索与实践在PHP的编程实践中,设计模式是解决常见软件设计问题的最佳实践。单例模式作为设计模式中的一种,确保一个类只有一个实例,并提供全局访问点,广泛应用于配置管理、日志记录和测试框架等场景。本文将深入探讨单例模式的原理、实现方式及其在PHP中的应用,帮助开发者更好地理解和运用这一设计模式。
在PHP开发中,单例模式通过确保类仅有一个实例并提供一个全局访问点,有效管理和访问共享资源。本文详细介绍了单例模式的概念、PHP实现方式及应用场景,并通过具体代码示例展示如何在PHP中实现单例模式以及如何在实际项目中正确使用它来优化代码结构和性能。
43 2
|
2月前
|
存储 运维 监控
超级好用的C++实用库之日志类
超级好用的C++实用库之日志类
36 0
|
3月前
|
API C# 开发框架
WPF与Web服务集成大揭秘:手把手教你调用RESTful API,客户端与服务器端优劣对比全解析!
【8月更文挑战第31天】在现代软件开发中,WPF 和 Web 服务各具特色。WPF 以其出色的界面展示能力受到欢迎,而 Web 服务则凭借跨平台和易维护性在互联网应用中占有一席之地。本文探讨了 WPF 如何通过 HttpClient 类调用 RESTful API,并展示了基于 ASP.NET Core 的 Web 服务如何实现同样的功能。通过对比分析,揭示了两者各自的优缺点:WPF 客户端直接处理数据,减轻服务器负担,但需处理网络异常;Web 服务则能利用服务器端功能如缓存和权限验证,但可能增加服务器负载。希望本文能帮助开发者根据具体需求选择合适的技术方案。
126 0
|
3月前
|
C# Windows 监控
WPF应用跨界成长秘籍:深度揭秘如何与Windows服务完美交互,扩展功能无界限!
【8月更文挑战第31天】WPF(Windows Presentation Foundation)是 .NET 框架下的图形界面技术,具有丰富的界面设计和灵活的客户端功能。在某些场景下,WPF 应用需与 Windows 服务交互以实现后台任务处理、系统监控等功能。本文探讨了两者交互的方法,并通过示例代码展示了如何扩展 WPF 应用的功能。首先介绍了 Windows 服务的基础知识,然后阐述了创建 Windows 服务、设计通信接口及 WPF 客户端调用服务的具体步骤。通过合理的交互设计,WPF 应用可获得更强的后台处理能力和系统级操作权限,提升应用的整体性能。
98 0
|
24天前
|
XML JSON Java
Logback 与 log4j2 性能对比:谁才是日志框架的性能王者?
【10月更文挑战第5天】在Java开发中,日志框架是不可或缺的工具,它们帮助我们记录系统运行时的信息、警告和错误,对于开发人员来说至关重要。在众多日志框架中,Logback和log4j2以其卓越的性能和丰富的功能脱颖而出,成为开发者们的首选。本文将深入探讨Logback与log4j2在性能方面的对比,通过详细的分析和实例,帮助大家理解两者之间的性能差异,以便在实际项目中做出更明智的选择。
158 3

推荐镜像

更多