MySQL之COUNT(*)性能到底如何?

  • GreatSQL社区原创内容未经授权不得随意使用,转载请联系小编并注明来源。
  • GreatSQL是MySQL的国产分支版本,使用上与MySQL一致。

前言

在实际开发过程中,统计一个表的数据量是经常遇到的需求,用来统计数据库表的行数都会使用COUNT(*)COUNT(1)或者COUNT(字段),但是表中的记录越来越多,使用COUNT(*)也会变得越来越慢,今天我们就来分析一下COUNT(*)的性能到底如何。

1.COUNT(1)、COUNT(*)与COUNT(字段)哪个更快?

执行效果:

  • COUNT(*)MySQL 对count(*)进行了优化,count(*)直接扫描主键索引记录,并不会把全部字段取出来,直接按行累加。
  • COUNT(1)InnoDB引擎遍历整张表,但不取值,server 层对于返回的每一行,放一个数字“1”进去,按行累加。
  • COUNT(字段)如果这个“字段”是定义为NOT NULL,那么InnoDB 引擎会一行行地从记录里面读出这个字段,server 层判断不能为NULL,按行累加;如果这个“字段”定义允许为NULL,那么InnoDB 引擎会一行行地从记录里面读出这个字段,然后把值取出来再判断一下,不是 NULL才累加。

实验分析


  • 本文测试使用的环境:
[root@zhyno1 ~]# cat /etc/system-release
CentOS Linux release 7.9.2009 (Core)

[root@zhyno1 ~]# uname -a
Linux zhyno1 3.10.0-1160.62.1.el7.x86_64 #1 SMP Tue Apr 5 16:57:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
  • 测试数据库采用的是(存储引擎采用InnoDB,其它参数默认):
(Mon Jul 25 09:41:39 2022)[root@GreatSQL][(none)]>select version();
+-----------+
| version() |
+-----------+
| 8.0.25-16 |
+-----------+
1 row in set (0.00 sec)

实验开始:

#首先我们创建一个实验表

CREATE TABLE test_count (
  `id` int(10) NOT NULL AUTO_INCREMENT PRIMARY KEY,
  `name` varchar(20) NOT NULL,
  `salary` int(1) NOT NULL,
  KEY `idx_salary` (`salary`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

#插入1000W条数据
DELIMITER //
CREATE PROCEDURE insert_1000w()
BEGIN
    DECLARE i INT;
    SET i=1;
    WHILE i<=10000000 DO
        INSERT INTO test_count(name,salary) VALUES('KAiTO',1);
        SET i=i+1;
    END WHILE;
END//
DELIMITER ;

#执行存储过程
call insert_1000w();

接下来我们分别来实验一下:

  • COUNT(1)花费了4.19秒
(Sat Jul 23 22:56:04 2022)[root@GreatSQL][test]>select count(1) from test_count;
+----------+
| count(1) |
+----------+
| 10000000 |
+----------+
1 row in set (4.19 sec)
  • COUNT(*)花费了4.16秒
(Sat Jul 23 22:57:41 2022)[root@GreatSQL][test]>select count(*) from test_count;
+----------+
| count(*) |
+----------+
| 10000000 |
+----------+
1 row in set (4.16 sec)
  • COUNT(字段)花费了4.23秒
(Sat Jul 23 22:58:56 2022)[root@GreatSQL][test]>select count(id) from test_count;
+-----------+
| count(id) |
+-----------+
|  10000000 |
+-----------+
1 row in set (4.23 sec)

我们可以再来测试一下执行计划

  • COUNT(*)
(Sat Jul 23 22:59:16 2022)[root@GreatSQL][test]>explain select count(*) from test_count;
+----+-------------+------------+------------+-------+---------------+------------+---------+------+---------+----------+-------------+
| id | select_type | table      | partitions | type  | possible_keys | key        | key_len | ref  | rows    | filtered | Extra       |
+----+-------------+------------+------------+-------+---------------+------------+---------+------+---------+----------+-------------+
|  1 | SIMPLE      | test_count | NULL       | index | NULL          | idx_salary | 4       | NULL | 9980612 |   100.00 | Using index |
+----+-------------+------------+------------+-------+---------------+------------+---------+------+---------+----------+-------------+
1 row in set, 1 warning (0.01 sec)

(Sat Jul 23 22:59:48 2022)[root@GreatSQL][test]>show warnings;
+-------+------+-----------------------------------------------------------------------+
| Level | Code | Message                                                               |
+-------+------+-----------------------------------------------------------------------+
| Note  | 1003 | /* select#1 */ select count(0) AS `count(*)` from `test`.`test_count` |
+-------+------+-----------------------------------------------------------------------+
1 row in set (0.00 sec)
  • COUNT(1)
(Sat Jul 23 23:12:45 2022)[root@GreatSQL][test]>explain select count(1) from test_count;
+----+-------------+------------+------------+-------+---------------+------------+---------+------+---------+----------+-------------+
| id | select_type | table      | partitions | type  | possible_keys | key        | key_len | ref  | rows    | filtered | Extra       |
+----+-------------+------------+------------+-------+---------------+------------+---------+------+---------+----------+-------------+
|  1 | SIMPLE      | test_count | NULL       | index | NULL          | idx_salary | 4       | NULL | 9980612 |   100.00 | Using index |
+----+-------------+------------+------------+-------+---------------+------------+---------+------+---------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

(Sat Jul 23 23:13:02 2022)[root@GreatSQL][test]>show warnings;
+-------+------+-----------------------------------------------------------------------+
| Level | Code | Message                                                               |
+-------+------+-----------------------------------------------------------------------+
| Note  | 1003 | /* select#1 */ select count(1) AS `count(1)` from `test`.`test_count` |
+-------+------+-----------------------------------------------------------------------+
1 row in set (0.00 sec)
  • COUNT(字段)
(Sat Jul 23 23:13:14 2022)[root@GreatSQL][test]>explain select count(id) from test_count;
+----+-------------+------------+------------+-------+---------------+------------+---------+------+---------+----------+-------------+
| id | select_type | table      | partitions | type  | possible_keys | key        | key_len | ref  | rows    | filtered | Extra       |
+----+-------------+------------+------------+-------+---------------+------------+---------+------+---------+----------+-------------+
|  1 | SIMPLE      | test_count | NULL       | index | NULL          | idx_salary | 4       | NULL | 9980612 |   100.00 | Using index |
+----+-------------+------------+------------+-------+---------------+------------+---------+------+---------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

(Sat Jul 23 23:13:29 2022)[root@GreatSQL][test]>show warnings;
+-------+------+-----------------------------------------------------------------------------------------------+
| Level | Code | Message                                                                                       |
+-------+------+-----------------------------------------------------------------------------------------------+
| Note  | 1003 | /* select#1 */ select count(`test`.`test_count`.`id`) AS `count(id)` from `test`.`test_count` |
+-------+------+-----------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

需要注意的是COUNT里如果是非主键字段的话

(Tue Jul 26 14:01:57 2022)[root@GreatSQL][test]>explain select count(name) from test_count where id <100 ;
+----+-------------+------------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
| id | select_type | table      | partitions | type  | possible_keys | key     | key_len | ref  | rows | filtered | Extra       |
+----+-------------+------------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | test_count | NULL       | range | PRIMARY       | PRIMARY | 4       | NULL |   99 |   100.00 | Using where |
+----+-------------+------------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

实验结果

1.从上面的实验我们可以得出,COUNT(*)COUNT(1)是最快的,其次是COUNT(id)

2.count(*)被MySQL查询优化器改写成了count(0),并选择了idx_salary索引。

3.count(1)count(id)都选择了idx_salary索引。

实验结论

总结:COUNT(*)=COUNT(1)>COUNT(id)

MySQL的官方文档也有说过:

InnoDB handles SELECT COUNT(*) and SELECT COUNT(1) operations in the same way. There is no performance difference

翻译: InnoDB以相同的方式处理SELECT COUNT(*)和SELECT COUNT(1)操作。没有性能差异

所以说明了对于COUNT(1)或者是COUNT(*),MySQL的优化其实是完全一样的,没有存在没有性能的差异。

但是建议使用COUNT(*),因为这是MySQL92定义的标准统计行数的语法。

2.COUNT(*)与TABLES_ROWS

在InnoDB中,MySQL数据库每个表占用的空间、表记录的行数可以打开MySQL的information_schema数据库。在该库中有一个TABLES表,这个表主要字段分别是:

  • TABLE_SCHEMA : 数据库名
  • TABLE_NAME:表名
  • ENGINE:所使用的存储引擎
  • TABLES_ROWS:记录数
  • DATA_LENGTH:数据大小
  • INDEX_LENGTH:索引大小

TABLE_ROWS用于显示这个表当前有多少行,这个命令执行挺快的,那这个TABLE_ROWS能代替count(*)吗?

我们用TABLES_ROWS查询一下表记录条数

(Sat Jul 23 23:15:14 2022)[root@GreatSQL][test]>SELECT TABLE_ROWS
    -> FROM INFORMATION_SCHEMA.TABLES
    -> WHERE TABLE_NAME = 'test_count';
+------------+
| TABLE_ROWS |
+------------+
|    9980612 |
+------------+
1 row in set (0.03 sec)

可以看到,记录的条数并不准确,因为InnoDB引擎下TABLES_ROWS行计数仅是大概估计值。

3.COUNT(*)是怎么样执行的?

首先要明确的是,MySQL有多种不同引擎,在不同的引擎中,count(*)有不同的实现方式,本文主要介绍的是在InnoDB引擎上的执行流程

在InnoDB存储引擎中,count(*)函数是先从内存中读取表中的数据到内存缓冲区,然后扫描全表获得行记录数的。简单来说就是全表扫描,一个循环解决问题,循环内: 先读取一行,再决定该行是否计入count循环内是一行一行进行计数处理的。

在MyISAM引擎中是把一个表的总行数存在了磁盘上,因此执行count(*)的时候会直接返回这个数,效率很高。

之所以InnoDB 不跟 MyISAM一样把数字存起来,是因为即使是在同一个时刻的多个查询,由于多版本并发控制(MVCC)的原因,InnoDB表应该返回多少行也是不确定的。而且不论是在事务支持、并发能力还是在数据安全方面,InnoDB都优于MyISAM。

虽然如此,InnoDB对于count(*)操作还是做了优化的。InnoDB是索引组织表,主键索引树的叶子节点是数据,而普通索引树的叶子节点是主键值。所以,普通索引树比主键索引树小很多。对于count(*)这样的操作,遍历哪个索引树得到的结果逻辑上都是一样的。因此,MySQL 优化器会找到最小的那棵树来遍历。

需要注意的是我们在这篇文章里讨论的是没有过滤条件的count(*),如果加了WHERE条件的话,MyISAM引擎的表也是不能返回得这么快的。

4.总结

  • 1.COUNT(*)=COUNT(1)>COUNT(id)

  • 2.COUNT函数的用法,主要用于统计表行数。主要用法有COUNT(*)、COUNT(字段)和COUNT(1)

  • 3.因为COUNT(*)是SQL92定义的标准统计行数的语法,所以MySQL对他进行了很多优化,MyISAM中会直接把表的总行数单独记录下来供COUNT(*)查询,而InnoDB则会在扫表的时候选择最小的索引来降低成本。这些优化的前提是没有进行WHERE和GROUP的条件查询。

  • 4.在InnoDB中COUNT(*)COUNT(1)实现上没有区别,而且效率一样,但是COUNT(字段)需要进行字段的非NULL判断,所以效率会低一些。

  • 5.因为COUNT(*)是SQL92定义的标准统计行数的语法,并且效率高,所以还是建议使用COUNT(*)查询表的行数。

  • 6.正如前面COUNT(name)的用例那样,在建表过程中需要根据业务需求建立性能较高的索引,同时也要注意避免建立不必要的索引。

最后多说一嘴,本文内容可能存在一些用例不够全面,如有不同见解,欢迎后台留言讨论。


Enjoy GreatSQL :)

文章推荐:

面向金融级应用的GreatSQL正式开源 https://mp.weixin.qq.com/s/cI_wPKQJuXItVWpOx_yNTg

Changes in GreatSQL 8.0.25 (2021-8-18) https://mp.weixin.qq.com/s/qcn0lmsMoLtaGO9hbpnhVg

MGR及GreatSQL资源汇总 https://mp.weixin.qq.com/s/qXMct_pOVN5FGoLsXSD0MA

GreatSQL MGR FAQ https://mp.weixin.qq.com/s/J6wkUpGXw3YkyEUJXiZ9xA

在Linux下源码编译安装GreatSQL/MySQL https://mp.weixin.qq.com/s/WZZOWKqSaGSy-mpD2GdNcA

关于 GreatSQL

GreatSQL是由万里数据库维护的MySQL分支,专注于提升MGR可靠性及性能,支持InnoDB并行查询特性,是适用于金融级应用的MySQL分支版本。

Gitee:

https://gitee.com/GreatSQL/GreatSQL

GitHub:

https://github.com/GreatSQL/GreatSQL

Bilibili:

https://space.bilibili.com/1363850082/video

微信&QQ群:

可搜索添加GreatSQL社区助手微信好友,发送验证信息“加群”加入GreatSQL/MGR交流微信群

QQ群:533341697

微信小助手:wanlidbc

本文由博客一文多发平台 OpenWrite 发布!

<think>我们面对的是数据表上的COUNT(*)查询优化问题。根据引用内容,特别是引用[1]和引用[3],我们可以总结出以下优化方法: 1. **存储引擎选择**:MyISAM引擎直接维护行数计数器,因此COUNT(*)非常快。但是,MyISAM不支持事务,且在实际生产环境中,尤其是使用InnoDB作为主存储引擎时,我们可以考虑在从库中使用MyISAM表(如引用[1]所述)来加速COUNT(*)查询。 2. **避免全表扫描**:COUNT(*)在InnoDB中需要扫描表(或者使用二级索引)来计数,因此在表上可能很慢。我们可以通过以下方式优化: - 使用近似值(如引用[1]中提到的从库MyISAM表,或者使用数据库提供的估算机制,如PostgreSQL的reltuples)。 - 添加有效的WHERE条件,并确保该条件上有索引,以减少扫描的数据量(引用[1]中的子查询优化分页查询就是一个例子)。 3. **子查询优化**:引用[1]中展示了一种通过子查询避免深度分页的方法,这种方法也可以用于优化COUNT(*)吗?实际上,COUNT(*)通常不需要分页,但我们可以通过类似思路将查询分解。 4. **使用汇总表**:如果不需要实时精确的计数,可以创建一张汇总表,定期更新总数。 5. **利用二级索引**:InnoDB中,二级索引比主键索引小,因此如果存在二级索引,优化器可能会选择扫描二级索引来计数(因为二级索引的叶子节点包含主键值,但不需要包含所有列,所以体积更小)。 6. **避免使用COUNT(列名)**:引用[3]明确指出,COUNT(列名)与COUNT(*)语义不同,且性能可能更差(因为需要检查列是否为NULL)。因此,要统计行数,一定要用COUNT(*)。 7. **分布式查询优化**:引用[4]提到分布式查询执行计划优化,对于分布式数据库(如OLAP系统),COUNT(*)可以通过并行扫描多个分片并汇总结果来加速。 具体优化策略如下: ### 1. 使用近似值(适用于可接受误差的场景) - 如引用[1]所述,在从库中将表改为MyISAM(但注意主从同步和表结构变更的管理)。 - 使用数据库的元数据估算(如MySQL的`SHOW TABLE STATUS`,但注意该值不精确): ```sql SHOW TABLE STATUS LIKE 'table_name'; ``` 返回结果中的`Rows`字段是估算值。 ### 2. 精确计数优化 - **添加过滤条件并利用索引**:如果查询有条件,确保该条件上有索引,这样COUNT(*)可以只扫描索引而不扫描全表。 例如: ```sql SELECT COUNT(*) FROM orders WHERE order_date > '2024-01-01'; ``` 在`order_date`上建立索引可以加速。 - **使用覆盖索引**:如果表有二级索引,InnoDB会优先选择最小的索引来扫描(因为二级索引通常比主键索引小)。因此,可以创建一个小的二级索引来加速COUNT(*)。但注意,添加索引会带来写入开销。 - **汇总表**:创建一个表,专门记录各个表的行数,并在每次增删时更新该表(通过触发器或应用层逻辑)。例如: ```sql CREATE TABLE table_counts ( table_name VARCHAR(64) PRIMARY KEY, row_count BIGINT ); ``` 然后,查询时直接: ```sql SELECT row_count FROM table_counts WHERE table_name = 'orders'; ``` - **分片计数**:在分布式数据库中,可以将COUNT(*)分解为多个分片上的并行查询,然后汇总结果。 ### 3. 改写查询避免全表扫描 引用[1]中提到的子查询优化方法虽然用于分页,但我们可以借鉴其思路:通过索引快速定位到起始位置,然后读取少量数据。但是,对于COUNT(*)这种需要整个表计数的操作,这种方法不直接适用。不过,如果我们只需要满足某个条件的行数,且该条件有索引,那么查询可以很快。 ### 4. 从库专用于计数查询 如引用[1]建议,在从库上执行COUNT(*)查询,避免影响主库。如果从库允许,可以将其中的表改为MyISAM(但要注意主从复制的一致性,因为主库是InnoDB,从库是MyISAM可能不被支持,需要单独处理)。 ### 5. 避免使用COUNT(列名) 坚持使用COUNT(*)来获得正确的行数,并避免COUNT(列名)可能带来的性能问题(引用[3])。 ### 6. 使用物化视图 部分数据库支持物化视图(如PostgreSQL),可以创建物化视图来存储聚合结果,并定期刷新。 ### 7. 并行查询 在支持并行查询的数据库(如PostgreSQL, Oracle)中,可以启用并行查询来加速COUNT(*)。 ### 示例:汇总表实现 步骤: 1. 创建汇总表: ```sql CREATE TABLE total_orders ( id INT PRIMARY KEY AUTO_INCREMENT, table_name VARCHAR(100) NOT NULL, count BIGINT NOT NULL ); INSERT INTO total_orders (table_name, count) VALUES ('orders', 0); ``` 2. 使用触发器维护(或在应用层维护): ```sql DELIMITER // CREATE TRIGGER after_orders_insert AFTER INSERT ON orders FOR EACH ROW BEGIN UPDATE total_orders SET count = count + 1 WHERE table_name = 'orders'; END;// DELIMITER ; -- 类似地,创建删除和更新(如果软删除)的触发器 ``` 3. 查询时: ```sql SELECT count FROM total_orders WHERE table_name = 'orders'; ``` ### 分布式环境下的优化(引用[4]) 在分布式OLAP系统中,COUNT(*)操作可以分解为多个节点并行执行。例如: ```sql SELECT COUNT(*) FROM large_table; ``` 可以分解为: ```sql -- 在每个分片上执行 SELECT COUNT(*) AS shard_count FROM shard_large_table_N; ``` 然后汇总所有分片的结果。 ### 总结 - **精确计数**:使用汇总表(实时更新)或利用索引(带条件查询)。 - **近似计数**:使用元数据估算(如`SHOW TABLE STATUS`)或从库MyISAM表(引用[1])。 - **分布式/并行计数**:利用分布式系统的并行能力(引用[4])。 - **避免全表扫描**:通过索引和条件减少扫描范围。 最后,注意:COUNT(*)在InnoDB上由于MVCC机制,需要扫描表来得到当前事务可见的行数,因此无法像MyISAM那样直接返回计数器。所以,在InnoDB上优化COUNT(*)的核心是减少扫描量。 ### 相关问题 1. 如何在InnoDB引擎上加速COUNT(*)查询? 2. 什么是汇总表?如何维护汇总表的数据一致性? 3. 在分布式数据库中如何优化COUNT(*)查询? 4. 为什么MyISAM引擎的COUNT(*)比InnoDB快? 5. 如何利用数据库元数据快速获取表行数的近似值?</think>### 优化数据表 `COUNT(*)` 查询性能的深度指南 在数据表上执行 `COUNT(*)` 查询时,性能瓶颈主要源于全表扫描的 I/O 开销和 MVCC 事务隔离机制。以下是经过验证的优化策略(结合引用内容): --- #### **1. 存储引擎优化** [^1][^3] - **MyISAM 计数器机制** 在从库中将表改为 MyISAM 引擎(仅适用于只读场景): ```sql ALTER TABLE large_table ENGINE=MyISAM; -- 从库执行 SELECT COUNT(*) FROM large_table; -- 毫秒级响应 ``` *原理*:MyISAM 直接维护行数计数器,无需扫描数据文件。 - **InnoDB 二级索引优化** 添加精简的二级索引(比主键索引体积小 30-70%): ```sql CREATE INDEX idx_compact ON large_table(lightweight_column); ``` *原理*:InnoDB 优先扫描最小索引(引用[3])。 --- #### **2. 精确计数优化** - **条件过滤 + 索引** 通过 WHERE 子句缩小扫描范围: ```sql -- 添加时间范围索引 CREATE INDEX idx_date ON orders(order_date); SELECT COUNT(*) FROM orders WHERE order_date > '2024-01-01'; -- 索引加速[^2] ``` - **子查询分页优化** [^1] 避免深度分页的全表扫描: ```sql SELECT COUNT(*) FROM ( SELECT id FROM large_table WHERE deleted = 0 ORDER BY id LIMIT 1000000, 1 -- 仅扫描定位点 ) AS tmp; ``` --- #### **3. 近似计数方案** | **方法** | 误差率 | 速度 | 实现方式 | |------------------------|--------|----------|------------------------------| | **元数据估算** | 5-10% | 毫秒级 | `SHOW TABLE STATUS LIKE 'table'` | | **物化视图** | 0% | 毫秒级 | 定期刷新汇总表[^1] | | **Redis 计数器** | 0% | 微秒级 | 应用层维护增量计数 | **物化表示例**: ```sql -- 创建汇总表 CREATE TABLE table_counts ( table_name VARCHAR(100) PRIMARY KEY, count BIGINT ); -- 定时刷新(每天) REPLACE INTO table_counts SELECT 'large_table', COUNT(*) FROM large_table; ``` --- #### **4. 分布式优化** [^4] 在 OLAP 系统(如 ClickHouse/Doris)中: ```sql -- 利用分布式执行引擎 SELECT COUNT(*) FROM distributed_table OPTION( parallel_workers = 32, -- 并行度 data_skip_index = 'min_max' -- 跳数索引 ); ``` *原理*:将查询分解到多节点并行执行,通过跳数索引跳过无关数据块。 --- #### **5. 架构级优化** - **读写分离** 将 `COUNT(*)` 路由到从库执行,避免主库性能抖动。 - **冷热数据分离** 将历史数据归档到压缩存储: ```sql -- 归档一年前数据 CREATE TABLE archive_2023 LIKE large_table; INSERT INTO archive_2023 SELECT * FROM large_table WHERE create_time < '2023-01-01'; ``` --- ### 性能对比 | **优化方案** | 扫描数据量 | 响应时间 | 适用场景 | |----------------------|------------|------------|------------------| | 全表扫描 (InnoDB) | 100% | 分钟级 | 小表 | | 二级索引扫描 | 30-70% | 秒级 | 通用 | | MyISAM 计数器 | 0% | 毫秒级 | 只读从库 | | 分布式并行查询 | 5-20% | 亚秒级 | PB 级数据 | --- ### 总结与推荐 1. **优先尝试** ```sql -- 添加条件 + 索引 SELECT COUNT(*) FROM table WHERE indexed_column = value; ``` 2. **备选方案** - 只读场景:MyISAM 引擎[^1] - 实时要求低:物化视图 - 海量数据:分布式执行[^4] 3. **绝对避免** ```sql SELECT COUNT(column) FROM table; -- 可能漏计 NULL 且更慢[^3] ``` > 📌 **关键结论**:`COUNT(*)` 在 InnoDB 上的性能取决于**扫描数据量小**,而非 `COUNT(1)` 或 `COUNT(*)` 的语法差异(二者性能相同)[^3]。 --- ### 相关问题 1. 如何验证 `COUNT(*)` 查询是否使用了索引覆盖扫描? 2. 在分库分表场景下如何高效实现全局 `COUNT(*)`? 3. MyISAM 的计数器机制在事务处理中有哪些缺陷? 4. 如何利用 Redis 实现高并发场景下的近似计数? 5. 分布式数据库中跳数索引(Skip Index)的工作原理是什么?[^4]
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值