谈谈‘执行计划“那些事

最新推荐文章于 2024-09-11 07:16:42 发布
最新推荐文章于 2024-09-11 07:16:42 发布
阅读量632 收藏
点赞数
分类专栏： Oracle 文章标签： access table loops nested filter oracle
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/myisdb/article/details/7386344
版权
今天，我来给各位做一个详细的一个讲解----看懂执行计划


首先，我们应该知道，对于看懂一个执行计划，对我们的SQL优化，有很大的帮助。


首先，我们应该知道这两个概念，一个是RBO，一个是CBO。RBO，是Oracle8i之前使用的，一种基于规则的一种优化器。这种规则，太过死板，在Oracle10g 以后的版本就已经彻底“抛弃“了。
CBO，基于成本的优化器。它的思路是让Oracle获取所有的执行计划，通过对执行计划的分析，获取一个Cost最少的一个，然后，产生一个最终的执行计划。


对于CBO来讲，最重要的参数则是Cardinality .如果，CBO获取的Cardinality不够准确（或者是过期了），都可能导致制定错误的CBO执行计划。


这里，这展示的是，CBO无法获得准确的Cardinality 值时，将会发生什么。




SQL>create table t as select 1 id,object_name from dba_objects;


Tablecreated.


SQL>update t set id=99 where rownum=1;


1row updated.


SQL>commit;


Commitcomplete.


SQL>create index t_ind on t (id);


Indexcreated.


SQL>select count(*) from t;


  COUNT(*)
----------
     50320


SQL>set autotrace trace exp;
SQL>select * from t where id=1;


50319rows selected.




ExecutionPlan
----------------------------------------------------------
Planhash value: 1601196873


--------------------------------------------------------------------------
|Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time|
--------------------------------------------------------------------------
|0 | SELECT STATEMENT  |      | 56425 |  4353K|    53   (4)| 00:00:01|
|*1 |  TABLE ACCESS FULL| T    | 56425 |  4353K|    53   (4)| 00:00:01|
--------------------------------------------------------------------------


PredicateInformation (identified by operation id):
---------------------------------------------------


   1- filter("ID"=1)


Note
-----

  • dynamicsampling used for this statement



--注：这里，我们没有对这个表 T进行统计分析，这个是 Oracle自动通过动态采样的方式收集分析数据）， CBO估算的记录有 56425（ Card），但是，这个也是比较接近表 T的实际统计数据， 50320， CBO走的是全表扫遍，这也是比较正确的。












当我们 统计一下。
SQL>SQL> exec dbms_stats.gather_table_stats(user,'T',cascade=>true);


PL/SQLprocedure successfully completed.


SQL>select * from t where id=1;


50319rows selected.




ExecutionPlan
----------------------------------------------------------
Planhash value: 1601196873


--------------------------------------------------------------------------
|Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time|
--------------------------------------------------------------------------
|0 | SELECT STATEMENT  |      | 50311 |  1326K|    52   (2)| 00:00:01|
|*1 |  TABLE ACCESS FULL| T    | 50311 |  1326K|    52   (2)| 00:00:01|
--------------------------------------------------------------------------


PredicateInformation (identified by operation id):
---------------------------------------------------


    1- filter("ID"=1)










这里，就是比较准确数据了。 CBO选择的全表扫描很是正确。我们这样看一下，当 id=99.CBO的选择。
SQL>select * from t where id=99;




ExecutionPlan
----------------------------------------------------------
Planhash value: 1376202287


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


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


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


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


|1 |  TABLE ACCESS BY INDEX ROWID| T     |     1 |    27 |     2(0)| 00:00
:01|


|*2 |   INDEX RANGE SCAN          | T_IND |     1 |       |     1(0)| 00:00
:01|


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




PredicateInformation (identified by operation id):
---------------------------------------------------


    2- access("ID"=99)






事实上，当我们统计表的时候， CBO可以不但获得 T表的信息，也可以统计出来索引的信息。所以，当我们执行‘ whereid = 99’是， CBO，很明确的执行了索引浏览。




下面，我来显示一下第二种，当不即时统计数据（数据过旧）， CBO的错误执行计划。


SQL>update t set id=99;


50320rows updated.




SQL>commit;


Commitcomplete.


SQL>select * from t where id=99;


50320rows selected.




ExecutionPlan
----------------------------------------------------------
Planhash value: 1376202287


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


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


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


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


|1 |  TABLE ACCESS BY INDEX ROWID| T     |     1 |    27 |     2(0)| 00:00
:01|


|*2 |   INDEX RANGE SCAN          | T_IND |     1 |       |     1(0)| 00:00
:01|


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




PredicateInformation (identified by operation id):
---------------------------------------------------


    2- access("ID"=99)


这里，我们能够清楚的得到这样的数据，我们没有即时的统计数据。 CBO依然从上一个执行计划中获得，导致，我们已经更新了所有记录，全表已经都是 id=99的记录了，但， CBO，一直认为，全表也还是只有一条 id=99的记录，选择了走索引扫描的错误信息。


SQL>set autotrace trace exp;
SQL>exec dbms_stats.gather_table_stats(user,'T',cascade=>true);


PL/SQLprocedure successfully completed.


SQL>select  *from t where id=99;


ExecutionPlan
----------------------------------------------------------
Planhash value: 1601196873


--------------------------------------------------------------------------
|Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time|
--------------------------------------------------------------------------
|0 | SELECT STATEMENT  |      | 50315 |  1326K|    52   (2)| 00:00:01|
|*1 |  TABLE ACCESS FULL| T    | 50315 |  1326K|    52   (2)| 00:00:01|
--------------------------------------------------------------------------


PredicateInformation (identified by operation id):
---------------------------------------------------


    1– filter("ID"=99)


这样，我们统计一下数据， CBO就能清楚的得到执行计划。


总结：当第一次执行 SQL时， CBO发现没有做分析，所以，使用了动态采集的方式来估算数据信息，然后，对表做了分析。 SQL在执行第二次执行时， CBO，发现表已经分析过了，就不用使用动态采集了，而是直接分析数据。


这里，就会出现两种情况：
1.如果表没有做过分析，那么 CBO可以通过动态采集的方式来获得分析数据，也可以获得正确的执行计划；
2.如果表被分析过，但是分析数据信息过久，这时候， CBO就不会通过动态采集方式，而是直接使用旧的分析数据，从而导致错误的执行计划。




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

这，我详细的讲一下 Card对 CBO 的影响。
这里，我举一下，嵌套查询和关联查询。


SQL>create table t1 (id int,name varchar2(100));


Tablecreated.


SQL>create table t2 (id int,name varchar2(100));


Tablecreated.


SQL>create index ind_t1 on t1(id);


Indexcreated.


SQL>create index ind_t2 on t2(id);


Indexcreated.


SQL>create index ind_t2_name on t2(name);


Indexcreated.


SQL>insert into t1 select object_id ,object_name from dba_objects;


50321rows created.




SQL>execdbms_stats.gather_table_stats(user,'T1',cascade=>true,method_opt=>'forall indexed columns');


PL/SQLprocedure successfully completed.


这里，我开始对 T2的 card进行伪造。


SQL>select  * from t1 where  id in  (select /*+ dynamic_sampling(t2 0)cardinality(t2 10000) */ id from t2 where name ='AA');


ExecutionPlan
----------------------------------------------------------
Planhash value: 2727019379


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


|Id  | Operation                       | Name        | Rows  | Bytes |Cost (%C
PU)|Time     |


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


|0 | SELECT STATEMENT                |             |     1 |    41 |54
(4)|00:00:01 |


|1 |  TABLE ACCESS BY INDEX ROWID    | T1          |     1 |    28 |2
(0)|00:00:01 |


|2 |   NESTED LOOPS                  |             |     1 |    41 |54
(4)|00:00:01 |


|3 |    VIEW                         | VW_NSO_1    | 10000 |   126K|1
(0)|00:00:01 |


|4 |     HASH UNIQUE                 |             |     1 |   634K|
    ||


|5 |      TABLE ACCESS BY INDEX ROWID| T2          | 10000 |   634K|1
(0)|00:00:01 |


|*6 |       INDEX RANGE SCAN          | IND_T2_NAME |     1 |       |1
(0)|00:00:01 |


|*7 |    INDEX RANGE SCAN             | IND_T1      |     1 |       |1
(0)|00:00:01 |


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




PredicateInformation (identified by operation id):
---------------------------------------------------


    6- access("NAME"='AA')
    7- access("ID"="$nso_col_1")
我们发出带有子查询的 SQL，同时使用 HINT


Cardinality（ t21000）的作用是告诉 CBO从 T2表获取数据到 1000行
dynamic_samping(t20) 的作用是禁止动态采集数据。


通过这种方法，我们就模拟了子查询的返回结果树，同时为了让 CBO完全依赖与这个信息生成实行计划，禁止了子查询的动态采集


这里， T2的数据过大，所以，采集了 HASHUNIQUE。




这里， 我们再把 Cardinality设置为（ T2， 1）。看看效果。




SQL>select  * from t1 where  id in  (select /*+ dynamic_sampling(t2 0)cardinality(t2 1) */ id from t2 where name ='AA');


ExecutionPlan
----------------------------------------------------------
Planhash value: 2727019379


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


|Id  | Operation                       | Name        | Rows  | Bytes |Cost (%C
PU)|Time     |


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


|0 | SELECT STATEMENT                |             |     1 |    41 |4  (
25)|00:00:01 |


|1 |  TABLE ACCESS BY INDEX ROWID    | T1          |     1 |    28 |2
(0)|00:00:01 |


|2 |   NESTED LOOPS                  |             |     1 |    41 |4  (
25)|00:00:01 |


|3 |    VIEW                         | VW_NSO_1    |     1 |    13 |1
(0)|00:00:01 |


|4 |     HASH UNIQUE                 |             |     1 |    65 |
    ||


|5 |      TABLE ACCESS BY INDEX ROWID| T2          |     1 |    65 |1
(0)|00:00:01 |


|*6 |       INDEX RANGE SCAN          | IND_T2_NAME |     1 |       |1
(0)|00:00:01 |


|*7 |    INDEX RANGE SCAN             | IND_T1      |     1 |       |1
(0)|00:00:01 |


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




PredicateInformation (identified by operation id):
---------------------------------------------------


    6- access("NAME"='AA')
    7- access("ID"="$nso_col_1")






Cardinality的数值对于 CBO的选择无效？）


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

我们看一下两个表关联查询的情况
SQL>select /*+ dynamic_sampling(t2 0) cardinality(t2 1000) */ * fromt1,t2 where t1.id=t2.id;


ExecutionPlan
----------------------------------------------------------
Planhash value: 2959412835


---------------------------------------------------------------------------
|Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time|
---------------------------------------------------------------------------
|0 | SELECT STATEMENT   |      |  1000 | 93000 |    58   (4)| 00:00:01|
|*1 |  HASH JOIN         |      |  1000 | 93000 |    58   (4)| 00:00:01|
|2 |   TABLE ACCESS FULL| T2   |  1000 | 65000 |     2   (0)| 00:00:01|
|3 |   TABLE ACCESS FULL| T1   | 50321 |  1375K|    55   (2)| 00:00:01|
---------------------------------------------------------------------------


PredicateInformation (identified by operation id):
---------------------------------------------------


    1– access("T1"."ID"="T2"."ID")


这里例子， CBO认为 T2关联的数据足够多，而 T1又足够大，所以，在这样的情况下， HASHJOIN是正确的。




我又举个  Cardinality（ T2 1），大家再看看差别。




SQL>select /*+ dynamic_sampling(t2 0) cardinality(t2 1) */ * from t1,t2where t1.id=t2.id;


ExecutionPlan
----------------------------------------------------------
Planhash value: 828990364


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


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


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


|0 | SELECT STATEMENT            |        |     1 |    93 |     4(0)| 00:0
0:01|


|1 |  TABLE ACCESS BY INDEX ROWID| T1     |     1 |    28 |     2(0)| 00:0
0:01|


|2 |   NESTED LOOPS              |        |     1 |    93 |     4(0)| 00:0
0:01|


|3 |    TABLE ACCESS FULL        | T2     |     1 |    65 |     2(0)| 00:0
0:01|


|*4 |    INDEX RANGE SCAN         | IND_T1 |     1 |       |     1(0)| 00:0
0:01|


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




PredicateInformation (identified by operation id):
---------------------------------------------------


    4- access("T1"."ID"="T2"."ID")




当 T1足够大， T2足够小，而且 T2有索引，所以，选择 NESTEDLOOPS 是合适的。


所以，我们可以看到， Cardinality对与 CBO的执行结果是很重要的一个参数。


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



这里，我来教大家怎么看懂执行计划。


SQL>select t1.* from t1,t2 where t1.id=t2.id and t1.id=5 and t2.name='A';


ExecutionPlan
----------------------------------------------------------
Planhash value: 828990364


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


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


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


|0 | SELECT STATEMENT            |        |     1 |    93 |     4(0)| 00:0
0:01|


|1 |  TABLE ACCESS BY INDEX ROWID| T1     |     1 |    28 |     2(0)| 00:0
0:01|


|2 |   NESTED LOOPS              |        |     1 |    93 |     4(0)| 00:0
0:01|


|*3 |    TABLE ACCESS FULL        | T2     |     1 |    65 |     2(0)| 00:0
0:01|


|*4 |    INDEX RANGE SCAN         | IND_T1 |     1 |       |     1(0)| 00:0
0:01|


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




PredicateInformation (identified by operation id):
---------------------------------------------------


    3- filter("T2"."NAME"='A' AND "T2"."ID"=5)
    4- access("T1"."ID"=5)


Note
-----

  • dynamicsampling used for this statement





我们这样看。最先缩进的，就是先执行的语句，语句在前，最先执行。故，应该是
“|*3 |    TABLE ACCESS FULL       | T2     |     1 |    65 |     2(0)| 00:0
0:01|  ” 最先执行。
接着就是
|2 |   NESTED LOOPS              |        |     1 |    93 |     4(0)| 00:0
0:01|
其次，就是
|1 |  TABLE ACCESS BY INDEX ROWID| T1     |     1 |    28 |     2(0)| 00:0
0:01|


最后，再是


|0 | SELECT STATEMENT            |        |     1 |    93 |     4(0)| 00:0
0:01|


这就是整个的 SQL执行计划
ID=4—>ID=3—>ID=2—>ID=1—>ID=0


翻译下来，大概是如下。


对于 T2进行全表扫描，把符合 T2.id=5和 T2.name='A'这个条件的记录读取出来，然后去找到索引 IND_T1 =5的值，知道把 T2读完。之后，根据索引的键值去 T1表，找到相应的数据，然后，输出出来。


对于后面有谓词的参数， filter， access这两个关键字
这样解释：如果执行计划显示的是 access，就表示这个谓词条件的值将会影响数据的访问路径（表还是索引，在这里，是索引），在这里它说明是通过访问索引的方式和 T2表做关联查询，而 filter表示谓词条件的值并不会影响数据访问的路径，而只是起到过滤的作用。




参照：谭怀远先生所著的《让Oracle跑得更快》


仅作为一个学习文档，有部分错误，请高手指点。请勿喷水，谢谢。
MyISDB
关注
专栏目录
请你谈谈explain执行计划的理解？&& 索引覆盖的理解？
一个搬砖工人
04-21 378
mysql可通过explain查看执行计划，通过执行计划，我们可以知道以下信息： 1.表的读取顺序 2.数据读取操作的操作类型 3.哪些索引可以使用 4.哪些索引被实际使用 5.表之间的引用 6.每张表有多少行被优化器查询 字段 理解 id select查询的序列号，包含一组数字，表示查询中执行select子句或操作表的顺序，id的序号会递增，id值越大优先级越高，越先被执行 select_type type 访问类型，sql查询优化中一个很重要的指标，结果值从好到坏依次是：sy
SQL Server执行计划的理解
ajwqb06628的专栏
06-28 413
SQL Server执行计划的理解 　　要理解执行计划，怎么也得先理解，那各种各样的名词吧。鉴于自己还不是很了解。本文打算作为只写懂的，不懂的懂了才写。 　　在开头要先说明，第一次看执行计划要注意，SQL Server的执行计划是从右向左看的。 　　名词解析： ...
Oracle执行计划&统计信息
liyongtao524的博客
10-31 1995
忙忙碌碌过完了一周，周四晚上睡的晚，周五又忙了一天，晚上九点左右一直睡到周六七点多，能睡吧，哈哈。上篇说到几天时间，谁能料到拖了一周，拖延症很严重，大家勿学毛竹哈，闲言少叙，书归正文，本片主要讲两大部分内容：执行计划和统计信息。 1执行计划 1.1什么是执行计划 SQL执行计划即一条查询语句执行过程或访问路径的描述，一般地，我们要分析某条SQL语句的性能问题，需要首先查看SQL的执行计划，通过执行计划可以定位性能问题，通过修改sql语句等方式达到优化SQL性能的效果。 1.2如何获取执行计划 说到怎么获取，
查看Oracle执行计划的几种常用方法-系列3
bisal的专栏
10-05 3533
http://blog.csdn.net/bisal/article/details/39225373
为什么软件测试计划重要性,谈谈“测试计划”这点事
weixin_32722049的博客
07-22 1485
最近，通过一个需求让我对测试计划有了一个清晰的了解以及运用，下面是在整个测试计划制定的要点以及测试计划制定过程中遇到一些问题，在此进行总结与分享：我们在日常生活、工作中经常需要做计划，正如古人有云：凡事预则立，不预则废。这句话充分的说明了计划的必要性和重要性。项目有项目计划，测试作为项目中的一部分，也需要制定测试计划。一、 什么是测试计划？1.测试计划就像写论文一样，列出提纲，才能一步步完善，有了...
谈谈“测试计划”这点事儿
hlkt521的博客
06-02 194
最近，通过一个需求让我对测试计划有了一个清晰的了解以及运用，下面是在整个测试计划制定的要点以及测试计划制定过程中遇到一些问题，在此进行总结与分享： 我们在日常生活、工作中经常需要做计划，正如古人有云：凡事预则立，不预则废。这句话充分的说明了计划的必要性和重要性。项目有项目计划，测试作为项目中的一部分，也需要制定测试计划。 一、 什么是测试计划？ 测试计划就像写论文一样，列出提纲，才能一步步完善，有了测试计划就会掌握整个项目的进度和方向，在工作中可以有个指导的作用，不会偏离工作方向。 测试计划规定预
简单谈谈MySQL的loose index scan
01-19
所以问题来了，如果是这样一个语句，执行起来应该是怎么样的呢？语句如下： select count(distinct a) from table1;  列a上有一个索引，那么按照简单的想法来讲，如何扫描呢？很简单，一条一条的扫描，这样一来，...
请谈谈你对“计划没有变化快”这句话的理解，为了使计划执行不受突发状况的影响，您有哪些好的方法
02-07
"Plans don't change quickly" is a phrase that means that plans are usually set and don't change often. It's important to have a solid plan in place so that unexpected events don't disrupt the ...
测试计划、测试设计、测试执行
范斐斐
09-01 4481
测试计划 　　最近在一个接一个的做项目，每做一个项目都有不同的感受，我想按照测试计划，测试设计，测试执行三个方面梳理一下，和大家谈谈感受 。 　　最初做测试计划的时候会根据测试工作量来估评测试时间和资源，然后对三轮测试的时间点做一个细分。可是随着经历越来越多的项目，感受到这样计划是远远不够的，为了避免后续的测试执行工作节外生枝，我们在做测试计划时就必须多想一点，不光要多想还得想细致了。下面
IOSTAT -X 详解
MyISDB--Focus On Database
03-28 1688
LSI 12Gb/s 控制器的性能。 iostat -x 的参数分析。http://yhj1065.blog.163.com/blog/static/1980021720119204495314/
关于重建控制文件的两种方式以及区别（resetlogs ,noresetlogs)
MyISDB--Focus On Database
04-15 1268
Version:1.0StartHTML:0000000167EndHTML:0000017312StartFragment:0000000484EndFragment:0000017296 <!-- @page {margin:2cm} p {margin-bottom:0.21cm} a:link {} --> 关于重建控制文件的两种方式以及区别（resetlogs
当列设置了unused之后的恢复
MyISDB--Focus On Database
09-27 974
SQL> create table test_a(id number(3),name varchar2(10),age number(3)); Table created. SQL>  insert into test_a values(1,'a',18); 1 row created. SQL>  insert into test_a values
SGA 与 HugePage
MyISDB--Focus On Database
03-21 953
如果像生产系统，SGA的空间，尽量要pin到OS 的memory 里面。减少内存掷出。 传统的掷出memory 是swap，这就涉及到虚拟内存地址和物理内存地址的映射关系。为了减少这样CPU的寻址，就有了，尽量把常用的数据keep到内存中。传统的掷出是4k的交换，但是，这样的效率是在不高。所以，我门有了hugepage的感念。默认一页是2M，hugepage 的单位是页数。如果，你的SGA是2G
DBA应该具有什么样的素质
MyISDB--Focus On Database
03-23 891
问题起源于在写一份材料的时候，对于自己的反思。 我把自己的观点发到了twitter和各大微博上，有不少朋友纷纷回复我。这这里，先感谢各位，因为有各种思想的交锋，观点的交流，让讨论变得很有意义。 我们究竟要成为一个怎么样的DBA，公司究竟需要一个怎么样的DBA？作为一个DBA应该须有怎么样的素质？ 首先作为一个DBA，数据库的基本功很重要，了解数据库的内存结构，物理结构，了解数据库
关于aotutrace 的若干问题
MyISDB--Focus On Database
03-20 598
因为要看执行计划，所以，就拿hr做实验了 没想到，当我执行 SQL> set autotrace on SP2-0618: Cannot find the Session Identifier.  Check PLUSTRACE role is enabled SP2-0611: Error enabling STATISTICS report SQL>  竟然会有这样的报错。
简要介绍联合索引
weixin_46028606的博客
09-10 561
联合索引
Oracle EBS AP预付款行分配行剩余预付金额数据修复
最新发布
陈显平的专栏-Oracle EBS
09-11 226
英文：You may not cancel this prepayment. See the Oracle Payables User’s Guide or online help.英文：APP-SQLAP-10117: You cannot delete a prepayment that has been applied to an invoice(s).中文：APP-SQLAP-10117: 您无法删除已核销至发票的预付款。请撤消所有预付款核销，撤消已付预付款的付款单据，然后删除预付款。
erlang学习: Mnesia Erlang数据库2
qq_52132912的博客
09-10 383
需要对do函数进行实现，才能展示出数据库中的数据,do函数在书上20.4.3有相应实现。实现do函数后的代码运行截图。能够插入但是不能查询。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值