MySQL SQL 分析 - 参数化查询 vs query cache 功能

最新推荐文章于 2024-03-26 10:43:23 发布
最新推荐文章于 2024-03-26 10:43:23 发布
阅读量7.9k 收藏 2
点赞数 1
分类专栏： mysql linux 文章标签： mysql 数据库 缓存 性能
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/signmem/article/details/12972127
版权
linux 同时被 2 个专栏收录
81 篇文章 0 订阅
订阅专栏
mysql
26 篇文章 0 订阅
订阅专栏

query cache,  mysql 5 开始附带的一个功能， 与引擎无关， 只与数据查询语法相关。

 

测试描述： 当前使用中是 MySQL-5.6.14 Linux RHEL6  64 位系统产生环境,  使用 INNODB 引擎， 分配 innodb 2g 内存空间

 

[root@TiYanPlat ~]# uname -a
Linux TiYanPlat 2.6.32-358.el6.x86_64 #1 SMP Tue Jan 29 11:47:41 EST 2013 x86_64 x86_64x86_64 GNU/Linux

mysql> select version();
+-----------+
| version() |
+-----------+
| 5.6.14    |
+-----------+
1 row in set (0.00 sec)

mysql> show variables like 'innodb_buffer_pool_size';
+-------------------------+------------+
| Variable_name           | Value      |
+-------------------------+------------+
| innodb_buffer_pool_size | 2147483648 |
+-------------------------+------------+
1 row in set (0.01 sec)

 

Query cache 功能：

利用 qeury_cache_size 定义内存大小， 内存用于把用户 SQL 放入内存中， 包括 SQL 语句， 包括SQL 语句执行的结果

假如下一次查询时使用相同的 SQL 语句， 则直接从内存中获得结果， 不再进行 SQL 分析， 不在进行磁盘 I/O 读数据。加速数据查询返回结果。

 

实现目标，开启 QCACHE 功能， 如 my.cnf 定义

query-cache-size=16777216
query-cache-type=ON

查询数据库中是否使用当前功能

mysql> show status like '%qcache%';
+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+
| Qcache_free_blocks      | 440      |
| Qcache_free_memory      | 12306960 |
| Qcache_hits             | 13176    |
| Qcache_inserts          | 29777    |
| Qcache_lowmem_prunes    | 0        |
| Qcache_not_cached       | 45862    |
| Qcache_queries_in_cache | 2098     |
| Qcache_total_blocks     | 4701     |
+-------------------------+----------+
8 rows in set (0.02 sec)

参数返回结果不再一一详细描述， 自行参考官方文档， 从上返回结果可以看到，使用中的数据库 SQL 命中率 （Qcache_hits） 并不理想，原因与业务有关。

 

SQL 分析一， 使用了 QUERY CACHE 的好处

原理， 利用 EXPLAIN 分析当前 SQL 执行计划， 利用 PROFILE 功能分析当前 SQL 执行计划，过程

执行下面语句进行分析

mysql> explain select tbcrbtnumb0_.id as id41_, tbcrbtnumb0_.business_ring_id as business2_41_, tbcrbtnumb0_.application_no as applicat3_41_, tbcrbtnumb0_.mobile as mobile41_ from tb_crbt_numbers_load tbcrbtnumb0_ where 1=1 and tbcrbtnumb0_.business_ring_id=11024;
+----+-------------+--------------+------+---------------+------+---------+------+--------+-------------+
| id | select_type | table        | type | possible_keys | key  | key_len | ref  | rows   | Extra       |
+----+-------------+--------------+------+---------------+------+---------+------+--------+-------------+
|  1 | SIMPLE      | tbcrbtnumb0_ | ALL  | NULL          | NULL | NULL    | NULL |180182 | Using where |
+----+-------------+--------------+------+---------------+------+---------+------+--------+-------------+
1 row in set (0.00 sec)

当前语法执行的是全表扫描，另外，需要从 180182 行中扫描相关结果

 

SQL 分析二， 判断第一次执行该 SQL 时候的执行过程

mysql> set profiling=1;

mysql> select tbcrbtnumb0_.id as id41_, tbcrbtnumb0_.business_ring_id as business2_41_, tbcrbtnumb0_.application_no as applicat3_41_, tbcrbtnumb0_.mobile as mobile41_ from tb_crbt_numbers_load tbcrbtnumb0_ where 1=1 and tbcrbtnumb0_.business_ring_id=11024;

+-------+---------------+---------------+-------------+
| id41_ | business2_41_ | applicat3_41_ | mobile41_   |
+-------+---------------+---------------+-------------+
| 30838 |         11024 | TH20121127229 | 02038688592 |
+-------+---------------+---------------+-------------+
1 row in set (0.30 sec)

mysql> show profile;                                                                                                          +--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.000191 |
| Waiting for query cache lock   | 0.000023 |
| init                           | 0.000090 |
| checking query cache for query | 0.000499 |
| checking permissions           | 0.000030 |
| Opening tables                 | 0.000131 |
| init                           | 0.000277 |
| System lock                    | 0.000042 |
| Waiting for query cache lock   | 0.000005 |
| System lock                    | 0.000443 |
| optimizing                     | 0.000364 |
| statistics                     | 0.000107 |
| preparing                      | 0.000059 |
| executing                      | 0.000019 |
| Sending data                   | 0.290067 |
| end                            | 0.000483 |
| query end                      | 0.000169 |
| closing tables                 | 0.000158 |
| freeing items                  | 0.000252 |
| Waiting for query cache lock   | 0.000063 |
| freeing items                  | 0.000305 |
| Waiting for query cache lock   | 0.000015 |
| freeing items                  | 0.000095 |
| storing result in query cache  | 0.000145 |
| cleaning up                    | 0.000330 |
+--------------------------------+----------+
25 rows in set, 1 warning (0.01 sec)

从上面看出， 第一次执行该 SQL， MySQL 需要对 SQL 进行锁缓存，初始化，从缓存中查询是否具备之前缓存过的 SQL，检查用户权限， 表权限，打开表，锁定内存，定制执行计划，执行语句，把数据从磁盘中放入内存中操作，关闭表，锁定数据， 缓存数据等操作， 工作原理与 ORACLE 类似

 

按照 QUERY CACHE 原则， 假如 SQL 语句改变 (tbcrbtnumb0_.business_ring_id=11024) 替换该变量值， 那么该 SQL 会被看作为一个新的 SQL， 这个时候， MySQL 将会对整个 SQL 做一次全新的操作， 如上（黄线标注描述）

 

分析 SQL 三

mysql> select tbcrbtnumb0_.id as id41_, tbcrbtnumb0_.business_ring_id as business2_41_, tbcrbtnumb0_.application_no as applicat3_41_, tbcrbtnumb0_.mobile as mobile41_ from tb_crbt_numbers_load tbcrbtnumb0_ where 1=1 and tbcrbtnumb0_.business_ring_id=11021;
+-------+---------------+---------------+-------------+
| id41_ | business2_41_ | applicat3_41_ | mobile41_   |
+-------+---------------+---------------+-------------+
| 30835 |         11021 | TH20121127259 | 02038688592 |
+-------+---------------+---------------+-------------+
1 row in set (0.34 sec)

mysql> show profile;
+--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.000795 |
| Waiting for query cache lock   | 0.000077 |
| init                           | 0.000045 |
| checking query cache for query | 0.000337 |
| checking permissions           | 0.000040 |
| Opening tables                 | 0.000113 |
| init                           | 0.000488 |
| System lock                    | 0.000050 |
| Waiting for query cache lock   | 0.000030 |
| System lock                    | 0.000289 |
| optimizing                     | 0.000512 |
| statistics                     | 0.000278 |
| preparing                      | 0.000078 |
| executing                      | 0.000028 |
| Sending data                   | 0.322662 |
| end                            | 0.004777 |
| query end                      | 0.001703 |
| closing tables                 | 0.000526 |
| freeing items                  | 0.000874 |
| Waiting for query cache lock   | 0.000311 |
| freeing items                  | 0.001809 |
| Waiting for query cache lock   | 0.000105 |
| freeing items                  | 0.000184 |
| storing result in query cache  | 0.000966 |
| cleaning up                    | 0.000678 |
+--------------------------------+----------+
25 rows in set, 1 warning (0.00 sec)

上 SQL二，三结果可以看到， 当 WHERE 条件改变， MySQL 会把这两个 SQL 识别为一个新的 SQL， 需要重新操作。

 

SQL 分析四， 假如我们重新执行 SQL 三操作，看看结果如何？（注意，这个时候 QUERY CACHE 真正发挥作用）

mysql> select tbcrbtnumb0_.id as id41_, tbcrbtnumb0_.business_ring_id as business2_41_, tbcrbtnumb0_.application_no as applicat3_41_, tbcrbtnumb0_.mobile as mobile41_ from tb_crbt_numbers_load tbcrbtnumb0_ where 1=1 and tbcrbtnumb0_.business_ring_id=11021;
+-------+---------------+---------------+-------------+
| id41_ | business2_41_ | applicat3_41_ | mobile41_   |
+-------+---------------+---------------+-------------+
| 30835 |         11021 | TH20121127259 | 02038688592 |
+-------+---------------+---------------+-------------+
1 row in set (0.00 sec)

mysql> show profile;                                                                                                          +--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.001367 |
| Waiting for query cache lock   | 0.000071 |
| init                           | 0.000027 |
| checking query cache for query | 0.000163 |
| checking privileges on cached  | 0.000129 |
| checking permissions           | 0.000386 |
| sending cached result to clien | 0.000164|
| cleaning up                    | 0.000079 |
+--------------------------------+----------+
8 rows in set, 1 warning (0.01 sec)

参考 SQL 分析三，四，数据查询需要使用的时间（绿色标注部分）很明显， SQL 分析四返回速度块了很多，另外，从系统返回的 SQL 分析看出来，系统直接从缓存中返回数据给客户， 没有重复进行 SQL 分析及磁盘 I/O 操作。（蓝色标注部分） 因此， QEURY CACHE 明显加速了 SQL 返回结果。

但必须注意，只有两个 SQL 相同的情况下，才能够获得 QUERY CACHE 的优点。

 

 

参数化查询

参数化查询能够在一定情况下避免了 SQL 注入， 而 ORACLE 也比较推荐使用参数化查询， ORACLE 每次执行 SQL （无论 SQL 是否语法一致）都存在 SQL 分析，

假如SQL语法不一样，则进行硬解析，需要重新定制执行计划

假如SQL语法不一致则进行软解析，避免重复定制执行计划，减少 CPU 消耗，增加 SQL 语句返回时间。

MySQL 官方文档中并没有提出到这点。

 

对 MySQL 进行参数化查询分析

SQL 参数化分析一


mysql> set @num=11204;
mysql> select tbcrbtnumb0_.id as id41_, tbcrbtnumb0_.business_ring_id as business2_41_, tbcrbtnumb0_.application_no as applicat3_41_, tbcrbtnumb0_.mobile as mobile41_ from tb_crbt_numbers_load tbcrbtnumb0_ where 1=1 and tbcrbtnumb0_.business_ring_id=@num;
+-------+---------------+---------------+-----------+
| id41_ | business2_41_ | applicat3_41_ | mobile41_ |
+-------+---------------+---------------+-----------+
| 31051 |         11204 | 1222570       | 85237810  |
| 31052 |         11204 | 1222570       | 82685386  |
| 31053 |         11204 | 1222570       | 82783689  |
| 31054 |         11204 | 1222570       | 82685106  |
| 31055 |         11204 | 1222570       | 38880051  |
+-------+---------------+---------------+-----------+
5 rows in set (0.37 sec)

mysql> show profile;                                                                                                          +--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.001858 |
| Waiting for query cache lock   | 0.000089 |
| init                           | 0.000150 |
| checking query cache for query | 0.001143 |
| checking permissions           | 0.000970 |
| Opening tables                 | 0.000544 |
| init                           | 0.000743 |
| System lock                    | 0.000170 |
| optimizing                     | 0.000332 |
| statistics                     | 0.000293 |
| preparing                      | 0.000134 |
| executing                      | 0.000057 |
| Sending data                   | 0.438626 |
| end                            | 0.000694 |
| query end                      | 0.000221 |
| closing tables                 | 0.000300 |
| freeing items                  | 0.000521 |
| cleaning up                    | 0.000360 |
+--------------------------------+----------+
18 rows in set, 1 warning (0.01 sec)


变量值不变情况下，重复执行该 SQL 语句

mysql> select tbcrbtnumb0_.id as id41_, tbcrbtnumb0_.business_ring_id as business2_41_, tbcrbtnumb0_.application_no as applicat3_41_, tbcrbtnumb0_.mobile as mobile41_ from tb_crbt_numbers_load tbcrbtnumb0_ where 1=1 and tbcrbtnumb0_.business_ring_id=@num;
+-------+---------------+---------------+-----------+
| id41_ | business2_41_ | applicat3_41_ | mobile41_ |
+-------+---------------+---------------+-----------+
| 31051 |         11204 | 1222570       | 85237810  |
| 31052 |         11204 | 1222570       | 82685386  |
| 31053 |         11204 | 1222570       | 82783689  |
| 31054 |         11204 | 1222570       | 82685106  |
| 31055 |         11204 | 1222570       | 38880051  |
+-------+---------------+---------------+-----------+
5 rows in set (0.34 sec)

mysql> show profile;                                                                                                          +--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.001188 |
| Waiting for query cache lock   | 0.000052 |
| init                           | 0.000030 |
| checking query cache for query | 0.001791 |
| checking permissions           | 0.000172 |
| Opening tables                 | 0.000614 |
| init                           | 0.001346 |
| System lock                    | 0.000268 |
| optimizing                     | 0.000626 |
| statistics                     | 0.000674 |
| preparing                      | 0.000439 |
| executing                      | 0.000028 |
| Sending data                   | 0.327278 |
| end                            | 0.000649 |
| query end                      | 0.000217 |
| closing tables                 | 0.000408 |
| freeing items                  | 0.000692 |
| cleaning up                    | 0.000570 |
+--------------------------------+----------+
18 rows in set, 1 warning (0.01 sec)

分析结果

从数据返回时间上看来（蓝色标注）， 使用参数化查询，并没有在时间返回上获得优势。

从SQL执行计划上看来（紫色标注), 相同 SQL 语句使用参数化查询，系统同样会重新定制执行计划，产生磁盘I/O， 并没有想 ORACLE 一样获得性能上的优化。

另外，参数化查询是不会在 query cache 内存块中取结果的。

 

可以看做每次使用参数化查询都会被认为是一个全新的 SQL 进行分析， （没有学习到 ORACLE 的精髓，比较失望）

 

注意，使用参数化查询时， 即时使用 SQL_cache  语法, 也无法使用 query cache 功能。

 

常见开发下有几种选择

1. 直接把 SQL 变量值提交至 MySQL API 执行，（可利用 QUERY CACHE 功能，有部分 SQL 能够进行数据加速）但可能会遇到 SQL 注入， 升级程序麻烦。

2. 利用  procudure, function 等功能先吧 SQL 进行打包然后再调用执行， 类似参数化查询， 无法获得 QUERY CACHE 功能， 令程序清晰， 程序升级，修改比较方便， 并且有效防止了 SQL 注入。

 

 

Terry_Tsang
关注
  • 1
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论
专栏目录
mysql 参数化_安全 -- mysql参数化查询,防止Mysql注入
weixin_39828847的博客
01-18 637
参数化查询(Parameterized Query 或 Parameterized Statement)是指在设计与数据库链接并访问数据时，在需要填入数值或数据的地方，使用参数(Parameter) 来给值，这个方法目前已被视为最有效可预防SQL注入攻击(SQL Injection) 的攻击手法的防御方式。有部份的开发人员可能会认为使用参数化查询，会让程序更不好维护，或者在实现部份功能上会非常不...
SqlServer参数化查询之where in和like实现详解
12-15
身为一名小小的程序猿，在日常开发中不可以避免的要和where in和like打交道，在大多数情况下我们传的参数不多简单做下单引号、敏感字符转义之后就直接拼进了SQL，执行查询，搞定。若有一天你不可避免的需要提高SQL的查询性能，需要一次性where in 几百、上千、甚至上万条数据时，参数化查询将是必然进行的选择。然而如何实现where in和like的参数化查询，是个让不少人头疼的问题。 where in 的参数化查询实现 首先说一下我们常用的办法，直接拼SQL实现，一般情况下都能满足需要 代码如下: string userIds = “1,2,3,4”; using (SqlConnec
关于mysql的锁问题导致的问题的当下解决方案
yes_is_ok的博客
09-06 1146
当mysql存在锁冲突的时候： 使用语句一： show [full] processlist; 注：最好使用mysql的root用户查看，才能看到所有进程信息，普通用户只能看到自己的，除非有mysql的root权限 重点看COMMAND和STATE的信息，这两个信息比较重要； 一般来说COMMAND在sleep状态是正常的（TIME字段值再高也正常），且其它的状态的TIME字段值一般不能太高...
MySQL如何使用参数化查询？
最新发布
长风破浪会有时的博客
03-26 396
参数化查询是一种编写数据库查询的方法，它可以帮助我们更安全地获取数据。就像是我们用一个特殊的盒子（参数）来装我们要查询的信息，然后把这个盒子交给数据库去查找。这样，数据库就只知道盒子里的内容，而不知道其他任何可能有害的信息。
mysql性能跟踪_MySQL 性能跟踪语句
weixin_33983238的博客
01-21 134
开启此功能mysql> set profiling=1;Query OK, 0 rows affected (0.00 sec)mysql> show tables;+----------------+| Tables_in_test |+----------------+| bag_item || bag_user || score || t |+----------------+4...
RDS MySQL参数调优最佳实践
weixin_34185560的博客
12-21 228
前言 很多时候，RDS用户经常会问如何调优RDS MySQL的参数，为了回答这个问题，写一篇blog来进行解释： 哪一些参数不能修改，那一些参数可以修改； 这些提供修改的参数是不是已经是最佳设置，如何才能利用好这些参数； 哪些参数可以改 细心的用户在购买RDS的时候都会看到，不同规格能够提供的最大连接数以及内存是不同的，所以这一些产品规格的限制参数：...
mysql查询缓存加锁_MySQL慢查询 – “等待查询缓存锁”
weixin_39992831的博客
01-28 282
我在与运行5.5的服务器相同的机器上的简单表上运行一个简单的查询。从2000万行表中返回约7000行，需要22秒。在分析时大部分时间都被多个“等待查询缓存锁定”占用。什么是“等待查询缓存锁定”，为什么这个查询需要这么长时间？这是我用设置服务器的方式吗？这是配置文件(注意操作的实际时间实际上是如下所示的here)：mysql> show profile for query 4;+-------...
flink-sql-connector-mysql-cdc-2.3.0.jar
07-05
flink同步mysql数据库所用包
sql-concat:MySQL查询生成器
04-29
构建针对库的查询（具体来说，通过期望其而不是MySQL的存储过程参数） 特征 轻松组成查询部分-query-builder对象是不可变的，因此您可以构建基本查询并通过少量修改（例如，使用条件where子句或联接）一次又一次地...
MySQL高级知识-查询与索引优化分析
02-20
手写手写SQL顺序机读顺序总结-SQL解析顺序SQL解析SQLJOINs七种JOIN图解实验：练习1、A、B两表共有2、A、B两表共有+A的独有3、A、B两表共有+B的独有4、A的独有5、B的独有6、AB全有MySQLFullJoin的实现因为MySQL不支持...
MySQL慢查询之pt-query-digest分析慢查询日志
12-16
可以把分析结果输出到文件中，分析过程是先对查询语句的条件进行参数化，然后对参数化以后的查询进行分组统计，统计出各查询的执行时间、次数、占比等，可以借助分析结果找出问题进行优化。 二、安装pt-query-digest...
SQL(参数化)的查询
07-30 5018
什么是参数化查询? 一，定义 参数化查询(Parameterized Query 或 Parameterized Statement)是指在设计与数据库链接并访问数据时，在需要填入数值或数据的地方，使用参数 (Parameter) 来给值，这个方法目前已被视为最有效可
mysql 性能命令_MySQL中使用SHOW PROFILE命令分析性能的用法整理
weixin_39633089的博客
01-19 112
show profile是由Jeremy Cole捐献给MySQL社区版本的。默认的是关闭的，但是会话级别可以开启这个功能。开启它可以让MySQL收集在执行语句的时候所使用的资源。为了统计报表,把profiling设为1mysql> SET profiling = 1;之后在运行一个查询mysql> SELECT COUNT(DISTINCT actor.first_name) AS ...
MySQL在线环境,[MySQL FAQ]系列 — 线上环境到底要不要开启query cache
weixin_29323977的博客
03-23 172
Query Cache(查询缓存，以下简称QC)存储SELECT语句及其产生的数据结果，特别适用于：频繁提交同一个语句，并且该表数据变化不是很频繁的场景，例如一些静态页面，或者页面中的某块不经常发生变化的信息。QC有可能会从InnoDB Buffer Pool或者MyISAM key buffer里读取结果。由于QC需要缓存最新数据结果，因此表数据发生任何变化(INSERT、UPDATE、DELE...
mysql cache lock_mysql服务器上有sql状态status显示 Waiting for query cache lock？
weixin_31885977的博客
02-01 345
【导读】与朋友或同事谈到mysql查询缓存功能的时候，个人喜欢把Query Cache比作荔枝，是非常营养的东西，但是一次性吃太多了，就容易导致上火而流鼻血，虽然不是特别恰当的比喻，但是有很多相似的地方，另外QueryCache有其特殊的业务场景，也不像其他数据库产品，缓存查询语句的执行计划等信息，而是直接缓存查询语句的记录集和对应的SQL语句。本文就给大家介绍下查询缓存的相关知识，希望可以引导大...
SpringBoot个人博客项目搭建—后台博客界面功能介绍（六）
清峰的博客
10-10 2425
后台博客界面功能介绍
SQL Server-聚焦sp_executesql执行动态SQL查询性能真的比exec好？
weixin_33923148的博客
11-22 123
前言 之前我们已经讨论过动态SQL查询呢？这里为何再来探讨一番呢？因为其中还是存在一定问题，如标题所言，很多面试题也好或者有些博客也好都在说在执行动态SQL查询时sp_executesql的性能比exec好，但是事实真是如此？下面我们来一探究竟。 探讨sp_executesql和exec执行动态SQL查询性能 首先我们创建如下测试表。 CREATE...
SQL参数化查询，Where语句中配置“?”
mark_jl的博客
03-28 1292
参数化查询(Parameterized Query 或 Parameterized Statement)是指在设计与数据库链接并访问数据时，在需要填入数值或数据的地方，使用参数 (Parameter) 来给值，这个方法目前已被视为最有效可预防SQL注入攻击 (SQL Injection) 的攻击手法的防御方式。
MYSQL是否支持参数化查询
06-02
是的，MySQL支持参数化查询。使用参数化查询可以有效地防止SQL注入攻击，提高应用程序的安全性。 在MySQL中，可以使用预处理语句来实现参数化查询。使用预处理语句，可以将SQL语句和参数分离开来，从而避免了恶意用户输入一些SQL语句，从而破坏原有的SQL语句执行逻辑的情况。 在PHP中，可以使用PDO扩展或mysqli扩展来实现MySQL的预处理语句。使用PDO预处理语句，可以更加方便地实现MySQL的参数化查询。例如： ``` $stmt = $pdo->prepare('SELECT * FROM users WHERE username = :username'); $stmt->bindParam(':username', $username); $stmt->execute(); ``` 在上面的代码中，使用了PDO的预处理语句和bindParam方法来绑定参数。这里的$pdo是PDO连接对象，$username是从用户输入中获取的参数。bindParam方法将参数值绑定到:username占位符上，并执行查询操作。 因此，MySQL支持参数化查询，可以使用预处理语句来实现。

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Terry_Tsang

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值