欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

一文弄懂MySQL中redo?log與binlog的區(qū)別

 更新時間:2022年02月15日 14:46:14   作者:DB-Engineer  
在學(xué)習(xí)mysql數(shù)據(jù)庫時,不可避免要去接觸到redo log和binlog,好多人對這兩者的概念分不太清,下面這篇文章主要給大家介紹了關(guān)于MySQL中redo?log與binlog區(qū)別的相關(guān)資料,需要的朋友可以參考下

前言

MySQL中有六種日志文件,分別是:重做日志(redo log)、回滾日志(undo log)、二進制日志(binlog)、錯誤日志(errorlog)、慢查詢?nèi)罩荆╯low query log)、一般查詢?nèi)罩荆╣eneral log),中繼日志(relay log)。本文將詳細(xì)介紹MySQL redo log與binlog區(qū)別,下面來一起看看詳細(xì)的介紹吧

1. 什么是redo log?

redo log又稱重做日志文件,用于記錄事務(wù)操作的變化,記錄的是數(shù)據(jù)修改之后的值,不管事務(wù)是否提交都會記錄下來。在實例和介質(zhì)失?。╩edia failure)時,redo log文件就能派上用場,如數(shù)據(jù)庫掉電,InnoDB存儲引擎會使用redo log恢復(fù)到掉電前的時刻,以此來保證數(shù)據(jù)的完整性。

1.1 redo日志文件名

每個InnoDB存儲引擎至少有1個重做日志文件組(group),每個文件組至少有2個重做日志文件,如默認(rèn)的ib_logfile0和ib_logfile1。
[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-kHz7zVve-1584783729916)(https://i.imgur.com/wbDzJFm.png)]

1.2 影響redo log參數(shù)

  • innodb_log_file_size:指定每個redo日志大小,默認(rèn)值48MB
  • innodb_log_files_in_group:指定日志文件組中redo日志文件數(shù)量,默認(rèn)為2
  • innodb_log_group_home_dir:指定日志文件組所在路勁,默認(rèn)值./,指mysql的數(shù)據(jù)目錄datadir
  • innodb_mirrored_log_groups:指定日志鏡像文件組的數(shù)量,默認(rèn)為1,此功能屬于未實現(xiàn)的功能,在5.6版本中廢棄,在5.7版本中刪除了。

以下顯示了一個關(guān)于redo日志組的配置:

mysql> show variables like 'innodb%log%';
+----------------------------------+------------+
| Variable_name                    | Value      |
+----------------------------------+------------+
...     
| innodb_log_file_size             | 2147483648 |
| innodb_log_files_in_group        | 2          |
| innodb_log_group_home_dir        | ./         |
...
+----------------------------------+------------+
15 rows in set (0.00 sec)

1.3 redo log大小怎么設(shè)置?

redo log文件的大小設(shè)置對于InnoDB存儲引擎的性能有著非常大的影響。

  • 設(shè)置的太大

設(shè)置很大以后減少了checkpoint,并且由于redo log是順序I/O,大大提高了I/O性能。但是如果數(shù)據(jù)庫意外出現(xiàn)了問題,比如意外宕機,那么需要重放日志并且恢復(fù)已經(jīng)提交的事務(wù),如果日志很大,那么將會導(dǎo)致恢復(fù)時間很長。甚至到我們不能接受的程度。

  • 設(shè)置的太小

當(dāng)一個日志文件寫滿后,innodb會自動切換到另外一個日志文件,而且會觸發(fā)數(shù)據(jù)庫的檢查點(checkpoint),這會導(dǎo)致innodb緩存臟頁的小批量刷新,會明顯降低innodb的性能。

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-6gU4thAZ-1584783729918)(https://i.imgur.com/Y2m7CCA.png)]

  • 怎么設(shè)置?

參考官方文檔’Optimizing InnoDB Redo Logging’章節(jié)

把重做日志文件設(shè)置很大,甚至與緩沖池一樣大。當(dāng)InnoDB將重做日志文件寫滿時,它會觸發(fā)數(shù)據(jù)庫的檢查點,把緩沖池的臟數(shù)據(jù)寫入磁盤。小的重做日志文件會導(dǎo)致許多不必要的磁盤寫入。雖然在以前版本中,大的重做日志文件導(dǎo)致冗長的恢復(fù)時間,但現(xiàn)在恢復(fù)速度更快,可以放心地使用大型重做日志文件。

考慮增加日志緩沖區(qū)的大小。 大型日志緩沖區(qū)可以在事務(wù)提交之前運行大型事務(wù),而無需將日志寫入磁盤。 因此,如果您有更新,插入或刪除許多行的事務(wù),則使日志緩沖區(qū)更大可以節(jié)省磁盤I/O. 使用innodb_log_buffer_size配置選項配置日志緩沖區(qū)大小。

設(shè)置innodb_log_write_ahead_size參數(shù),表示redo log寫前的塊大小。InnoDB以512字節(jié)一個block的方式對齊寫入ib_logfile文件,但文件系統(tǒng)一般以4096字節(jié)為一個block單位。如果即將寫入的日志文件塊不在OS Cache時,就需要將對應(yīng)的4096字節(jié)的block讀入內(nèi)存,修改其中的512字節(jié),然后再把該block寫回磁盤。當(dāng) 當(dāng)前寫入文件的偏移量不能整除該值時,則補0,多寫一部分?jǐn)?shù)據(jù)。這樣當(dāng)寫入的數(shù)據(jù)是以磁盤block size對齊時,就可以直接write磁盤,而無需read-modify-write這三步了。

2. 什么是binlog

binlog記錄了對MySQL數(shù)據(jù)庫執(zhí)行更改的所有操作,但是不包括SELECT和SHOW這類操作,因為這類操作對數(shù)據(jù)本身并沒有修改。然后,若操作本身并沒有導(dǎo)致數(shù)據(jù)庫發(fā)生變化,那么該操作也會寫入二進制日志。例如:

root@localhost [(none)] 08:30:14>set binlog_format = 'STATEMENT';

root@localhost [(none)] 08:30:26>use test;
Database changed
root@localhost [test] 08:30:33>select * from account;
+----------+---------+
| acct_num | amount  |
+----------+---------+
|      138 |   14.98 |
|      141 | 1937.50 |
|       97 | -100.00 |
+----------+---------+
3 rows in set (0.00 sec)


root@localhost [test] 08:30:53>show master status;
+----------------------+----------+--------------+------------------+--------------------------------------------+
| File                 | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                          |
+----------------------+----------+--------------+------------------+--------------------------------------------+
| my3306_binlog.000052 |      471 |              |                  | e4382832-949d-11e8-97ba-080027793430:1-205 |
+----------------------+----------+--------------+------------------+--------------------------------------------+


root@localhost [test] 08:31:04>update account set acct_num=139 where amount=14;
Query OK, 0 rows affected (0.01 sec)
Rows matched: 0  Changed: 0  Warnings: 0

root@localhost [test] 08:31:35>show binlog events in 'my3306_binlog.000052';
+----------------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------+
| Log_name             | Pos | Event_type     | Server_id | End_log_pos | Info                                                                |
+----------------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------+
| my3306_binlog.000052 |   4 | Format_desc    |   1003306 |         123 | Server ver: 5.7.23-log, Binlog ver: 4                               |
| my3306_binlog.000052 | 123 | Previous_gtids |   1003306 |         194 | e4382832-949d-11e8-97ba-080027793430:1-204                          |
| my3306_binlog.000052 | 194 | Gtid           |   1003306 |         259 | SET @@SESSION.GTID_NEXT= 'e4382832-949d-11e8-97ba-080027793430:205' |
| my3306_binlog.000052 | 259 | Query          |   1003306 |         331 | BEGIN                                                               |
| my3306_binlog.000052 | 331 | Table_map      |   1003306 |         384 | table_id: 108 (test.account)                                        |
| my3306_binlog.000052 | 384 | Update_rows    |   1003306 |         440 | table_id: 108 flags: STMT_END_F                                     |
| my3306_binlog.000052 | 440 | Xid            |   1003306 |         471 | COMMIT /* xid=14 */                                                 |
| my3306_binlog.000052 | 471 | Gtid           |   1003306 |         536 | SET @@SESSION.GTID_NEXT= 'e4382832-949d-11e8-97ba-080027793430:206' |
| my3306_binlog.000052 | 536 | Query          |   1003306 |         615 | BEGIN                                                               |
| my3306_binlog.000052 | 615 | Query          |   1003306 |         736 | use `test`; update account set acct_num=139 where amount=14         |
| my3306_binlog.000052 | 736 | Query          |   1003306 |         816 | COMMIT                                                              |
+----------------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------+
11 rows in set (0.01 sec)

從上述例子中可以看到,MySQL數(shù)據(jù)庫首先進行update操作,從返回的結(jié)果看到Changed為0,這意味著該操作并沒有導(dǎo)致數(shù)據(jù)庫的變化。但是通過show binlog events in '...'可以看出在二進制日志中的確進行了記錄。

如果想記錄SELECT和SHOW操作,那只能使用查詢?nèi)罩?-general_log[={0|1}](1為啟用)

2.1 binlog文件名

通過配置參數(shù)--log-bin[=name]可以啟動二進制日志。如果不指定那么,則默認(rèn)binlog日志文件名為主機名,后綴名為binlog的序列號,默認(rèn)路勁為數(shù)據(jù)目錄(datadir).你也可以指定絕對路徑,如:

# cat /etc/my.cnf|grep log-bin
log-bin = /data/mysql/mysql3306/logs/my3306_binlog

# cd /data/mysql/mysql3306/logs
# ls -l
total 60
-rw-r----- 1 mysql mysql   194 Aug 15 10:04 my3306_binlog.000045
-rw-r----- 1 mysql mysql  1552 Aug 16 10:01 my3306_binlog.000046
-rw-r----- 1 mysql mysql  2953 Aug 17 09:56 my3306_binlog.000047
-rw-r----- 1 mysql mysql  1239 Aug 20 10:29 my3306_binlog.000048
-rw-r----- 1 mysql mysql   217 Aug 20 10:29 my3306_binlog.000049
-rw-r----- 1 mysql mysql 19567 Aug 21 10:24 my3306_binlog.000050
-rw-r----- 1 mysql mysql   194 Aug 22 08:01 my3306_binlog.000051
-rw-r----- 1 mysql mysql   816 Aug 22 08:31 my3306_binlog.000052
-rw-r----- 1 mysql mysql   384 Aug 22 08:01 my3306_binlog.index

2.2 影響binlog的參數(shù)

  • max_binlog_size:指定單個binlog文件最大值。默認(rèn)值為1g,最大值1g,如果超過該值,則產(chǎn)生新的binlog文件,后綴名+1,并記錄到.index文件。
  • binlog_cache_size:使用事務(wù)表存儲引擎(如innodb存儲引擎)時,所有未提交的binlog日志會被記錄到一個緩存中去,等事務(wù)提交時再將緩存中的binlog寫入到binlog文件中。緩存的大小由binlog_cache_size決定,默認(rèn)大小為32K。

binlog_cache_size是基于session的,也就是說,當(dāng)一個線程開始一個事務(wù)時,MySQL會自動分配一個大小為binlog_cache_size的緩存,因此該值的設(shè)置需要非常小心,不能設(shè)置過大。
當(dāng)一個事務(wù)的記錄大于設(shè)定的binlog_cache_size時,MySQL會把緩存中的日志寫入一個臨時文件中,因此該值又不能設(shè)的太小。
那怎么設(shè)置呢?

通過show global status命令查看binlog_cache_use,binlog_cache_disk_use的狀態(tài),以判斷當(dāng)前binlog_cache_size設(shè)置是否合適。

通過show global status命令查看binlog_cache_use,binlog_cache_disk_use的狀態(tài),以判斷當(dāng)前binlog_cache_size設(shè)置是否合適。

binlog_cache_use:記錄了使用緩存寫binlog次數(shù)
binlog_cache_disk_use:記錄了使用臨時文件寫binlog次數(shù)。

示例:

root@localhost [(none)] 09:55:48>show variables like 'binlog_cache_size';
+-------------------+---------+
| Variable_name     | Value   |
+-------------------+---------+
| binlog_cache_size | 32768   |
+-------------------+---------+
1 row in set (0.00 sec)

root@localhost [(none)] 09:53:26>show global status like 'binlog_cache%';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| Binlog_cache_disk_use | 0     |
| Binlog_cache_use      | 33553 |
+-----------------------+-------+
2 rows in set (0.00 sec)

使用緩存次數(shù)為33553,臨時文件使用次數(shù)為0。說明32KB的緩存大小對于當(dāng)前MySQL數(shù)據(jù)庫是夠用的。
  • max_binlog_cache_size:如果事務(wù)需要的內(nèi)存超過很多字節(jié),則服務(wù)器會生成多于“max_binlog_cache_size”字節(jié)的存儲錯誤所需的并發(fā)事務(wù)。 最小值為4096字節(jié),最大可能值為16EB(exabytes)。 建議的最大值為4GB; 這是因為MySQL目前無法使用大于4GB的二進制日志位置。
  • expire_logs_days:表示binlog文件自動刪除N天前的文件。默認(rèn)值為0,表示不自動刪除,最大值99.要手動刪除binlog文件,可以使用purge binary logs語句。例如:
PURGE { BINARY | MASTER } LOGS
   { TO 'log_name' | BEFORE datetime_expr }

PURGE BINARY LOGS TO 'mysql-bin.010';
PURGE BINARY LOGS BEFORE '2008-04-02 22:46:26';
PURGE BINARY LOGS BEFORE now() - interval 3 days;
  • binlog_rows_query_log_events:默認(rèn)為不啟用,啟用binlog_rows_query_log_events時,可以在binary log中記錄原始的SQL語句
root@localhost [test] 08:07:52>show binlog events in 'my3306_binlog.000056';
+----------------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------+
| Log_name             | Pos | Event_type     | Server_id | End_log_pos | Info                                                                |
+----------------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------+
| my3306_binlog.000056 |   4 | Format_desc    |   1003306 |         123 | Server ver: 5.7.23-log, Binlog ver: 4                               |
| my3306_binlog.000056 | 123 | Previous_gtids |   1003306 |         194 | e4382832-949d-11e8-97ba-080027793430:1-206                          |
| my3306_binlog.000056 | 194 | Gtid           |   1003306 |         259 | SET @@SESSION.GTID_NEXT= 'e4382832-949d-11e8-97ba-080027793430:207' |
| my3306_binlog.000056 | 259 | Query          |   1003306 |         331 | BEGIN                                                               |
| my3306_binlog.000056 | 331 | Table_map      |   1003306 |         375 | table_id: 108 (test.t)                                              |
| my3306_binlog.000056 | 375 | Update_rows    |   1003306 |         421 | table_id: 108 flags: STMT_END_F                                     |
| my3306_binlog.000056 | 421 | Xid            |   1003306 |         452 | COMMIT /* xid=16 */                                                 |
| my3306_binlog.000056 | 452 | Gtid           |   1003306 |         517 | SET @@SESSION.GTID_NEXT= 'e4382832-949d-11e8-97ba-080027793430:208' |
| my3306_binlog.000056 | 517 | Query          |   1003306 |         589 | BEGIN                                                               |
| my3306_binlog.000056 | 589 | Table_map      |   1003306 |         633 | table_id: 108 (test.t)                                              |
| my3306_binlog.000056 | 633 | Write_rows     |   1003306 |         673 | table_id: 108 flags: STMT_END_F                                     |
| my3306_binlog.000056 | 673 | Xid            |   1003306 |         704 | COMMIT /* xid=18 */                                                 |
| my3306_binlog.000056 | 704 | Gtid           |   1003306 |         769 | SET @@SESSION.GTID_NEXT= 'e4382832-949d-11e8-97ba-080027793430:209' |
| my3306_binlog.000056 | 769 | Query          |   1003306 |         841 | BEGIN                                                               |
| my3306_binlog.000056 | 841 | Rows_query     |   1003306 |         887 | # insert into t select 3                                            |
| my3306_binlog.000056 | 887 | Table_map      |   1003306 |         931 | table_id: 108 (test.t)                                              |
| my3306_binlog.000056 | 931 | Write_rows     |   1003306 |         971 | table_id: 108 flags: STMT_END_F                                     |
| my3306_binlog.000056 | 971 | Xid            |   1003306 |        1002 | COMMIT /* xid=24 */                                                 |
+----------------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------+
# insert into t select 3   就是開啟binlog_rows_query_log_events選項后,記錄的原始SQL語句。
  • sync_binlog:sync_binlog=[N]表示沒寫緩沖N次就同步到磁盤,如果將N設(shè)為1,即sync_binlog表示采用同步寫磁盤的方式來寫二進制日志,在MySQL5.7.7后,默認(rèn)為1。會對數(shù)據(jù)庫的IO系統(tǒng)帶來一定影響,但可以得到最大的高可用行。
  • binlog_checksum:該參數(shù)目的就是寫入binlog進行校驗,有兩個值[crc32|none],默認(rèn)為crc32
  • binlog-do-db:表示需要寫入日志的數(shù)據(jù)庫,默認(rèn)為空,表示同步所有庫
  • binlog-ignore-db:表示忽略寫入日志的數(shù)據(jù)庫,默認(rèn)為空,表示同步所有庫
  • log-slave-update:表示從master端取得并執(zhí)行的binlog,寫入自己的binlog文件中,一般應(yīng)用在master=>slave=>slave架構(gòu)
  • binlog_format:記錄binlog的格式。[statement,row,mixed],在MySQL5.7.7之后,默認(rèn)為row。

存儲引起對binlog格式的支持情況:

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-drzPlzHa-1584783729919)(https://i.imgur.com/nFgK19H.png)]

2.3 查看binlog

使用mysqlbinlog程序進行查看,例如:

[root@mysqldb1 10:58:18 /data/mysql/mysql3306/logs]
# mysqlbinlog -v --base64-output=decode-rows my3306_binlog.000052|more



/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#180822  8:01:00 server id 1003306  end_log_pos 123 CRC32 0xcbe20047 	Start: binlog v 4, server v 5.7.23-log created 180822  8:01:00 at startup
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
# at 123
#180822  8:01:00 server id 1003306  end_log_pos 194 CRC32 0xb1bda518 	Previous-GTIDs
# e4382832-949d-11e8-97ba-080027793430:1-204
# at 194
#180822  8:10:59 server id 1003306  end_log_pos 259 CRC32 0xeced9ada 	GTID	last_committed=0	sequence_number=1	rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= 'e4382832-949d-11e8-97ba-080027793430:205'/*!*/;
# at 259
#180822  8:10:59 server id 1003306  end_log_pos 331 CRC32 0x6da7802a 	Query	thread_id=2	exec_time=0	error_code=0
SET TIMESTAMP=1534896659/*!*/;
SET @@session.pseudo_thread_id=2/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=45/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 331
#180822  8:10:59 server id 1003306  end_log_pos 384 CRC32 0xf239dd79 	Table_map: `test`.`account` mapped to number 108
# at 384
#180822  8:10:59 server id 1003306  end_log_pos 440 CRC32 0xef6460fe 	Update_rows: table id 108 flags: STMT_END_F
### UPDATE `test`.`account`
### WHERE
###   @1=137
###   @2=14.98
### SET
###   @1=138
###   @2=14.98
# at 440
#180822  8:10:59 server id 1003306  end_log_pos 471 CRC32 0x360f05d0 	Xid = 14
COMMIT/*!*/;
# at 471
#180822  8:31:35 server id 1003306  end_log_pos 536 CRC32 0x662c8f17 	GTID	last_committed=1	sequence_number=2	rbr_only=no
SET @@SESSION.GTID_NEXT= 'e4382832-949d-11e8-97ba-080027793430:206'/*!*/;
# at 536
#180822  8:31:35 server id 1003306  end_log_pos 615 CRC32 0xa728a60a 	Query	thread_id=3	exec_time=0	error_code=0
SET TIMESTAMP=1534897895/*!*/;
BEGIN
/*!*/;
# at 615
#180822  8:31:35 server id 1003306  end_log_pos 736 CRC32 0x7513aa73 	Query	thread_id=3	exec_time=0	error_code=0
use `test`/*!*/;
SET TIMESTAMP=1534897895/*!*/;
update account set acct_num=139 where amount=14
/*!*/;
# at 736
#180822  8:31:35 server id 1003306  end_log_pos 816 CRC32 0x1cd7f41c 	Query	thread_id=3	exec_time=0	error_code=0
SET TIMESTAMP=1534897895/*!*/;
COMMIT
/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

3. redo log與binlog的區(qū)別

第一:redo log是在InnoDB存儲引擎層產(chǎn)生,而binlog是MySQL數(shù)據(jù)庫的上層產(chǎn)生的,并且二進制日志不僅僅針對INNODB存儲引擎,MySQL數(shù)據(jù)庫中的任何存儲引擎對于數(shù)據(jù)庫的更改都會產(chǎn)生二進制日志。

第二:兩種日志記錄的內(nèi)容形式不同。MySQL的binlog是邏輯日志,其記錄是對應(yīng)的SQL語句。而innodb存儲引擎層面的重做日志是物理日志。

第三:兩種日志與記錄寫入磁盤的時間點不同,二進制日志只在事務(wù)提交完成后進行一次寫入。而innodb存儲引擎的重做日志在事務(wù)進行中不斷地被寫入,并日志不是隨事務(wù)提交的順序進行寫入的。

二進制日志僅在事務(wù)提交時記錄,并且對于每一個事務(wù),僅在事務(wù)提交時記錄,并且對于每一個事務(wù),僅包含對應(yīng)事務(wù)的一個日志。而對于innodb存儲引擎的重做日志,由于其記錄是物理操作日志,因此每個事務(wù)對應(yīng)多個日志條目,并且事務(wù)的重做日志寫入是并發(fā)的,并非在事務(wù)提交時寫入,其在文件中記錄的順序并非是事務(wù)開始的順序。

第四:binlog不是循環(huán)使用,在寫滿或者重啟之后,會生成新的binlog文件,redo log是循環(huán)使用。

第五:binlog可以作為恢復(fù)數(shù)據(jù)使用,主從復(fù)制搭建,redo log作為異常宕機或者介質(zhì)故障后的數(shù)據(jù)恢復(fù)使用。

總結(jié)

到此這篇關(guān)于MySQL中redo log與binlog區(qū)別的文章就介紹到這了,更多相關(guān)MySQL redo log與binlog區(qū)別內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!

相關(guān)文章

  • MySQL中DML添加數(shù)據(jù)insert的操作方法

    MySQL中DML添加數(shù)據(jù)insert的操作方法

    DML英文全稱Data Manipulation Language數(shù)據(jù)操作語言,用來對數(shù)據(jù)庫中表的數(shù)據(jù)記錄進行增、刪、改在實際開發(fā)過程中使用比較多,務(wù)必掌握操作,這篇文章主要介紹了MySQL中DML添加數(shù)據(jù)insert的操作方法,需要的朋友可以參考下
    2023-07-07
  • MySQL日志維護策略匯總

    MySQL日志維護策略匯總

    這篇文章主要介紹了MySQL日志維護策略匯總,需要的朋友可以參考下
    2015-08-08
  • You have an error in your SQL syntax; check the manual that corresponds解決方法

    You have an error in your SQL&

    You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version
    2023-02-02
  • mysql中使用shell語句實現(xiàn)xtrabackup自動物理備份增量備份

    mysql中使用shell語句實現(xiàn)xtrabackup自動物理備份增量備份

    這篇文章主要為大家介紹了mysql數(shù)據(jù)庫使用shell實現(xiàn)xtrabackup自動物理備份增量備份腳本,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪
    2023-07-07
  • 詳解mysql 獲取當(dāng)前日期及格式化

    詳解mysql 獲取當(dāng)前日期及格式化

    本篇文章主要介紹了mysql 獲取當(dāng)前日期及格式化,具有一定的參考價值,感興趣的小伙伴們可以參考一下。
    2016-12-12
  • MySQL安裝出現(xiàn)The?configuration?for?MySQL?Server?8.0.28?has?failed.?You?can...錯誤的解決辦法

    MySQL安裝出現(xiàn)The?configuration?for?MySQL?Server?8.0.28?has

    這篇文章主要給大家介紹了MySQL安裝出現(xiàn)The?configuration?for?MySQL?Server?8.0.28?has?failed.?You?can...錯誤的解決辦法,文中通過圖文介紹的非常詳細(xì),需要的朋友可以參考下
    2023-09-09
  • Centos7下mysql 8.0.15 安裝配置圖文教程

    Centos7下mysql 8.0.15 安裝配置圖文教程

    這篇文章主要為大家詳細(xì)介紹了Centos7下mysql 8.0.15 安裝配置圖文教程,具有一定的參考價值,感興趣的小伙伴們可以參考一下
    2019-03-03
  • 解決mysql報錯:1264-Out of range value for column ‘字段‘ at row 1

    解決mysql報錯:1264-Out of range value for&nb

    這篇文章主要介紹了解決mysql報錯:1264-Out of range value for column ‘字段‘ at row 1問題,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教
    2023-11-11
  • mysql中int(3)和int(10)的數(shù)值范圍是否相同

    mysql中int(3)和int(10)的數(shù)值范圍是否相同

    依稀還記得有次面試,有面試官問我int(10)與int(11)有什么區(qū)別,當(dāng)時覺得就是長度的區(qū)別吧,后來發(fā)現(xiàn)事情不是這么簡單,這篇文章主要給大家介紹了關(guān)于mysql中int(3)和int(10)的數(shù)值范圍是否相同的相關(guān)資料
    2021-10-10
  • MySQL中必須了解的13個關(guān)鍵字總結(jié)

    MySQL中必須了解的13個關(guān)鍵字總結(jié)

    這篇文章主要為大家詳細(xì)介紹了MySQL中必須了解學(xué)會的13個關(guān)鍵字,文中的示例代碼簡潔易懂,對我們掌握MySQL有一定的幫助,需要的可以了解下
    2023-09-09

最新評論