一文弄懂MySQL中redo?log與binlog的區(qū)別
前言
MySQL中有六種日志文件，分別是：重做日志（redo log）、回滾日志（undo log）、二進(jìn)制日志（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ā)生變化，那么該操作也會寫入二進(jìn)制日志。例如：
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ù)庫首先進(jìn)行update操作，從返回的結(jié)果看到Changed為0，這意味著該操作并沒有導(dǎo)致數(shù)據(jù)庫的變化。但是通過show binlog events in '...'可以看出在二進(jìn)制日志中的確進(jìn)行了記錄。
如果想記錄SELECT和SHOW操作，那只能使用查詢?nèi)罩?-general_log[={0|1}](1為啟用)
2.1 binlog文件名
通過配置參數(shù)--log-bin[=name]可以啟動二進(jìn)制日志。如果不指定那么，則默認(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的二進(jìn)制日志位置。
- 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表示采用同步寫磁盤的方式來寫二進(jìn)制日志，在MySQL5.7.7后，默認(rèn)為1。會對數(shù)據(jù)庫的IO系統(tǒng)帶來一定影響，但可以得到最大的高可用行。
- binlog_checksum：該參數(shù)目的就是寫入binlog進(jìn)行校驗，有兩個值[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程序進(jìn)行查看，例如：
[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)生的，并且二進(jìn)制日志不僅僅針對INNODB存儲引擎，MySQL數(shù)據(jù)庫中的任何存儲引擎對于數(shù)據(jù)庫的更改都會產(chǎn)生二進(jìn)制日志。
第二：兩種日志記錄的內(nèi)容形式不同。MySQL的binlog是邏輯日志，其記錄是對應(yīng)的SQL語句。而innodb存儲引擎層面的重做日志是物理日志。
第三：兩種日志與記錄寫入磁盤的時間點不同，二進(jìn)制日志只在事務(wù)提交完成后進(jìn)行一次寫入。而innodb存儲引擎的重做日志在事務(wù)進(jìn)行中不斷地被寫入，并日志不是隨事務(wù)提交的順序進(jìn)行寫入的。
二進(jìn)制日志僅在事務(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學(xué)習(xí)第三天 Windows 64位操作系統(tǒng)下驗證MySQL
MySQL學(xué)習(xí)第三天教大家如何在Windows 64位操作系統(tǒng)下驗證MySQL，感興趣的小伙伴們可以參考一下2016-05-05
這篇文章主要給大家介紹了關(guān)于MySQL慢查詢?nèi)罩镜淖饔煤烷_啟的相關(guān)資料，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2021-01-01
MySQL中的FIND_IN_SET函數(shù)的使用場景
MySQL 中的?FIND_IN_SET()?函數(shù)用于在一個逗號分隔的字符串列表中查找指定的值,并返回其在列表中的位置,下面就來介紹一下FIND_IN_SET函數(shù)的具體使用,感興趣的可以了解一下2024-05-05
Centos7下使用yum安裝mysql數(shù)據(jù)庫的詳細(xì)教程(增強版)
這篇文章主要介紹了Centos7下使用yum安裝mysql數(shù)據(jù)庫的詳細(xì)教程(增強版),非常不錯，具有參考借鑒價值，需要的朋友可以參考下2016-12-12
當(dāng)一個字段需要同時等于多個值的時候，用and直接連不會有數(shù)據(jù)查出。2011-08-08
mysql下運行腳本，有兩種方法，都是在命令行下進(jìn)行的，需要的朋友可以記錄下2014-07-07
在MySQL集群中,主庫更新會同步到從庫,但從庫更新不同步到主庫,主從復(fù)制能分?jǐn)倝毫?本文就來介紹一下mysql搭建主從復(fù)制的實現(xiàn)步驟,感興趣的可以了解一下2024-11-11
mysql5.7版本開始支持JSON類型字段,本文主要介紹了mysql中json_extract的具體使用,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2024-05-05
mysql 如何使用JSON_EXTRACT() 取json值
這篇文章主要介紹了mysql如何使用JSON_EXTRACT() 取json值的操作方式，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2022-07-07
Mysql?COUNT()函數(shù)基本用法及應(yīng)用詳解
這篇文章主要介紹了Mysql?COUNT()函數(shù)基本用法及應(yīng)用的相關(guān)資料,COUNT()函數(shù)是SQL中常用的聚合函數(shù),用于統(tǒng)計滿足特定條件的記錄數(shù),它可以靈活地應(yīng)用于各種查詢場景,幫助用戶快速獲取所需的數(shù)據(jù)統(tǒng)計信息,需要的朋友可以參考下2024-12-12