数据库修化神篇一——B-树如何使查询更快

浅谈为什么数据库要用B树 记住,数据库的性能往往决定了整个系统的响应速度,下一次当你遇到查询慢的问题时,别忘了看看你的索引结构,说不定你就能找到那个让系统加速的小“钥匙”!举个例子,假设你在数据库里存了一堆商品的价格信息,如果你想查询100到500元之间的商品,B+树的设计可以让你从一个叶子节点开始,顺着链表快速找到符合条件的所有数据。这种结构的好处是,数据更集中,查找效率更高,特别是当你要进行范围查询时,比如“找出大于50且小于100的所有记录”,B+树能帮你更快完成任务。别担心,我会用最简单的方式,帮你把这个复杂的概念搞清楚。 阅读详情

B-树如何使查询更快

本文翻译自,部分内容翻译可能不准确,请以原文为准。

B树是一种有助于搜索大量数据的结构,B-树发明于 40 多年前发,现在仍然被大多数现代数据库使用。尽管出现了较新的索引结构,比如 LSM 树,但B-树在处理大多数数据库查询时依然非常高效。

阅读这篇文章后,您将了解 B-树 如何组织数据以及它如何执行搜索查询。

背景

为了理解B-树,让我们首先关注二叉搜索树 (BST)。

这里可能会有疑问,B-树和二叉搜索树难道不是一样的吗?

这里的“B”代表的是什么呢?

据wikipedia.org里的内容,B-树的发明者爱德华·麦克雷特(Edward M. McCreight)曾经说过:

the more you think about what the B in B-trees means, the better you understand B-trees.”
“你越是思考B树中的B意味着什么,你就越能理解B树。”

我们常常将B-树与BST混淆在一起,实际上他们并不完全相同。但是从BST出发,有助于我们理解B-树。让我们从一个简单的 BST 示例开始:

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

较大的数字总是在右边,较小的数字在左边。随着我们节点的增多,这种规则结构会更加清晰。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

这棵树包含七个数字,我们最多需要访问三个节点才能找到任何数字。以下示例可视化了搜索 14,这里使用 SQL 来定义查询,以便将此树视为实际的数据库索引。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

硬件

从理论上讲,使用二叉搜索树来运行我们的查询看起来性能不错,它的时间复杂度(搜索时)与 B 树相同,都是O(logn)。但在实现过程中,数据结构需要在实际硬件上工作,使用该数据结构构建的索引必须存储在计算机上的某个位置。

计算机有三个可以存储数据的位置:

  • CPU缓存
  • RAM(内存)
  • 磁盘(存储)

缓存完全由 CPU 管理,缓存相对较小,通常为几兆字节。索引可能包含千兆字节的数据,因此索引不适合放在缓存里。

数据库大量使用内存 (RAM),内存有如下优点:

  • 确保快速随机访问
  • 它的大小可能非常大

当然内存也有一些缺点,电源关闭后数据将会丢失,与磁盘相比,价格比较昂贵。

内存的缺点就是磁盘的优点,磁盘比较便宜,掉电后数据也不会丢失。但是磁盘的访问速度相对较慢,尤其需要注意顺序读取和随机读取,只要在某些条件下磁盘读取速度较快,后面会详细解释这一点。

随机和顺序访问

内存可以视为一个大可以存放数据的大数组,根据数组下标对内存数据进行访问。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

假设我们要访问下标为1,4,6的数据,我们需要随机访问。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

如果我们要将1,4,6的数据与3,4,5的数据进行比较,则我们可以顺序访问。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

“随机读取”和“顺序读取”之间的区别是由硬盘驱动器来决定的。磁盘一般由磁头和圆盘组成。

“随机读取”需要将磁头移动到磁盘上的给定位置,而“顺序读取”只需要旋转磁盘,允许磁头读取连续值。读取数据量较大(MB以上)时,这两种访问类型之间的差异是巨大的,使用“顺序读取”可显著缩短获取数据所需的时间。

Adam Jacobs在Acm Queue上发表的文章“The Pathologies of Big Data”中研究了随机访问和顺序访问之间的速度差异。它揭示了一些令人震惊的事实:

  • HDD 上的顺序访问可能比随机访问快数十万倍
  • 从磁盘按顺序读取可能比从内存中随机读取更快

现在谁还在使用机械硬盘呢?都考虑SSD了吧!但这项研究表明,完全按顺序读取 HDD 可能比 SSD 更快。但是,请注意,这篇文章是 2009 年的文章,SSD 在过去十年中得到了显着发展,因此这些结果可能已经过时。

总而言之,最关键的是我们要尽可能地选择顺序访问。在下一段中,我将解释如何将其应用于我们的索引结构。

优化树以实现顺序访问

二叉搜索树可以用和堆相同的方式在内存中表示:

  • 父节点位置为 i
  • 左节点位置是 2i
  • 右节点位置是 2i+1

以下是根据示例计算这些位置的方式(父节点从 1 开始):

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

根据计算出的位置,将节点与内存对齐:

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

让我们回到之前的可视化查询,

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

它在内存级里是这个样子的:

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

执行查询时,需要访问内存地址 1、3 和 6,访问三个节点非常快。但随着我们存储的数据越来越多,树会变得越来越高。存储超过 100 万个值需要高度至少20的树。这意味着必须从内存中不同位置读取 20 个值,这将会导致完全随机的访问!

页面

当一棵树长得很高时,随机访问会导致越来越多的延迟。减少这个问题的解决方案很简单:在宽度而不是高度上扩展数。这可以通过将多个值打包到单个节点中来实现。(深度访问还是广度访问的问题)

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

这种存储方式带来了如下好处:

  • 这棵树较浅(两层而不是三层)
  • 它仍然有很大的空间来容纳新的价值,而不需要进一步增长

对此类索引执行的查询如下所示:

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

请注意,每次访问节点时,我们都需要加载节点的所有值。在此示例中,我们需要加载 4 个值(如果树已满,则为 6 个值)才能到达我们正在寻找的值。下面,我们来看看这颗查询树在内存中的可视化效果:

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

与前面的示例(树的高度增长)相比,此搜索速度应该更快。我们只需要随机访问两次(跳转到单元格 0 和 9),然后按顺序读取其余值。

随着我们数据库的增长,这个解决方案的效果越来越好。如果要存储 100 万个值,则需要:

  • 有 20 层(高度20)的二叉搜索树
  • 有 10 层(高度10)的 3 值节点树

来自单个节点的值构成一个页面,在上面的示例中,每个页面(节点)由三个值组成。页面是放置在彼此相邻的磁盘上的一组值,因此数据库可以通过一次顺序读取一次读取整个页面。

那么在实际的数据库中,页面是如何实现的呢?Postgres页面 大小为 8kB。假设 20% 用于元数据,因此还剩 6kB,需要一半的页面来存储指向节点子节点的指针,因此它为我们提供了 3kB 的值。BIGINT 大小为 8 个字节,因此我们可以在单个页面中存储 ~375(3*1024/8) 个值。

假设数据库中一些相当大的表有 10 亿行,我们需要在 Postgres 树中存储多少个级别来存储它们?根据上面的计算,如果我们创建一个可单个节点包含375 个值的树,存储 10 亿个值时树只有4层(高度4)。二叉搜索树需要 30 层(高度30)才能处理如此数量的数据。

总而言之,在树的单个节点中放置多个值有助于我们降低其高度,从而利用顺序存取的好处。此外,B-树不仅可以在高度上增长,还可以在宽度上增长(通过使用更大的页面)。

平衡

数据库中有两种类型的操作:写入和读取。在上一节中,我们解决了从 B-树中读取数据的问题。尽管如此,写作也是一个至关重要的部分。在将数据写入数据库时,B-树需要不断更新新值。

树的形状取决于添加到树中的值的顺序,它在二叉树中很容易看到。如果值以不正确的顺序相加,我们可能会获得具有不同深度的树。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

当树在不同的节点上具有不同的深度时,称为不平衡树。基本上有两种方法可以将这样的树恢复到平衡状态:

  • 只需按正确的顺序添加值即可从头开始重建它。
  • 随着新值的添加,始终保持平衡。

B-树实现选择第二个选项。使树始终保持平衡的功能称为自平衡。

自平衡算法示例

构建 B-树只需创建一个节点并添加新值即可开始,直到其中没有可用空间。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

如果对应页面上没有空间了,则需要分叉。要执行分叉,需要选择“分叉点”。在这种情况下,它将是 12,因为它位于中间。“分叉点”是将移动到上层页面的值。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

现在,出现了一种有趣的场景——“分叉点”没有上页。在这种情况下,需要生成一个新的页面(“分叉点”将成为新的根页面!)

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

最后,这三个中有一些可用空间,因此可以添加值 14。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

按照这个算法,我们可以不断地向 B 树添加新的值,并且它会一直保持平衡!

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

在这一点上,您可能有一个合理的担忧,即有很多可用空间没有机会被填充。例如,值 14、15 和 16 位于不同的页面上,因此这些页面将永远只有一个值和两个可用空间。

这是由拆分位置选择引起的。我们总是在中间拆分页面。但是每次我们进行拆分时,我们都可以选择我们想要的任何拆分位置。

Postgres 有一个算法,每次执行拆分时都会运行!它的实现可以在 Postgres 源代码的 _bt_findsplitloc() 函数中找到。它的目标是尽可能少地留出可用空间。

总结

在本文中,您了解了 B-树的工作原理。总而言之,它可以简单地描述为具有两个变化的二叉搜索树:

  • 每个节点可以包含多个值
  • 使用自平衡算法插入新值
Android Studio安装常见问题详解——Android Emulator Hypervisor Driver for AMD Processors installation failed. 目录一、问题描述二、解决方案2.1 开启CPU虚拟化2.2 禁用Hyper-V2.3 使用管理员命令行在驱动程序包中执行“silent_install.bat” 一、问题描述 新买的AMD轻薄本,在安装Android Studio时遇到问题: Android Emulator Hypervisor Driver for AMD Processors installation failed. 笔记本配置为: 二、解决方案 2.1 开启CPU虚拟化 设置虚拟化的步骤这里不进行详细介绍了。如果需要,可以自行百 阅读详情

相关推荐

慕课软件质量保证与测试(习题集)

慕课金陵科技学院.软件质量保证与测试.期末复习.习题汇总0 总目录1 绪论1.1 软件质量保证与测试的产生与发展1.2 软件缺陷,软件错误,软件故障1.3 软件质量保证与测试的意义,原则和挑战1.4 单元测试1.5 课后作业2 软件测试策略2.1 软件测试的模型,过程和生命周期2.2 软件测试的方法和技术2.3 单元测试2.4 课后作业3 黑盒测试3.1 黑盒测试概述3.2 等价类划分测试3.3 边界值测试3.4 错误推测法3.5 判定表驱动法3.6 因果图法3.7 场景法3.8 正交实验法3.9 单元测试

weixin_42473228的博客 5万+

The Pathologies of Big Data(大数据病理)

本文详细描述了大数据的产生原因,为了找到大数据产生的原因,论文前部分通过一份伪数据分析了传统情况下处理数据出现的问题,接着有分析了计算机的硬件,通过磁盘、SSD、内存的顺序读写和随机读写的对比,找到了处理解决大数据问题的规则,接着这个规则对面对的问题给出了解决方法,最终为大数据下定了一个定义。

Yore - Home 2286

密码学新手必看:三大顶级会议论文下载与阅读指南(附完整资源链接)

本文为密码学新手提供了系统性的三大顶级会议(Crypto、Eurocrypt、Asiacrypt)论文学习指南。内容涵盖如何高效获取最新论文资源、结构化精读论文的方法论,以及将理论转化为代码实践的路径,旨在帮助初学者快速构建密码学知识体系并应用于研究。

weixin_29214691的博客 321

大厂必备技能:数据结构树之B树、B+树

今天呢,在本篇文章中,咱们结束树这种数据结构,讲解最后几个知识点,也就是大家学习Java过程中肯定听说过的B树以及B+树,我相信大家肯定听过这两种树,大部分是在MySQL高级篇讲解索引的底层原理的时候,大家肯定知道索引的底层是B+树,在咱们B+树key保存着每条数据的唯一索引,而data域则保存着当前数据在咱们硬盘中的内存地址。今天呢,咱们好好讲解一下B树以及B+树,最后咱们手写一下B+树,让大家更好的掌握这棵特别重要且效率非常之高的树,让咱们的技术更上一层楼,离优秀的自己更近一步。

zjjcchina的博客 869

Vivado新手必看:5分钟搞定FPGA程序固化到Flash(附MCS文件生成全流程)

本文为FPGA新手详细解析了如何将程序固化到Flash存储器的完整流程。核心在于理解SRAM工艺FPGA断电易失的特性,并利用Vivado工具将比特流文件转换为Flash可识别的MCS文件。文章重点拆解了生成MCS文件的关键配置步骤、硬件连接要点,以及通过JTAG烧写Flash的实战操作,并提供了常见启动失败问题的排查清单,帮助开发者实现设计从调试到产品部署的关键跨越。

weixin_29230901的博客 355

【云原生之Docker实战】使用docker部署Monica个人开源CRM系统

【云原生之Docker实战】使用docker部署Monica个人开源CRM系统

jks212454的博客 2388

数据结构与算法分析:实现一个快速查找树的算法

作者:禅与计算机程序设计艺术 数据结构与算法分析:实现一个快速查找树的算法 1. 引言 1.1. 背景介绍 快速查找树,也叫二叉查找树,是一种非常常用的树形数据结构。它以二叉树的形式表示数据,并提供了高效的查找、插入、删除等操作。快速查找树具有以下

AI天才研究院 5127

Magisk如何针对性隐藏Root避免被检测

Magisk隐藏特征码有两种途径,一种是通过插件,一种是定制源码。插件的方式相对简单,但是使用范围也有限,好处是成本低好上手。定制源码难度大,成本高,好处是稳定,后续也好更新维护。

zhonglunshun的专栏 1万+

数据结构之查找算法:B树

查找算法:B树

千寻瀑 1270

Windows部署OpenClaw报错不断?这篇环境配置指南帮你解决难题

想在Windows上部署OpenClaw却频频报错?🔧 本文详细梳理了OpenClaw部署必需环境的安装步骤和官方下载地址 📦,提供完整的验证清单和常见问题排查方法,帮你一次性搞定所有环境配置,顺利部署OpenClaw ✅

XiaoqiangClub的博客 6658

LinePhone3.2.7(android端最新版本) sip客户端

SIP客户端For android:LinePhone3.2.7(最新版本),官网地址:http://www.linphone.org/

比B+Tree更快,查询速度飙升的秘密武器

我们都知道MySQL中的B+Tree索引结构,对于根据某个条件查找记录是非常快的。那么,在不断追求极致的驱动下,你有没有想过MySQL会不会有比B+Tree更快的数据结构,来加速查找记录的性能呢?答案是有的,MySQL为了让我们更快地获取自己想查找的记录,在InnoDB中,将查询频繁的条件和索引树结果做了一个Hash映射,这样,一个查询就不需要每次搜索B+Tree去定位结果了,这个Hash映射就叫做AHI,全称Adaptive Hash Index,自适应哈希索引。一听这名字,你或许已经猜出个一二了。

资料免费分享,点击名片 237

IMSL CNL 7.0.0 (x86-64)Crack

IMSL CNL 7.0.0 (x86-64)Crack intel的算法库破解文件,这是C++版本的破解文件

B 树如何让您的查询更快?

在本文中,您了解了 B 树的工作原理。每个节点可能包含多个值插入新值之后是自平衡算法。尽管现代数据库使用的结构通常是B树的一些变体(例如B+树),但它们仍然基于原始概念。在我看来,B 树的一大优势在于它是直接设计用于在实际硬件上处理大量数据的。这可能就是B树陪伴我们这么久的原因。原文地址。

xuejianxinokok的专栏 935

jdk-8u144-linux-x64.tar.gz.

该资源为搭建Linux系统Java环境用,资源的后缀为tar.gz格式的压缩包

android 蓝牙通讯demo

android 下蓝牙通讯demo,实现了发现蓝牙,使能蓝牙,通过蓝牙发送消息。

阿里面试,问了B+树,这个回答让我通过了

上周我通过阿里一面,岗位是客户端开发工程师。面试过程中面试官问了B+树,回答时面试官一直点头(应该回答得还不错,过了),今天详细讲一讲B+树。

4万+

Elasticsearch的数据库与数据仓库整合

1.背景介绍 Elasticsearch是一个开源的搜索和分析引擎,基于Lucene库,具有实时搜索、文本分析、数据聚合等功能。在大数据时代,Elasticsearch在数据库和数据仓库领域得到了广泛的应用。本文将从以下几个方面进行讨论: 背景介绍 核心概念与联系 核心算法原理和具体操作步骤以及数学模型公式详细讲解 具体代码实例和详细解释说明 未来发展趋势与挑战 附录常见问题与解答 1....

AI天才研究院 1396

MySQL 索引实战详解:为什么B+类型的索引查询更快

MySQL中B+树索引查询更快,本质是其结构设计完美适配“磁盘存储特性”和“业务查询场景”,核心可总结为3点(结合前文细节和示意图,强化记忆):非叶节点纯索引化,压缩树高,将磁盘I/O次数控制在3-4次,大幅降低查询耗时——这是B+树比B树、哈希索引I/O效率更高的核心原因;叶子节点有序双向链表,高效支持范围查询、排序、分页,适配绝大多数业务场景——这是B+树比哈希索引、B树通用性更强的关键;

黑牛儿的博客 489

B+树 范围查询_数据结构与算法-- B+树

既然前面提到B-树的查找性能已经很优秀了,为什么又出来了B+树?试想B-树每查找一个元素都进行一次磁盘IO,尽管已经通过降低树高减少IO次数,但如果树高为n,要查找的元素恰好位于叶子结点,那么最快也要经过n次IO,如果数据库中存在上亿条记录,查询的性能可想而知。那么有没有更好的方法提高效率呢?B+树便产生了。开始讲B+树之前,先 温习一下B-树的特性:一个m阶的B-树具有以下特性:1.根节点至少有...

weixin_39885412的博客 2387

数据库索引设置原理-B+树

数据库查询优化主要依赖索引机制。全表扫描会逐行读取数据并匹配条件,效率较低。索引通过B+树数据结构实现,将数据有序组织(支持字符串按字典序排序),显著提升查询速度。建立索引应遵循"常查、常排、常连、高选"原则,但对小表、频繁更新字段、低选择性字段等不建议建立索引。B+树通过减少I/O操作和优化存储结构,能够高效处理各种数据类型查询。

weixin_39112004的博客 747

规避这些坑,能让你在查询数据库时更快

在数据库中,对于查询操作比较频繁的表,可以使用索引,索引又分为主键索引和非主键索引(有人也分为聚簇索引和非聚簇索引),我们先来看看主键索引是如何提高查询性能的。索引经历了几个阶段,第一个阶段使用的是二叉树,将数据直接存储在各个节点上,虽然相对一般查询来说也提高了效率,但是由于层级太高,查询和维护的时候都比较麻烦;第二阶段是B-数,此时也是将数据存储在各个节点上,虽然提高了维护效率,但是加载全部的信息还是需要不少的时间;第三阶段是B+数,该阶段将索引存储到B+树上,非叶子节点不存储数据,叶子节点也不存储数据,

m0_49622667的博客 721

Mysql中的B树索引和B+树索引的区别?

在B树中,你可以将键和值存放在内部节点和叶子节点;但在B+树中,内部节点都是键,没有值,叶子节点同时存放键和值。 B+树的叶子节点有一条链相连,而B树的叶子节点各自独立。 1 使用B树的好处 B树可以在内部节点同时存储键和值,因此,把频繁访问的数据放在靠近根节点的地方将会大大提高热点数据的查询效率。这种特性使得B树在特定数据重复多次查询的场景中更加高效。 2 使用B+树的好处 由于B+树的内部节点只存放键,不存放值,因此,一次读取,可以在内存页中获取更多的键,有利于更快地缩小查找范围。 B+树..

麦田里的守望者 5633

[DB] Database Compression

无损压缩是一种压缩方法,在压缩和解压缩过程中不会丢失任何信息。解压缩后的数据与原始数据完全相同,所有的信息都能被精确恢复。

m0_74331272的博客 1172

mysql数据库-索引后续篇

1.B树和B+树的区别 B树中,你可以将键和值存放在内部节点和叶子节点;但在B+树中,内部节点都是键没有值。叶子节点同时存放键和值。优势:可以在;内部节点同时存储键和值,因此把频繁访问的数据放在靠近根节点的地方将会大大提高热点数据的查询效率。这种特性使得B树在特定数据重复多次查询的场景中更加高效。 B+树的叶子节点有一条链相连,而B树的叶子节点各自独立。优点:B+树的内部节点只存放键,不存放值,因此,一次读取,可以在内存页中获取更多的键,有利于更快地缩小查找范围,B+树的叶节点由一条链相连,因此,当需要进行

weixin_43940150的博客 188

B树和B+树简单分析总结

本文参考 公众号 程序员小灰中关于B+树的讲解 ​ MySQL索引主要基于Hash和B+树的数据结构,本文将对B树和B+树进行一个简单的描述。 ​ 我们都知道,树的查询效率高,并且可以保持有序,但MySQL并未使用二叉查找树这种更快的查找方式来设计索引,是由于在服务器上查找时必须考虑到IO因素,并且数据库索引是保存在磁盘上的,当数据量比较大时,索引大小甚至可以到到G单位以上,当我们...

lichunliang的博客 1593

单表查询和多表连接查询哪个效率更快?

《高性能mysql》中的回答

weixin_45756851的博客 4064

单表查询和多表连接查询哪个效率更快

这个问题自己找了一个易懂的解答 一.第一个解答来源于《高性能Mysql》中的回答 很多高性能的应用都会对关联查询进行分解。简单地,可以对每个表进行一次单表查询,然后将结果在应用程序中进行关联。例如,下面这个查询: select * from tag join tag_post on tag_post.tag_id=tag.id join post on tag_post.post_id=...

luoluo_lj的博客 1961

mongodb为什么默认不使用速度更快的hash索引?反而使B+树索引

MongoDB默认使用B+树索引而非哈希索引的原因在于综合性能考量。哈希索引虽在精确查询时具备O(1)优势,但存在三大缺陷:无法支持范围查询(如age>20)、不能直接用于排序操作、不支持复合索引的前缀匹配。而B+树索引通过有序存储特性,既能高效处理点查询(O(logn)),又能完美支持范围查询、排序和复合查询,成为数据库应对多样化查询场景的理想选择。这种设计权衡体现了工程实践中的通用性优先原则。

MongoDB4.0.7源代码研究,find、inser等命令调用过程,B+树数据存储逻辑,索引查询逻辑等深入知识。 762
上一篇: 数据库修仙秘境篇十——nfs详解
下一篇: pandoc自定义过滤器
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值