oracle概念分析,1.Oracle性能优化的基本概念和原理

最新推荐文章于 2024-04-08 21:30:38 发布
最新推荐文章于 2024-04-08 21:30:38 发布
阅读量138 收藏 1
点赞数
文章标签： oracle概念分析

----------------------Oracle性能优化的基本概念和原理－－－－－－－－－－－－－－－－－－－－

一、成本的含义

两层含义——

1、从表面看，是诸如执行计划等工具导致的执行次数

2、SQL语句执行的时候导致的实际的消耗

综上描述，将成本定义为指由优化器执行计算而导致的消耗，

也就是优化器对执行语句所用的时间的最优的估计。

优化器——数学模型，驻留在数据库上的程序、视图、触发器、作业。当执行SQL语句的时候，

会自动调用后台的程序结合视图的数据找出最优的SQL的执行策略。

二、优化器的模式

1、RBO优化器(RBO优化法则)——执行机制很简单，人为的通过既定的规则控制SQL语句的执行，

表的内容对执行计划是没有影响的，从oracle10g版本开始，RBO优化法则被全面淘汰。

2、CBO优化器(CBO优化法则)——执行SQL语句的时候，尝试找到成本最低的数据访问的方法，

而且考虑表和索引的内容。

CBO优化器又叫做基于成本的优化器、基于代价的优化法则、CBO优化器、CBO优化法则、

基于代价的优化器＝CBO

参数：

SQL> show parameter optimizer;

NAME                                 TYPE                             VALUE

------------------------------------ -------------------------------- ------------------------------

optimizer_dynamic_sampling           integer                          2

optimizer_features_enable            string                           10.2.0.4

optimizer_index_caching              integer                          0

optimizer_index_cost_adj             integer                          100

optimizer_mode                       string                           ALL_ROWS

optimizer_secure_view_merging        boolean                          TRUE

optimizer_mode选项：

ALL_ROWS——用能返回结果集的所有行来表示最短时间内完成语句的执行计划，默认用CBO法则

FIRST_ROWS_n——用能返回结果集的前n行来表示最短时间内完成语句的执行计划，默认用CBO法则

例如:first_rows(20)

CHOOSE_oracle9i数据库的默认值，提供了一种时运行选择方式，

可以在RBO和CBO之间切换，建议在10g版本中不用。

RULE——基于规则的优化法则(RBO)

三、动态采样

在段对象(表、索引、分区)没有作统计分析(收集对象的性能数据)的前提下，

为了使得优化器得到足够的信息，以保证作出正确的执行计划而生的一种技术。

可以看成是分析手段的一个补充，直接从需要分析的对象收集一些数据块(采样)

来获得CBO需要的信息。

案例：

SQL> create table t as select owner,object_type from all_objects;

Table created.

SQL> select count(1) from t;

COUNT(1)

----------

40907

SQL> set linesize 10000

SQL> set autotrace traceonly exp  －－打开查看执行计划的工具

SQL> select * from t;

Execution Plan

----------------------------------------------------------

Plan hash value: 1601196873

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      | 43528 |  1190K|    30   (4)| 00:00:01 |  －－执行计划估计的结果是有误差的。

|   1 |  TABLE ACCESS FULL| T    | 43528 |  1190K|    30   (4)| 00:00:01 |

--------------------------------------------------------------------------

Note

-----

- dynamic sampling used for this statement  －－这个SQL做了动态采样。

COST值是RBO优化法则中是没有的。

COST＝将所有的消耗转化为单块读的次数。

禁用动态采样的话：

SQL> select /*+ dynamic_sampling(t 0) */ * from t;  －－采样的级别为0，表示禁用动态采样

Execution Plan

----------------------------------------------------------

Plan hash value: 1601196873

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      | 10047 |   274K|    29   (0)| 00:00:01 |  －－误差更大。

|   1 |  TABLE ACCESS FULL| T    | 10047 |   274K|    29   (0)| 00:00:01 |

--------------------------------------------------------------------------

SQL> conn /as sysdba

Connected.

SQL> show parameter dyn

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

optimizer_dynamic_sampling           integer     2   －－默认的动态采样的级别

系统级别禁用动态采样的话：

SQL> alter system set optimizer_dynamic_sampling=0 scope=both;

System altered.

SQL> show parameter dyn

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

optimizer_dynamic_sampling           integer     0

SQL> select * from t;  －－不用加提示，直接禁用

Execution Plan

----------------------------------------------------------

Plan hash value: 1601196873

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      | 10047 |   274K|    29   (0)| 00:00:01 |

|   1 |  TABLE ACCESS FULL| T    | 10047 |   274K|    29   (0)| 00:00:01 |

--------------------------------------------------------------------------

SQL> alter system set optimizer_dynamic_sampling=2 scope=both;  －－还原默认值

System altered.

SQL> show parameter dyn

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

optimizer_dynamic_sampling           integer     2

结论——有动态采样虽然有少许的误差，但是比不采样好好的多，最起码执行计划不会很离谱。

正常的情况：

1、收集统计分析信息

2、当用户执行SQL的时候，会根据收集到的统计分析信息生成执行计划。

3、按照执行计划去执行SQL语句

尝试手工分析(手工收集性能数据)：

在SYS下：

SQL> exec dbms_stats.gather_table_stats('scott','t',estimate_percent=>100);

PL/SQL procedure successfully completed.

如果在scott下：

SQL> show user

USER is "SCOTT"

SQL> exec dbms_stats.gather_table_stats(user,'t',estimate_percent=>100);

PL/SQL procedure successfully completed.

SQL> select * from t;

Execution Plan

----------------------------------------------------------

Plan hash value: 1601196873

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      | 40907 |   559K|    30   (4)| 00:00:01 |  －－没有误差

|   1 |  TABLE ACCESS FULL| T    | 40907 |   559K|    30   (4)| 00:00:01 |

--------------------------------------------------------------------------

发现此时没有以下的字样：

Note

-----

- dynamic sampling used for this statement

执行计划会不会随着数据的改变而改变：

SQL> delete from t where rownum<=30000;

30000 rows deleted.

SQL> commit;

Commit complete.

SQL> select * from t;  －－执行计划的得出完全依赖于性能数据，性能数据不变，执行计划就不变。性能数据的改变依赖于统计信息的收集。

Execution Plan

----------------------------------------------------------

Plan hash value: 1601196873

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      | 40907 |   559K|    30   (4)| 00:00:01 |

|   1 |  TABLE ACCESS FULL| T    | 40907 |   559K|    30   (4)| 00:00:01 |

--------------------------------------------------------------------------

重新分析一次：

SQL> exec dbms_stats.gather_table_stats(user,'t',estimate_percent=>100);

PL/SQL procedure successfully completed.

SQL> select * from t;

Execution Plan

----------------------------------------------------------

Plan hash value: 1601196873

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      | 10907 |   149K|    29   (0)| 00:00:01 |

|   1 |  TABLE ACCESS FULL| T    | 10907 |   149K|    29   (0)| 00:00:01 |

--------------------------------------------------------------------------

尝试将统计信息删除：

SQL> exec dbms_stats.delete_table_stats(user,'t');  －－删掉性能数据

PL/SQL procedure successfully completed.

SQL> select * from t;

Execution Plan

----------------------------------------------------------

Plan hash value: 1601196873

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      | 12185 |   333K|    29   (0)| 00:00:01 |

|   1 |  TABLE ACCESS FULL| T    | 12185 |   333K|    29   (0)| 00:00:01 |

--------------------------------------------------------------------------

Note

-----

- dynamic sampling used for this statement   －－开始动态采样了。

SQL> delete from t;

10907 rows deleted.

SQL> commit;

Commit complete.

SQL> select * from t;   －－动态采样是会随着数据的变化而变化的，因为每次执行SQL，发现没有性能数据收集的话，强制动态采样。

Execution Plan

----------------------------------------------------------

Plan hash value: 1601196873

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      |     1 |    28 |    29   (0)| 00:00:01 |

|   1 |  TABLE ACCESS FULL| T    |     1 |    28 |    29   (0)| 00:00:01 |

--------------------------------------------------------------------------

Note

-----

- dynamic sampling used for this statement

SQL> select /*+ dynamic_sampling(t 0) */ * from t;  －－禁用

Execution Plan

----------------------------------------------------------

Plan hash value: 1601196873

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      | 10047 |   274K|    29   (0)| 00:00:01 |  －－plan严重错误

|   1 |  TABLE ACCESS FULL| T    | 10047 |   274K|    29   (0)| 00:00:01 |

--------------------------------------------------------------------------

SQL> truncate table t;  －－HWM下降了，extent回收。

Table truncated.

SQL> select /*+ dynamic_sampling(t 0) */ * from t;  －－不用动态采样的话，估计行数的时候是按照extent估算的。

Execution Plan

----------------------------------------------------------

Plan hash value: 1601196873

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      |    82 |  2296 |     2   (0)| 00:00:01 |

|   1 |  TABLE ACCESS FULL| T    |    82 |  2296 |     2   (0)| 00:00:01 |

--------------------------------------------------------------------------

SQL> select * from t;  －－不是按照extent数量估算，而是按照实际来估算。

Execution Plan

----------------------------------------------------------

Plan hash value: 1601196873

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      |     1 |    28 |     2   (0)| 00:00:01 |

|   1 |  TABLE ACCESS FULL| T    |     1 |    28 |     2   (0)| 00:00:01 |

--------------------------------------------------------------------------

Note

-----

- dynamic sampling used for this statement

统计分析和动态采样的区别：

1、场景不一样——统计分析的结果会存储在磁盘(存储在数据字典表)，

但是动态采样的分析结果是不存储的，每次SQL执行，动态采样都会强制执行

(前提是没有分析数据)。每次执行SQL的时候，

会根据这些分析的结果按照CBO数学模型来组装执行计划，执行计划存储在共享池的库缓存中，

执行计划需要存储在数据字典中的分析信息，这些内容会存储在数据字典高速缓存中。

显然，动态采样不具有共享性，随时变化，加大了资源的消耗。

2、分析范围指标不一样：动态采样靠加大采样的级别来加大分析的范围。

而统计分析是靠参数estimate_percent来加大分析的范围。

exec dbms_stats.gather_table_stats(user,'t',estimate_percent=>100);

3、分析程度不一样——动态采样是采样评估，统计分析是对CBO数学模型中众多的指标进行数学运算，

从本质上说，统计分析的结果会更加准确。

4、动态采样仅仅是一个补救措施(CBO数学模型的一个分支)，

而不是得到准确的执行计划的专用方法。

加大采样级别：

SQL> insert into t select owner,object_type from all_objects;

40907 rows created.

SQL> commit;

Commit complete.

SQL> select /*+ dynamic_sampling(t 0) */ * from t;

Execution Plan

----------------------------------------------------------

Plan hash value: 1601196873

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      |    82 |  2296 |     2   (0)| 00:00:01 |

|   1 |  TABLE ACCESS FULL| T    |    82 |  2296 |     2   (0)| 00:00:01 |

--------------------------------------------------------------------------

SQL> select /*+ dynamic_sampling(t 1) */ * from t;

Execution Plan

----------------------------------------------------------

Plan hash value: 1601196873

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      | 44185 |  1208K|    29   (4)| 00:00:01 |

|   1 |  TABLE ACCESS FULL| T    | 44185 |  1208K|    29   (4)| 00:00:01 |

--------------------------------------------------------------------------

Note

-----

- dynamic sampling used for this statement

SQL> select /*+ dynamic_sampling(t 2) */ * from t;

Execution Plan

----------------------------------------------------------

Plan hash value: 1601196873

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      | 45659 |  1248K|    29   (4)| 00:00:01 |

|   1 |  TABLE ACCESS FULL| T    | 45659 |  1248K|    29   (4)| 00:00:01 |

--------------------------------------------------------------------------

Note

-----

- dynamic sampling used for this statement

SQL> select /*+ dynamic_sampling(t 3) */ * from t;

Execution Plan

----------------------------------------------------------

Plan hash value: 1601196873

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      | 40907 |  1118K|    29   (4)| 00:00:01 |

|   1 |  TABLE ACCESS FULL| T    | 40907 |  1118K|    29   (4)| 00:00:01 |

--------------------------------------------------------------------------

Note

-----

- dynamic sampling used for this statement

SQL> select /*+ dynamic_sampling(t 4) */ * from t;

Execution Plan

----------------------------------------------------------

Plan hash value: 1601196873

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      | 40907 |  1118K|    29   (4)| 00:00:01 |

|   1 |  TABLE ACCESS FULL| T    | 40907 |  1118K|    29   (4)| 00:00:01 |

--------------------------------------------------------------------------

Note

-----

- dynamic sampling used for this statement

SQL> select /*+ dynamic_sampling(t 10) */ * from t;

Execution Plan

----------------------------------------------------------

Plan hash value: 1601196873

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      | 40907 |  1118K|    29   (4)| 00:00:01 |

|   1 |  TABLE ACCESS FULL| T    | 40907 |  1118K|    29   (4)| 00:00:01 |

--------------------------------------------------------------------------

Note

-----

- dynamic sampling used for this statement

采样级别越高，越准确，但是给系统带来的损耗也越大！

或者直接将系统参数改为一个较大的值，不用写提示/*+ dynamic_sampling(t n) */，

直接用所调整的采样级别。

周德峰
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
oracle统计sql优化与原理详解
qq_36758630的博客
06-26 1241
简介：oracle统计类sql的优化，此篇只讲count sum avg max min orderby，主要还是要知道索引存储列值和rowid的特性，我的博客里也有常用索引（树状索引）的详解。一.count(*)的优化直接上例子（假设test表有10w数据，列有10列）：1.select count(*) from test count(*)我们都知道是统计有多少数量，通常我们建表都会有一个主键...
Oracle优化器案例与原理分析（盖国强）
05-12
Oracle优化器案例与原理分析（盖国强），不错的oracle资料。
Oracle的优化原理
mustbelove的专栏
11-20 1152
前面讲了ORACLE性能调优原则，但是可能有许多朋友不知道ORACLE优化机理到底是什么？下面作一简单说明。    解释    先说明一下，ORACLE有一个优化器（Optimizer），ORACLE的优化机理就是从Optimizer开始的。    明确两个概念：Optimizer 对ORACLE的优化方式有两种，一种是基于规则的，我们称为RBO（Rule-Based Optimiza
Oracle数据库是一款功能强大、性能卓越的数据库管理系统，其优势体现在以下几个方面
最新发布
BLOG域名:programb.blog.csdn.net
04-08 498
它是构建千兆字节数据系统或超高可用性系统的关键工具。：当表中积累了多年的数据时，可以采用分表策略，例如按年份创建新表并将对应年份的数据存储进去，以此减少单表的数据量，提高查询效率。：对于含有数十亿条记录的大表，可以实施表分区技术，将数据分散到不同的物理分区中，这样在查询时只需要扫描相关的分区，而不是整个表。：定期检查并删除表中的重复记录，可以避免数据冗余，并保持数据表的整洁，这有助于提高查询效率和节省存储空间。：Oracle提供了丰富的数据管理功能，能够处理大量数据，并保证数据的持久保存、共享和可靠性。
ORACLE优化原理
橘子汽水的博客
06-08 206
ORCLE优化原理 ， 解析SQL过程 T-SQL在查询各个阶级分别干了什么： （1）FROM 阶段 FROM阶段标识出查询的来源表，并处理表运算符。在涉及到联接运算的查询中（各种join），主要有以下几个步骤： 　　a.求笛卡尔积。不论是什么类型的联接运算，首先都是执行交叉连接（cross join），求笛卡儿积，生成虚拟表VT1-J1。 b.ON筛选器。这个阶段对上个步骤生成的VT1-J1进行筛选，根据ON子句中出现的谓词进行筛选，让谓词取值为true的行通过了考验，插入到V...
Oracle 优化原理
数据工匠-PowerData
07-12 294
1.Query transformer: 1)View merging - represent the view to the containing query block(table). 2)Predicate pushing - push the relevant predicates from the containing query block into the view. 3)Su
oracle的索引原理
Better_Man123的专栏
06-02 1610
[1] 基本的索引概念查询DBA_INDEXES视图可得到表中所有索引的列表，注意只能通过USER_INDEXES的方法来检索模式(schema)的索引。访问USER_IND_COLUMNS视图可得到一个给定表中被索引的特定列。[2] 组合索引当某个索引包含有多个已索引的列时，称这个索引为组合（concatented）索引。在 Oracle9i引入跳跃式扫描的索引访问方法之前，查询只能在有限条件下
Oracle优化常用概念.pptx
09-22
Oracle 优化常用概念 Oracle 优化器是 Oracle 数据库管理系统中一个核心组件，负责根据用户提交的 SQL 语句生成最优的执行计划，以提高查询...了解 Oracle 优化器的常用概念对于提高查询效率和数据库性能至关重要。
Oracle索引分析与查询优化.pdf
10-09
Oracle 索引分析与查询优化 Oracle 是一种关系型数据库，广泛应用于国内交通、电力、通信和金融等重要领域。...通过对 Oracle 索引的原理机制和查询优化的理解，可以提高 Oracle 数据库的性能和效率。
ORACLE索引的使用与优化.pdf
10-10
ORACLE索引的使用与优化.pdf 数据库系统是信息管理系统的核心，基于数据库的联机事务处理（OLTP）和联机分析处理（OLAP）是在医院中最为重要的计算机应用之一。从医院信息管理系统（HIS）的应用分析来看，查询的SQL...
Oracle数据库原理及应用教学大纲.pdf
12-16
* 了解 Oracle 数据库的安全机制和性能优化技术 四、教学内容及学时安排 ### 1. 第一讲：数据库基本概念 * 数据库的定义和作用 * 数据库管理系统的类型 * 数据库的基本概念：数据、模式、数据类型、数据关系 ###...
1.Oracle性能优化的基本概念和原理
weixin_33825683的博客
08-20 98
----------------------Oracle性能优化的基本概念和原理－－－－－－－－－－－－－－－－－－－－一、成本的含义两层含义—— 1、从表面看，是诸如执行计划等工具导致的执行次数 2、SQL语句执行的时候导致的实际的消耗综上描述，将成本定义为指由优化器执行计算而导致的消耗，也就是优化器对执行语句所用的时间的最优的估计。优化器——数学模型，驻留在数据库...
oracle数据库的性能优化思路
红孩儿编程大师
10-31 318
数据库访问优化漏斗法则 1 减少数据访问 例如调整索引，调整SQL的执行计划 2 返回更少的数据 使用分页技术 3 减少交互次数 使用批量提交的方式 4 减少CPU开销 排序与绑定变量的技术 5 利用更多的资源 利用多个CPU的并行执行 Merits 性能优化方法 1 测量 2 评估 3 再现 4 改进 5 推断 6 安装 改进性能的可能的措施有： 1 添加索引以避免全表扫描 2 删除不必要的索引 3 对表和索引进行分区 4 使用物化视图 5 使用绑...
ORACLE基础概念
Z_T_T的博客
05-10 455
数据库实例    用Oracle官方描述：实例是访问Oracle数据库所需的一部分计算机内存和辅助处理后台进程，是由进程和这些进程所使用的内存(SGA)所构成一个集合。其实就是用来访问和使用数据库的一块进程，它只存在于内存中。就像Java中new出来的实例对象一样。我们访问Oracle都是访问一个实例，但这个实例如果关联了数据库文件，就是可以访问的，如果没有，就会得到实例不可用的错误。
Oracle性能优化（一）理解SQL的执行方式，优化可执行的SQL
vivasugar的博客
03-07 266
此帖参考网上多种性能优化的资料，分析，整理，去重，纠错，加上自己的理解和认知汇总而成。转载请写明出处，谢谢 1. 理解访问Table的方式 全表扫描 全表扫描就是顺序地访问表中每条记录. ORACLE采用一次读入多个数据块(database block)的方式优化全表扫描。 通过ROWID访问表 你可以采用基于ROWID的访问方式情况,提高访问表的效率，ROWID包含了表中记录的物理位置信...
ORACLE性能优化简述
m0_38036502的博客
05-26 352
ORACLE性能 ORALCE插入：ORACLE用PARALLEL并行+APPEND直接加载技术+NOLOGGING不记日志技术 比直接INSERT插入效率能提升30%以上。 DB2插入：通过LOAD FROM CURSOR可以实现在不通的表空间或数据库之间快速轻松地转移数据的方法， 比INSET INTO效率要相对快一些，但是如果执行中出现错误，容易导致表不可用。 1.SELECT子句中避免使用‘*’，多表查询时，列名前有表名标示； 2.能用UNION ALL的情况绝不用UNION； 3.减少数据库访问次
oracle性能优化篇之执行计划详解.pdf
09-24
《Oracle性能优化篇之执行计划详解》是一篇介绍Oracle数据库性能优化中的关键概念和技术的文章。通过深入讲解Oracle执行计划的相关内容，帮助读者更好地理解和优化数据库查询性能。 在Oracle数据库中，执行计划是...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值