MySQL表分区的理论和实践_wang_quan_li的博客-CSDN博客
MySQL表分区的理论和实践
wang_quan_li
于 2015-01-19 11:15:58 发布
679
收藏
分类专栏：
Mysql
文章标签：
mysql
优化
性能
Mysql
专栏收录该内容
35 篇文章
1 订阅
订阅专栏
当面临大数据存储时，数据库的性能往往成为了瓶颈。 除了增加服务器做主从库之外，数据库自身也有很多需要优化的地方。 在减少查询范围的工作中，很多人采取了分表的方式。 比如建立用户表100个，分别为users_00到users_99。 很多公司都采取了这样做的方法，比如1亿数据，拆到每个表就是100万，查询会快很多。 分表法在物理上看，肯定是多表了，自然会快，但是后期很难扩展，比如要加一个user_100，以前的hash公式就废了 而且对用户不透明，PHP代码啥的要写一壶了。 除了上面那种分发，还有用merge表的，merge表对用户我个人认为这个东西只适合做数据仓库 因为首先它是MyISAM引擎，没有行级锁，其次是字段变更比较麻烦，维护起来比较复（其实我也没用过）。
然后说表分区。首先在物理层，全部是每个区分文件的。这样可以突破IO瓶颈。 这两天测试了以下，不同的分区锁表时不影响其它分区的查询。这样并发瓶颈也可以突破。 而且是InnoDB引擎，行锁很舒服。 最主要的是，除了在information schema库里面需要关注以下以外，代码和数据库维护方面完全不需要了，代码完全透明 不过这次我们所选择的针对于用户账户搜索的字段却不是透明的，我们需要对账户进行hash然后选择分区，这里就需要封装到Model里了 而且分区可以随时改，虽然目前不知道更改效率如何，但也是一条语句就能搞定的事情。
在确保了这些问题之后，确定使用分区来做。 假设我要做一张用户表，首先用垂直切，按照功能切成用户账户表，用户资料表，用户订单表等表。 虽然垂直分区可以使用，但MySQL5.5的版本还不能使用……基于使用稳定版的愿望，我还是使用垂直分表而不是垂直分区。 我的第六感告诉我，垂直分区+水平分区，很有可能带来笛卡尔积的计算复杂度，所以，作为PHPer的我还是用可控性较高的垂直分表来做。
垂直分表+水平分区这个问题确定后。 然后要确定分区算法。 MySQL自带的三种分别为range，list和hash range感觉可以，list就算了，hash听起来比较酷。 range方法需要自己写边缘，对于分区比较少的时候，比较好用，如果分区多的话，便要写好长好长。 所以这里我采用hash的方法
建表语句如下
Create
10
11
CREATE
TABLE
employees (
id
INT
NOT
NULL
fname
VARCHAR
(30),
lname
VARCHAR
(30),
hired
DATE
NOT
NULL
DEFAULT
'1970-01-01'
separated
DATE
NOT
NULL
DEFAULT
'9999-12-31'
job_code
INT
store_id
INT
PARTITION
BY
HASH(store_id)
PARTITIONS 4;
这是官方手册的语句，它的ID并不是主键，和计划有些出入…… 不过，字段比较清晰的，第一个从句里面hash方法的参数是一个表达式，表达式的结果必须是整数，这里面表示以store_id作为参数进行分区、 这个表达式并不是乱写的，官方手册有下面一段话，关于如何提高效率和让每个区容量相近 In other words, the more closely the graph of the column value versus the value of the expression follows a straight line as traced by the equation y=cx where c is some nonzero constant, the better the expression is suited to hashing. This has to do with the fact that the more nonlinear an expression is, the more uneven the distribution of data among the partitions it tends to produce.线性关系的表达式更适合哈希算法，越紧接线性算法，每个分区的数据越平均。 In theory, pruning is also possible for expressions involving more than one column value, but determining which of such expressions are suitable can be quite difficult and time-consuming. For this reason, the use of hashing expressions involving multiple columns is not particularly recommended.表达式不要太复杂，否则效率低。 普通的哈希是取余计算 N = MOD(expr, num). 第二个从句表示分了四个区，默认是1,如果是0则会报错。这里面必须是正整数。 为了方便实践，我们自己建表
Create
10
CREATE
TABLE
IF
NOT
EXISTS `pusers` (
`id`
int
(11)
NOT
NULL
AUTO_INCREMENT,
`fname`
varchar
(64)
NOT
NULL
`lname`
varchar
(64)
NOT
NULL
`signed`
int
(11)
NOT
NULL
PRIMARY
KEY
(`id`, `signed`)
ENGINE=InnoDB
DEFAULT
CHARSET=utf8 AUTO_INCREMENT=1
PARTITION
BY
HASH(signed)
PARTITIONS 10;
我用的加密算法如下，本来ascii直接加的算法全部是70-100还有0-10的结果，优化后是这个样子，差不多保持了每个分区的数据相近
encrypt
10
protected
function
ecrypt(
$str
$str1
=
substr
$str
, 0, 1);
$number
=
abs
(ord(
$str1
) - 97) % 4;
$str2
=
substr
$str
, 1, 1);
$number
=
$number
* 25 + ord(
$str2
) - 97;
$number
=
$number
% 100;
return
$number
用压力测试ab插了100万数据，然后开始测试。 用signed+fname的效率是单纯搜fname的10倍左右（非explain，直接搜）。 不过这个倍率看起来不太美妙，因为名字我们没有加索引。 虽然在很多高级搜索的功能中，我们的确不能加太多索引，但为了测试，我一边插着数据一边加了索引
index
ALTER
TABLE
pusers
ADD
INDEX
fn (fname);
然后我explain里下面两条语句 mysql> explain select * from pusers where fname = 'Vmed'; +----+-------------+--------+------+---------------+------+---------+-------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+--------+------+---------------+------+---------+-------+------+-------------+ | 1 | SIMPLE | pusers | ref | fn | fn | 194 | const | 9 | Using where | +----+-------------+--------+------+---------------+------+---------+-------+------+-------------+
mysql> explain select * from pusers where fname = 'Vmed' and signed = 95; +----+-------------+--------+------+---------------+------+---------+-------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+--------+------+---------------+------+---------+-------+------+-------------+ | 1 | SIMPLE | pusers | ref | fn | fn | 194 | const | 1 | Using where | +----+-------------+--------+------+---------------+------+---------+-------+------+-------------+ 可以看出，虽然都很快，都是用了const的索引……（是我数据量太少了啊），但是一个查寻了9行而另一个只查了一行。 然后是右模糊搜索，同样是索引。我们也只能这么做了，因为下图99的数字就是根据Pw而来的。 mysql> explain select * from pusers where fname LIKE 'Pwy%' and signed=99; +----+-------------+--------+-------+---------------+------+---------+------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+--------+-------+---------------+------+---------+------+------+-------------+ | 1 | SIMPLE | pusers | range | fn | fn | 194 | NULL | 114 | Using where | +----+-------------+--------+-------+---------------+------+---------+------+------+-------------+ 1 row in set (0.01 sec)
mysql> explain select * from pusers where fname LIKE 'Pwy%'; +----+-------------+--------+-------+---------------+------+---------+------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+--------+-------+---------------+------+---------+------+------+-------------+ | 1 | SIMPLE | pusers | range | fn | fn | 194 | NULL | 286 | Using where | +----+-------------+--------+-------+---------------+------+---------+------+------+-------------+ 1 row in set (0.00 sec) 左模糊的测试不用做可大家都懂的，10个分区就是10倍的效率，但是……结果是错误的啊。
我本来想，既然和索引差不多，那就直接用索引好了。 但是，索引本身扔到内存中是非常耗费内存的。 这个表现在有500W的数据，索引已经200多M了。当我们的服务器内存较小，表又很大的时候，分区确实是不错的选择。 mysql> select * from pusers where lname='Eywrodz'; +---------+-------+---------+--------+ | id | fname | lname | signed | +---------+-------+---------+--------+ | 5999926 | Bzb | Eywrodz | 0 | +---------+-------+---------+--------+ 1 row in set (2.62 sec)
mysql> select * from pusers where lname='Eywrodz' and signed=0; +---------+-------+---------+--------+ | id | fname | lname | signed | +---------+-------+---------+--------+ | 5999926 | Bzb | Eywrodz | 0 | +---------+-------+---------+--------+ 1 row in set (0.09 sec)
在分区No0（第1分区）中，有18万数据，没有索引的lname字段来搜索，速度相差30倍
wang_quan_li
关注
关注
点赞
收藏
评论
MySQL表分区的理论和实践
当面临大数据存储时，数据库的性能往往成为了瓶颈。除了增加服务器做主从库之外，数据库自身也有很多需要优化的地方。在减少查询范围的工作中，很多人采取了分表的方式。比如建立用户表100个，分别为users_00到users_99。很多公司都采取了这样做的方法，比如1亿数据，拆到每个表就是100万，查询会快很多。分表法在物理上看，肯定是多表了，自然会快，但是后期很难扩展，比如要加一个u
复制链接
扫一扫
专栏目录
spark的转换算子2
changshupx的博客
09-08
1119
1）coalesce
def coalesce(numPartitions: Int, shuffle: Boolean = false)(implicit ord: Ordering[T] = null): RDD[T]
该函数用于将RDD进行重分区，使用HashPartitioner。
第一个参数为重分区的数目，第二个为是否进行shuffle，默认为false;
作用
缩减分区数，用于大数据集过滤后，提高小数据集的执行效率。
val ListRDD: RDD[Int] = context.makeRDD
mysql表分区
weixin_47684689的博客
11-24
93
记录一下在实际项目中的表分区使用。
参与评论
您还未登录，请先
登录
后发表或查看评论
MySQL高级特性一：分区表
热门推荐
yongqi_wang的博客
01-22
3万+
对用户来说，分区表时一个独立的罗技表，但是底层由多个无力字表组成。实现分区的代码实际上是对一组底层表的句柄对象的封装。对分区表的请求，都会通过句柄对象转化成对存储引擎的接口调用。所以分区对于SQL层来说是一个完全封装底层实现的黑盒子，对应用是透明的，但是从底层的文件系统来看就很容易发现，每一个分区表都有一个使用#分隔明明的表文件。
MySQL实现分区表的方式；对底层表的封装，意味着索引也是按照分...
mysql实践小结,MySQL数据库数据分区实践小结
weixin_33212486的博客
03-18
40
MySQL数据库数据分区实践总结针对项目现有数据库进行数据分区可用的方式及其利弊：1)RANGE方式分区：PARTITION BY RANGE (id)(PARTITION pt1 VALUES LESS THAN (10) COMMENT = 'host "127.0.0.1", port "6001"' ENGINE = SPIDER,PARTITION pt2 VALUES LESS THA...
TiDB 分区表优化实践
TiDBer的博客
09-22
138
原文来源：
https://tidb.net/blog/0279fbc9
...
mysql优化多核心_MySQL优化核心理论与实践
weixin_39630048的博客
02-06
56
背景描述：朋友单位OA系统前不久完成升级大改造，后端用的MySQL存储数据，上线跑了个把月，抱怨电话开始接二连三打来，不是这里打不开，就是那里无响应，有人比喻升级后变成老爷车，越来越慢，问题迫在眉睫，必须马上想对策呀。由于部署采用了规范文档，上线前也做了各种测试，于是乎，在线排查，未果，翻出实施文档，逐条阅读，未果，于是想起曾经一个业务系统，也碰到类似情况，后来通过各种优化得以缓解，遂有下文，《M...
mysql(5)-分区实践
jinjin603的博客
11-09
175
mysql提供了4中分区方案range，list，hash，key。本次只记录操作的过程，在理论方面暂时没有做记录。会在结束的展示完成之后再做详细的分析。1.创建数据库2.创建数据表创建数据表xks_driver，指定id为自增，分区为按照id进行hash分区，分区个数为53.查看表的样式frm：表示表的文件结构
par：表示分区结构
xks_driver做了5个分区，分别是p0p1p2p3p4
mysql消息表_Mycat（4）：消息表mysql数据库分表实践
weixin_32001191的博客
01-29
158
1，业务需求比方一个社交软件，比方像腾讯的qq。能够进行群聊天(gid)，也能够单人聊天。这里面使用到了数据库中间件mycat，和mysql数据表分区。关于mycat分区參考：【 数据库垂直拆分，水平拆分利器，cobar升级版mycat】http://blog.csdn.net/freewebsys/article/details/440463652，详细方案设置分区利用mysql分区，假设mys...
mysql 主键 最佳实践_MySQL 的 20+ 条最佳实践
weixin_29938387的博客
02-17
98
数据库操作是当今 Web 应用程序中的主要瓶颈。 不仅是 DBA(数据库管理员)需要为各种性能问题操心，程序员为做出准确的结构化表，优化查询性能和编写更优代码，也要费尽心思。在本文中，我列出了一些针对程序员的 MySQL 优化技术。在我们开始学习之前，我补充一点：你可以在 Envato Market 上找到大量的 MySQL 脚本和实用程序。1.优化查询的查询缓存大部分MySQL服务器都有查询缓存...
Mysql --分表、分库、分区（横向纵向、分区列）的区别与详解
S_ZaiJiangHu的博客
07-20
606
mysql数据库中的数据是以文件的形式存储在磁盘介质上，具体存储目录，请查阅“my.cnf”中的“datadir”属性。一张数据表主要对应着三个文件，一个是FRM存放表结构的，一个是MYD存放表数据的，一个是MYI存表索引的。如果一张表的数据量太大的话，那么MYD、MYI就会变的很大，查找数据就会变得很慢，这个时候可以利用mysql的分区功能，在物理上将这一张表对应的三个文件，分割成许多个小块，这样做的话，我们查找一条数据时，就不用全部查找了，只要知道这条数据在哪一块，然后在那一块找就行了。如果表的数据太大
mysql 复制表语句_mysql - 复制表
weixin_35949256的博客
01-19
497
理论：如果我们需要完全的复制MySQL的数据表，包括表的结构，索引，默认值等。 如果仅仅使用create table ... select 命令，是无法实现的。本章节将为大家介绍如何完整的复制MySQL数据表，步骤如下：1、使用 show create table 命令获取创建数据表(create table) 语句，该语句包含了原数据表的结构，索引等。2、复制以下命令显示的SQL语句，修改数据表...
mysql数据库分区优化
rptina的专栏
05-04
547
分区就是按一定的规则将偌大的一张mysql数据表切割成若干个表分区，物理上以文件形式分开存储，但是逻辑上是一张完成的表，对代码层也是透明的，理论上无需修改任何代码就能“完美”优化，但其实也存在一些隐藏的陷阱。分区无法解决数据库并发连接的性能问题，数据表分区也有它的瓶颈，数据庞大到一定量级的时候，还是需要做分表分库处理。
分区表按照类型可以分为范围分区(Range)、列表分区(List)以及哈希分...
MySQL高级特性——分区表
小羽毛的博客
03-06
434
MySQL从5.0和5.1版本开始引入了很多高级特性，如分区、触发器等。下面学习MySQL的分区表（本人所使用的MySQL版本是5.7）。
1 概述
对用户来说，分区表是一个独立的逻辑表，但底层是由多个物理子表组成 。实现分区的代码实际上是对一组底层表的句柄对象（Handler Object）的封闭。对分区表的请求，都会通过句柄对象转化成存储引擎的接口调用...
linux 分区理论,Linux中磁盘分区——理论篇
weixin_42303285的博客
05-08
116
Linux中磁盘分区——理论篇现在主流的分区的方式有两种——MBR分区和GPT分区，本文将着重介绍MBR分区底层原理，及用相关命令验证相关原理为什么要对磁盘进行分区优化I/O性能隔离系统和应用程序实现磁盘空间的配额限制同一磁盘可采用不同的文件系统同一磁盘上可以安装多个操作系统//当然，分区也会有若干缺点，这里忽略不计MBR分区MBR：Master Boot Record, MBR磁盘分区是一种使用...
mysql5.7修改表结构是否会锁表,MySQL修改表结构导致的表元数据锁(table metadata lock)...
weixin_39738115的博客
03-23
601
MySQL修改表结构导致的表元数据锁(table metadata lock)2018-04-25 17:37:12 阿炯只要有一个语句被堵住(Waiting for table metadata lock)就会导致后面的一系列查询(包括读)全部被堵。为什么需要Metadata lockMetadata lock介绍：参考官方手册：http://dev.mysql.com/doc/refman/5...
《MySQL性能优化和高可用架构实践》阅读总结
wang_luwei的博客
09-19
895
文章目录介绍第1章 MySQL架构介绍1.1 MySQL简介1.2 MySQL主流的分支版本1.3 MySQL存储引擎1.4 MySQL逻辑架构1.5 MySQL物理文件体系结构第2章 InnoDB存储引擎体系结构2.1 缓冲池2.2 change buffer2.3 自适应哈希索引2.4 redo log buffer2.5 double write2.6 InnoDB后台线程2.6.1 InnoDB主线程2.6.2 InnoDB后台I/O线程2.6.3 InnoDB脏页刷新线程2.6.4 InnoDB
mysql性能调优最佳实践_MySQL性能优化的21个最佳实践
weixin_29522547的博客
02-08
86
今天，数据库的操作越来越成为整个应用的性能瓶颈了，这点对于Web应用尤其明显。关于数据库的性能，这并不只是DBA才需要担心的事，而这更是我们程序员需要去关注的事情。当我们去设计数据库表结构，对操作数据库时(尤其是查表时的SQL语句)，我们都需要注意数据操作的性能。这里，我们不会讲过多的SQL语句的优化，而只是针对MySQL这一Web应用最多的数据库。希望下面的这些优化技巧对你有用。1. 为查询缓存...
mysql 运维 最佳实践_【MySQL性能优化的21个最佳实践】
weixin_34469962的博客
01-28
71
#运维#http://www.antvision.cn/今天，数据库的操作越来越成为整个应用的性能瓶颈了，这点对于Web应用尤其明显。关于数据库的性能，这并不只是DBA才需要担心的事，而这更是我们程序员需要去关注的事情。当我们去设计数据库表结构，对操作数据库时(尤其是查表时的SQL语句)，我们都需要注意数据操作的性能。这里，我们不会讲过多的SQL语句的优化，而只是针对MySQL这一Web应用最...
MySQL 55题及答案【八】
最新发布
zf888999666的博客
12-20
497
9.mysql 中 varchar 与 char 的区别以及 varchar(50)中的 50 代表的涵。3. int（20）中 20 的涵义: int(M)中的 M indicates the maximum。1. varchar 与 char 的区别: char 是一种固定长度的类型，varchar 则是。myisam 表时，select，update，delete，insert 语句都会给表自动。Mysql 内建的复制功能是构建大型，高性能应用程序的基础。3. 从服务器重做中继日志中的时间，
Linux 下安装多个mysql
wyhhahaha的博客
12-19
346
Linux 下安装多个mysql
“相关推荐”对你有帮助么？
非常没帮助
没帮助
一般
有帮助
非常有帮助
提交
©️2022 CSDN
皮肤主题：大白
设计师：CSDN官方博客
返回首页
wang_quan_li
CSDN认证博客专家
CSDN认证企业博客
码龄17年
暂无认证
213
原创
7万+
周排名
184万+
总排名
109万+
访问
等级
1万+
积分
147
粉丝
85
获赞
69
评论
225
收藏
私信
关注
热门文章
微信支付问题，支付成功后跳转到指定页面
43489
应用程序无法正常启动 0xc000007b （包括win7 64位）的解决方法
15662
jenkins pipeline参数化构建
14566
postgresql insert 出现duplicate key value violates unique constraint错误
14143
ueditor编辑文章时候，复制粘贴内容，原来的图片不能显示
13897
分类专栏
datax
1篇
canal
1篇
kkFileView
1篇
java
1篇
科研论文
15篇
课程设计
1篇
thinkphp
30篇
Web信息抽取
7篇
Mysql
35篇
Hadoop
4篇
云计算
1篇
Openstack
大数据
4篇
DevOps
3篇
php
116篇
javascript
1篇
Apache
7篇
MOOC
1篇
AppCan
1篇
PhoneGap
腾讯风铃无线建站
3篇
深度学习
phpQuery
1篇
百度siteapp
搜狐快站
2篇
zend studio
8篇
微信
79篇
dedecms
8篇
系统安装
15篇
微信云
1篇
系统分析师
zTree
1篇
yyuc
1篇
ueditor
4篇
Zend Framework
96篇
python
2篇
移动中间件
1篇
微社区
1篇
discuz
11篇
postgresql
8篇
框架
8篇
Phalcon
百度直达号
支付宝服务窗
loadrunner
1篇
日志分析
2篇
webbench
redis
7篇
代码诊断
3篇
HTML5
APIgility
1篇
Node.js
1篇
api
7篇
git
12篇
github
1篇
laravel
2篇
架构
45篇
产品经理
2篇
nginx
27篇
OAuth
4篇
运维
136篇
sphinx
1篇
rest
3篇
性能优化
19篇
持续集成
23篇
sql server
1篇
ubuntu
2篇
piwik
4篇
阿里云
3篇
jenkins
17篇
Memcache
1篇
设计模式
1篇
logstash
9篇
ElasticSearch
12篇
kibana
5篇
测试
微服务
2篇
云服务总线
paas
研发管理
2篇
区块链
AI
2篇
最新评论
Mac上安装hive出现错误HiveSchemaTool:Parsing failed. Reason: Missing required option
落羽爱吃鱼:
我的前面要加个空格才有用
apache atlas2.1.0导入hive元数据import-hive.sh命令错误解决
G3-平头哥:
https://jiezhi.github.io/2020/08/18/atlas2-hive-hook-error/
canal.adapter启动报错Could not resolve placeholder ‘HOSTNAME%%.*‘
路过蜻蜓1209:
具体怎么做呢
canal.adapter启动报错Could not resolve placeholder ‘HOSTNAME%%.*‘
路过蜻蜓1209:
具体怎么做呢
微信支付问题，支付成功后跳转到指定页面
m0_73219100:
怎么联系你
您愿意向朋友推荐“博客详情页”吗？
强烈不推荐
不推荐
一般般
推荐
强烈推荐
提交
最新文章
DataX-web运行时报错：jdbc4.MySQLNonTransientConnectionException:Could not create database server
mysql出现ERROR : (2006, ‘MySQL server has gone away‘) 的问题意思就是指client和MySQL server之间的链接断开了
centos7 elasticsearch6.8.3启动提示bound or publishing to a non-loopback address, enforcing bootstrap che
2021年20篇
2018年5篇
2017年15篇
2016年144篇
2015年96篇
2014年397篇
2011年4篇
2009年13篇
目录
目录
分类专栏
datax
1篇
canal
1篇
kkFileView
1篇
java
1篇
科研论文
15篇
课程设计
1篇
thinkphp
30篇
Web信息抽取
7篇
Mysql
35篇
Hadoop
4篇
云计算
1篇
Openstack
大数据
4篇
DevOps
3篇
php
116篇
javascript
1篇
Apache
7篇
MOOC
1篇
AppCan
1篇
PhoneGap
腾讯风铃无线建站
3篇
深度学习
phpQuery
1篇
百度siteapp
搜狐快站
2篇
zend studio
8篇
微信
79篇
dedecms
8篇
系统安装
15篇
微信云
1篇
系统分析师
zTree
1篇
yyuc
1篇
ueditor
4篇
Zend Framework
96篇
python
2篇
移动中间件
1篇
微社区
1篇
discuz
11篇
postgresql
8篇
框架
8篇
Phalcon
百度直达号
支付宝服务窗
loadrunner
1篇
日志分析
2篇
webbench
redis
7篇
代码诊断
3篇
HTML5
APIgility
1篇
Node.js
1篇
api
7篇
git
12篇
github
1篇
laravel
2篇
架构
45篇
产品经理
2篇
nginx
27篇
OAuth
4篇
运维
136篇
sphinx
1篇
rest
3篇
性能优化
19篇
持续集成
23篇
sql server
1篇
ubuntu
2篇
piwik
4篇
阿里云
3篇
jenkins
17篇
Memcache
1篇
设计模式
1篇
logstash
9篇
ElasticSearch
12篇
kibana
5篇
测试
微服务
2篇
云服务总线
paas
研发管理
2篇
区块链
AI
2篇
目录
评论
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
查看更多评论
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额
抵扣说明：
1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。 2.余额无法直接购买下载，可以购买VIP、C币套餐、付费专栏及课程。
余额充值