MySQL Redo Log

MySQL Redo Log

MySQL主從復制：https://blog.csdn.net/a18792721831/article/details/146117935
MySQL Binlog：https://blog.csdn.net/a18792721831/article/details/146606305
MySQL General Log：https://blog.csdn.net/a18792721831/article/details/146607343
MySQL Slow Log：https://blog.csdn.net/a18792721831/article/details/147166971
MySQL Error Log：https://blog.csdn.net/a18792721831/article/details/147167038
MySQL Redo Log: https://blog.csdn.net/a18792721831/article/details/149862528
MySQL Undo Log: https://blog.csdn.net/a18792721831/article/details/149880355

MySQL Redo Log

  • Redo Log 介紹
  • Redo Log 的落盤
  • Redo Log 的數量及大小修改
  • CheckPoint
  • LSN
  • Mysql 8.0 的 Redo Log 歸檔
  • Mysql 8.0 中的 Redo Log 禁用
  • 官網文檔

InnoDB使用 Redo Log 來保證數據的一致性和可持久化。

Redo Log 介紹

MySQL采用的是WAL(Write-Ahead Logging)技術，也就是先寫日志在寫磁盤。如果有修改操作，則先將操作記錄在 Redo Log 中，然后將 Redo Log Buffer 中的數據刷新到磁盤的日志文件中，最后寫入數據文件中。

Redo Log 記錄了這個頁做了什么改動，對Redo Log 進行落盤，不僅可以保證數據持久化，還可以提高寫入效率。

  • MySQL如果每次都按頁落盤，即使有少量數據的修改，每次落盤也是整個數據頁，那么IO成本將會非常高。而Redo Log 記錄的是緩沖池中頁的修改記錄，因此每次只需要對 Redo Log 進行落盤，而不需要對整個頁落盤。大大降低了落盤的數據量，節約成本，提高寫入效率。
  • 如果每次都是將頁落盤，那么頁會在不同的位置，因此落盤時基本上就是隨機IO，而有了Redo Log，只將Redo Log 落盤，就可以將這些隨機 IO 轉換成順序IO ,這樣也可以提高寫入效率。

Redo Log 另一個很重要的作用就是崩潰恢復能力。事務在提交時會把Redo Log 刷新到磁盤中，如果此時系統宕機了，那么重啟之后，只需要根據 Redo Log 的記錄把數據頁未更新的部分更新一下，就可以恢復事務所做的數據變更。

Redo Log 的落盤

Redo Log 由兩部分組成: Redo Log 緩沖區和 Redo Log 文件。

Redo Log 緩沖區的大小通過 innodb_log_buffer_size 參數來設置。通過 show global variables like 'innodb_log_buffer_size';查看

image-20250412170026934

16777216B=16384K=16M

當事務更新時，一般先寫入Redo Log 緩沖區，在寫入 Redo Log 文件。而具體的寫入頻率由innodb_flush_log_at_trx_commit參數控制。查看 show global variables like 'innodb_flush_log_at_trx_commit';

image-20250412170324262

innodb_flush_log_at_trx_commit參數有3個有效值：

  • 0，每秒將日志緩沖區寫入日志文件一次，并在日志文件上執行磁盤刷新操作，未刷新日志的事務可能會在崩潰中丟失，此時 InnoDB不在符合事務持久性的要求。
  • 1，在每次提交事務時，日志緩沖區都會寫入日志文件中，并在日志文件上執行磁盤刷新操作。
  • 2，在每次提交事務后寫入日志，并且日志每秒刷新一次到磁盤。未刷新日志的事務可能會在崩潰中丟失。當MySQL服務發生宕機，但操作系統沒有發生宕機時，不會出現數據丟失。但是當操作系統宕機時，重啟后可能會丟失Redo Log 緩沖中還沒有刷新到 Redo Log 文件中的數據。

選擇不同的落盤頻率，對于MySQL的性能存在一定的影響

創建一張表，用于驗證性能

use test;
drop table if exists test_redo;
create table `test_redo`(
`id` int not null auto_increment,
`a` varchar(20) default null,
`b` int default null,
`c` datetime not null default current_timestamp,
primary key (`id`)
) engine=innodb charset=utf8mb4;
drop procedure if exists test_insert;
delimiter ;;
create procedure test_insert()
begin
declare i int;
set i = 1;
while(i <= 100000) do
insert into test_redo(a,b) values(i,i);
set i=i+1;
end while;
end;;
delimiter ;

執行

image-20250412172229332

執行**set global innodb_flush_log_at_trx_commit=0**后，調用 test_insert插入10萬的數據

image-20250412172936711

花費了3分27秒5，也就是207.5秒。

執行**set global innodb_flush_log_at_trx_commit=1**,調用test_insert插入10萬數據

image-20250412173943934

花費了6分55秒4，也就是415.4秒，是等于0的2倍

執行**set global innodb_flush_log_at_trx_commit=2**，調用test_insert插入10萬數據

image-20250412174656848

和等于0差不多。

innodb_flush_log_at_trx_commit參數設置為0或2的寫入速度比設置為1的寫入速度快很多。但是如果某個MySQL實例將 innodb_flush_log_at_trx_commit參數設置為0或2，那么它其實已經不具備ACID中的D(Durability,持久性)。在一般情況下，建議將innodb_flush_log_at_trx_commit參數設置為1，這樣可以保證MySQL在崩潰恢復時數據不丟失。

Redo Log 的數量及大小修改

MySQL啟動后，Redo Log 的大小和個數就是固定的，比如可以配置3個大小為2GB的Redo Log，文件名類似于 ib_logfile0。Redo Log 是循環寫的。

從 MySQL 8.0.30 開始，支持“多文件”redo log，文件名格式為：#ib_redo<N>

https://dev.mysql.com/doc/refman/8.0/en/innodb-redo-log.html#innodb-redo-log-multiple-files

從MySQL 從 8.0.30 版本（2022年7月發布）開始，對 InnoDB 的 redo log 存儲方式進行了重大調整，將傳統的 ib_logfile0、ib_logfile1 文件改為存儲在 #innodb_redo 目錄中

https://dev.mysql.com/doc/refman/8.0/en/innodb-redo-log.html

Clipboard_Screenshot_1745236922

image-20250421200242503

帶有 _tmp是備用redo_log。因為在 mysql 8.0 中增加了動態調整 redo_log大小的能力，在調整過程中，會使用備用redo_log，直到調整完成。

使用文件 rename 防止在動態調整過程中因為宕機導致的文件丟失。

相關參數

參數默認值說明
innodb_redo_log_directory./#innodb_redo指定 redo log 目錄路徑（可獨立于數據目錄）
innodb_redo_log_capacity104857600 (100MB)總 redo log 容量（動態調整，單位：字節）
innodb_redo_log_files32最大 redo log 文件數（自動管理實際使用數）

image-20250421200404372

image-20250528173259715

從第一個文件開始寫，當redo_log0寫滿了，在寫redo_log1,直到最后一個redo_log也寫滿了，繼續從第一個文件開始寫。其中 write pos是當前記錄的位置，一邊寫一邊移動；CheckPoint是當前要擦除的位置，也是向后推移的。擦除記錄前會確保記錄已經更新到數據文件中。

RodoLog 幾個重要的參數：

  • Innodb_log_group_home_dir:控制 Redo Log 的存放路徑，如果沒有配置，默認在數據目錄下

    image-20250802144856927

    image-20250802144948081

    如果要修改，需要修改 mysql.cnf文件

    先在mysql目錄下創建redolog目錄,記得修改權限

    image-20250802160718676

    接著在redolog目錄下創建'#innodb_redo'目錄，記得修改目錄權限為 750 ，文件權限為 640 ，并且修改權限組為 ‘999:999’

    docker 中mysql 以999 的uid執行

    接著配置Redo Log 的目錄為新創建的目錄

    [mysqld]
server_id=100
log_bin=/var/lib/mysql-bin/mysql-bin
binlog_format=row
early-plugin-load=keyring_file.so
keyring_file_data=/var/lib/mysql/keyring
binlog_encryption=on
log-error=/var/log/mysql/mysql-error.log
innodb_log_group_home_dir=/var/lib/mysql-redolog

    然后重啟

    docker run \
--name master \
-e MYSQL_ROOT_PASSWORD=master \
-v /data/mysql/master/log:/var/log/mysql \
-v /data/mysql/master/data:/var/lib/mysql \
-v /data/mysql/master/conf:/etc/mysql/conf.d \
-v /data/mysql/master/binlog:/var/lib/mysql-bin \
-v /data/mysql/master/redolog1:/var/lib/mysql-redolog \
-p 3106:3306 \
-d \
mysql:8.0

    啟動后mysql會在新的redolog目錄下創建redofile

    image-20250802165310731

  • innodb_log_file_size:控制Redo Log的大小，默認值為 48Mb,但是不能超過 512GB除以 innodb_log_files_in_group 參數配置的值，如果 innodb_log_files_in_group 參數的值為2，那么 innodb_log_file_size 參數的最大值為256G.

    如果innodb_redo_file_size 參數設置的太小，那么有可能導致Mysql 的redolog 頻繁切換，頻繁的觸發數據的 CheckPoint，刷新臟頁的次數隨之增加，從而影響IO性能。

    如果有一個大的事務把所有的Redo Log 寫滿了還沒有寫完，就會導致日志不能切換，Mysql 有可能就不能正常提供服務了。

    如果參數設置的太大，雖然可以提升IO性能，但是當Mysql宕機時，恢復的時間也很長。

  • Innodb_log_files_in_group:控制Redo Log的文件數量

CheckPoint

CheckPoint 是Redo Log 中當前要擦除的位置，Redo Log 在擦除記錄前會確保記錄已經更新到數據文件中。因此，也可以認為CheckPoint就是控制數據頁刷新到磁盤的操作。

如果發生宕機重啟，那么將會從CheckPoint之后開始恢復，之前已經刷新的數據頁不需要恢復。

LSN

Innodb的LSN(Log Sequence Number, 日志序列號)。

LSN用來精確記錄Redo Log的位置信息，大小為 8 字節(mysql 5.6.3 之前是4字節)。

LSN的值是根據Redo Log 寫入量計算的，寫入多少字節的Log, LSN就增長多少。

可以通過 show engine InnoDB status\G查看


=====================================
2025-08-02 09:10:54 140514356577856 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 2 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 1 srv_active, 0 srv_shutdown, 676 srv_idle
srv_master_thread log flush and writes: 0
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 10
OS WAIT ARRAY INFO: signal count 12
RW-shared spins 0, rounds 0, OS waits 0
RW-excl spins 0, rounds 0, OS waits 0
RW-sx spins 0, rounds 0, OS waits 0
Spin rounds per wait: 0.00 RW-shared, 0.00 RW-excl, 0.00 RW-sx
------------
TRANSACTIONS
------------
Trx id counter 5902
Purge done for trx's n:o < 5899 undo n:o < 0 state: running but idle
History list length 0
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 421989504019672, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 421989504018864, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 421989504018056, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
--------
FILE I/O
--------
I/O thread 0 state: waiting for completed aio requests (insert buffer thread)
I/O thread 1 state: waiting for completed aio requests (read thread)
I/O thread 2 state: waiting for completed aio requests (read thread)
I/O thread 3 state: waiting for completed aio requests (read thread)
I/O thread 4 state: waiting for completed aio requests (read thread)
I/O thread 5 state: waiting for completed aio requests (write thread)
I/O thread 6 state: waiting for completed aio requests (write thread)
I/O thread 7 state: waiting for completed aio requests (write thread)
I/O thread 8 state: waiting for completed aio requests (write thread)
Pending normal aio reads: [0, 0, 0, 0] , aio writes: [0, 0, 0, 0] ,ibuf aio reads:
Pending flushes (fsync) log: 0; buffer pool: 0
874 OS file reads, 275 OS file writes, 108 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:insert 0, delete mark 0, delete 0
discarded operations:insert 0, delete mark 0, delete 0
Hash table size 34679, node heap has 3 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 1 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
0.00 hash searches/s, 0.00 non-hash searches/s
---
LOG
---
Log sequence number          29869673
Log buffer assigned up to    29869673
Log buffer completed up to   29869673
Log written up to            29869673
Log flushed up to            29869673
Added dirty pages up to      29869673
Pages flushed up to          29869673
Last checkpoint at           29869673
Log minimum file id is       0
Log maximum file id is       0
32 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 0
Dictionary memory allocated 489041
Buffer pool size   8192
Free buffers       7192
Database pages     996
Old database pages 387
Modified db pages  0
Pending reads      0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 0, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 853, created 143, written 201
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
No buffer pool page gets since the last printout
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 996, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
0 read views open inside InnoDB
Process ID=1, Main thread ID=140514029545024 , state=sleeping
Number of rows inserted 0, updated 0, deleted 0, read 0
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
Number of system rows inserted 8, updated 331, deleted 8, read 4791
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
  • Log sequence number: 表示整個數據庫最新的LSN值
  • Log flushed up to: 表示最新寫入日志文件的事務產生的LSN值
  • Last checkpoint at:表示最新的數據頁刷新到磁盤時的LSN值

Mysql 8.0 的 Redo Log 歸檔

在數據備份過程中可能會復制 Redo Log。如果Mysql 的寫入比較多，那么復制 Redo Log 的速度就會跟不上 Redo Log的生成速度。加上Redo Log是以覆蓋方式記錄的，就有可能會丟失部分Redo Log。

Mysql 8.0.17 引入了 Redo Log 歸檔，按照 Redo Log 記錄順序寫入歸檔文件中，以解決備份時Redo Log丟失的問題。

Redo Log 的歸檔由innodb_redo_log_archive_dirs參數控制。

首先創建一個Redo Log 的歸檔文件夾：

image-20250802171922474

設置參數

image-20250802172022591

因為是docker 啟動的MySQL，因此需要先關閉MySQL，在將 Redo Log 掛載進去

docker run \
--name master \
-e MYSQL_ROOT_PASSWORD=master \
-v /data/mysql/master/log:/var/log/mysql \
-v /data/mysql/master/data:/var/lib/mysql \
-v /data/mysql/master/conf:/etc/mysql/conf.d \
-v /data/mysql/master/binlog:/var/lib/mysql-bin \
-v /data/mysql/master/redolog:/var/lib/mysql-redolog \
-v /data/mysql/master/redolog_archive:/var/lib/mysql-redolog-archive \
-p 3106:3306 \
-d \
mysql:8.0

image-20250802172233975

設置Redo Log 的歸檔目錄

set global innodb_redo_log_archive_dirs='redolog-archiving:/var/lib/mysql-redolog-archive';

redolog-archiving 表示歸檔目錄的標識符，冒號后面的才是歸檔目錄

image-20250802172432785

注意此時僅僅是設置了Redo Log 的歸檔目錄，mysql不會自動開始歸檔

image-20250802172549315

還需要啟動歸檔

do innodb_redo_log_archive_start("redolog-archiving", "redo-0001");

需要注意，如果mysql實例被禁用了Redo Log ，那么啟動歸檔會失敗

Error executing DO statement. You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘"’ at line 1 - Connection: master: 350ms

redolog-archiving是定義的歸檔目錄的標識符，redo-0001是保存歸檔文件的子目錄。

使用show global status like 'innodb_redo_log_enabled'查看是否禁用

image-20250802172940570

使用alter instance enable innodb redo_log;啟用Redo Log

image-20250802173022662

需要注意的是如果需要使用子目錄，比如 redo-0001，此時需要自己創建

Error executing DO statement. Redo log archive directory ‘/var/lib/mysql-redolog-archive/redo-0001’ does not exist or is not a directory - Connection: master: 311ms

image-20250802173219230

創建了目錄，并且正確的設置了權限后，就會成功啟動

DO statement executed successfully. - Connection: master: 210ms

接著查看歸檔目錄

image-20250802173307100

此時會在Redo Log的歸檔目錄下創建對應的Sql文件

執行一個sql，看看會不會刷新到歸檔目錄的sql文件中

create database test;
use test;
create table t(id int,name varchar(256));
insert into t values(1, 'test');

image-20250802173622901

image-20250802174138833

停止歸檔

do innodb_redo_log_archive_stop();

image-20250802174350757

Mysql 8.0 中的 Redo Log 禁用

從 Mysql 8.0.21開始可以禁用 Redo Log。

可以在數據導入過程中加速。

Mysql 即使禁用 Redo Log，在Mysql 啟動時，依然會檢查 Redo Log 目錄，并且如果Redo Log目錄中存在CheckPoint之后的數據，依然會檢查完整性，并嘗試恢復數據。

只有當Mysql啟動后，才能禁用 Redo Log。禁用后會永久生效。

禁用

alter instance disable innodb redo_log;

查看

SHOW GLOBAL STATUS LIKE 'Innodb_redo_log_enabled';

啟用

alter instance enable innodb redo_log;

從實際測試情況來看，禁用與啟用 redo log 有 10%~30% 的執行時間差異

https://segmentfault.com/a/1190000023415055

官網文檔

https://dev.mysql.com/doc/refman/8.4/en/innodb-redo-log.html

本文來自互聯網用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。
如若轉載，請注明出處：http://www.pswp.cn/bicheng/91930.shtml
繁體地址，請注明出處：http://hk.pswp.cn/bicheng/91930.shtml
英文地址，請注明出處：http://en.pswp.cn/bicheng/91930.shtml

如若內容造成侵權/違法違規/事實不符，請聯系多彩編程網進行投訴反饋email:809451989@qq.com，一經查實，立即刪除！

相關文章

項目實戰1：Rsync + Sersync 實現文件實時同步

項目實戰1：Rsync + Sersync 實現文件實時同步

項目實戰&#xff1a;Rsync Sersync 實現文件實時同步 客戶端中數據發生變化&#xff0c;同步到server端&#xff08;備份服務器&#xff09;。 Rsync&#xff1a;負責數據同步&#xff0c;部署在server端。 Sersync&#xff1a;負責監控數據目錄變化&#xff0c;并調用rsync進…
閱讀更多...
Spring Boot 全 YAML 配置 Liquibase 教程

Spring Boot 全 YAML 配置 Liquibase 教程

一、項目初始化配置 1.1 創建 Spring Boot 項目 通過 Spring Initializr 生成基礎項目&#xff0c;配置如下&#xff1a; ??Project??: Maven??Language??: Java??Spring Boot??: 3.5.3&#xff08;最新穩定版&#xff09;??Project Metadata??: Group: com…
閱讀更多...
STM32-驅動OLED顯示屏使用SPI（軟件模擬時序）實現

STM32-驅動OLED顯示屏使用SPI（軟件模擬時序）實現

本章概述思維導圖&#xff1a;SPI通信協議SPI通信協議介紹SPI通訊&#xff1a;高速的、串行通訊、全雙工、同步、總線協議&#xff1b;&#xff08;通過片選信號選中設備&#xff09;&#xff1b;注&#xff1a;SPI通訊通過片選信號選中設備&#xff0c;串口通訊通過端口號選中…
閱讀更多...
Easy系列PLC相對運動指令實現定長輸送(ST源代碼)

Easy系列PLC相對運動指令實現定長輸送(ST源代碼)

匯川Easy系列PLC總線伺服轉矩控制功能塊 Easy系列PLC總線伺服轉矩控制功能塊(詳細PDO配置+完整ST源代碼)_pdo中添加目標力矩然后映射到軸中-CSDN博客文章瀏覽閱讀215次。Easy系列PLC如何實現輪廓速度模式PV速度模式Easy系列PLC如何實現輪廓速度模式PV速度控制_匯川easy plc輪廓…
閱讀更多...
SpringCloud學習第一季-4

SpringCloud學習第一季-4

目錄 16.SpringCloud Alibaba Nacos服務注冊和配置中心 SpringCloud Alibaba簡介 1. 為什么出現 SpringCloud Alibaba 2. SpringCloud Alibaba帶來了什么 2.1 能干什么 2.2 去哪里下載 2.3 怎么玩 3. 學習資料的獲取 17.SpringCloud Alibaba Nacos服務注冊和配置中心 …
閱讀更多...
嵌入式開發學習———Linux環境下數據結構學習（五）

嵌入式開發學習———Linux環境下數據結構學習（五）

折半查找&#xff08;二分查找&#xff09;適用于已排序的數組&#xff0c;通過不斷縮小查找范圍定位目標值。int binarySearch(int arr[], int size, int target) {int left 0, right size - 1;while (left < right) {int mid left (right - left) / 2;if (arr[mid] t…
閱讀更多...
（一）React +Ts（vite創建項目/useState/Props/Interface）

（一）React +Ts（vite創建項目/useState/Props/Interface）

文章目錄 項目地址 一、React基礎 1.1 vite創建 1. 創建項目 2. 安裝項目所需環境 1.2 jsx 1. 三元表達式 1.3 基礎 1. 創建第一個組件 2. 安裝boostrap 3. 插件常用命令 4. map 二、組件 2.1 useState 1. useState 2. 使用 3.更新對象 4. 更新數組（增，刪，改） 5. 使用immer…
閱讀更多...
網關和BFF是如何演化的

網關和BFF是如何演化的

BFF&#xff08;Backend For Frontend&#xff09;:對返回的數據結構進行聚合、裁剪、透傳等適配邏輯。 適用于API網關之后的數據聚合、裁剪與透傳簡化客戶端邏輯&#xff0c;減少網絡開銷敏感數據過濾 BFF邏輯層 架構沒有最好&#xff0c;要看是否滿足當前的業務場景。 業務的…
閱讀更多...
SQL中的WITH語句（公共表表達式CTE）解釋

SQL中的WITH語句（公共表表達式CTE）解釋

SQL中的WITH語句&#xff08;公共表表達式CTE&#xff09; WITH語句&#xff0c;也稱為公共表表達式&#xff08;Common Table Expression&#xff0c;CTE&#xff09;&#xff0c;是SQL中一種強大的功能&#xff0c;它允許你創建臨時結果集&#xff0c;這些結果集可以在后續的…
閱讀更多...
服務器地域選擇指南：深度分析北京/上海/廣州節點對網站速度的影響

服務器地域選擇指南：深度分析北京/上海/廣州節點對網站速度的影響

更多云服務器知識&#xff0c;盡在hostol.com你準備開一個覆蓋全國的線上零食店&#xff0c;現在萬事俱備&#xff0c;只差一個核心問題沒解決&#xff1a;你唯一的那個總倉庫&#xff0c;應該建在哪里&#xff1f;是建在哈爾濱&#xff0c;讓南方的朋友下單后&#xff0c;一包…
閱讀更多...
桶排序-Java實現

桶排序-Java實現

桶排序是一種分配式排序算法&#xff0c;將元素分到有限數量的桶里&#xff0c;每個桶再單獨排序&#xff08;比如用插入排序&#xff09;&#xff0c;最后依次把各個桶中的元素取出來即完成排序。 時間復雜度&#xff1a;最佳 O(n) | 平均 O(n n/k k) | 最差 O(n) 空間復雜…
閱讀更多...
oracle知識

oracle知識

這里寫自定義目錄標題Oracle常用的數據類型&#xff1a;Oracle實操&#xff1a;創建數據表Oracle約束建表的時候設置約束&#xff1a;表創建后添加添加約束&#xff1a;Oracle常用的數據類型&#xff1a; Oracle實操&#xff1a;創建數據表 Oracle約束 建表的時候設置約束&…
閱讀更多...
超級人工智能+無人機操控系統，振興鄉村經濟的加速器，（申請專利應用），嚴禁抄襲！

超級人工智能+無人機操控系統，振興鄉村經濟的加速器，（申請專利應用），嚴禁抄襲！

無人機邊緣智能系統&#xff1a;山林珍稀資源探測的完整架構與實戰指南本人設計的多模態邊緣AI系統已在秦嶺山區完成實地驗證&#xff0c;對7種高價值食用菌識別準確率達94.3%&#xff0c;定位誤差小于0.8米一、前沿技術融合的商業化機遇根據Gartner 2025年技術成熟度曲線分析&…
閱讀更多...
用騰訊地圖寫一個逆地址解析（很詳細）

用騰訊地圖寫一個逆地址解析（很詳細）

首先說明以下代碼適合有前端基礎知識的同學。以下是css和html部分<!DOCTYPE html><html lang"zh-CN"><!-- lang是用來申明語言類型&#xff0c;這里申明為中文&#xff08;zh&#xff09;中國大陸&#xff08;CN&#xff09;補充中文繁體為zh-TW --&g…
閱讀更多...
在 Vue3+Vite+TypeScript 項目中使用 svg 文件并支持自定義樣式

在 Vue3+Vite+TypeScript 項目中使用 svg 文件并支持自定義樣式

參考文檔&#xff1a;vite-svg-loader 安裝與配置 安裝插件 pnpm add vite-svg-loader -D配置 // vite.config.ts import svgLoader from vite-svg-loaderexport default defineConfig({plugins: [vue(),svgLoader({defaultImport: component})] })使用 <script setup …
閱讀更多...
ShimetaPi M4-R1：國產高性能嵌入式平臺的異構計算架構與OpenHarmony生態實踐

ShimetaPi M4-R1：國產高性能嵌入式平臺的異構計算架構與OpenHarmony生態實踐

在全球化芯片供應鏈波動及樹莓派等硬件持續漲價的背景下&#xff0c;ShimetaPi M4-R1 作為全棧國產化嵌入式開發平臺&#xff0c;以 高性能異構計算架構 和 開源鴻蒙原生支持 為核心突破點&#xff0c;填補了中高端邊緣設備開發的國產方案空白。其基于瑞芯微 RK3568B2 的硬件設…
閱讀更多...
zookeeper分布式鎖 -- 讀鎖和寫鎖實現方式

zookeeper分布式鎖 -- 讀鎖和寫鎖實現方式

讀鎖和寫鎖讀鎖: 是共享鎖,讀鎖與讀鎖是可以兼容的,所以同時有多個請求都可以持有寫鎖: 是獨占鎖,寫鎖與任何鎖都互斥,所以只有一個請求持有,這個請求釋放寫鎖其他請求才能持有一旦持有寫鎖,說明數據在發送變化就不能讀了,自然一個請求就不能出現讀鎖和寫鎖共存的情況總結: 讀鎖…
閱讀更多...
第二篇：Linux 文件系統操作：從基礎到進階

第二篇：Linux 文件系統操作：從基礎到進階

目錄 一、文件與目錄管理基礎 創建文件 創建目錄 目錄結構查看 二、鏈接文件深入理解 創建軟鏈接 創建硬鏈接 核心區別對比 三、文件壓縮與解壓縮全攻略 1、壓縮命令對比 2、解壓縮命令 3、三種壓縮方式性能對比 4、通用解壓技巧 四、文件查找與搜索 1、按文件名…
閱讀更多...
嗶哩嗶哩招游戲內容產品運營

嗶哩嗶哩招游戲內容產品運營

游戲內容產品運營【2026屆】&#xff08;崗位信息已獲jobleap.cn授權轉發到csdn&#xff09;嗶哩嗶哩集團 上海收錄時間&#xff1a; 2025年08月01日職位描述1、負責研究B站游戲創作者的創作過程、動機及遇到的問題&#xff0c;產出研究報告&#xff1b; 2、結合用研分析和相關…
閱讀更多...
談談Flutter中的Key

談談Flutter中的Key

目錄 前言 一、什么是Key 1.StatelessWidget 2.StatefulWidget 3.加入Key后的效果 二、什么時候應該使用 Key&#xff1f; 1.Flutter判斷widget的邏輯 1.Flutter判斷組件身份的規則 1.Widget的類型&#xff08;runtimeType&#xff09;相同 2. Key相同&#xff08;ke…
閱讀更多...
最新文章

Copyright @ 2022~2023