标签：png size src sem type creat rom 关联 iat
子查询我相信大部分人都写过，但是昨天遇到一个比较坑的问题，由于有较好的备份，很短时间就恢复了误操作数据，但是这个问题值得分享。course (student_id INT(11),course VARCHAR(20)course VALUES (‘1‘, ‘测试1‘);course VALUES (‘2‘, ‘测试2‘);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
FROMyhtest.student semi
JOIN (yhtest.course)
WHERE (yhtest.student.id = yhtest.student.id
)
也就是说我们这个子查询中的id 列被解析为了主表的id 列，这样，where 条件是一个恒成立的条件，所以导致我们的查询过结果是a表的全表结果，而这也是这样的查询不抛错的原因。
子查询中的字段，首先会在子查询中查找，1）如果子查询中没该字段，则会去外层主表查找，如果能找到，也不会抛错！ 2）如果子查询和主表中都没有该字段，则会抛错。
这其实是一个比较不理想的结果，如果我们无意中错误是update操作，那么这个结果太糟糕。
这个我们提了两个醒：
1）做数据库操作之前，最好都备份
2）平时写sql的时候，子查询尽量都写成表关联的形式，表关联形式，如果出现这种错误，会直接抛出错误。子查询形式，虽然好懂，一目了然，但是性能一般不大好，再一个，如果掉进了以上这种误更新坑中......
3）在不同版本的数据库对于子查询的优化操作也是不尽相同，性能差异在不同版本之间还是比较明显的。
标签：png size src sem type creat rom 关联 iat
原文地址：http://blog.51cto.com/11286233/2059003
