索引底层原理分析、索引实战

最新推荐文章于 2024-05-13 23:17:50 发布
最新推荐文章于 2024-05-13 23:17:50 发布
阅读量502 收藏 1
点赞数
分类专栏： 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/mashaokang1314/article/details/90524086
版权

B+Tree

在这里插入图片描述

聚簇索引

特点：

  1. 按主键值的大小进行记录和页的排序：
    • 数据页里的记录是按照主键值从小到大的一个单向链表；
    • 数据页之间也是按照主键值从小到大排序的一个双向链表；
    • B+树中同一个层的页目录也是按照主键值从小到大排序的一个双向链表；
  2. B+树的叶子节点存储的是完整的用户记录，就是指这个记录中存储了所有列的值；

具有这两种特性的B+树称为聚簇索引，所有完整的用户记录都存放在这个聚簇索引的叶子节点处。InnoDB存储引擎会自动的为我们创建聚簇索引。在InnoDB存储引擎中，聚簇索引就是数据的存储方式，也就是所谓的索引即数据，数据即索引；

二级索引(辅助索引)

聚簇索引只能在搜索条件是主键值时才能发挥作用，因为B+Tree中的数据都是按照主键进行排序的。当我们想以别的列作为搜索条件时，我们可以多建几棵B+树，不同的B+树采用不同的排序规则。

二级索引与聚簇索引的不同：

  • 按指定的索引列的值来进行排序而不是主键；
  • 叶子节点存储的不是完整的用户记录，而只是索引列+主键；
  • 目录项记录中不是主键+页号，变成了索引列+页号；
  • 在对二级索引进行查找数据时，需要根据主键值去聚簇索引中再查找一遍完整的用户记录，这个过程叫回表。

联合索引

以多个列的大小为排序规则建立B+树称为联合索引，本质上也是一个二级索引。

目录项记录的唯一性

我们需要保证B+树的同一层内节点的目录项记录除页号这个字段以外是唯一的。所以对二级所用的内节点目录的内容实际上是由三个部分构成的：

  • 索引列的值；
  • 主键值；
  • 页号；

先通过联合索引的B+树找到对应行节点，节点中包含主键，获取到主键再通过主键B+树找到主键对应的数据。

B+树索引总结

  1. 每个索引都对应一课B+树，用户记录都存储在B+树的叶子节点，所有目录都存储在非叶子节点；
  2. InnoDB存储引擎会自动为主键建立聚簇索引，聚簇索引的叶子节点包含完整的用户记录；
  3. 可以为指定的列建立二级索引，二级索引的叶子节点包含的用户记录由索引列+主键组成，所以如果想通过二级索引来查找完整的用户记录的话，需要回表操作，也就是通过二级索引找到主键值之后再到聚簇索引中查找完整的用户记录。
  4. B+树中每层节点都是按照索引列值从小到大的顺序排序而组成了双向链表，而且每个页内的记录（不论 是用户记录还是目录项记录）都是按照索引列的值从小到大的顺序而形成了一个单链表。如果是联合索引
    的话，则页面和记录先按照联合索引前边的列排序，如果该列值相同，再按照联合索引后边的列排序。
  5. 通过索引查找记录是从B+树的根节点开始，一层一层向下搜索。由于每个页面都按照索引列的值建立了 页目录，所以在这些页面中的查找非常快。

索引实战

索引的代价

空间上的代价

一个索引都会对应一个B+树，树中每一个节点都是一个数据页，一个页默认会占用16kb的存储空间，所以一个索引也是会占用磁盘空间的。

时间上的代价

索引是对数据的排序，那么当对数据表进行增删改操作时都需要去维护修改内容涉及到的B+树索引。在进行增删改时可能需要额外的时间进行一些记录移动，页面分裂，页面回收等操作来维护好排序。

索引实战

mysql> create table abc(
    -> a int primary key auto_increment,
    -> b varchar(5) not null,
    -> c varchar(5) not null,
    -> d varchar(5) not null,
    -> e varchar(5) not null
    -> );

建立联合索引

select * from abc where b=1 and c=1 and d=1;

全值匹配

mysql> explain select * from abc where b=1 and c=1 and d=1;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | abc   | NULL       | ALL  | abcIndex      | NULL | NULL    | NULL |    6 |    16.67 | Using where |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+

查询优化器会分析这些查询条件并且按照可以使用的索引列的顺序来决定使用那个查询条件。

匹配最左列

mysql> explain select * from abc where b=1;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | abc   | NULL       | ALL  | abcIndex      | NULL | NULL    | NULL |    6 |    16.67 | Using where |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 3 warnings (0.00 sec)

mysql> explain select * from abc where b=1 and c=1;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | abc   | NULL       | ALL  | abcIndex      | NULL | NULL    | NULL |    6 |    16.67 | Using where |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 4 warnings (0.00 sec)

mysql> explain select * from abc where c=1;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | abc   | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    6 |    16.67 | Using where |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

可以看到如果从左边b列开始匹配才能用到联合索引，而直接使用c列匹配用不到建立的联合索引。这是因为B+树先是按照b列的值排序的，在b列只相同的情况下才使用c列进行排序。所以如果直接用c列去匹配是无序的，这就是最左列匹配。

匹配列前缀

mysql> explain select * from abc where b like '%101%';
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | abc   | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    6 |    16.67 | Using where |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

mysql> explain select * from abc where b like '11%';
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
| id | select_type | table | partitions | type  | possible_keys | key      | key_len | ref  | rows | filtered | Extra                 |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
|  1 | SIMPLE      | abc   | NULL       | range | abcIndex      | abcIndex | 22      | NULL |    1 |   100.00 | Using index condition |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
1 row in set, 1 warning (0.00 sec)

因为通过%1%这个条件查询是无序的，所以只能通过全表扫描。而通过1%查询b对应的1已经排好了序，所以可以走索引查询。

匹配范围值

mysql> explain select * from abc where b>1 and b<3;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | abc   | NULL       | ALL  | abcIndex      | NULL | NULL    | NULL |    6 |    16.67 | Using where |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 3 warnings (0.00 sec)

由于B+树中的数据页和记录是先按b列排序的，所以查询过程是这样的：

  • 找到b值为1的记录；
  • 找到b值为3的记录；
  • 由于所有记录都是由链表练级来的，它们之间的记录可以很容易取出来；
  • 找到这些记录的主键值，再到聚簇索引中回表查找完整的记录；

注意

在使用联合进行范围查找时，只有对索引最左边的那个列进行范围查找时才能用到B+树索引。

mysql> explain select * from abc where b>1 and c>3;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | abc   | NULL       | ALL  | abcIndex      | NULL | NULL    | NULL |    6 |    16.67 | Using where |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
  • 通过b>1来对b进行返回查找，找到的结果可能有多条不同记录；
  • 对这些记录继续通过c>3继续过滤；

实际上只有b>1使用了B+树索引，c>3并没有使用到；

精确匹配某一列并范围匹配另一列

对于用一个联合索引，虽然对多个列都进行范围查找时只能用到最左边那个索引列，但是如果左边的列时精确查找，则右边的列可以使用索引进行范围查找；

mysql> explain select * from abc where b=2 and c>3;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | abc   | NULL       | ALL  | abcIndex      | NULL | NULL    | NULL |    6 |    16.67 | Using where |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 4 warnings (0.00 sec)

因为对于b=2的节点，c是排好序的；

排序

mysql> select * from abc order by b,c,d;
+---+---+---+---+----+
| a | b | c | d | e  |
+---+---+---+---+----+
| 1 | 1 | 1 | 1 | 1  |
| 2 | 1 | 2 | 3 | 4  |
| 3 | 2 | 2 | 3 | 4  |
| 6 | 2 | 4 | 3 | 10 |
| 4 | 2 | 5 | 3 | 4  |
| 5 | 2 | 5 | 3 | 10 |
+---+---+---+---+----+

先按照b列排序，b列值相同，按c列排好序，c列值相同，按d列排好序。因为B+树本身就是按照这个规则排好序的，所以直接从索引中提取数据，然后进行回表操作取出记录就行了。

分组

mysql> select b,c,d,count(*) from abc group by b,c,d;
+---+---+---+----------+
| b | c | d | count(*) |
+---+---+---+----------+
| 1 | 1 | 1 |        1 |
| 1 | 2 | 3 |        1 |
| 2 | 2 | 3 |        1 |
| 2 | 4 | 3 |        1 |
| 2 | 5 | 3 |        2 |
+---+---+---+----------+
5 rows in set (0.00 sec)

这个查询相当于做了3次分组操作：

  • 先把记录按照b值进行分组，所有b值相同的分为一组；
  • 将每个b值相同的分组里的记录再按照c值进行分组，将c值相同的记录放到一个分组里；
  • 再将上一步中产生的分组按照d值分成更小的组；

如果没有索引的话，这个分组过程全部需要在内存中实现，而如果有索引的话，正好这个分组顺序又和B+树中的索引咧顺序一致，所以直接从磁盘中按顺序取就好了。

对于使用联合索引进行排序或分组的注意事项

  • 对于联合索引有个问题需要注意，order by的子句后边的列的顺序也必须按照索引列的顺序给出；
  • 对于这种order by b或者order by b,c或者select * from abc where b=1 order by c,d也可以使用到索引。
    不可以使用索引进行排序或分组的几种情况

ASC、DESC混用

如果order by子句后的列不加ASC或者DESC默认是按照ASC升序排序的。

mysql> explain select * from abc order by b asc,c desc;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra          |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
|  1 | SIMPLE      | abc   | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    6 |   100.00 | Using filesort |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
1 row in set, 1 warning (0.00 sec)

因为对于联合索引我们要求各个排序列的排序顺序是一致的；

如何建立索引

考虑索引选择性

索引的选择性是指不重复的索引值也叫基数与表记录数的比值：
选择性=基数/记录数

取值范围(0,1]，选择性越高索引的价值越大。如果选择性等于1，就代表这个列的不重复值和表记录数是一样的，如果选择性非常小，那么就代表这个列的重复值是很多的，不适合建立索引。

mysql> select count(distinct(a))/count(*) as aindex from abc;
+--------+
| aindex |
+--------+
| 1.0000 |
+--------+
1 row in set (0.00 sec)

mysql> select count(distinct(b))/count(*) as aindex from abc;
+--------+
| aindex |
+--------+
| 0.3333 |
+--------+

考虑前缀索引

用列的前缀代替整个列作为索引key，当前缀长度合适时，可以做到既使得前缀索引的选择性接近全列所用，同时因为索引key变短而减少索引文件的大小和维护开销；

总结

  • 索引列的类型尽量小；
  • 利用索引字符串值的前缀；
  • 主键自增；
  • 定位并删除表中的重复和冗余索引；
  • 尽量使用主键索引进行查询，避免回表带来的性能损耗；
Mrkang1314
关注
专栏目录
mysql索引详解
学Java，找哪吒
07-07 10万+
MySQL的存储引擎架构将查询处理与数据的存储/提取相分离
MySQL索引机制(详细+原理+解析)
xuhss_com的博客
04-02 1403
Python微信订餐小程序课程视频 https://edu.csdn.net/course/detail/36074 Python实战量化交易理财系统 https://edu.csdn.net/course/detail/35475 MySQL索引机制 永远年轻，永远热泪盈眶 一.索引的类型与常见的操作 前缀索引 MySQL 前缀索引能有效减小索引文件的大小，提高索引的速度。但是前缀索引也有它的坏处：MySQL 不能在 ORDER BY 或 GROUP BY 中使用前缀索引，也不能把它们用作覆盖索引
课堂笔记：MySQL(一) InnoDb行格式、数据页结构以及索引底层原理分析
沮丧的南瓜
06-02 283
一、InnoDb行格式、数据页结构以及索引底层原理分析 Mysql架构图 存储引擎负责对表中的数据的进行读取和写入，常用的存储引擎有InnoDB、MyISAM、Memory等，不同的存储 引擎有自己的特性，数据在不同存储引擎中存放的格式也是不同的，比如Memory都不用磁盘来存储数据。 在InnoDB中，数据会存储到磁盘上，在真正处理数据时需要先将数据加载到内存，表中读取某些记录时， InnoDB存储引擎不需要一条一条的把记录从磁盘上读出来，InnoDB采取的方式是：将数据划分为若干个页，以 页作为磁盘和
MySQL数据页、页分裂机制
资料免费分享，点击名片
11-16 412
在MySQL的设定中，同一个表空间内的一组连续的数据页为一个extent（区），默认区的大小为1MB，页的大小为16KB。约定好了数据的组织方式，那MySQL的作用不就是：按照约定数据规则将数据文件中的数据加载进内存，然后展示给用户看，以及提供其他能力吗？你也一定了解了：你create出来的table其实是属于一个表空间的，而所谓的表空间其实对应着一个真实存在于物理磁盘上的文件。就导致后一个数据页中的所有行并不一定比前一个数据页中的行的id大。假设上图中的id就是你自定义的不会自增的主键。
mysql 行格式知识了解
u010738038的专栏
02-07 358
mysql 行格式知识了解
什么是页分裂、页合并？
最新发布
yimeng_Sama的博客
05-13 1180
在InnoDB存储引擎中，表数据都是根据主键顺序组织存放的，这种存储方式的表称为。行数据，都是存储在聚集索引的叶子节点上的。而我们之前也讲解过InnoDB的逻辑结构图：在InnoDB引擎中，数据行是记录在逻辑结构page 页中的，而每一个页的大小是固定的，默认16K。那也就意味着， 一个页中所，如果插入的数据行row在该页存储不下，将会存储到下一个页中，页与页之间会通过指针连接。
Mysql ——行格式
meser88的博客
01-13 886
定义 库中记录展示时是一条记录一条记录的，也就是一行一行 那这样的每条记录在库中的存储方式称为行格式 行格式归属于存储引擎范围（换个存储引擎可能就不同方式存储） 分类 Compact (Version 5.6 默认) Redundant (比较老的数据格式) Dynamic (Version 5.7默认) Compressed(不能应用在System data) Compact和Dynamic应用较广泛; 规定（只讨论InnoDB）： 存储单元为页（page），16KB（16384B） .
数据库MYSQL底层原理分析-笔记-pdf
05-15
1. **InnoDB行格式、数据页结构以及索引底层原理分析**： - InnoDB是MySQL中最主要的存储引擎，它支持事务处理和行级锁定。 - 行格式：InnoDB有多种行格式，如Compressed、Compact、Redundant等，每种格式在存储...
干货！MySQL常见的面试题＋索引原理分析.docx
06-06
本文将深入探讨MySQL索引的本质、底层原理以及实战经验。 首先，理解MySQL索引的本质至关重要。索引是一种特殊的数据结构，用于加速数据库的查询过程。当对表中的某个字段创建索引后，数据库系统可以不必全表扫描，...
mysql联合索引的底层原理，进阶加薪全靠它
m0_60606468的博客
03-01 966
*本文已被[CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】](https://docs.qq.com/doc/DSmxTbFJ1cmN。**本文已被[CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】](https://docs.qq.com/doc/DSmxTbFJ1cmN。**完整开源项目：docs.qq.com/doc/DSmxTbFJ1cmN1R2dB **1R2dB)收录**
分类数据集索引读取
05-15
分类数据集索引读取,针对深度学习中分类问题，读取数据集路径及类别并写入本地.txt文件，作为分类网络读取训练或验证图片的索引文件
mysql 页和叶子页_一看就懂的：MySQL数据页以及页分裂机制，别在说不会了
weixin_39587029的博客
01-30 568
下面我们就一起看下，究竟什么是MySQL的数据页、数据区等概念。二、数据页长啥样？数据页长下面这样：image.png三、什么是数据区？在MySQL的设定中，同一个表空间内的一组连续的数据页为一个extent(区)，默认区的大小为1MB，页的大小为16KB。16*64=1024，也就是说一个区里面会有64个连续的数据页。连续的256个数据区为一组数据区。于是我们可以画出这张图：image从直观上看...
mysql 页分裂_mysql聚簇索引的页分裂原理实例分析
weixin_34064233的博客
01-19 645
本文实例讲述了mysql聚簇索引的页分裂。分享给大家供大家参考，具体如下：在MySQL中，MyISAM采用的是非聚簇索引的，InnoDB存储引擎是采用聚簇索引的。聚簇结构的特点：根据主键查询条目时,不用回行(数据就在主键节点下)如果碰到不规则数据插入时,造成频繁的页分裂为什么会产生页分裂？这是因为聚簇索引采用的是平衡二叉树算法，而且每个节点都保存了该主键所对应行的数据，假设插入数据的主键是自增长的...
MySQL表(一)-索引组织表、 InnoDB逻辑存储结构
星光之子的博客
08-10 269
索引组织表、 InnoDB逻辑存储结构索引组织表InnoDB逻辑存储结构表空间段-segment区-extent页-Page行-Row 索引组织表 在InnoDB存储引擎中，表 都是 根据 主键顺序 组织存放的，这种 存储方式 的 表 称为 索引组织表（index organized table） 在InnoDB存储引擎表中，每张表都有个主键（Primary Key），如果在创建表时没有显式地定义主键，则InnoDB存储引擎会按如下方式选择或创建主键： 首先判断 表中 是否有 非空的唯一索引（Unique
mysql数据页和索引页_mysql-innodb-页结构-索引页
weixin_35075144的博客
01-27 2218
innodb数据页的空间被分成了7部分记录头:delete_mask表示当前记录是否被删除,被删掉的记录不会立马清除,next_record会把被删掉的记录组成一个垃圾链表,以备重用这部分数据min_rec_maskb+树每层非叶子节点的最小记录都会添加该标记n_owned记录分组中有多少条记录heap_no表示当前记录在本页中的位置 mysql默认会添加两条伪记录,一个代表最大记录一个代表最小记...
04 | 浅谈mysql索引上
风语听画
12-28 200
一. 表类型 在InnoDB存储引擎表中，每张表都有个主键，如果在创建表时没有显式地定义主键（Primary Key），则InnoDB存储引擎会按如下方式选择或创建主键： 首先表中是否有非空的唯一索引（Unique NOT NULL），如果有，则该列即为主键。 不符合上述条件，InnoDB存储引擎自动创建一个6个字节大小的自动增长指针。 设置默认主键的作用：设立主键后，对主键建立主键索引，所有数...
mysql 页分裂_Innodb页面分裂
weixin_31600859的博客
01-19 1303
何时进行页面分裂插入操作时首先调用乐观插入函数btr_cur_optimistic_insert，若发现此次空间不足，进行悲观插入，函数btr_cur_pessimistic_insert，在这里会触发页面分裂。dberr_t btr_cur_optimistic_insert(...) {...if (leaf && page_size.is_compressed() &...
【索引】：如何在海量数据中快速查找某个数据？
南方以北
06-09 4212
在【B+树】：MySQL数据库索引是如何实现的？中，我们讲了MySQL数据库索引的实现原理。MySQL底层依赖的是B+树这种数据结构。那类似Redis这样的Key-Value数据库中的索引，又是怎么实现的呢？底层依赖的有是什么数据结构呢？ 今天，我们来讲一下索引这种常用的技术解决思路，底层往往会依赖哪些数据结构。同时，通过索引这个应用场景，我也带你回顾一下，之前我们学过的几种支持动态集合的数据结...
你真的理解MySQL索引吗？一文带你从数据结构层面解析mysql索引原理
python6_quanzhan的博客
09-17 324
索引数据结构 数据页基本结构 ： 从上图可以推断出，查询某条记录关键步骤只有2个： 定位到数据页 定位到记录 如果没有索引，查询某条记录只能先依次遍历数据页，确定记录所在的数据页之后；再从数据页中通过 页目录 定位到具体的记录，这样做效率肯定是很低的。 为了方便说明，先建一张示例表： mysql> CREATE TABLE index_demo( -> c1 INT, -> c2 INT, -> c3 CHAR(1).
深入解析Lucene索引与查询原理与实战代码
《Lucene原理与代码分析完整版》是一本深入剖析Lucene底层技术的实用指南，由Lucene开发团队的资深成员撰写。本书围绕Lucene的核心功能——全文检索，分为两大部分：原理篇和代码分析篇。 在原理篇中，作者详细讲解...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值