优化高手都需要深入的访问路径（ACCESS PATH）

已于 2022-10-20 15:16:53 修改
阅读量599 收藏 1
点赞数
分类专栏： DBA SQL优化 文章标签： sql 数据库
于 2022-10-20 15:16:36 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u011868279/article/details/127414126
版权
DBA 同时被 2 个专栏收录
183 篇文章 12 订阅
订阅专栏
SQL优化
17 篇文章 1 订阅
订阅专栏

访问路径：通过哪种方式对数据进行访问. 全表扫描、索引扫描或ROWID获取数据。

常见访问路径

1.TABLE ACCESS FULL(全表扫描)

  • 多块读
  • HINT:FULL(表名/别名)
  • 等待事件为db file scattered read.
  • 若为并行全表扫描，等待事件为direct path read.

2.TABLE ACCESS BY USER ROWID

  • 直接用ROWID获取数据，单块读。
  • 该访问路径在Oracle所有的访问路径中性能是最好的。

3.TABLE ACCESS BY ROWID RANGE

  • 表示ROWID 范围扫描，多块读。
  • 因为同一个块里面的ROWID是连续的，同一个EXTENT里面的ROWID也是连续的，所以可以多块读。

4.TABLE ACCESS BY INDEX ROWID

  • 回表，单块读

5.INDEX UNIQUE SCAN

  • 索引唯一扫描，单块读。
  • 对唯一索引或者主键列进行等值查询，就会走INDEX UNIQUE SCAN
  • 其性能仅次于TABLE ACCESS BY USER ROWID
scott@orclpdb1:orclcdb> set autot trace
scott@orclpdb1:orclcdb> 
scott@orclpdb1:orclcdb> 
scott@orclpdb1:orclcdb> select * from emp where empno=7369;

1 row selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 2949544139

--------------------------------------------------------------------------------------
| Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |        |     1 |    38 |     1   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| EMP    |     1 |    38 |     1   (0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN         | PK_EMP |     1 |       |     0   (0)| 00:00:01 |
--------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("EMPNO"=7369)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          2  consistent gets
          0  physical reads
          0  redo size
        961  bytes sent via SQL*Net to client
        385  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

scott@orclpdb1:orclcdb>

6.INDEX RANGE SCAN

  • 索引范围扫描，单块读，返回的数据是有序的，
  • HINT:INDEX(表名/别名 索引名)
  • 对唯一索引或者主键索引进行范围查找（INDEX RANGE SCAN，等待事件db file sequential read）。对非唯一索引进行等值查找.
scott@orclpdb1:orclcdb> select * from test where object_id=100;

1 row selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 3297604684

----------------------------------------------------------------------------------------------
| Id  | Operation                           | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |        |     1 |   132 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| TEST   |     1 |   132 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN                  | IDX_ID |     1 |       |     1   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("OBJECT_ID"=100)


Statistics
----------------------------------------------------------
        136  recursive calls
          0  db block gets
        408  consistent gets
         33  physical reads
          0  redo size
       2686  bytes sent via SQL*Net to client
        621  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
         74  sorts (memory)
          0  sorts (disk)
          1  rows processed

scott@orclpdb1:orclcdb>

索引范围扫描默认是从索引中最左边的叶子块开始，然后往右边的叶子块扫描（从小到大），当检查到不匹配数据的时候，就停止扫描。

scott@orclpdb1:orclcdb> select * from test where object_id<100 order by object_id desc;

98 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 1069979465

---------------------------------------------------------------------------------------
| Id  | Operation                    | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |        |    94 | 12408 |     5   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID | TEST   |    94 | 12408 |     5   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN DESCENDING| IDX_ID |    94 |       |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("OBJECT_ID"<100)


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
         18  consistent gets
          1  physical reads
          0  redo size
      14379  bytes sent via SQL*Net to client
        711  bytes received via SQL*Net from client
          8  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         98  rows processed

scott@orclpdb1:orclcdb>

  INDEX RANGE SCAN DESCENDING 表示索引降序范围扫描，从右往左扫描，返回的数据是降序显示的。

7.INDEX SKIP SCAN

  • 索引跳跃扫描，单块读。
  • 返回的数据是有序的
  • HINT:INDEX_SS(表名/别名 索引名)
  • 当组合索引的引导列（第一个列）没有在where条件中，并且组合索引的引导列/前几个列的基数很低，where过滤条件对组合索引中非引导列进行过滤的时候就会发生索引跳跃扫描。
  • 等待事件为 db file sequential read.
scott@orclpdb1:orclcdb> create index idx_ownerid on test(owner,object_id);

Index created.

scott@orclpdb1:orclcdb> drop index idx_id;

Index dropped.

scott@orclpdb1:orclcdb> select * from test where object_id<100;

98 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 607061290

---------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |             |    94 | 12408 |    42   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| TEST        |    94 | 12408 |    42   (0)| 00:00:01 |
|*  2 |   INDEX SKIP SCAN                   | IDX_OWNERID |    94 |       |    39   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("OBJECT_ID"<100)
       filter("OBJECT_ID"<100)


Statistics
----------------------------------------------------------
         59  recursive calls
          0  db block gets
         92  consistent gets
         17  physical reads
          0  redo size
      14379  bytes sent via SQL*Net to client
        466  bytes received via SQL*Net from client
          8  SQL*Net roundtrips to/from client
          6  sorts (memory)
          0  sorts (disk)
         98  rows processed

scott@orclpdb1:orclcdb>

8.INDEX FULL SCAN

  • INDEX FULL SCAN 表示索引全扫描，单块读，返回的数据是有序的。
  • HINT:INDEX(表名/别名 索引名)
  • 索引全扫描会扫描索引中所有的叶子块（从左往右扫描）
  • 若索引很大，会产生严重的性能问题（因为是单块读）
  • 等待事件： db file sequential read
scott@orclpdb1:orclcdb> select * from test order by object_id,owner;

73516 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 2007178810

-----------------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      | 73516 |  9476K|       |  2570   (1)| 00:00:01 |
|   1 |  SORT ORDER BY     |      | 73516 |  9476K|    13M|  2570   (1)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| TEST | 73516 |  9476K|       |   399   (1)| 00:00:01 |
-----------------------------------------------------------------------------------


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       1430  consistent gets
          0  physical reads
          0  redo size
    4868592  bytes sent via SQL*Net to client
      54537  bytes received via SQL*Net from client
       4903  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
      73516  rows processed

scott@orclpdb1:orclcdb> create index idx_idowner on test(object_id,owner,0);

Index created.

scott@orclpdb1:orclcdb> select * from test order by object_id,owner;

73516 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 3870803568

-------------------------------------------------------------------------------------------
| Id  | Operation                   | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |             | 73516 |  9476K|  1865   (1)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| TEST        | 73516 |  9476K|  1865   (1)| 00:00:01 |
|   2 |   INDEX FULL SCAN           | IDX_IDOWNER | 73516 |       |   234   (1)| 00:00:01 |
-------------------------------------------------------------------------------------------


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
      11531  consistent gets
        232  physical reads
          0  redo size
    4868592  bytes sent via SQL*Net to client
      54316  bytes received via SQL*Net from client
       4903  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      73516  rows processed

scott@orclpdb1:orclcdb>

9.INDEX FAST FULL SCAN

  • 索引快速全扫描，多块读。
  • HINT:INDEX_FFS（表名/别名 索引名）
  • 等待事件 db file scattered read
scott@orclpdb1:orclcdb> drop index idx_ownername;

Index dropped.

scott@orclpdb1:orclcdb> create index idx_ownername on test(owner,object_name,0);

Index created.

scott@orclpdb1:orclcdb> select owner,object_name from test;

73516 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 3888663772

--------------------------------------------------------------------------------------
| Id  | Operation            | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |               | 73516 |  2871K|   146   (0)| 00:00:01 |
|   1 |  INDEX FAST FULL SCAN| IDX_OWNERNAME | 73516 |  2871K|   146   (0)| 00:00:01 |
--------------------------------------------------------------------------------------


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       5405  consistent gets
        537  physical reads
          0  redo size
    3773365  bytes sent via SQL*Net to client
      54307  bytes received via SQL*Net from client
       4903  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      73516  rows processed

scott@orclpdb1:orclcdb> create index idx_id on test(object_id);

Index created.

scott@orclpdb1:orclcdb> select object_name from test where object_id<100;

98 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 3297604684

----------------------------------------------------------------------------------------------
| Id  | Operation                           | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |        |    94 |  3760 |     5   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| TEST   |    94 |  3760 |     5   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN                  | IDX_ID |    94 |       |     2   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("OBJECT_ID"<100)


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
         18  consistent gets
          1  physical reads
          0  redo size
       2851  bytes sent via SQL*Net to client
        476  bytes received via SQL*Net from client
          8  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         98  rows processed

scott@orclpdb1:orclcdb> create index idx_idname on test(object_id,object_name);

Index created.

scott@orclpdb1:orclcdb> select object_name from test where object_id<100;

98 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 3678957952

-------------------------------------------------------------------------------
| Id  | Operation        | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |            |    94 |  3760 |     2   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| IDX_IDNAME |    94 |  3760 |     2   (0)| 00:00:01 |
-------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("OBJECT_ID"<100)


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          9  consistent gets
          1  physical reads
          0  redo size
       2851  bytes sent via SQL*Net to client
        476  bytes received via SQL*Net from client
          8  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         98  rows processed

scott@orclpdb1:orclcdb> select object_name from test where object_id>100;

73415 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 252646278

-----------------------------------------------------------------------------------
| Id  | Operation            | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |            | 73420 |  2867K|   142   (1)| 00:00:01 |
|*  1 |  INDEX FAST FULL SCAN| IDX_IDNAME | 73420 |  2867K|   142   (1)| 00:00:01 |
-----------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("OBJECT_ID">100)


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       5386  consistent gets
        513  physical reads
          0  redo size
    3530801  bytes sent via SQL*Net to client
      54686  bytes received via SQL*Net from client
       4896  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      73415  rows processed

scott@orclpdb1:orclcdb>

10.INDEX FULL SCAN(MIN/MAX)

  • 索引最小、最大值扫描、单块读
  • INDEX FULL SCAN(MIN/MAX) 只会访问“索引高度”个索引块，其性能与INDEX UNIQUE SCAN一样，其性能仅次于TABLE ACCESS BY USER ROWID

11.MAT_VIEW REWRITE ACCESS FULL

  • MAT_VIEW REWRITE ACCESS FULL 表示物化视图全表扫描、多块读。
  • 因为物化视图本质上也是一个表，所以其扫描方式与全表扫描一样。
scott@orclpdb1:orclcdb> 
scott@orclpdb1:orclcdb> 
scott@orclpdb1:orclcdb> create materialized view test_mv build immediate enable query rewrite 
  2  as select object_id,object_name from test;

Materialized view created.

scott@orclpdb1:orclcdb> select object_id,object_name from test;

73516 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 1627509066

----------------------------------------------------------------------------------------
| Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |         | 73516 |  2799K|   129   (1)| 00:00:01 |
|   1 |  MAT_VIEW REWRITE ACCESS FULL| TEST_MV | 73516 |  2799K|   129   (1)| 00:00:01 |
----------------------------------------------------------------------------------------


Statistics
----------------------------------------------------------
         36  recursive calls
         12  db block gets
       5370  consistent gets
        453  physical reads
       1980  redo size
    4184006  bytes sent via SQL*Net to client
      54311  bytes received via SQL*Net from client
       4903  SQL*Net roundtrips to/from client
          2  sorts (memory)
          0  sorts (disk)
      73516  rows processed

scott@orclpdb1:orclcdb>

因为物化视图TEST_MV 已经包含查询需要的字段，所以该SQL会直接访问物化视图TEST_MV.

2单块单读与多块读

  • 单块读:从磁盘1次读取1个块到buffer cache.
  • 多块读:从磁盘1次读取多个块到buffer cache.
  • 如果数据块都已经缓存在buffer cache中，那就不需要物理I/O了，没有物理I/O也就不存在单块读与多块读。
  • 绝大数的平台，一次I/O最多只能读取或者写入1MB数据。
  • Oracle的块大小默认是8K,那么一次I/O最多只能写入128个块到磁盘，最多只能读取128个块到buffer cache.
  • 在判断哪个访问路径性能好的时候，通常是估算每次访问的I/O次数，谁的I/O次数少，谁的性能就好。在估算I/O次数的时候，我们只需要算个大概即可。
DB架构
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
ASP.NET 链接 Access 数据库路径问题最终解决方案
10-30
ASP.NET 链接 Access 数据库路径问题最终解决方案
DB - Access Path Selection in a Relational DMS
07-12
DB - Access Path Selection in a Relational Database Management System.pdf In a high level query and data manipulation language such as SQL, requests are stated non-procedurally, without reference to access paths. This paper describes how System R chooses access paths for both simple (single relation) and complex queries (such as joins), given a user specification of desired data as a boolean expression of predicates. System R is an experimental database management system developed to carry ..
详解Oracle数据库中table Access by index rowid原理及优化方法
最新发布
专注于数据库技术分享，包含但不限于Oracle，MySQL，PostgreSQL，ElasticSearch及国产数据库等
04-03 368
在Oracle数据库中，是指在执行SQL查询时，数据库首先利用索引来定位到相关数据行的ROWID（Row Identifier），然后通过ROWID直接访问表的相应数据块以获取完整行数据的过程。ROWID是一个伪列，对于每行数据都是唯一的，它指向了数据在数据库物理存储结构中的具体位置。
OleDB 访问Access驱动.rar
09-29
解决win 64位 32位 oledb不能访问Access数据库的问题
ASKDATABRAKE_VC访问数据库access_
10-02
一个实例，VC和ACCESS数据库进行开发的一个实例，包括数据库的连接，访问，关闭等。
C#源码 访问ACCESS数据库 通过反射调用命令 清理数据库 执行数据库优化 压缩操作
01-25
C#源码 访问ACCESS数据库 通过反射调用命令 清理数据库 执行数据库优化 压缩操作 非常不错的参考资料
ORACLE 优化---回表（TABLE ACCESS BY INDEX ROWID)
u011868279的博客
12-14 1万+
当对一个列创建索引之后，索引会包含该列的键值以及键值对应行所在的rowid。通过索引中记录的rowid访问表中的数据就叫回表。回表一般是单块读，回表次数太多会严重影响SQL性能，如果回表次数太多，就不应该走索引扫描了，应该直接走全表扫描。 在进行SQL优化的时候，一定要注意回表次数！特别是要注意回表的物理I/O次数！ SQL> select * from test where owner...
table access by index rowid
cuiyan1982的专栏
10-16 5275
原文地址：http://blog.csdn.net/shushugood/article/details/51475825 table access by index rowid  回表：在数据中，当查询数据的时候，在索引中查找索引后，获得该行的rowid，根据rowid再查询表中数据，就是回表。 --创建一个表， 索引只建立在object_id上
Oracle12c新特性-Table access by index rowid batched 的解释
qq_44897264的博客
04-13 2046
Table access by index rowid batched就是通过在访问索引表时一次性获取多个行的行ID，并且将它们按照一定批次分组，然后批量访问这些行所在的数据表的方式来优化查询执行效率的。Table access by index rowid batched（表访问索引行批处理）是一种Oracle数据库查询执行计划中的操作，表示在执行查询时，通过索引表的行ID来访问数据表，并且可以一次获取多个行的数据。
在OLTP中，表访问的几种常规操作
数据库
11-11 2149
在OLTP中，表访问的几种常规操作 1、table access(full)：全表扫描，通过扫描全表的方式来访问表，这样的表操作，一般情况下是不想 PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- Plan hash value: 139135
索引
road_of_technology的博客
03-08 180
索引组织表 ​ **回表：**select * from t where id=1之类的查询，id列有索引，如果是普通的表，需要先从索引中获取rowid，然后定位到表中，获取id以外的其他列的动作，这就是回表。 索引组织表最大的特点：表就是索引，索引就是表，这是一种很特别的设计，所以无须访问表。 但是这种设计的表的更新比普通表开销更大。因为表要和索引一样有序的排序，更新负担将会非常严重，因此...
oracle中慢sql优化思路
独孤清扬玩DB
07-04 9635
参考资料：官方文档SQL Tuning Guide https://docs.oracle.com/en/database/oracle/oracle-database/12.2/tgsql/sql-performance-fundamentals.html#GUID-DD9CAA74-3E0B-48C9-8770-AADB614BC992 Oracle Database 2 Day + Performance Tuning Guide Oracle Performance Tuning Guide
关于Oracle表访问方式的总结
weixiaohuai的博客
06-17 1394
一、简介 Oracle访问表中记录主要有下面三种方式： 全表扫描（TABLE ACCESS FULL）； 通过ROWID访问表（TABLE ACCESS BY ROWID）； 索引扫描（TABLE ACCESS BY INDEX SCAN）； 下面结合示例分别对三种访问方式进行详解。 二、全表扫描（TABLE ACCESS FULL） 概念：Oracle顺序访问数据表中的每一条记录，并检查每条记录是否满足where指定的过滤条件。在表很大的情况下，不太建议使用全表扫描，效率很低，除非查询出来的记
Oracle SQL执行计划操作（1）——表相关操作
数据库生态圈（RDB & NoSQL & Bigdata）——专注于关系库优化（Oracle&Mysql&PG&SQL Server ）
11-11 966
本文详细说明了Oracle SQL语句执行计划中表相关操作，同时，结合实例对其进行了深入讲解。
oracle TABLE ACCESS BY INDEX ROWID 你不知道的索引回表-开发系列（三）
热门推荐
xiaohai798的专栏
11-11 3万+
TABLE ACCESS BY INDEX ROWID 你不知道的索引回表带来的低效率
【索引分类】位图索引
Sharon--start focusing on Oracle
04-11 1243
位图索引 位图索引非常适合于决策支持系统(Decision Support System，DSS)和数据仓库，它们不应该用于通过事务处理应用程序访问的表。它们可以使用较少到中等基数(不同值的数量)的列访问非常大的表。尽管位图索引最多可达30个列，但通常它们都只用于少量的列。例如，您的表可能包含一个称为Sex的列，它有两个可能值：男和女。这个基数只为2，如果用户频繁地根据Sex列的值查询该表，这就
powershell 不需要accesskey and secretkey访问S3代码
07-14
在 PowerShell 中访问 Amazon S3 存储桶时，你需要提供有效的 Access Key 和 Secret Key 进行身份验证。以下是一个示例代码，展示了如何使用 PowerShell 访问 S3： ```powershell # 安装 AWS Tools for PowerShell ...

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值