首页 > 数据库 >MySQL - binlog日志简介及设置

MySQL - binlog日志简介及设置

时间：2024-05-31 10:21:53浏览次数：27  
标签：bin binlog log MySQL mysql 日志 ###

基本概念

binlog是Mysql sever层维护的一种二进制日志，与innodb引擎中的redo/undo log是完全不同的日志；其主要是用来记录对mysql数据更新或潜在发生更新的SQL语句，记录了所有的DDL和DML(除了数据查询语句)语句，并以事务的形式保存在磁盘中，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。

一般来说开启二进制日志大概会有1%的性能损耗(参见MySQL官方中文手册 5.1.24版)。

作用主要有：

  • 复制：MySQL Replication在Master端开启binlog，Master把它的二进制日志传递给slaves并回放来达到master-slave数据一致的目的
  • 数据恢复：通过mysqlbinlog工具恢复数据
  • 增量备份

二进制日志包括两类文件：二进制日志索引文件（文件名后缀为.index）用于记录所有的二进制文件，二进制日志文件（文件名后缀为.00000*）记录数据库所有的DDL和DML(除了数据查询语句)语句事件。

日志管理

开启binlog

修改配置文件 my.cnf

配置 log-bin 和 log-bin-index 的值，如果没有则自行加上去。

log-bin=mysql-bin
log-bin-index=mysql-bin.index

这里的 log-bin 是指以后生成各 Binlog 文件的前缀，比如上述使用master-bin，那么文件就将会是master-bin.000001、master-bin.000002 等。

log-bin-index 则指 binlog index 文件的名称，这里我们设置为master-bin.index，可以不配置。

命令查看配置

binlog开启后，可以在配置文件中查看其位置信息，也可以在myslq命令行中查看：

mysql> show variables like '%log_bin%';
+---------------------------------+---------------------------------------------+
| Variable_name                   | Value                                       |
+---------------------------------+---------------------------------------------+
| log_bin                         | ON                                          |
| log_bin_basename                | D:\Program Files\MySQL\data\mysql-bin       |
| log_bin_index                   | D:\Program Files\MySQL\data\mysql-bin.index |
| log_bin_trust_function_creators | OFF                                         |
| log_bin_use_v1_row_events       | OFF                                         |
| sql_log_bin                     | ON                                          |
+---------------------------------+---------------------------------------------+
6 rows in set (0.07 sec)

查看binlog文件列表

mysql>  show binary logs;
+------------------+-----------+-----------+
| Log_name         | File_size | Encrypted |
+------------------+-----------+-----------+
| mysql-bin.000001 |       202 | No        |
| mysql-bin.000002 |      2062 | No        |
+------------------+-----------+-----------+
2 rows in set (0.07 sec)

binlog文件开启binlog后，会在数据目录（默认）生产host-bin.n（具体binlog信息）文件及host-bin.index索引文件（记录binlog文件列表）。当binlog日志写满(binlog大小max_binlog_size，默认1G),或者数据库重启才会生产新文件，但是也可通过手工进行切换让其重新生成新的文件（flush logs）；另外，如果正使用大的事务，由于一个事务不能横跨两个文件，因此也可能在binlog文件未满的情况下刷新文件。

查看日志状态

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000002 |     2062 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.08 sec)

显示正在写入的二进制文件，及当前position

刷新日志

mysql> flush logs;
Query OK, 0 rows affected (0.12 sec)

mysql>  show binary logs;
+------------------+-----------+-----------+
| Log_name         | File_size | Encrypted |
+------------------+-----------+-----------+
| mysql-bin.000001 |       202 | No        |
| mysql-bin.000002 |      2109 | No        |
| mysql-bin.000003 |       155 | No        |
+------------------+-----------+-----------+
3 rows in set (0.07 sec)

自此刻开始产生一个新编号的binlog日志文件

每当mysqld服务重启时，会自动执行此命令，刷新binlog日志；在mysqldump备份数据时加 -F 选项也会刷新binlog日志；

重置(清空)所有binlog日志

mysql> reset master;

常用命令

mysqlbinlog查看日志

D:\Program Files\MySQL
$ bin\mysqlbinlog data\mysql-bin.000002

在MySQL5.5以下版本使用mysqlbinlog命令时如果报错，就加上 “--no-defaults”选项

  • mysqlbinlog是mysql官方提供的一个binlog查看工具，
    • 也可使用–read-from-remote-server从远程服务器读取二进制日志，
    • 还可使用--start-position --stop-position、--start-time= --stop-time精确解析binlog日志

内容：

BINLOG '
K3L4XBMBAAAARQAAAHEGAAAAAJoCAAAAAAEACmxvbmdodWJhbmcABXRoZW1lAAUDDwUREQWWAAgA
AAABAQACASGhIgQL
K3L4XB4BAAAAPQAAAK4GAAAAAJoCAAAAAAEAAgAF/wA0AQAABGFhYWEAAAAAAMBYQFz4citc+HIr
sXjMIA==
'/*!*/;
# at 1710
#190606  9:53:47 server id 1  end_log_pos 1741 CRC32 0xddb08f33         Xid = 216
COMMIT/*!*/;
# at 1741
#190606  9:53:47 server id 1  end_log_pos 1820 CRC32 0x166b4128         Anonymous_GTID  last_committed=5        sequence_number=6       rbr_only=yes    original_committed_timestamp=1559786027387679   immediate_commit_timestamp=15597860273
        transaction_length=321
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1559786027387679 (2019-06-06 09:53:47.387679 ?D1ú±ê×?ê±??)
# immediate_commit_timestamp=1559786027387679 (2019-06-06 09:53:47.387679 ?D1ú±ê×?ê±??)
/*!80001 SET @@session.original_commit_timestamp=1559786027387679*//*!*/;
/*!80014 SET @@session.original_server_version=80016*//*!*/;
/*!80014 SET @@session.immediate_server_version=80016*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 1820
#190606  9:53:47 server id 1  end_log_pos 1901 CRC32 0x47def222         Query   thread_id=10    exec_time=0     error_code=0
SET TIMESTAMP=1559786027/*!*/;
BEGIN
/*!*/;
# at 1901
#190606  9:53:47 server id 1  end_log_pos 1970 CRC32 0x5a235198         Table_map: `longhubang`.`theme` mapped to number 666
# at 1970
#190606  9:53:47 server id 1  end_log_pos 2031 CRC32 0x62dc1928         Write_rows: table id 666 flags: STMT_END_F

show binlog events查看binlog日志

A.查询第一个(最早)的binlog日志：
  mysql> show binlog events; 

B.指定查询 mysql-bin.000021 这个文件：
  mysql> show binlog events in 'mysql-bin.000021';

C.指定查询 mysql-bin.000021 这个文件，从pos点:8224开始查起：
  mysql> show binlog events in 'mysql-bin.000021' from 8224;

D.指定查询 mysql-bin.000021 这个文件，从pos点:8224开始查起，查询10条
  mysql> show binlog events in 'mysql-bin.000021' from 8224 limit 10;

E.指定查询 mysql-bin.000021 这个文件，从pos点:8224开始查起，偏移2行，查询10条
  mysql> show binlog events in 'mysql-bin.000021' from 8224 limit 2,10;

内容：

mysql> show binlog events  in 'mysql-bin.000002' from 1710 limit 10;
+------------------+------+----------------+-----------+-------------+--------------------------------------+
| Log_name         | Pos  | Event_type     | Server_id | End_log_pos | Info                                 |
+------------------+------+----------------+-----------+-------------+--------------------------------------+
| mysql-bin.000002 | 1710 | Xid            |         1 |        1741 | COMMIT /* xid=216 */                 |
| mysql-bin.000002 | 1741 | Anonymous_Gtid |         1 |        1820 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
| mysql-bin.000002 | 1820 | Query          |         1 |        1901 | BEGIN                                |
| mysql-bin.000002 | 1901 | Table_map      |         1 |        1970 | table_id: 666 (longhubang.theme)     |
| mysql-bin.000002 | 1970 | Write_rows     |         1 |        2031 | table_id: 666 flags: STMT_END_F      |
| mysql-bin.000002 | 2031 | Xid            |         1 |        2062 | COMMIT /* xid=223 */                 |
| mysql-bin.000002 | 2062 | Rotate         |         1 |        2109 | mysql-bin.000003;pos=4               |
+------------------+------+----------------+-----------+-------------+--------------------------------------+
7 rows in set (0.14 sec)

数据恢复

完全备份

D:\Program Files\MySQL
$ bin\mysqldump  -h127.0.0.1 -p3306 -uroot -phongda$123456 -lF -B longhubang >D:\data\backup\longhubang.dump
mysqldump: [Warning] Using a password on the command line interface can be insecure.

注意要创建好D:\data\backup文件夹。

这里使用了-lF，注意必须大写F,当备份工作刚开始时系统会刷新log日志，产生新的binlog日志来记录备份之后的数据库“增删改”操作。

查看一下：

mysql> show binary logs;
+------------------+-----------+-----------+
| Log_name         | File_size | Encrypted |
+------------------+-----------+-----------+
| mysql-bin.000001 |       202 | No        |
| mysql-bin.000002 |      2109 | No        |
| mysql-bin.000003 |       374 | No        |
| mysql-bin.000004 |       155 | No        |
+------------------+-----------+-----------+
4 rows in set (0.10 sec)

也就是说， mysql-bin.000004 是用来记录完全备份命令时间之后对数据库的所有“增删改”操作。

Linux数据备份命令：

/usr/local/mysql/bin/mysqldump -uroot -p123456 -lF --log-error=/root/myDump.err -B zyyshop > /root/BAK.zyyshop.sql

数据恢复

经过一段时间，数据库出现问题，需要恢复

 mysql> flush logs;

此时执行一次刷新日志索引操作，重新开始新的binlog日志记录文件，理论说 mysql-bin.000004 这个文件不会再有后续写入了(便于我们分析原因及查找pos点)，以后所有数据库操作都会写入到下一个日志文件；

查看binlog日志：

mysql> show binlog events in 'mysql-bin.000004';

最后一段日志内容：

| mysql-bin.000004 | 3976 | Xid            |         1 |        4007 | COMMIT /* xid=2375 */                    |
| mysql-bin.000004 | 4007 | Anonymous_Gtid |         1 |        4086 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'     |
| mysql-bin.000004 | 4086 | Query          |         1 |        4167 | BEGIN                                    |
| mysql-bin.000004 | 4167 | Table_map      |         1 |        4236 | table_id: 666 (longhubang.theme)         |
| mysql-bin.000004 | 4236 | Delete_rows    |         1 |        4505 | table_id: 666 flags: STMT_END_F          |
| mysql-bin.000004 | 4505 | Xid            |         1 |        4536 | COMMIT /* xid=2393 */                    |
| mysql-bin.000004 | 4536 | Anonymous_Gtid |         1 |        4613 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'     |
| mysql-bin.000004 | 4613 | Query          |         1 |        4736 | drop database  longhubang /* xid=2411 */ |
| mysql-bin.000004 | 4736 | Rotate         |         1 |        4783 | mysql-bin.000005;pos=4                   |
+------------------+------+----------------+-----------+-------------+------------------------------------------+
70 rows in set (0.21 sec)

通过分析，造成数据库破坏的pos点区间是介于4613--4736 之间，只要恢复到4613前就可。

先进行完全备份恢复：

D:\Program Files\MySQL
$ bin\mysql  -h127.0.0.1 -p3306 -uroot -phongda$123456 -v <D:\data\backup\longhubang.dump

binlog日志恢复：

D:\Program Files\MySQL
$ bin\mysqlbinlog    --stop-position=4613    data\mysql-bin.000004 | bin\mysql  -h127.0.0.1 -p3306 -uroot -phongda$123456  longhubang
mysql: [Warning] Using a password on the command line interface can be insecure.

增量数据恢复语法格式：

mysqlbinlog mysql-bin.0000xx | mysql -u用户名 -p密码 数据库名

常用选项：
​  --start-position=953                   起始pos点
​  --stop-position=1437                   结束pos点
​  --start-datetime="2013-11-29 13:18:54" 起始时间点
​  --stop-datetime="2013-11-29 13:21:53"  结束时间点
​  --database=zyyshop                     指定只恢复zyyshop数据库(一台主机上往往有多个数据库，只限本地log日志)
​    
不常用选项：    
​  -u --user=name              Connect to the remote server as username.连接到远程主机的用户名
​  -p --password[=name]        Password to connect to remote server.连接到远程主机的密码
​  -h --host=name              Get the binlog from server.从远程主机上获取binlog日志
​  --read-from-remote-server   Read binary logs from a MySQL server.从某个MySQL服务器上读取binlog日志

小结：实际是将读出的binlog日志内容，通过管道符传递给mysql命令。这些命令、文件尽量写成绝对路径；

上面的binlog恢复语句也可以拆分：

D:\Program Files\MySQL
$ bin\mysqlbinlog   --stop-position=4613    data\mysql-bin.000004 > D:\data\backup\004.sql

D:\Program Files\MySQL
$ bin\mysql -h127.0.0.1 -p3306 -uroot -phongda$123456 longhubang
mysql: [Warning] Using a password on the command line interface can be insecure.
.......
 
mysql> source D:\data\backup\004.sql

所谓恢复，就是让mysql将保存在binlog日志中指定段落区间的sql语句逐个重新执行一次而已。

主从复制

复制是mysql最重要的功能之一，mysql集群的高可用、负载均衡和读写分离都是基于复制来实现的；从5.6开始复制有两种实现方式，基于binlog和基于GTID（全局事务标示符）；本文接下来将介绍基于binlog的一主一从复制；

其复制的基本过程如下：

  1. Master将数据改变记录到二进制日志(binary log)中
  2. Slave上面的IO进程连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容
  3. Master接收到来自Slave的IO进程的请求后，负责复制的IO进程会根据请求信息读取日志指定位置之后的日志信息，返回给Slave的IO进程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置
  4. Slave的IO进程接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的 bin-log的，文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的告诉Master从某个bin-log的哪个位置开始往后的日志内容
  5. Slave的Sql进程检测到relay-log中新增加了内容后，会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容，并在自身执行

写入机制

我们一起来看一下MySQL执行事物的过程中 binlog 的落盘机制。MySQL是如何保证你使用的binlog是安全的！

binlog的高速缓存

首先为大家介绍一个概念：binlog的高速缓存

意思是：所有未commit的事物产生的binlog，都会被先记录到binlog的高速缓存中。等该事物被commit时，再将缓存中的数据写入binlog日志文件中。

高速缓存的大小可以由参数binlog_chache_size 默认大小为：32768 ，并且每个session都有自己的独立的缓存。多个会话指间彼此不影响。

binlog_chache_size不能设置太大，否则大量事物打来后肯定会造成宝贵的内存资源被浪费。但是也别太小，因为当一个事物产生的日志足够大超过该参数设置的值时，MySQL会将缓存中的binlog数据写到临时文件中去。

mysql> show variables like '%binlog_cache%';
+-----------------------+----------------------+
| Variable_name         | Value                |
+-----------------------+----------------------+
| binlog_cache_size     | 32768                |
| max_binlog_cache_size | 18446744073709547520 |
+-----------------------+----------------------+
2 rows in set (0.00 sec)

刷盘机制

其实binlog写入磁盘的机制由参数sync_binlog控制。

  • 策略1:sync_binlog = 0

    当设置sync_binlog = 0时，表示innodb不会主动控制将binlog落盘，innodb仅仅会将binlog写入到OS Cache中，至于什么时间将binlog刷入磁盘中完全依赖于操作系统。选这种策略，一旦操作系统宕机，OS Cache中的binlog就会丢失。

  • 策略2:sync_binlog = 1

    设置sync_binlog = 1时，表示事物commit时将binlog落盘！这样哪怕机器宕机了，也能确保binlog会被写入到磁盘中。

  • 策略3:sync_binlog=N

    这里的N不是0，也不是1。

    当N大于1时，表示开启组提交，也就是group commit，如果你之前不层了解组提交的话，你可以这样理解它：比如N=5，那MySQL就会等收集5个binlog后再将这5个binlog一口气同步到磁盘上。好处很明显，一次IO可以往磁盘上刷入N个binlog，IO效率会有所提升。坏处也很明显，比如N=5，那当MySQL收集了4个binlog时，服务器宕机，这4个binlog就会丢失。

官方推荐策略2方式

运维中查看binlog日志

mysql二进制日志有三种格式：statement、row、mixed

一般我们在主从复制过程中采用的格式都是mixed。这种格式兼具了基于行(row)和基于语句(statement)的优点，速度和效率是最高的。

运维给出二进制的binlog文件

将其转换成utf8文件：

mysqlbinlog mysql-bin.000345 > mysql-bin.000345.txt

输出：

SET @@SESSION.GTID_NEXT= 'db939aab-1291-11ea-a147-6c92bf6083de:12067013'/*!*/;
# at 71904493
#201130 14:44:16 server id 3341167209  end_log_pos 71904556 CRC32 0x55bf687f 	Query	thread_id=11827220	exec_time=0	error_code=0
SET TIMESTAMP=1606718656/*!*/;
BEGIN
/*!*/;
# at 71904556
#201130 14:44:16 server id 3341167209  end_log_pos 71904647 CRC32 0xccce734d 	Table_map: `invstone`.`t_sso_ticket_info` mapped to number 95
# at 71904647
#201130 14:44:16 server id 3341167209  end_log_pos 71904923 CRC32 0xc72e8724 	Update_rows_v1: table id 95 flags: STMT_END_F

BINLOG '
wJTEXxNpKibHWwAAAIctSQQAAF8AAAAAAAEACGludnN0b25lABF0X3Nzb190aWNrZXRfaW5mbwAN
/gMPDwMDDxISAxIS/g7+YJYAlgCWAAAAAAD+YEwQTXPOzA==
wJTEXxhpKibHFAEAAJsuSQQAAF8AAAAAAAEADf////8A4CA2YzZmZGQ3NGMyYzE0YTA3ODY4NTk3
MTBlOWNmZDk4YigAAAAABmZhbmdia/////8CAAAAB2pzeS13ZWKZp/zrCZmn/POKAAAAAJmn/OsJ
maf86wogNjk2Mjg0ODFmY2ViNDk3NjhhNWZlMDdiNDI1OWM1YzkA4CA2YzZmZGQ3NGMyYzE0YTA3
ODY4NTk3MTBlOWNmZDk4YigAAAAABmZhbmdia/////8DAAAAB2pzeS13ZWKZp/zrCZmn/PORAAAA
AJmn/OsJmaf86xAgNjk2Mjg0ODFmY2ViNDk3NjhhNWZlMDdiNDI1OWM1Yzkkhy7H
'/*!*/;
# at 71904923
#201130 14:44:16 server id 3341167209  end_log_pos 71904954 CRC32 0xa4f47fbd 	Xid = 103880476
COMMIT/*!*/;
# at 71904954

在使用mysqlbinlog查看混合模式的二进制文件时，基于行的部分默认是以base64编码显示

将其中的base64转换成sql:

mysqlbinlog --base64-output=decode-rows -v mysql-bin.000345 > mysql-bin.0003452.txt

输出：

# at 81880980
#201130 15:16:15 server id 3341167209  end_log_pos 81881102 CRC32 0xbeafaa0c 	Table_map: `huishi-server`.`hs_capital_attachment_sync_info` mapped to number 55827
# at 81881102
#201130 15:16:15 server id 3341167209  end_log_pos 81889094 CRC32 0x35905375 	Update_rows_v1: table id 55827
# at 81889094
#201130 15:16:15 server id 3341167209  end_log_pos 81897122 CRC32 0x7181fac7 	Update_rows_v1: table id 55827 flags: STMT_END_F
### UPDATE `huishi-server`.`hs_capital_attachment_sync_info`
### WHERE
###   @1=9669
###   @2=1
###   @3='AJXT'
###   @4='AJXT20201130150240564'
###   @5='BO194471256404393984'
###   @6='qydafj-1000019989/qynz'
###   @7='浼佷笟妗ｆ闄勪欢-1000019989/鍐呰处'
###   @8=211812
###   @9='http://hs-statics.shitou.com/huishi_pro/archiveManager/20骞?鏈堜唤寮€绁╛1605617655326_gHL.jpeg'
###   @10=0
###   @11=1606719762
###   @12='guosiying'
###   @13=1606719762
###   @14='guosiying'
###   @15=0
###   @16='qynz-30'
###   @17=1
###   @18=0
### SET
###   @1=9669
###   @2=1
###   @3='AJXT'
###   @4='AJXT20201130150240564'
###   @5='BO194471256404393984'
###   @6='qydafj-1000019989/qynz'
###   @7='浼佷笟妗ｆ闄勪欢-1000019989/鍐呰处'
###   @8=211812
###   @9='http://hs-statics.shitou.com/huishi_pro/archiveManager/20骞?鏈堜唤寮€绁╛1605617655326_gHL.jpeg'
###   @10=1
###   @11=1606719762
###   @12='guosiying'
###   @13=1606720575
###   @14='guosiying'
###   @15=0
###   @16='qynz-30'
###   @17=1
###   @18=0
### UPDATE `huishi-server`.`hs_capital_attachment_sync_info`
### WHERE
###   @1=9670
###   @2=1

参考：

MySQL的binlog日志

腾讯工程师带你深入解析 MySQL binlog

初探 MySQL 的 Binlog

超级有用的15个mysqlbinlog命令

谈谈MySQL bin log的写入机制、以及线上的参数是如何配置的

转载自https://www.cnblogs.com/hongdada/p/10983768.html  

标签：bin,binlog,log,MySQL,mysql,日志,###
From： https://www.cnblogs.com/liftsail/p/18223965

相关文章

  • Mysql视图和索引
    什么是视图（view）   MySQL中的视图（View）是一个虚拟的表，其内容由查询定义。视图并不在数据库中以存储的数据值形式存在。行和列数据来自由定义视图的查询所引用的表，并且在引用视图时动态生成。视图的优势简化复杂性：通过视图，用户可以只看到他们感兴趣的数据或数据的简化版......
  • 面经-Java，Linux，Mysql，网络
    状态码2xx:成功类3xx：重定向4xx：客户端错误5xx：服务器错误404：未找到网页400：请求语法错误500：服务器错误503：服务器停机200：成功post和get的区别get多用于获取服务端数据，post多用于向服务端推送数据。get的参数多拼接在url中，post的参数放在请求体中。故post的安全系数高......
  • 31.MySQL数据库【一】基础介绍
    【一】数据库初识1）存储数据的演变过程基于内存保存文件操作json模块搭建TCP的客户端和服务端，TCP服务端用作存储服务，TCP客户端用于上传和下载数据存储数据的位置就是数据库2）数据库本质就是一块基于网络通信保存数据的应用程序3）数据库的介绍1.关联性数据库（存......
  • 32.MySQL数据库【二】存储引擎与基本数据类型.
    【一】MySQL之存储引擎1）介绍针对不同的数据有不同的处理机制，存储引擎就是不同的处理机制2）MySQL主要的存储引擎1.innodb是MySQL5.5版本之后的默认存储引擎支持事务、外锁、外键2.myisam是MySQL5.5版本之前的默认存储引擎速度比innodb快，但数据安全性较弱3.memory......
  • 34.MySQL数据库【四】过滤条件
    过滤条件【一】语法select*/字段名from*/表名where*/字段名=字段值;--执行顺序from起手知道是那张表where根据过滤条件在表中过滤数据select再过滤出自己想要的数据【二】准备的数据#创建表createtablefilt_eg( idintnotnulluniqueauto_increment,......
  • 33.MySQL数据库【三】约束条件
    约束条件限制表中的数据，保证数据的准确性和可靠性而存在的限制规则【一】非空约束（notnull）限制指定字段不能为空#建表createtableeg( namevarchar(32)notnull, hobbyvarchar(32));#name字段不能为空【二】唯一性约束（unique）限制字段具有唯一性，不能重复，但能为......
  • 35.MySQL数据库【五】多表查询和子查询
    多表查询和子查询【一】概念子查询：将一条SQL语句的查询结果加括号当做另外一条SQL语句的查询结果链表查询：先将多张表拼接到一起，形成一张大表，让后基于单表查询获取数据1）创建数据#建表createtabledep( idintPRIMARYKEYAUTO_INCREMENT,namevarchar(20));......
  • MySQL Shell 调用外部脚本
    使用CLI工具时，打错命令很容易纠正。不过，在MySQlShell中工作时，命令可能会更长、更复杂。以下是运行MySQLDocumentStore的一个例子。db.scores.find("year(date)=2023").fields(['lastName','firstName','round(avg(score),2)asavg','count(score)asnum......
  • 【docker】docker 下 MySQL偶然无法访问
    1.概述我有一个环境遇到了docker下MySQL偶然无法访问，具体情况如下可以被看到可以telnet通畅，这个jar是我自己研发的，主要这台机器是别人的没有装telnet但是任务还是报错所在机器telnet通但是无法登录，同事说遇到过比如网络卡或者不稳定，需要重启一下mysql我先去......
  • 【Yarn】yarn logs 日志过大 The total log size is too large The log size limit is
    1.概述今天要排查一个现场，然后需要下载日志查看，结果发现日志过大，无法下载[mr@cqsec10075~]$yarnlogs-applicationIdapplication_1679365191066_0008>aa.txt2023-03-2814:24:42......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99