小心这种写法真会删库跑路，你的工资怕不够赔！！！(一)

1、问题发现

今天收到一朋友反馈，发现执行一个存储过程后，整个表数据都没有了。
我让朋友把存储过程发过来我查一下，结果存储过程好长好几百行，短时间没有发现原因，结果朋友自己从阿里的审计日志发现了问题。

2、问现复现

做一个极简例子即可复现此问题

--构造测试数据 创建一个表，并插入5行
create table t
(id int);
insert into t
values(1),(3),(4),(5),(6);

复制

此时查询t表 有5行记录

编写存储过程 根据参数删除其中一行记录

drop procedure if exists sp1 ;
delimiter ;;
CREATE PROCEDURE sp1 (id bigint)
BEGIN
 SET @id = id;
delete from t where  id = @id ;
END ;;
delimiter ;
复制

调用存储过程 删除指id = 1 的那一行

call sp1(1);
复制

执行后 再查询，发现t表为空了

看到这里的朋友发现问题在哪里了吗？

3、分析问题

想弄明白为什么会这样，我就想那看存储过程内的语句变成什么样了就知道了

a、第一种方法 查看全量日志

set global general_log=1;
show variables like '%general_log%';
复制

发现全量日志中记载的是 call sp(1) 这个语句

b、第二种方法 查看慢日志

在delete 后 加一个sleep 构造慢SQL

set global slow_query_log=on;
show variables like 'slow_query_log_file';
复制

发现慢日志中记载的也是 call sp(1) 这个语句

c、第三种方法 查看binlog日志

SET SESSION binlog_format = 'STATEMENT';
show master status; 
show binlog events in 'LAPTOP-MT6UTC5I-bin.000072';
复制

至此真相大白了。原来where 1=1 永远为真了。

4、分析根因

以前写过一篇MySQL变量的文章 有兴趣的可以点这传送