一个子查询引发的血案
2017-12-16 13:54
113 查看
最近再次看到一个帖子,说使用类似如下子查询删除数据,结果发现所有的数据都被删除了
DELETE FROM a
WHERE id in (
SELECT id FROM b
)
粗看这是一个没有任何毛病的删除操作,只会删除 a,b 表 id 匹配的记录。但实际上这个查询暗藏杀机,如果 b 表恰好有数据,并且b表没有字段id,这个操作的结棍是什么?
很显然,如果b表没有id字段,并且有数据,那么子查询中的id就是a表的id字段,那么这个条件就相当于 WHERE a.id=a.id,后果可想而知。
通常在资深DBA制定的SQL规范中,都会有一条,明确写明字段所属的表,如果遵守了,就不会出现这种问题
如果你DBA的这个规范不屑一顾,那么你要小心了
(此文也在个人微信公共号ZJCXC发布)
DELETE FROM a
WHERE id in (
SELECT id FROM b
)
粗看这是一个没有任何毛病的删除操作,只会删除 a,b 表 id 匹配的记录。但实际上这个查询暗藏杀机,如果 b 表恰好有数据,并且b表没有字段id,这个操作的结棍是什么?
很显然,如果b表没有id字段,并且有数据,那么子查询中的id就是a表的id字段,那么这个条件就相当于 WHERE a.id=a.id,后果可想而知。
通常在资深DBA制定的SQL规范中,都会有一条,明确写明字段所属的表,如果遵守了,就不会出现这种问题
如果你DBA的这个规范不屑一顾,那么你要小心了
(此文也在个人微信公共号ZJCXC发布)
相关文章推荐
- C#:WQL查询LIKE子句中反斜杠字符引发的血案及解决之道
- 子查询引发的血案
- super dealloc 引发的血案
- 转alter index rebuild online引发的血案
- 一个字母引发的编译血案
- parseInt引发的血案
- 一条cltq指令引发的血案
- 如何避免session引发的血案
- 一个数据类型不匹配引发的coredump“血案”
- 记Task Scheduler一个选项引发的血案
- 一个“Sprng轮子”引发的“血案”(3)
- Android 4.0 中由ProGuard引发的一场血案
- 一个return引发的血案
- ID重复引发的血案,按钮点击事件不起作用
- 一场precision引发的血案
- 5年前面试题引发的“血案”(1)(日志切换时的检查点和表空间管理)
- break使用不当引发的一个“血案”
- 5年前面试题引发的“血案”(番外篇)(总结和乱侃)
- 一个低级错误引发的血案
- 记一次saltstack软件版本升级到2017.7新版本时所引发的“血案”!