站长圈旗下网站:
您当前的位置:
> MySQL数据库——表的约束
MySQL数据库——表的约束
创建数据表指的是在已存在的数据库是建立新表。创建数据表的过程是规定数据列的属性的过程，同时也是实施数据完整性（包括实体完整性、引用完整性和域完整性等）约束的过程……
1、创建表的语法形式
数据表属于数据库，在创建数据表之前，要选择一个数据库（在MySQL控制台应该使用&USE&数据库名&&语句指定是在哪个数据库中创建），如果没有选择数据库，会抛出&No database selected&的错误。
创建数据表的语句为CREATE TABLE，语法格式如下：
CREATE TABLE &表名&
&&&&& 字段名1 数据类型［列级别约束条件］［默认值］,
&&&&& 字段名2 数据类型［列级别约束条件］［默认值］,
&&&&& ［表级别约束条件］
使用CREATE TABLE创建表时，必须指定以下信息：
1）要创建的表的名称，不区分大小写，不能使用SQL语言中的关键字。
2）数据表中的每一个列（字段）的名称和数据类型，如果创建多个列，要用逗号隔开。
例：创建员工表tb_emp1
首先选择数据库，在phpMyAdmin中直接选择test数据库即可。
在MySQL控制台中输入语句
接下来创建tb_emp1表，输入语句为：
执行后即为创建了一个名为tb_tmp1的数据表。
2、使用主键约束
&&&&& 主键是表中一列或多列的组合。主键约束要求主键列的数据唯一，并且不允许为空。主键能够惟一地标识表中的一条记录，可以结合外键来定义不同数据表之间的关系，并且可以加快数据库查询的速度。主键与记录之间是一一对应的关系。主键分为两种类型：单字段主键和多字段主键。
&&&&& 1）单字段主键
&&&&& 主键由一个字段组成，SQL语句格式有两种：
&&&&& a)在定义列的同时指定主键，语法格式如下：
&&&&&&&&&&& 字段名 数据类型 PRIMARY KEY［默认值］
&&&&& 例：定义数据表tb_emp 2，其主键为id：
&&&&& b)定义完所有列之后指定主键，语法格式如下
&&&&&&&&&&& ［CONSTRAINT &约束名&］PRIMARY KEY(&字段名&)
&&&&& 例：定义数据表tb_emp 3，其主键为id：
&&&&& 2）多字段联合主键
&&&&& 多字段联合主键是由多个字段联合组成，语法格式如下：
&&&&&&&&&&& PRIMARY KEY［字段1,字段2,&&,字段n］
&&&&& 例：定义数据表tb_emp4，假设表中没有主键id，为了唯一确定一个员工，可以把name、deptId联合起来做主键，SQL语句为：
3、使用外键约束
外键用来在两个表的数据之间建立链接，它可以是一列或者多列。一个表可以有一个或多个外键。外键对应的是参照完整性，一个表的外键可以是空值，若不为空值，则每一个外键值必须等于另一个表中主键的某个值。
外键：首先是表中的一个字段，它可以不是本表的主键，但对应另外一个表的主键。外键的作用是保证数据引用的完整性，定义外键后，不允许删除在另一个表中具有关联关系的行。
主表（父表）：对于两个具有关联关系的表而言，相关联字段中主键所在的那个表即是主表（父表）。
从表（子表）：对于两个具有关联关系的表而言，相关联字段中外键所在的那个表即是从表（子表）。
创建外键的语法格式如下：
［CONSTRAINT &外键名&］PRIMARY& KEY(&字段名１& [,&字段名2&&&] ) REFERENCES &主表名& (&主键列1[,主键列2,&&]&)
&外键名&这定义的外键约束的名称，一个表中不能有相同名称的外键；&字段名&表示子表需要添加外键约束的字段列；&主表名&即被子表外键所依赖的表的名称；&主键列&表示主表中定义的主键列，或者列组合。
例：定义数据表tb_emp5，并在tb_emp5表上创建外键约束
先创建一个部门表tb_dept1：
定义数据表tb_emp5，让它的deptId作为外键关联到tb_dept1的主键，输入SQL语句如下：
在MySQL控制台使用SHOW CREATE TABLE tb_emp5\G;查看表结构：
创建外键成功。
4、使用非空约束
&&&&& 非空约束（Not Null Constraint）指字段的值不能为空。对于使用了非空约束的字段，如果用户在添加数据时没有指定值，数据库系统会报错。
&&&&& 非空约束的语法格式如下：
&&&&& 字段名 数据类型 not null
&&&&& 例：定义数据表tb_emp6，指定员工的名称不能为空，SQL语句如下：
&&&&& 执行后，在数据表tb_emp6中创建了一个name字段，其插入值不能为空（not null）。
5、使用唯一性约束
唯一性约束（Unique Constraint）要求该列唯一，允许为空，但只能出现一个空值。唯一约束可以确保一列或者几列不出现重复值。
&&&&& 非空约束的语法格式如下：
&&&&& 1）在定义完列之后直接指定唯一约束，语法格式如下：
&&&&&&&&&&& 字段名 数据类型 UNIQUE
&&&&& 例：定义数据表tb_dept2，指定部门的名称唯一，SQL语句如下：
&&&&& 2）在定义完所有列之后指定唯一约束，语法格式如下：
&&&&&&&&&&& ［CONSTRAINT &约束名&］UNIQUE(&字段名&)
&&&&& 例：定义数据表tb_dept4，指定部门的名称唯一，SQL语句为：
&&&&& UNIQUE和PRIMARY KEY的区别：一个表中可以有多个字段声明为UNIQUE，但只能有一个PRIMARY KEY声明；声明为PRIMARY KEY的列不允许有空值，而声明为UNIQUE的字段允许有一个空值（NULL）的存在。
6、使用默认约束
&&&&& 默认约束（Default Constraint）指定某列的默认值。
&&&&& 默认约束的语法格式如下：
&&&&&&&&&&& 字段名 数据类型 DEFAULT 默认值
&&&&& 例：定义数据表tb_emp7，指定员工的部门编号默认为1111，SQL语句为：
执行后，表tb_emp7的deptId字段拥有了一个默认的值1111，新插入的记录如果没有指定部门编号，则默认都为1111。
7、设置表的属性值自动增加
&&&&& 在数据库应用中，经常希望在每次插入新记录时，系统自动生成字段的主键值。可以通过为表主键添加AUTO_INCREMENT关键字来实现。在MySQL中AUTO_INCREMENT的默认初始值是1，每新增一条记录，字段值自动加1.一个表只能有一个字段使用AUTO_INCREMENT约束，且该字段必须为主键的一部分。AUTO_INCREMENT约束的字段可以是任何整数类型（TINYINT、SMALLINT、INT、BIGINT等）。
&&&&& 语法格式如下：
&&&&&&&&&&& 字段名 数据类型 AUTO_INCREMENT
&&&&& 例：定义数据表tb_emp8，指定员工的编号自动递增，SQL语句为：
&&&&& 执行后，表tb_emp8中的id字段的值在添加记录时会自动增加，默认的id值从1开始，每添加一条记录该值自动加1。
&&&&& 例：向表tb_emp8插入记录：
执行后，查看表tb_emp8，增加了3条记录：
站长圈推荐
网站建设知识在数据库设计时，主要就是对实体和关系的设计，实体表现出来就是表，关系表现出来就是外键。而对于一个表，由两部分组成：主键和属性。主键的简单定义就是表中为每一行数据的唯一标识。其实更准确的说法，每一行数据的唯一标识是候选键（Candidate Key），一个表中可以有很多个候选键，主键是候选键中的一个，主要用于更方便的检索和管理数据。一个表中可以有多个候选键，但是只有一个主键。由于主键常常用于检索数据，也用于表之间的关联，所以主键的设计的好坏将会严重影响数据操作的性能。下面来介绍下主键设计的几个考虑因素。
主键的数据类型
最常见的主键数据类型是数字类型、固定长度的字符类型和GUID类型。通常情况下，RDBMS会在主键上建立聚集索引（SQL Server默认都这么做），由于我们使用B-Tree的数据结构来存储索引数据，所以一般对主键有以下两个要求：
越短越好&&越短在一个Page中存储的节点越多，检索速度就越快。
顺序增长&&如果每一条插入的数据的主键都比前面的主键大，那么B-Tree上的节点也是顺序增长的，不会造成频繁的B-Tree分割。
越短越好是为了查询的速度快，顺序增长是为了插入速度快。
有了这两个要求，我们再来分析下各个数据类型：
数字类型：根据数据量决定是用Int16还是Int32或者Int64，能用Int32的就不需要使用Int64。
字符类型：基本不满足前面提到的2点要求，字符类型一般不会很短，而且也很可能不是顺序增长的，所以不是特别推荐的主键类型。当然如果确实业务需求使用字符类型，那么也尽量使用char(XX)而不要使用varchar(XX)，因为在RDBMS中，对于定长字符串和变成字符串的数据结构和处理是不一样的，varchar的性能更差。
GUID类型：这个类型并不是所有数据库都有对应的数据类型，SQL Server有uniqueidentifier，MySQL没有。GUID类型在SQL Server中是16个字节，不算短，比4个字节的Int32长多了。在插入新数据时，GUID一般都是使用NewId()这样的生成随机GUID的方式生成的，所以也不是顺序增长的，在插入速度上不会很快。
通过上面的比较，我们知道使用数字类型是更好的方式，那么我们为什么还会有人使用GUID和字符串来当主键呢？那是因为：
相对于数字类型，字符类型更易读易记，在检索关联的数据时，更方便直接。
GUID的优势是全球唯一，也就是说同样的系统，如果部署了多套环境，那么里面的数据的主键仍然是唯一的，这样有助于数据的集成。典型的例子就是一个系统在全国每个省份都部署一套，每个省份的数据各种录入，互不干扰，然后再把每个省的数据集成起来为总部做分析。
数据库主键与业务主键
前面说到一个表可能有很多个唯一标识的候选键，那么这么多候选键中，哪个应该拿来做主键呢？一种方案是再新建一个独立的字段作为主键，该字段并没有业务含义，只是一个自增列或者流水号，用于唯一标识每一行数据，这是数据库主键。另外一种方案是选择其中较短较常用的属性作为主键，这是业务主键。个人建议是不要使用任何有业务含义的字段作主键，而是使用一个自增的（或者系统生成的）没有实际业务意义的字段作为主键。为什么呢？主要是出于以下考虑：
具有业务意义的字段很可能是用户从系统录入的，不要信任用户的任何输入，只要是用户自己录入的，那么就很有可能录错了，如果发现录入错误，这个时候再对主键进行修改，将会涉及到大量关联的外键表的修改，是很麻烦的一件事情。比如在做人员表的时候，就不要使用员工号或者身份证号做主键。
具有业务意义的字段虽然在当前阶段是唯一的，是不变的，但是并不能保证随着公司政策变动、业务调整等原因，导致该业务字段需要修改，以满足新的业务要求，这个时候要修改主键也是很麻烦的事情。比如部门表，我们以部门Code作为主键，但是后来部门变动，Code修改，则系统部门表的主键也得更改。
还有一个原因是业务主键在数据录入的时候不一定是明确知道的，有时我们会在不知道业务主键的情况下，就录入其他相关信息，这个时候，如果使用业务主键做数据库的主键，那么数据将无法录入。比如员工表把员工号作为主键，那么员工还没有入职，没有员工号的时候，HR需要先维护一些该预入职员工的信息是不可能的。
联合主键就是以多个字段来唯一标识每一行数据。前面已经说到主键应该越短越好，而且是建议是一个没有意义的自增列，那么是不是就不会再需要联合主键呢？答案是否定的，我们仍然可能会使用到联合主键。联合主键主要使用在多对多的关系时，中间表就需要使用联合主键。在简单的多对多关系中，我们不需要为中间的关联建立实体，所以中间表可能就只需要两列，分别是两个实体表的主键。
主键值的生成
主键值的生成可以参考NHibernate的配置，概况下来主要有这么几种生成方式：
自增，这是SQL Server常用的主键生成方式，完全由数据库管理主键的值。
Sequence对象，这是Oracle常用的主键生成方式，现在SQL Server已支持。主要是在数据库中有一个Sequence对象，通过该对象生成主键。
GUID，这是用于GUID类型的主键，可以使用newid()这种数据库提供的函数，或者使用程序生成Guid并赋值。
Hilo值，这是一种使用高低位算法生成的数字值的主键。该值由NHibernate程序内部生成。
其他程序赋值，完全由程序根据自己的算法生成并赋值。
更详细的主键生成，我们可以参见：
主键与索引
在概念和作用上，主键与索引是完全两个不同的东西，但是由于我们大部分情况下都是使用主键检索数据，所以大部分数据库的默认实现，在建立主键时会自动建立对应的索引。
以SQL Server为例，默认情况下，建立主键的列，就会建立聚集索引，但是实际上，我们可以在建立主键时不使用聚集索引。另外还有一个唯一约束（索引）的概念，该索引中的数据必须是唯一不能重复的，感觉和主键的意义一样，但是还是有一点点区别。
主键是只能由一个，而唯一约束（索引）在一个表中可以有多个。
主键不能为空，而唯一约束（索引）是可以为空的。
阅读(...) 评论()在 MySQL 中，从 10 万条主键不连续的数据里随机取 3000 条，如何做到高效？
几百万记录的表，每天大概有10万条记录发生更新，从这10万条里随机取3000条做数据分析，select id from table where date_refresh =
order by rand() limit 0,3000
狂慢！！！大概三四十秒吧
按投票排序
你 sort 那几百万行的表干啥……SELECT id FROM table WHERE date_refresh =
取出当日更新的10万 id （你给 date_refresh 建了索引对吧？），放内存里面随机 shuffle 一下，顶多占用几 MB 内存，取前 3000 个，然后 SELECT * FROM table WHERE id IN (id_0, id_1, id_2, ..., id_2999)
这个问题有点意思。按照我的理解，“从10万条数据里随机取3000条用于数据分析”这个需求，关键是取样的均匀性。也就是说，不能简单地连续取3000条数据，而是要让取样尽量覆盖整个数据区间。但是对于均匀性来说，随机取样并不是必要的，或者更严格地说，随机取样其实不能完全满足均匀性的要求，因为在极端情况下，随机取样仍然可能集中在区间的某一部分。简单的均匀取样的方式就是从区间m中均匀地取n个样本，也就是每m/n条记录取一条。但是，更重要的问题是ID是不连续的。也就是说，无法简单地通过n/m的步长来事先计算id以取得数据。也就是说，这个问题归结为“在倾斜数据集中进行均匀取样”的算法。在这种情况下，最直观的方法是使用临时表先将ID变成连续的。楼上Rio提出的算法：取出当日更新的10万 id放入一个数组在数组中随机取出3000个id用select in读取指定的3000条记录就是“通过临时表先将ID变成连续”的解决方式。另外几位提出了进一步的优化，即在每次更新原表时，就将ID先存入一个临时表或数组里，避免了在读取数据时再创建临时表,但算法本质上是一样的。这个算法最大的开销是要建立一个临时表。假设当日更新有记录有m条，需要随时选取n条，那么成本包括：读取原表中所有当日更新的id O(m)把所有这些id写入临时表
O(m)在临时表中随机选取n个id O(n)在原表中读取n条记录
O(n)一共是O(m)*2 + O(n)*2，其中最大的成本是两个O(m)。一般来说，取样数量n比较小，但是区间m可能会非常大。如果m不是10万条，而是10亿条甚至更多呢？O(m)*2就会大得让人吃不消了。有没有办法只对m读取一次呢？有。如果我们知道m和n，就可以在遍历m的时候，直接按照n/m的步长取值。实现如下：创建一个store procedure。首先通过select count(*)取得所有当日更新记录的数量（m，假设为10万）。已知n为3000，所以步长为0=33。在select where date_refresh = 上打开一个cursor，往下fetch，每33条记录中返回一条。比较郁闷的是，mysql的cursor不支持跳过记录，所以必须逐行fetch。当cursor结束时，取样即完成。这里有一个小变化。如果你实在不满意每隔m/n条取一条的方式，坚持要随机取样，那么可以在每个m/n条记录的区间进行随机取样，也就是说，每次返回记录时，按rand()*33决定返回的记录。随机函数的调用次数为n次而不是m次，所以是可以接受的。但是且慢。当通过select count(*)取得所有当日更新记录的数量，仍然需要扫描所有当日更新的id。当然，由于它不需要返回m个id，而只返回一个数字，运行速度肯定比select id要快得多。但是算法复杂度仍然为O(m)。一个优化方法是，设置一个内存计数器，在每次更新原表记录时，将计数器加1，最终可以得到所有当日更新记录的数量。这看起来，跟“更新原表时将ID先存入一个临时表或数组里”的方法差不多，实际性能差别极大。因为对整数进行单调递增，是一个CPU原子操作。既不需要建立临时表，也不需要建立数组，更不用处理锁和并行的问题，简单地执行一条CPU指令就可以了。到这里，可以看出新算法在性能上提高了很多，但是看来我们还是没有完全避免O(m)*2。有没有办法达到O(m)？有没有办法在事先不知道m的情况下进行取样？甚至进一步，连O(m)都避免，只是简单地读取n条记录，完全无视没有落在取样范围以外的其它记录？回答是有。这要用到一种特殊的可变步长采样算法，而且可能无法用sql实现，需要hack mysql的内核。如果有机会我会贴一篇文章，暂时就不多说了。
因为你用了rand()，遍历每条记录都要运算一次rand()，当然慢了我以前翻译过一篇国外mysql牛人写的关于随机排序的文章，仅供参考 主要的思路是，如果id是连续分布，那直接根据max(id)进行获得随机id，然后直接取出如果id不连续，存在空挡，那么可以总是选择比随机出的id大（或小）的记录如果id不连续，且必须尽可能平均地获取记录，那么需要额外做一个表，将不连续的id映射成连续id，然后进行随机
需要看你所需3000条数据的分布，密度有没有强要求。从方案来说，不要把随机种子的压力放在DB上是根本，数据存储基本都是b+tree，随机是效率很低的行为。如果知道id的范围和分布，完全可以用程序随机出3000个id，分别获取，当然要注意尽量用fetch，否则3000次的单独抓取效率也是很低的。如果不知道id分布，可以把块数据集取到本机的内存中（某字段排序加limit），再用动态语言去随机取数据。但是这样的问题要注意内存的开销，一次取多少块数据可以满足你的分布需求，筛选粒度的均匀程度，都会决定最终的性能。
1.- SELECT MIN(id) AS minid from table where date_refresh = ;2.- SELECT id FROM pages WHERE (RAND()*100000)+3.- SELECT * FROM table WHERE id IN(id1,id2....id3000);我觉的你的ID 如果是连续的你可以用上面方法不明白你的记录为什么不是连续的给每条记录一个autoincrement的编号不可以吗？如果不是连续的那就只能用上面提到的办法读出所有的10万条记录到个文件里，或者一个新的表里再按序处理================================================更新一下那我试着用python处理一下Python 不是很会，边学边写的拿小表格测试了，应该能运行1.从表中读取出当天发生更新的10万条数据放到个list里2.利用python的 random.shuffle()打乱这个list数据的顺序3.读出前3000个数据然后你就可以处理这3000个数据，或者查找这3000个ID对应的表的内容了================================================#!/usr/bin/pythonimport MySQLdbimport randomconn = MySQLdb.connect (host = "localhost",
user = "user",
passwd = "pwd",
db = "test")cursor = conn.cursor ()data =[]#读取数据库里的当天发生更新的主键cursor.execute("SELECT id FROM table where date_refresh = ")resList = cursor.fetchall()#某种list的准换，我也不太明白，说是列表表列的区别（1L，2L，3L....）=&[1,2,3]data = [int(e[0])for e in resList]#随机打乱顺序,我测试10 000个数据还是挺快的random.shuffle(data)# 取前3000个data = data[:3000]print datacursor.close ()conn.close ()
经本人精心研究及仔细测试，楼上除了加cache以外似乎没有最优解，于是来一段我最常用的：前言：要随机筛选不连续的ID，用 &= 或者 &= 是必然的 hack 手段。1、首先，请来一段 Random = 0-1 的随机。例如：&?php
$rand = random(1, 100) / 100;
表的数据越大，小数点需要留的越多。2、于是，再建立以下的查询&?php
$sql = 'SELECT * FROM `table` WHERE id &= (SELECT FLOOR( MAX(id) * '.$rand.') FROM `table` ) ORDER BY id LIMIT 1;';
再试试你平常用的手法呵呵。当然，这个还是得扫表（范围：RAND - MAXID），对于有极限要求的人来说还是不够滴。本回答只是提供一种思路。。。。
LZ的问题：在MySQL中，从10万条主键不连续的数据里随机取3000条，如何做到高效？修改 几百万记录的表，每天大概有10万条记录发生更新，从这10万条里随机取3000条做数据分析，select id
from table where date_refresh =
order by rand() limit
0,3000，狂慢！！！大概三四十秒吧回答：1.select id
from table where date_refresh =
order by rand() limit
0,3000;是非常不明智的做法，因为RAND()函数的随机因子变成这个表总数据量，所以速度会非常慢，跟读取多少条记录不是特别大的关系；2. 表总记录是几百万，也即不超过1KW3.每天有大概10W条记录发生更新，我理解为UPDATE，若是错了，请LZ纠正，因为按此思路进行解答；4.像这样的记录，应该有字段记录数据是否发生过变更，也即应该会有一个更新时间，比如TIMESTAMP类型的字段非常适合，若是没有，那只能借助触发器，解决性能损失大点，从你的WHERE子句的字段看，就是字段：date_refresh5.每天从主表中读取 date_refresh发生变化的所有记录的ID到一张表中，且ID字段为主键；6.再对这张表进行select id
from table order by rand() limit
0,3000 ，或者不直接随机，也即搞复杂点，利用程序实现内存随机读取数据的方案，若真是10W条可以考虑采用数据库方式完成，毕竟一个字段且是主键会非常快的7.根据随机到的3KID，再去主表读取数据，进行下一步的分析...[b]推荐：[/b][url=]淘宝和阿里巴巴去Oracle化事件 引发数据库技术人员大讨论[/url]
把所有的当天更新的ID取出来，放在文件里，我们就可以知道最大的行数。然后根据行数来随机选择某一行的数据。这个东西的难点在于你不能使用readline一行一行的读，而要使用read来根据\n判断一行，找到相应的行。速度不会快，但估计比你那个快，你用的rand根本无法优化
SELECT *FROM `table` AS t1 JOIN (SELECT ROUND(RAND() * ((SELECT MAX(id) FROM `table`)-(SELECT MIN(id) FROM `table`))+(SELECT MIN(id) FROM `table`)) AS id) AS t2WHERE t1.id &= t2.idORDER BY t1.id LIMIT 1;
每天新增的时候，记录下id，存在内存中。再从内存中，在程序中，对10万条id，随机出3000个id，再到数据库中查。
已有帐号？
无法登录？
社交帐号登录& & MySQL自增主键归零的方法：如果曾经的数据都不需要的话，可以直接清空所有数据，并将自增字段恢复从1开始计数：truncate&table&table_& & 2.&当用户没有truncate的权限时且曾经的数据不需要时：& & 1）删除原有主键：ALTER&TABLE&'table_name'&DROP&'id';& & 2）添加新主键：ALTER&TABLE&'table_name'&ADD&'id'&int(11)&NOT&NULL&FIRST;& & 3）设置新主键：ALTER&TABLE&'table_name'&MODIFY&COLUMN&'id'&int(11)&NOT&NULL&AUTO_INCREMENT,ADD&PRIMARY&KEY(id);& & 3. 当用户没有权限时：& & 可以直接设置数据表的 AUTO_INCREMENT 值为想要的初始值，比如10000：ALTER&TABLE&'table_name'&AUTO_INCREMENT=&10000;
声明：该文章系网友上传分享，此内容仅代表网友个人经验或观点，不代表本网站立场和观点；若未进行原创声明，则表明该文章系转载自互联网；若该文章内容涉嫌侵权，请及时向
上一篇：下一篇：
相关经验教程
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.001 收益
的原创经验被浏览，获得 ￥0.001 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.001 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.001 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.001 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益
的原创经验被浏览，获得 ￥0.005 收益