MySQL的表中插入新的属性怎么做?
单纯的update肯定不行,update只是DML语言,你要增加新属性是需要改变表结构的,是需要DDL语言,所有步骤是:
成都创新互联专注于普安企业网站建设,响应式网站,商城网站开发。普安网站建设公司,为普安等地区提供建站服务。全流程按需网站设计,专业设计,全程项目跟踪,成都创新互联专业和态度为您提供的服务
1、更改表结构,增加一个字段放置新增的属性
alter table 表名 add 字段名 字段类型;
2、插入新记录
insert into 表名(字段名,多个用逗号分隔) values (记录的值,几个字段对应几个值);
commit;
mysql笔记(10)-数据的插入和更新(insert/update/case)
常见的插入方式有以下几种:
这种方式每次只能插入一行
且set从句内的values不能全部为空
这种方式可以一次性插入多行
不同行之间的数据要 用逗号进行分隔
这种方式用于替换表中的某一行
若新插入记录的主码已经存在于表中,则用新记录替换旧记录
若新插入记录的主码不在表中,则直接插入新记录
普通的update语句写法如下:
例如:在instructor(教师信息)表中
我们想更新 ID为10101的教师的工资为70000
对于更复杂的数据更新 我们可以添加 case-when从句
从而实现对数据的分类更新
例如:在instructor(教师信息)表中 对所有教师进行涨薪
对工资小于等于100000的涨薪5%,其他人涨薪3%
想在mysql数据库中的表中插入一列,怎么做?
传统情况
我们先回顾一下,在没有 "立刻加列" 功能时,加列操作是怎么完成的。我们也借此来熟悉一下本期的图例:
当进行 加列操作 时,所有的数据行 都必须要 增加一段数据(图中的 列 4 数据)
如上一期图解所讲,当改变数据行的长度,就需要 重建表空间(图中灰蓝的部分为发生变更的部分)
数据字典中的列定义也会被更新
以上操作的问题在于 每次加列 操作都需要重建表空间,这就需要大量 IO以及大量的时间
立刻加列
"立刻加列" 的过程如下图:
请点击输入图片描述
请点击输入图片描述
"立刻加列" 时,只会变更数据字典中的内容,包括:
在列定义中增加 新列的定义
增加 新列的默认值
"立刻加列" 后,当要读取表中的数据时:
由于 "立刻加列" 没有 变更行数据,读取的行数据只有 3 列
MySQL 会将 新增的第 4 列的默认值,追加到 读取的数据后
以上过程描述了 如何读取 在 "立刻加列" 之前写入的数据,其实质是:在读取数据的过程中,"伪造" 了一个新列出来
那么如何读取 在 "立刻加列" 之后 写入的数据呢 ? 过程如下图:
当读取 行 4 时:
请点击输入图片描述
请点击输入图片描述
通过判断 数据行的头信息中的instant 标志位,可以知道该行的格式是 "新格式":该行头信息后有一个新字段 "列数"
通过读取 数据行的 "列数" 字段,可以知道 该行数据中多少列有 "真实" 的数据,从而按列数读取数据
通过上图可以看到:读取 在"立刻加列" 前/后写入的数据是不同的流程
通过以上的讨论,我们可以总结 "立刻加列" 之所以高效的原因是:
在执行 "立刻加列" 时,不变更数据行的结构
读取 "旧" 数据时,"伪造" 新增的列,使结果正确
写入 "新" 数据时,使用了新的数据格式(增加了instant标志位 和 "列数" 字段),以区分新旧数据
读取 "新" 数据时,可以如实读取数据
那么 我们是否能一直 "伪造" 下去 ? "伪造" 何时会被拆穿 ?
考虑以下场景:
用 "立刻加列" 增加列 A
写入数据行 1
用 "立刻加列" 增加列 B
写入数据行 2
删除列 B
我们推测一下 "删除列 B" 的最小代价:需要修改 数据行中的instant标志位或 "列数" 字段,这至少会影响到 "立刻加列" 之后写入的数据行,成本类似于重建数据
从以上推测可知:当出现 与 "立刻加列" 操作不兼容 的 DDL 操作时,数据表需要进行重建,如下图所示:
请点击输入图片描述
请点击输入图片描述
扩展思考题:是否能设计其他的数据格式,取代instant标志位和 "列数" 字段,使得 加列/删列 操作都能 "立刻完成" ?(提示:考虑 加列 - 删列 - 再加列 的情况)
使用限制
在了解原理之后,我们来看看 "立刻加列" 的使用限制,就很容易能理解其中的前两项:
"立刻加列" 的加列位置只能在表的最后,而不能加在其他列之间
在元数据中,只记录了 数据行 应有多少列,而没有记录 这些列 应出现的位置。所以无法实现指定列的位置
"立刻加列" 不能添加主键列
加列 不能涉及聚簇索引的变更,否则就变成了 "重建" 操作,不是 "立刻" 完成了
"立刻加列"不支持压缩的表格式
按照 WL 的说法:"COMPRESSED is no need to supported"(没必要支持不怎么用的格式)
总结回顾
我们总结一下上面的讨论:
"立刻加列" 之所以高效的原因是:
在执行 "立刻加列" 时,不变更数据行的结构
读取 "旧" 数据时,"伪造" 新增的列,使结果正确
写入 "新" 数据时,使用了新的数据格式 (增加了 instant 标志位 和 "列数" 字段),以区分新旧数据
读取 "新" 数据时,可以如实读取数据
"立刻加列" 的 "伪造" 手法,不能一直维持下去。当发生 与 "立刻加列" 操作不兼容 的 DDL 时,表数据就会发生重建
回到之前遗留的两个问题:
"立刻加列" 是如何工作的 ?
我们已经解答了这个问题
所谓 "立刻加列" 是否完全不影响业务,是否是真正的 "立刻" 完成 ?
可以看到:就算是 "立刻加列",也需要变更 数据字典,那么 该上的锁还是逃不掉的。也就是说 这里的 "立刻" 指的是 "不变更数据行的结构",而并非指 "零成本地完成任务"
利用mysql存储过程循环插入新数据并更新
DROP PROCEDURE IF EXISTS excute_job_v340;
create procedure excute_job_v340()
begin
declare rdevid int; //声明参数
declare rech_id int;
declare slot int;
declare new_rech_id int;
declare new_price DOUBLE;//声明参数
declare done INT DEFAULT FALSE;////声明结束标识参数
-- 声明游标
DECLARE rdevrech_id CURSOR FOR
select r.id as rdevid,r.rechargeconfig_id as rech_id,r.slot_no as slot from b_device_tbl dev
LEFT JOIN r_device_rechargeconfig_tbl r on dev.id= r.device_id
where dev.dev_typedef_id =7 and dev.masterid is not NULL and r.rechargeconfig_type=4 and r.is_deleted=0 and r.slot_no is not NULL;
-- 将结束标志绑定到游标
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;
-- 打开游标
OPEN rdevrech_id;
-- 遍历
read_loop: LOOP
-- 取值
FETCH NEXT from rdevrech_id INTO rdevid,rech_id,slot;
IF done THEN
LEAVE read_loop;
END IF;// 结束判断
select price into new_price from c_device_rechargeconfig_item_tbl where rechargeconfig_id =rech_id limit 1;
INSERT INTO `c_device_rechargeconfig_tbl` ( `type`, `style_id`, `is_default`, `dev_type_code`, `is_deleted`, `create_time`, `slot_no`)
VALUES ( '4', NULL, '0', '0', '0', '2019-08-19 15:59:24',slot );
select max(id) into new_rech_id from c_device_rechargeconfig_tbl ;
INSERT INTO `c_device_rechargeconfig_item_tbl` ( `price`, `goods`, `description`, `is_deleted`, `create_time`, `rechargeconfig_id` )
VALUES ( new_price,new_price, '0.00', '0', '2019-08-19 15:59:24', new_rech_id);
update r_device_rechargeconfig_tbl set rechargeconfig_id=new_rech_id where id=rdevid;
END LOOP;
CLOSE rdevrech_id;
end;
call excute_job_v340() ;//调用执行
当前标题:mysql怎么插入新的 mysql中怎么添加数据
网站路径:http://scyingshan.cn/article/dohoedi.html