温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

子查询更新操作的坑

发布时间:2020-05-24 19:27:43 来源:网络 阅读:1441 作者:雪隐千寻 栏目:MySQL数据库

子查询我相信大部分人都写过,但是昨天遇到一个比较坑的问题,由于有较好的备份,很短时间就恢复了误操作数据,但是这个问题值得分享。
首先建立如下测试表:
CREATE TABLE course (
student_id INT(11),
course VARCHAR(20)
);
INSERT INTO course VALUES ('1', '测试1');
INSERT INTO course VALUES ('2', '测试2');
INSERT INTO course VALUES ('3', '测试3');

CREATE TABLE student (
id INT(11),
name VARCHAR(20)
) ;
INSERT INTO student VALUES ('1', 'jiate');
INSERT INTO student VALUES ('2', 'haoshen');
INSERT INTO student VALUES ('3', 'leishen');
INSERT INTO student VALUES ('4', 'tetui');

子查询更新操作的坑

现在我们执行如下查询操作:
SELECT FROM student WHERE id IN (SELECT id FROM course)
子查询更新操作的坑
这个结果很明显,多了一条。而在昨天,我们开发写的是个update 操作,也是就:update student set name='特腿' where id in (select id from course) 本来更新1000条的数据,开发直接误更新了40万条。
仔细排查后,发现刚才两条sql发现 course 中根本就不存在id列,那么刚才那两条sql为啥没有抛出id报错,而是直接全表匹配了?
我们 desc extended 看看优化器究竟干了什么?
DESC EXTENDED SELECT
FROM student WHERE id IN (SELECT id FROM course)

SHOW WARNINGS

子查询更新操作的坑
第一行1276 大意是说第二个查询中的 id 列在第一个表中被解析到
第二行就是解析器解析后的sql,我们贴出来看看
SELECT
yhtest.student.id AS id,
yhtest.student.name AS name
FROM
yhtest.student semi
JOIN (yhtest.course)
WHERE (
yhtest.student.id = yhtest.student.id
)

也就是说我们这个子查询中的id 列被解析为了主表的id 列,这样,where 条件是一个恒成立的条件,所以导致我们的查询过结果是a表的全表结果,而这也是这样的查询不抛错的原因。
子查询中的字段,首先会在子查询中查找,1)如果子查询中没该字段,则会去外层主表查找,如果能找到,也不会抛错! 2)如果子查询和主表中都没有该字段,则会抛错。
这其实是一个比较不理想的结果,如果我们无意中错误是update操作,那么这个结果太糟糕。
这个我们提了两个醒:
1)做数据库操作之前,最好都备份
2)平时写sql的时候,子查询尽量都写成表关联的形式,表关联形式,如果出现这种错误,会直接抛出错误。子查询形式,虽然好懂,一目了然,但是性能一般不大好,再一个,如果掉进了以上这种误更新坑中......
3)在不同版本的数据库对于子查询的优化操作也是不尽相同,性能差异在不同版本之间还是比较明显的。

向AI问一下细节

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

AI