立即登录 免费注册

浅析InnoDB索引结构

代码 代码 919 人阅读 | 0 人回复

<
0、导读

  InnoDB表的索引有哪些特征，和索引构造规划是如何的
1、InnoDB会萃索引特性

我们明白，InnoDB引擎的会萃索引构造表，必然会有一个会萃索引。
止数据（row data）存储正在会萃索引的叶子节面（除发作overflow的列，拜见 ，前面简称 “前置文”），并且其存储的相对挨次与决于会萃索引的挨次。那里道相对挨次而没有是物理挨次，是由于叶子节面数据页中，止数据的物理挨次战相对挨次能够并非分歧的，放正在前面会讲。
InnoDB会萃索引的挑选前后挨次是如许的：

  •        假如有隐式界说的主键（PRIMARY KEY），则会挑选该主键做为会萃索引
  •        不然，挑选第一个一切列皆没有许可为NULL的独一索引
  •        若前二者皆出有，则InnoDB会挑选内乱置的DB_ROW_ID做为会萃索引，定名为GEN_CLUST_INDEX
出格提示： DB_ROW_ID占用6个字节，每次自删，且是全部真例内乱齐局分派。也便是道，当前真比方果有多个表皆接纳了内乱置的DB_ROW_ID做为会萃索引，则正在那些表插进新数据时，他们的内乱置DB_ROW_ID值并非持续的，而是腾跃的。像上面如许：
  1. t1表的ROW_ID：1、3、7、10
  2. t2表的ROW_ID：2、4、5、6、8、9
复造代码
2、InnoDB索引规划

InnoDB默许的索引数据规划接纳B+树（空间索引接纳R树），索引数据存储正在叶子节面。
InnoDB的根本I/O存储单元是数据页(page)，一个page默许是16KB。我们正在 前置文 道过，每一个page默许会预留1/16闲暇空间用于后绝数据“变少”更新所需，因而正在最理想的挨次插进形态下，其发生的碎片也起码，这时候候好未几能挖谦15/16的page空间。假如是随机写进的话，则page空间操纵率大要是1/2 ~ 15/16。
当 row_format = DYNAMIC|COMPRESSED 时，索引最多少度为 3072字节，当 row_format = REDUNDANT|COMPACT 时，索引最年夜少度为 767字节。当page size没有是默许的16KB时，最年夜索引少度限定也会随着发作变革。
我们接下去别离考证闭于InnoDB索引的根本规划特性。
起首创立以下测试表：
  1. [root@yejr.me] [innodb]> CREATE TABLE `t1` (
  2.  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  3.  `c1` int(10) unsigned NOT NULL DEFAULT &#39;0&#39;,
  4.  `c2` varchar(100) NOT NULL,
  5.  `c3` varchar(100) NOT NULL,
  6.  PRIMARY KEY (`id`),
  7.  KEY `c1` (`c1`)
  8. ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
复造代码
  用上面的办法写进10条测试数据：
  1. set @uuid1=uuid(); set @uuid2=uuid();
  2. insert into t1 select 0, round(rand()*1024),
  3.                @uuid1, concat(@uuid1, @uuid2);
复造代码
  看下 t1 表的团体规划：
  1. # 用innodb_ruby东西检察
  2. [root@yejr.me]# innodb_space -s ibdata1 -T innodb/t1 space-indexes
  3. id    name       root   fseg        fseg_id   used    allocated   fill_factor
  4. 238   PRIMARY    3      internal    1         1       1           100.00%
  5. 238   PRIMARY    3      leaf        2         0       0           0.00%
  6. 239   c1         4      internal    3         1       1           100.00%
  7. 239   c1         4      leaf        4         0       0           0.0
  9. # 用innblock东西检察
  10. [root@yejr.me]# innblock innodb/t1.ibd scan 16
  11. ...
  12. ===INDEX_ID:238
  13. level0 total block is (1)
  14. block_no:     3,level:   0|*|
  15. ===INDEX_ID:239
  16. level0 total block is (1)
  17. block_no:     4,level:   0|*|
复造代码
  能够看到  索引ID索引范例根节面page no索引层下238主键索引(会萃索引)31239帮助索引41 3、InnoDB索引特性考证

3.1 特性1：会萃索引叶子节面存储整止数据

   先扫描第3个page，截与此中第一条物理记载的内乱容：
  1. [root@yejr.me]# innodb_space -s ibdata1 -T innodb/t1 -p 3 page-dump
  2. ...
  3. records:
  4. {:format=>:compact,
  5. :offset=>127,
  6. :header=>
  7.  {:next=>263,
  8.   :type=>:conventional,
  9.   :heap_number=>2,
  10.   :n_owned=>0,
  11.   :min_rec=>false,
  12.   :deleted=>false,
  13.   :nulls=>[],
  14.   :lengths=>{"c2"=>36, "c3"=>72},
  15.   :externs=>[],
  16.   :length=>7},
  17. :next=>263,
  18. :type=>:clustered,
  19. #第一条物理记载，id=1
  20. :key=>[{:name=>"id", :type=>"INT UNSIGNED", :value=>1}],
  21. :row=>
  22.  [{:name=>"c1", :type=>"INT UNSIGNED", :value=>777},
  23.   {:name=>"c2",
  24.    :type=>"VARCHAR(400)",
  25.    :value=>"a1c1a7c7-bda5-11e9-8476-0050568bba82"},
  26.   {:name=>"c3",
  27.    :type=>"VARCHAR(400)",
  28.    :value=>
  29.     "a1c1a7c7-bda5-11e9-8476-0050568bba82a1c1aec5-bda5-11e9-8476-0050568bba82"}],
  30. :sys=>
  31.  [{:name=>"DB_TRX_ID", :type=>"TRX_ID", :value=>10950},
  32.   {:name=>"DB_ROLL_PTR",
  33.    :type=>"ROLL_PTR",
  34.    :value=>
  35.     {:is_insert=>true,
  36.      :rseg_id=>119,
  37.      :undo_log=>{:page=>469, :offset=>272}}}],
  38. :length=>129,
  39. :transaction_id=>10950,
  40. :roll_pointer=>
  41.  {:is_insert=>true, :rseg_id=>119, :undo_log=>{:page=>469, :offset=>272}}}
复造代码
很较着，几乎是存储了整条数据的内乱容。
会萃索引树的键值(key)是主键索引值(i=10)，会萃索引节面值(value)是其他非会萃索引列(c1,c2,c3)和隐露列(DB_TRX_ID、DB_ROLL_PTR)。
劣化倡议1：尽管没有要存储年夜工具数据，使得每一个叶子节面皆能存储更大都据，低落碎片率，进步buffer pool操纵率。此外也能尽管制止发作overflow。

3.2 特性2：会萃索引非叶子节面存储指背子节面的指针

对上里的测试表持续写进新数据，曲到会萃索引树从一层团结成两层。
我们按照旧文 InnoDB表会萃索引层下甚么时分发作变革 里的计较方法，推算出去估计一个叶子节面最多可存储111笔记录，因而正在插进第112笔记录时，便会从一层下度团结成两层下度。经过真测，也几乎是云云。
  1. [root@yejr.me] [innodb]>select count(*) from t1;
  2. +----------+
  3. | count(*) |
  4. +----------+
  5. |      112 |
  6. +----------+
  8. [root@yejr.me]# innblock innodb/t1.ibd scan 16
  9. ...
  10. ===INDEX_ID:238
  11. level1 total block is (1)
  12. block_no:     3,level:   1|*|
  13. level0 total block is (2)
  14. block_no:     5,level:   0|*|block_no:     6,level:   0|*|
  15. ...
复造代码
此时能够看到根节面照旧是pageno=3，而叶子节面变成了[5, 6]两个page。由此可知，根节面上该当只要两条物理记载，存储着别离指背pageno=[5, 6]那两个page的指针。
我们剖析下3号page，看看它的详细规划：
  1. [root@yejr.me]# innodb_space -s ibdata1 -T innodb/t1 -p 3 page-dump
  2. ...
  3. records:
  4. {:format=>:compact,
  5. :offset=>125,
  6. :header=>
  7.  {:next=>138,
  8.   :type=>:node_pointer,
  9.   :heap_number=>2,
  10.   :n_owned=>0,
  11.   :min_rec=>true, #第一笔记录是min_key
  12.   :deleted=>false,
  13.   :nulls=>[],
  14.   :lengths=>{},
  15.   :externs=>[],
  16.   :length=>5},
  17. :next=>138,
  18. :type=>:clustered,
  19. #第一笔记录，只存储key值
  20. :key=>[{:name=>"id", :type=>"INT UNSIGNED", :value=>1}],
  21. :row=>[],
  22. :sys=>[],
  23. :child_page_number=>5, #value值是指背的叶子节面pageno=5
  24. :length=>8} #整笔记录耗损8字节，撤除key值4字节中，指针也需求4字节
  26. {:format=>:compact,
  27. :offset=>138,
  28. :header=>
  29.  {:next=>112,
  30.   :type=>:node_pointer,
  31.   :heap_number=>3,
  32.   :n_owned=>0,
  33.   :min_rec=>false,
  34.   :deleted=>false,
  35.   :nulls=>[],
  36.   :lengths=>{},
  37.   :externs=>[],
  38.   :length=>5},
  39. :next=>112,
  40. :type=>:clustered,
  41. #第两笔记录，只存储key值
  42. :key=>[{:name=>"id", :type=>"INT UNSIGNED", :value=>56}],
  43. :row=>[],
  44. :sys=>[],
  45. :child_page_number=>6, #value值是指背的叶子节面pageno=6
  46. :length=>8}
复造代码
劣化倡议2: 索引列数据少度越小越好，如许索引树存储服从越下，正在非叶子节面能存储越大都据，延缓索引树层下团结的速率，均匀搜刮服从更下。

3.3 特性3：帮助索引同时会存储主键索引列值

正在帮助索引中，老是同时会存储主键索引（大概道会萃索引）的列值，其感化便是正在对帮助索引扫描时，能够从叶子节面间接获得对应的会萃索引值，并可按照该值回表查询获得止数据（假如需求回表查询的话）。那个特征也被称为Index Extensions（5.6版本以后的劣化器新特征，详睹 Use of Index Extensions）。
此外，正在帮助索引的非叶子节面中，索引记载的key值是索引界说的列值，而对应的value值则是会萃索引列值（简称PKV）。假如帮助索引界说时曾经包罗了部门会萃索引列，则索引记载的value值是已被包罗的余下的会萃索引列值。
创立以下测试表：
  1. CREATE TABLE `t3` (
  2.  `a` int(10) unsigned NOT NULL AUTO_INCREMENT,
  3.  `b` int(10) unsigned NOT NULL DEFAULT &#39;0&#39;,
  4.  `c` varchar(20) NOT NULL DEFAULT &#39;&#39;,
  5.  `d` varchar(20) NOT NULL DEFAULT &#39;&#39;,
  6.  `e` varchar(20) NOT NULL DEFAULT &#39;&#39;,
  7.  PRIMARY KEY (`a`,`b`),
  8.  KEY `k1` (`c`,`b`)
  9. ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
复造代码
  随机插进一些测试数据：
  1. # 挪用shell剧本写进500条数据
  2. [root@yejr.me]# cat insert.sh
  3. #!/bin/bash
  4. . ~/.bash_profile
  5. cd /data/perconad
  6. i=1
  7. max=500
  8. while [ $i -le $max ]
  9. do
  10. mysql -Smysql.sock -e "insert ignore into t3 select
  11.    rand()*1024, rand()*1024, left(md5(uuid()),20) ,
  12.    left(uuid(),20), left(uuid(),20);" innodb
  13. i=`expr $i + 1`
  14. done
  16. # 实践写进498条数据（此中有2条主键抵触失利）
  17. [root@yejr.me] [innodb]>select count(*) from t3;
  18. +----------+
  19. | count(*) |
  20. +----------+
  21. |      498 |
  22. +----------+
复造代码
  剖析数据规划：
  1. # 主键
  2. [root@test1 perconad]# innodb_space -s ibdata1 -T innodb/t2 space-indexes
  3. id    name     root  fseg        fseg_id   used   allocated   fill_factor
  4. 245   PRIMARY  3     internal    1         1      1           100.00%
  5. 245   PRIMARY  3     leaf        2         5      5           100.00%
  6. 246   k1       4     internal    3         1      1           100.00%
  7. 246   k1       4     leaf        4         2      2           1
  9. [root@yejr.me]# innodb_space -s ibdata1 -T innodb/t2 -p 4 page-dump
  10. ...
  11. records:
  12. {:format=>:compact,
  13. :offset=>126,
  14. :header=>
  15.  {:next=>164,
  16.   :type=>:node_pointer,
  17.   :heap_number=>2,
  18.   :n_owned=>0,
  19.   :min_rec=>true,
  20.   :deleted=>false,
  21.   :nulls=>[],
  22.   :lengths=>{"c"=>20},
  23.   :externs=>[],
  24.   :length=>6},
  25. :next=>164,
  26. :type=>:secondary,
  27. :key=>
  28.  [{:name=>"c", :type=>"VARCHAR(80)", :value=>"00a5d42dd56632893b5f"},
  29.   {:name=>"b", :type=>"INT UNSIGNED", :value=>323}],
  30. :row=>
  31.  [{:name=>"a", :type=>"INT UNSIGNED", :value=>310},
  32.   {:name=>"b", :type=>"INT UNSIGNED", :value=>9}],
  33.   # 此处给剖析成b列的值了，实践上是指背叶子节面的指针，即child_page_number=9
  34.   # b列实在值是323
  35. :sys=>[],
  36. :child_page_number=>335544345,
  37. # 此处剖析禁绝确，实践上是下一笔记录的record header，共6个字节
  38. :length=>36}
  40. {:format=>:compact,
  41. :offset=>164,
  42. :header=>
  43.  {:next=>112,
  44.   :type=>:node_pointer,
  45.   :heap_number=>3,
  46.   :n_owned=>0,
  47.   :min_rec=>false,
  48.   :deleted=>false,
  49.   :nulls=>[],
  50.   :lengths=>{"c"=>20},
  51.   :externs=>[],
  52.   :length=>6},
  53. :next=>112,
  54. :type=>:secondary,
  55. :key=>
  56.  [{:name=>"c", :type=>"VARCHAR(80)", :value=>"7458824a39892aa77e1a"},
  57.   {:name=>"b", :type=>"INT UNSIGNED", :value=>887}],
  58. :row=>
  59.  [{:name=>"a", :type=>"INT UNSIGNED", :value=>623},
  60.   {:name=>"b", :type=>"INT UNSIGNED", :value=>10}],
  61.   # 同上，实际上是child_page_number=10，而非b列的值
  62. :sys=>[],
  63. :child_page_number=>0,
  64. :length=>36} #数据少度16字节
复造代码
趁便道下，帮助索引上出存储TRX_ID, ROLL_PTR那些（他们只存储正在会萃索引上）。
上里用innodb_ruby东西剖析的非叶子节面部门内乱容不敷精确，以是我们用两进造方法翻开数据文件两次供证确认：
  1. # 此处也能够用 hexdump 东西
  2. [root@yejr.me]# vim -b path/t3.ibd
  3. ...
  4. :%!xxd
  6. # 找到帮助索引地点的那部门数据
  7. 0010050: 0002 0272 0000 00e1 0000 0002 01b2 0100  ...r............
  8. 0010060: 0200 1b69 6e66 696d 756d 0003 000b 0000  ...infimum......
  9. 0010070: 7375 7072 656d 756d 1410 0011 0026 3030  supremum.....&00
  10. 0010080: 6135 6434 3264 6435 3636 3332 3839 3362  a5d42dd56632893b
  11. 0010090: 3566 0000 0143 0000 0136 0000 0009 1400  5f...C...6......
  12. 00100a0: 0019 ffcc 3734 3538 3832 3461 3339 3839  ....7458824a3989
  13. 00100b0: 3261 6137 3765 3161 0000 0377 0000 026f  2aa77e1a...w...o
  14. 00100c0: 0000 000a 0000 0000 0000 0000 0000 0000  ................
  16. # 参考page物理构造方法停止剖析，获得上面的成果
  17. /* 第一笔记录 */
  18. 1410 0011 0026, record header, 5字节
  19. 3030 6135 6434 3264 6435 3636 3332 3839 3362 3566,c=&#39;00a5d42dd56632893b5f&#39;,20B
  20. 0000 0143, b=323, 4B
  21. 0000 0136, a=310, 4B
  22. 0000 0009, child_pageno=9, 4B
  24. /* 2 */
  25. 1400 0019 ffcc, record header
  26. 3734 3538 3832 3461 3339 3839 3261 6137 3765 3161, c=&#39;7458824a39892aa77e1a&#39;
  27. 0000 0377, b=887
  28. 0000 026f, a=623
  29. 0000 000a, child_pageno=10
复造代码
如今反过去看，上里用innodb_ruby东西剖析出去的page-dump成果该当是如许的才对（我只拔取一笔记录，请自止比照战之前的不同的地方）：
  1. {:format=>:compact,
  2. :offset=>164,
  3. :header=>
  4.  {:next=>112,
  5.   :type=>:node_pointer,
  6.   :heap_number=>3,
  7.   :n_owned=>0,
  8.   :min_rec=>false,
  9.   :deleted=>false,
  10.   :nulls=>[],
  11.   :lengths=>{"c"=>20},
  12.   :externs=>[],
  13.   :length=>6},
  14. :next=>112,
  15. :type=>:secondary,
  16. :key=>
  17.  [{:name=>"c", :type=>"VARCHAR(80)", :value=>"7458824a39892aa77e1a"},
  18.   {:name=>"b", :type=>"INT UNSIGNED", :value=>887}],
  19. :row=> [{:name=>"a", :type=>"INT UNSIGNED", :value=>623}],
  20. :sys=>[],
  21. :child_page_number=>10,
  22. :length=>36}
复造代码
能够看到，几乎如前里所道，帮助索引的非叶子节面的value值存储的是会萃索引列值。
劣化倡议3：帮助索引列界说的少度越小越好，界说帮助索引时，出需要隐式的减上会萃索引列（5.6版本以后）。

3.4 特性4：出有可用的会萃索引列时，会利用内乱置的ROW_ID做为会萃索引

创立几个像上面如许的表，使其挑选内乱置的ROW_ID做为会萃索引：
  1. [root@yejr.me] [innodb]> CREATE TABLE `tn1` (
  2.  `c1` int(10) unsigned NOT NULL DEFAULT 0,
  3.  `c2` int(10) unsigned NOT NULL DEFAULT 0
  4. ) ENGINE=InnoDB;
复造代码
  轮回对几个表写数据：
  1. insert into tt1 select 1,1;
  2. insert into tt2 select 1,1;
  3. insert into tt3 select 1,1;
  4. insert into tt1 select 2,2;
  5. insert into tt2 select 2,2;
  6. insert into tt3 select 2,2;
复造代码
检察 tn1 - tn3 内外的数据（那里因为innodb_ruby东西剖析的成果不准确，以是我改用hexdump去阐发）：
  1. tn1
  2. 000c060: 0200 1a69 6e66 696d 756d 0003 000b 0000  ...infimum......
  3. 000c070: 7375 7072 656d 756d 0000 1000 2000 0000  supremum.... ...
  4. 000c080: 0003 1200 0000 003d f6aa 0000 01d9 0110  .......=........
  5. 000c090: 0000 0001 0000 0001 0000 18ff d300 0000  ................
  6. 000c0a0: 0003 1500 0000 003d f9ad 0000 01da 0110  .......=........
  7. 000c0b0: 0000 0002 0000 0002 0000 0000 0000 0000  ................
  9. tn2
  10. 000c060: 0200 1a69 6e66 696d 756d 0003 000b 0000  ...infimum......
  11. 000c070: 7375 7072 656d 756d 0000 1000 2000 0000  supremum.... ...
  12. 000c080: 0003 1300 0000 003d f7ab 0000 0122 0110  .......=....."..
  13. 000c090: 0000 0001 0000 0001 0000 18ff d300 0000  ................
  14. 000c0a0: 0003 1600 0000 003d feb0 0000 01db 0110  .......=........
  15. 000c0b0: 0000 0002 0000 0002 0000 0000 0000 0000  ................
  17. tn3
  18. 000c060: 0200 1a69 6e66 696d 756d 0003 000b 0000  ...infimum......
  19. 000c070: 7375 7072 656d 756d 0000 1000 2000 0000  supremum.... ...
  20. 000c080: 0003 1400 0000 003d f8ac 0000 0123 0110  .......=.....#..
  21. 000c090: 0000 0001 0000 0001 0000 18ff d300 0000  ................
  22. 000c0a0: 0003 1700 0000 003e 03b3 0000 012a 0110  .......>.....*..
  23. 000c0b0: 0000 0002 0000 0002 0000 0000 0000 0000  ................
复造代码
  此中表示DB_ROW_ID的值别离是：
  1. tn1
  2. 0003 12 => (1,1)
  3. 0003 15 => (2,2)
  5. tn2
  6. 0003 13 => (1,1)
  7. 0003 16 => (2,2)
  9. tn3
  10. 0003 14 => (1,1)
  11. 0003 17 => (2,2)
复造代码
很较着，内乱置的DB_ROW_ID几乎是正在全部真例级别同享自删分派的，而没有是每一个表独享一个DB_ROW_ID序列。
我们能够设想下，假如一个真例中有多个表皆用到那个DB_ROW_ID的话，必将会形成并收恳求的合作/等候。此外也能够会形成主从复造情况下，从库上relay log回放时能够会由于数据扫描机造的成绩形成严峻的复造提早成绩。详情参考 从库数据的查找战参数slave_rows_search_algorithms。
劣化倡议4：自止显现界说可用的会萃索引/主键索引，没有要让InnoDB挑选内乱置的DB_ROW_ID做为会萃索引，制止潜伏的机能丧失。
篇幅曾经有面年夜了，本次的浅析事情便先到那里吧，当前再持续。

4、几面总结

   最初针对InnoDB引擎表，总结几条倡议吧。  

  •        每一个表皆要有隐式主键，最好是自删整型，且出有营业用处
  •        不管是主键索引，仍是帮助索引，皆尽量挑选数据范例较小的列
  •        界说帮助索引时，出需要隐式减上主键索引列（针对MySQL 5.6以后）
  •        止数据越短越好，假如每一个列皆是牢固少的则更好（没有是像VARCHAR如许的可变少度范例）
   上述测试情况基于Percona Server 5.7.22：
  1. # MySQL的版本是Percona Server 5.7.22-22，我本人下载源码编译的
  2. [root@yejr.me#] mysql -Smysql.sock innodb
  3. ...
  4. Server version: 5.7.22-22-log Source distribution
  5. ...
  6. [root@yejr.me]> \s
  7. ...
  8. Server version:     5.7.22-22-log Source distribution
复造代码
  Enjoy MySQL :)  延长浏览





  • MySQL Manual：Use of Index Extensions

  • jcole.us：The physical structure of InnoDB index pages
  • jcole.us：B+Tree index structures in InnoDB
  • jcole.us：How does InnoDB behave without a Primary Key?
最初，欢送扫码定阅《治弹MySQL》专栏，快人一步获得我最新的MySQL手艺分享


免责声明：假如进犯了您的权益，请联络站少，我们会实时删除侵权内乱容，感谢协作！
1、本网站属于个人的非赢利性网站，转载的文章遵循原作者的版权声明，如果原文没有版权声明，按照目前互联网开放的原则，我们将在不通知作者的情况下，转载文章;如果原文明确注明“禁止转载”，我们一定不会转载。如果我们转载的文章不符合作者的版权声明或者作者不想让我们转载您的文章的话，请您发送邮箱：Cdnjson@163.com提供相关证明，我们将积极配合您！
2、本网站转载文章仅为传播更多信息之目的，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证信息的正确性和完整性，且不对因信息的不正确或遗漏导致的任何损失或损害承担责任。
3、任何透过本网站网页而链接及得到的资讯、产品及服务，本网站概不负责，亦不负任何法律责任。
4、本网站所刊发、转载的文章，其版权均归原作者所有，如其他媒体、网站或个人从本网下载使用，请在转载有关文章时务必尊重该文章的著作权，保留本网注明的“稿件来源”，并自负版权等法律责任。
回复 关闭延时

使用道具 举报

王的第1001个梦 LV2
发布了 13 篇主题 · 获得积分 135
 
高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于作者
王的第1001个梦 LV2
累计积分 135
发表主题数 13
热门标签
  • Archiver| 手机版| 小黑屋|
Powered by Discuz! X3.4 Copyright © 2001-2020, Tencent Cloud.( 鲁ICP备2023025969号-1 )|Sitemap