mysql 頁的理解和實際分析

目錄

      • 頁（Page）是 Innodb 存儲引擎用于管理數據的最小磁盤單位
        • B+樹的一般高度
        • 記錄在頁中的存儲
      • innodb ibd文件
        • innodb 頁類型
        • 分析`ibd`文件
          • 查看數據表的行格式
          • 查看ibd文件
        • 分析 ibd的第4個頁：`B-tree Node`類型
          • 先分析File Header(38字節-描述頁信息)
          • 再分析Page Header（56字節-記錄頁的狀態信息）
          • 分析Infimum + Supremum Record (26字節-兩個虛擬行記錄)
          • User Record(表中的數據記錄)
          • COMPACT行記錄格式
          • File Tailer(最后8字節)
      • 附：二進制文件查看小技巧
      • 頁分裂/頁合并
        • innodb數據的存儲
        • 頁合并
        • 頁分裂
      • 附加：mysql頻繁的插入刪除導致的問題
        • 1. 性能下降
        • 2. 碎片化
        • 3. 鎖定和阻塞
        • 4. 日志文件增長
        • 5. 資源競爭

頁（Page）是 Innodb 存儲引擎用于管理數據的最小磁盤單位

innoDB 中頁的默認大小是 16KB

假設一行記錄的數據大小為1k，那么單個葉子節點（頁）中的記錄數=16K/1K=16

在這里插入圖片描述

  1. File Header: 文件頭部，頁的一些通用信息（38字節）
  2. page Header: 頁面頭部,數據頁專有的一些信息（56字節）
  3. infimum+supremum: 行記錄最小值和最大值，兩個虛擬的行記錄（26字節）
  4. user recorders: 實際存儲的行記錄內容（不確定）
  5. free space: 頁中尚未使用的空間（不確定）
  6. Page Directory: 頁中的某些記錄的相對位置（不確定）
  7. File Tailer: 校驗頁是否完整（8字節）
B+樹的一般高度

即非葉子節點能存放多少指針？

假設主鍵ID為bigint類型，長度為8字節，而指針大小在InnoDB源碼中設置為6字節，這樣一共14字節，一個頁中能存放多少這樣的單元，其實就代表有多少指針，即16kb/14b=1170；那么可以算出一棵高度為2的B+樹，大概能存放1170*16=18720條這樣的數據記錄(即1170個索引，每個索引定位葉子節點的一頁數據，一頁能存儲16行原始數據)。

根據同樣的原理我們可以算出一個高度為3的B+樹大概可以存放：1170*1170*16=21,902,400行數據。所以在InnoDB中B+樹高度一般為1-3層，它就能滿足千萬級的數據存儲。在查找數據時一次頁的查找代表一次IO，所以通過主鍵索引查詢通常只需要1-3次邏輯IO操作即可查找到數據。

記錄在頁中的存儲
  1. 當一個記錄需要插入頁的時候，會從Free space劃分空間到User recorders
  2. Free Space部分的空間全部被User Records部分替代掉之后，也就意味著這個頁使用完了，如果還有新的記錄插入的話，就需要去申請新的頁了

innodb ibd文件

ibd文件是以頁為單位進行管理的，頁通常是以16k為單位，所以ibd文件通常是16k的整數倍

innodb 頁類型
名稱十六進制解釋
FIL_PAGE_INDEX0x45BFB+樹葉節點
FIL_PAGE_UNDO_LOGO0x0002UNDO LOG頁
FIL_PAGE_INODE0x0003索引節點
FIL_PAGE_IBUF_FREE_LIST0x0004InsertBuffer空閑列表
FIL_PAGE_TYPE_ALLOCATED0x0000該頁的最新分配
FIL_PAGE_IBUF_BITMAP0x0005InsertBuffer位圖
FIL_PAGE_TYPE_SYS0x0006系統頁
FIL_PAGE_TYPE_TRX_SYS0x0007事務系統數據
FIL_PAGE_TYPE_FSP_HDR0x0008FILE SPACE HEADER
FIL_PAGE_TYPE_XDES0x0009擴展描述頁
FIL_PAGE_TYPE_BLOB0x000ABLOB頁
分析ibd文件
mubi@mubideMacBook-Pro bin $ mysql -uroot -p123456
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 109
Server version: 5.6.40 MySQL Community Server (GPL)Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved.Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -ADatabase changed
mysql> select * from tb_user;
+------------+--------+----------+-------+-------------+----------+
| id         | userID | password | name  | phone       | address  |
+------------+--------+----------+-------+-------------+----------+
|          1 | 00001  | 123456   | zhang | 15133339999 | Shanghai |
|          2 | 00002  | 123456   | wang  | 15133339999 | Beijing  |
|          4 | 0003   | NULL     | abc   | NULL        | NULL     |
|          6 | 0003   | NULL     | abc   | NULL        | NULL     |
|          7 | 0004   | 123456   | tom   | 110         | beijing  |
|         10 | 0004   | 123456   | tom   | 110         | beijing  |
| 2147483647 | 0004   | 123456   | tom   | 110         | beijing  |
+------------+--------+----------+-------+-------------+----------+
7 rows in set (0.00 sec)mysql>
查看數據表的行格式
mysql> show table status like 'tb_user'\G;
*************************** 1. row ***************************Name: tb_userEngine: InnoDBVersion: 10Row_format: CompactRows: 6Avg_row_length: 2730Data_length: 16384
Max_data_length: 0Index_length: 16384Data_free: 0Auto_increment: 2147483647Create_time: 2020-03-21 16:10:06Update_time: NULLCheck_time: NULLCollation: utf8_general_ciChecksum: NULLCreate_options:Comment:
1 row in set (0.00 sec)ERROR:
No query specifiedmysql>
查看ibd文件

在這里插入圖片描述

使用py_innodb_page_info工具（https://github.com/happieme/py_innodb_page_info）

在這里插入圖片描述

注意到文件大小114688字節（114688 = 16 * 1024 * 7）即有7個頁（要分析哪個頁直接定位到二進制文件到開始，然后分析即可）

分析 ibd的第4個頁：B-tree Node類型

page offset 00000003, page type <B-tree Node>, page level <0000>

>>> hex(3 * 16 * 1024)
'0xc000'
>>> hex(4 * 16 * 1024)
'0x10000'
>>>
先分析File Header(38字節-描述頁信息)

在這里插入圖片描述

  • 2D A1 2D 57 -> 數據頁的checksum值
  • 00 00 00 03 -> 頁號（偏移量）,當前是第3頁
  • FF FF FF FF -> 目前只有一個數據頁，無上一頁
  • FF FF FF FF -> 目前只有一個數據頁，無下一頁
  • 00 00 00 04 6F 65 24 CF -> 該頁最后被修改的LSN
  • 45 BF -> 頁的類型，0x45BF代表數據頁，剛好這頁是數據頁
  • 00 00 00 00 00 00 00 00 -> 獨立表空間，該值為0
  • 00 00 00 06 -> 表空間的SPACE ID
再分析Page Header（56字節-記錄頁的狀態信息）

參見：innodb-page-header

在這里插入圖片描述

標識字節數解釋本次值:說明
PAGE_N_DIR_SLOTS2number of directory slots in the Page Directory part; initial value = 200 02,2個槽位
PAGE_HEAP_TOP2record pointer to first record in heap01 ED，堆第一個開始位置的偏移量，也即空閑偏移量
PAGE_N_HEAP2number of heap records; initial value = 280 0A
PAGE_FREE2record pointer to first free record01 1C
PAGE_GARBAGE2“number of bytes in deleted records”00 20，刪除的記錄字節
PAGE_LAST_INSERT2record pointer to the last inserted record01 C5，最后插入記錄的位置偏移
PAGE_DIRECTION2either PAGE_LEFT, PAGE_RIGHT, or PAGE_NO_DIRECTION00 02，自增長的方式進行行記錄的插入，方向向右
PAGE_N_DIRECTION2number of consecutive inserts in the same direction, for example, “last 5 were all to the left”00 02
PAGE_N_RECS2number of up[ser records00 07，共7條有效記錄數
PAGE_MAX_TRX_ID8the highest ID of a transaction which might have changed a record on the page (only set for secondary indexes)00 00 00 00 00 00 00 00
PAGE_LEVEL2level within the index (0 for a leaf page)00 00
PAGE_INDEX_ID8identifier of the index the page belongs to00 00 00 00 00 00 00 16
PAGE_BTR10“file segment header for the leaf pages in a B-tree” (this is irrelevant here)00 00 00 06 00 00 00 02 00 F2
PAGE_LEVEL10“file segment header for the non-leaf pages in a B-tree” (this is irrelevant here)00 00 00 06 00 00 00 02 00 32
  • 0xc000 + 01 ED = 0xC1ED地址后面的都是空閑的

在這里插入圖片描述

  • 0xc000 + 01 C5 = 0xC1C5最后一條記錄
    在這里插入圖片描述
分析Infimum + Supremum Record (26字節-兩個虛擬行記錄)

infimum: n. 下確界;
supremum: n. 上確界;

Infimum和Suprenum Record用來限定記錄的邊界，Infimum是比頁中任何主鍵值都要小的值，Suprenum是指比任何頁中可能大值還要大的值，這兩個值在頁創建時被建立，并且在任何情況下都不會被刪除。Infimum和Suprenum與行記錄組成單鏈表結構，查詢記錄時，從Infimum開始查找，如果找不到結果會直到查到最后的Suprenum為止，然后通過Page Header中的FIL_PAGE_NEXT指針跳轉到下一個page繼續從Infimum開始逐個查找

在這里插入圖片描述

#Infimum偽行記錄
01 00 02 00 20/*recorder header*/
69 6E 66 69 6D 75 6D 00/*只有一個列的偽行記錄，記錄內容就是Infimum（多了一個0x00字節）
*/
#Supremum偽行記錄
08 00 0B 00 00/*recorder header*/
73 75 70 72 65 6D 75 6D/*只有一個列的偽行記錄，記錄內容就是Supremum*/

infimum行記錄的recorder header部分，最后2個字節位00 20表示下一個記錄的位置的偏移量

User Record(表中的數據記錄)

用戶所有插入的記錄都存放在這里，默認情況下記錄跟記錄之間沒有間隙，但是如果重用了已刪除記錄的空間，就會導致空間碎片。每個記錄都有指向下一個記錄的指針，但是沒有指向上一個記錄的指針。記錄按照主鍵順序排序:即用戶可以從數據頁最小記錄開始遍歷，直到最大的記錄，這包括了所有正常的記錄和所有被delete-marked記錄，但是不會訪問到被刪除的記錄(PAGE_FREE)

COMPACT行記錄格式

在這里插入圖片描述

  • 行格式的首部是一個非NULL變長字段長度列表，而且是按照列的順序逆序放置的。當列的長度小于255字節，用1字節表示，若大于255個字節，用2個字節表示，變長字段的長度最大不可以超過2個字節（這也很好地解釋了為什么MySQL中varchar的最大長度為65535，因為2個字節為16位，即pow(2,16)-1=65536）。第二個部分是NULL標志位，該位指示了該行數據中是否有NULL值，1個字節表示；該部分所占的字節應該為bytes；接下去的部分是為記錄頭信息（record header），固定占用5個字節（40位），每位的含義如下

  • 預留位1 1（bit位） 沒有使用

  • 預留位2 1 沒有使用

  • delete_mask 1 標記該記錄是否被刪除

  • min_rec_mask 1 標記該記錄是否為B+樹的非葉子節點中的最小記錄

  • n_owned 4 表示當前槽管理的記錄數

  • heap_no 13 表示當前記錄在記錄堆的位置信息

  • record_type 3 表示當前記錄的類型，0表示普通記錄，1表示B+樹非葉節點記錄，2表示最小記錄，3表示最大記錄

  • next_record 16 表示下一條記錄的相對位置

在這里插入圖片描述

File Tailer(最后8字節)

在這里插入圖片描述

7E 75 29 30 6F 65 24 CF

注意到File Header該頁最后被修改的LSN：00 00 00 04 6F 65 24 CF，可以看到后4個字節和File Tailer的后4個字節相同

附：二進制文件查看小技巧

  • 使用python可以方便的進行二進制相關的轉換
    1. hex(16) # 10進制轉16進制
    2. oct(8) # 10進制轉8進制
    3. bin(8) # 10進制轉2進制
>>> hex(6 * 16 * 1024)
'0x18000'
>>> hex(3 * 16 * 1024)
'0xc000'
>>>
  • vscode可以安裝hexdump for VSCode插件

頁分裂/頁合并

innodb-page-merging-and-page-splitting

InnoDB不是按行的來操作的，它可操作的最小粒度是頁，頁加載進內存后才會通過掃描頁來獲取行/記錄，curd操作則會產生頁合并，頁分裂操作。

innodb數據的存儲

在 InnoDB 存儲引擎中，所有的數據都被邏輯地存放在表空間中，表空間（tablespace）是存儲引擎中最高的存儲邏輯單位，在表空間的下面又包括段（segment）、區（extent）、頁（page）, 頁中存放實際的數據記錄行
在這里插入圖片描述
MySQL 使用 InnoDB 存儲表時，會將表的定義和數據相關記錄、索引等信息分開存儲，其中前者存儲在.frm文件中，后者存儲在.ibd文件中(ibd文件既存儲了數據也存儲了索引)
在這里插入圖片描述
在創建表時，會在磁盤上的 datadir 文件夾中生成一個 .frm 的文件，這個文件中包含了表結構相關的信息

頁合并

刪除記錄時會設置record的flaged標記為刪除，當一頁中刪除記錄超過MERGE_THRESHOLD（默認頁體積的50%）時，InnoDB會開始尋找最靠近的頁（前或后）看看是否可以將兩個頁合并以優化空間使用。例如：合并操作使得頁#5保留它之前的數據，并且容納來自頁#6的數據。頁#6變成一個空頁，可以接納新數據。

頁分裂

頁可能填充至100%，在頁填滿了之后，下一頁會繼續接管新的記錄。但如果下一頁也沒有足夠空間去容納新（或更新）的記錄，那么就必須創建新的頁了，如下

  1. 創建新頁
  2. 判斷當前頁（頁#10）可以從哪里進行分裂（記錄行層面）
  3. 移動記錄行
  4. 重新定義頁之間的關系
#9 #10 #11 #12 #13 ...#8 #10 #14 #11 #12 #13 ...

如上，頁#10沒有足夠空間去容納新記錄，頁#11也同樣滿了, #10要分列為兩列, 且頁的前后指針關系要發生改變

附加：mysql頻繁的插入刪除導致的問題

1. 性能下降

頻繁的插入和刪除操作會增加數據庫的工作量，特別是在高并發環境下，可能導致查詢響應時間變長。

解決方案：

優化查詢：確保你的查詢是有效且高效的，使用適當的索引。

批量操作：盡可能使用批量插入（INSERT INTO … VALUES (), (), …）和批量刪除（DELETE FROM WHERE id IN (…)) 而不是單條記錄操作。

分區表：對于非常大的表，考慮使用分區表，這可以改善查詢性能和減少單個表的維護負擔。

2. 碎片化

頻繁的插入和刪除操作會導致數據文件和索引文件碎片化，這會降低查詢效率。

解決方案：

定期重建索引：使用OPTIMIZE TABLE命令來重建表的索引，這可以幫助減少碎片。

歸檔舊數據：定期歸檔舊數據到另一個表或數據庫中，減少主表的負擔。

3. 鎖定和阻塞

在高并發環境下，頻繁的插入和刪除操作可能導致行級鎖或表級鎖，從而引起阻塞和死鎖。

解決方案：

減少鎖的粒度：考慮使用較低級別的隔離級別（如READ COMMITTED），或者使用樂觀鎖策略。

鎖優化：分析并優化事務的設計，確保事務盡可能短，避免長事務。

使用鎖定的最小范圍：盡可能在WHERE子句中指定具體的條件來減少鎖定的范圍。

4. 日志文件增長

頻繁的寫入操作會增加二進制日志（如binlog）和重做日志（如InnoDB的redo log）的大小，這可能會影響磁盤I/O性能。

解決方案：

配置合適的日志文件大小：調整max_binlog_size或innodb_log_file_size參數以控制日志文件的大小。

定期清理日志文件：使用PURGE BINARY LOGS命令來刪除舊的二進制日志文件。

5. 資源競爭

在高負載情況下，頻繁的插入和刪除可能會增加CPU和內存的使用率，尤其是在多核服務器上。

解決方案：

硬件升級：如果可能，增加服務器的CPU核心數或內存容量。

負載均衡：使用數據庫復制或分片策略來分散負載。

監控和調優：定期監控數據庫性能，根據需要調整配置。

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

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

相關文章

【優選算法】C++滑動窗口

【優選算法】C++滑動窗口

1、長度最小的子數組 思路&#xff1a; class Solution { public:int minSubArrayLen(int target, vector<int>& nums) {// 滑動窗口// 1.left0,right0// 2.進窗口( nums[right])// 3.判斷// 出窗口// (4.更新結果)// 總和大于等于 target 的長度最小的 子數組…
閱讀更多...
ffmpeg（四）：濾鏡命令

ffmpeg（四）：濾鏡命令

FFmpeg 的濾鏡命令是用于音視頻處理中的強大工具&#xff0c;可以完成剪裁、縮放、加水印、調色、合成、旋轉、模糊、疊加字幕等復雜的操作。其核心語法格式一般如下&#xff1a; ffmpeg -i input.mp4 -vf "濾鏡參數" output.mp4或者帶音頻濾鏡&#xff1a; ffmpeg…
閱讀更多...
408考研逐題詳解：2009年第33題

408考研逐題詳解：2009年第33題

2009年第33題 在 OSI 參考模型中&#xff0c;自下而上第一個提供端到端服務的層次是&#xff08; &#xff09; A. 數據鏈路層 \qquad B. 傳輸層 \qquad C. 會話層 \qquad D.應用層 解析 本題主要考查 OSI 參考模型各層的核心功能、端到端服務的定義。 OSI 參考模型&am…
閱讀更多...
CentOS 7.9安裝Nginx1.24.0時報 checking for LuaJIT 2.x ... not found

CentOS 7.9安裝Nginx1.24.0時報 checking for LuaJIT 2.x ... not found

Nginx1.24編譯時&#xff0c;報LuaJIT2.x錯誤&#xff0c; configuring additional modules adding module in /www/server/nginx/src/ngx_devel_kit ngx_devel_kit was configured adding module in /www/server/nginx/src/lua_nginx_module checking for LuaJIT 2.x ... not…
閱讀更多...
自制喜悅字貼

自制喜悅字貼

一、想法 據說&#xff0c;把“喜悅”兩個字掛在家里顯眼的地方&#xff0c;時常看到&#xff0c;就能心情愉悅。剛好最近在學習前端flex布局&#xff0c;用代碼實現&#xff0c;導出圖片&#xff0c;打印出來&#xff0c;帖在家里&#xff0c;非常nice。現在分享給大家。 二…
閱讀更多...
每日八股文6.3

每日八股文6.3

每日八股-6.3 Mysql1.COUNT 作用于主鍵列和非主鍵列時&#xff0c;結果會有不同嗎&#xff1f;2.MySQL 中的內連接&#xff08;INNER JOIN&#xff09;和外連接&#xff08;OUTER JOIN&#xff09;有什么主要的區別&#xff1f;3.能詳細描述一下 MySQL 執行一條查詢 SQL 語句的…
閱讀更多...
量化面試綠皮書：6. 燒繩子計時

量化面試綠皮書：6. 燒繩子計時

文中內容僅限技術學習與代碼實踐參考&#xff0c;市場存在不確定性&#xff0c;技術分析需謹慎驗證&#xff0c;不構成任何投資建議。 6. 燒繩子計時 你有兩根繩子&#xff0c;每根繩子燃燒需要1小時。但是任何一根繩子在不同點都有不同的密度&#xff0c;所以不能保證繩子內不…
閱讀更多...
2-深度學習挖短線股1

2-深度學習挖短線股1

選短線個股的流程 &#xff08;1&#xff09;數據預處理&#xff0c;根據短線個股篩選標準&#xff0c;給個股日線數據打標。 &#xff08;2&#xff09;模型訓練&#xff0c;針對每只股票&#xff0c;訓練得到分類模型。 &#xff08;3&#xff09;結果預測&#xff0c;根據訓…
閱讀更多...
【數據分析】探索嬰兒年齡變化對微生物群落（呼吸道病毒和細菌病原體）結構的影響

【數據分析】探索嬰兒年齡變化對微生物群落（呼吸道病毒和細菌病原體）結構的影響

禁止商業或二改轉載，僅供自學使用，侵權必究，如需截取部分內容請后臺聯系作者! 文章目錄 介紹1. 混合效應邏輯回歸模型2. 隨機森林模型3. Maaslin2 分析加載R包數據下載導入數據數據預處理混合效應邏輯回歸模型分析微生物群落結構隨年齡的變化隨機森林模型預測病原體定植Maas…
閱讀更多...
實戰：子組件獲取父組件訂單信息

實戰：子組件獲取父組件訂單信息

最佳實踐建議 優先使用 props&#xff1a;適合父子組件直接通信&#xff0c;數據流向清晰復雜場景用 eventBus&#xff1a;跨組件通信推薦使用 mitt 庫避免過度使用 $parent&#xff1a;會導致組件耦合度高&#xff0c;難以維護provide/inject 適用于跨層級&#xff1a;如主題…
閱讀更多...
Spring Security深度解析：構建企業級安全框架

Spring Security深度解析：構建企業級安全框架

Spring Security深度解析：構建企業級安全框架 本文將深入探討Spring Security安全框架的核心原理、架構設計和實際應用，幫助開發者全面掌握企業級應用安全防護技術。 目錄 Spring Security概述核心架構與原理認證機制詳解授權機制詳解核心組件分析配置與集成高級特性應用安全…
閱讀更多...
計算矩陣A和B的乘積

計算矩陣A和B的乘積

根據矩陣乘法規則&#xff0c;編程計算矩陣的乘積。函數fix_prod_ele()是基本方法編寫&#xff0c;函數fix_prod_opt()是優化方法編寫。 程序代碼 #define N 3 #define M 4 typedef int fix_matrix1[N][M]; typedef int fix_matrix2[M][N]; int fix_prod_ele(f…
閱讀更多...
《Brief Bioinform》: 鼠腦單細胞與Stereo-seq數據整合算法評估

《Brief Bioinform》: 鼠腦單細胞與Stereo-seq數據整合算法評估

一、寫在前面 基因捕獲效率、分辨率一直是空間轉錄組細胞類型識別的攔路虎&#xff0c;許多算法能夠整合單細胞(single-cell, sc)或單細胞核(single-nuclear, sn)數據與空間轉錄組數據&#xff0c;從而幫助空轉數據的細胞類型注釋。此前我們介紹過近年新出爐的Stereo-seq平臺&…
閱讀更多...
camera功能真的那么難用嗎

camera功能真的那么難用嗎

背景 Android開發工作過程中&#xff0c;經常需要用到camera相關能力&#xff0c;比如&#xff1a;人臉識別&#xff0c;ai識別&#xff0c;拍照預覽&#xff0c;攝像頭錄制等等需求。都需要使用到camera&#xff0c;且需要拿到camera的預覽數據。但是每次開發這塊代碼都比較繁…
閱讀更多...
USART 串口通信全解析：原理、結構與代碼實戰

USART 串口通信全解析：原理、結構與代碼實戰

文章目錄 USARTUSART簡介USART框圖USART基本結構數據幀起始位偵測數據采樣波特率發生器串口發送數據 主要代碼串口接收數據與發送數據主要代碼 USART USART簡介 一、USART 的全稱與基本定義 英文全稱 USART&#xff1a;Universal Synchronous Asynchronous Receiver Transmi…
閱讀更多...
LeetCode 152. 乘積最大子數組 - 動態規劃解法詳解

LeetCode 152. 乘積最大子數組 - 動態規劃解法詳解

文章目錄 問題描述解題思路動態規劃狀態定義狀態轉移方程完整代碼實現復雜度分析示例解析關鍵點說明總結問題描述 給定一個整數數組 nums，請找出數組中乘積最大的連續子數組（該子數組中至少包含一個數字），并返回該子數組對應的乘積。 示例： 輸入: [2,3,-2,4] 輸出: 6 解…
閱讀更多...
Python： 操作 Excel折疊

Python： 操作 Excel折疊

??Python 操作 Excel 折疊（分組）功能詳解（openpyxl & xlsxwriter 雙方案） 在處理 Excel 報表或數據分析時，我們常常希望通過 折疊（分組）功能 來提升表格的可讀性和組織性。本文將詳細介紹如何使用 Python 中的兩個主流 Excel 操作庫 —— openpyxl 和 xlsxwriter …
閱讀更多...
28、元組的遍歷

28、元組的遍歷

const_cast 只能用于指針或引用類型&#xff0c;而不能用于基本類型如 int。 在的代碼中&#xff0c;試圖將 i 轉換為 const_cast<int>(i)&#xff0c;這是不合法的。 可以使用模板函數來獲取元組中的元素&#xff0c;而不是使用 const_cast。以下是修正后的代碼&#x…
閱讀更多...
sendDefaultImpl call timeout（rocketmq）

sendDefaultImpl call timeout（rocketmq）

rocketmq 連接異常 senddefaultimpl call timeout-騰訊云開發者社區-騰訊云 第一種情況&#xff1a; 修改broker 的配置如下&#xff0c;注意brokerIP1 這個配置必須有&#xff0c;不然 rocketmq-console 顯示依然是內網地址 caused by: org.apache.rocketmq.remoting.excep…
閱讀更多...
【仿生機器人】仿生機器人智能架構：從感知到個性的完整設計

【仿生機器人】仿生機器人智能架構：從感知到個性的完整設計

仿生機器人智能架構&#xff1a;從感知到個性的完整設計 仿生機器人不僅需要模擬人類的外表&#xff0c;更需要具備類人的認知、情感和個性特征。本研究提出了一個綜合性的軟件架構&#xff0c;實現了從環境感知到情感生成、從實時交互到人格塑造的完整智能系統。該架構突破了…
閱讀更多...
最新文章

Copyright @ 2022~2023