MySql实战篇：写一个简单的存储过程，完成订单定时任务

Mysql.jpg

前言

之前我们分享了MySql的性能优化、索引详解等内容，本篇文章主要是针对想要入门MySql存储过程的读者而写的。主要实现的业务是订单库里面的超过30分钟没有支付的订单全部置为失效订单。

创建订单表

CREATE TABLE `shop_order` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '订单ID',
  `good_id`int(11) NOT NULL COMMENT '商品ID',
  `order_amount` decimal(11,2) NOT NULL COMMENT '订单金额',
  `status` varchar(10) NOT NULL COMMENT '订单状态：0：交易待支付，1：交易支付中，2：交易成功、3：交易关闭',
  `create_date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_date` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '更新时间',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='商城订单表';

插入测试数据

insert into shop_order(id,good_id,order_amount,status, create_date, update_date)
values(1,1,99.00,0,NOW(),NOW());
insert into shop_order(id,good_id,order_amount,status, create_date, update_date)
values(2,3,126.00,0,NOW(),NOW());
insert into shop_order(id,good_id,order_amount,status, create_date, update_date)
values(3,9,45.00,0,NOW(),NOW());

如下图所示：

表数据.jpg

编写存储过程定时任务

BEGIN
    UPDATE 
      `shop_order` AS order_ 
    set
      order_.`status` = '3' 
    WHERE 1 = 1 
      AND order_.status = '0' 
      AND TIMESTAMPDIFF(MINUTE, order_.`create_date`, NOW()) > 30;
END

解读：存储过程执行的时候如果超过30分钟并且订单状态为0（交易待支付）的订单修改状态为3（已失效）。

设置定时计划

定时计划.jpg

备注：时间可以根据具体情况进行调整哦！

总结

存储过程的优点

(1).增强SQL语言的功能和灵活性：存储过程可以用控制语句编写，有很强的灵活性，可以完成复杂的判断和较复杂的运算。

(2).标准组件式编程：存储过程被创建后，可以在程序中被多次调用，而不必重新编写该存储过程的SQL语句。而且数据库专业人员可以随时对存储过程进行修改，对应用程序源代码毫无影响。

(3).较快的执行速度：如果某一操作包含大量的Transaction-SQL代码或分别被多次执行，那么存储过程要比批处理的执行速度快很多。因为存储过程是预编译的。在首次运行一个存储过程时查询，优化器对其进行分析优化，并且给出最终被存储在系统表中的执行计划。而批处理的Transaction-SQL语句在每次运行时都要进行编译和优化，速度相对要慢一些。

(4).减少网络流量：针对同一个数据库对象的操作（如查询、修改），如果这一操作所涉及的Transaction-SQL语句被组织进存储过程，那么当在客户计算机上调用该存储过程时，网络中传送的只是该调用语句，从而大大减少网络流量并降低了网络负载。

(5).作为一种安全机制来充分利用：通过对执行某一存储过程的权限进行限制，能够实现对相应的数据的访问权限的限制，避免了非授权用户对数据的访问，保证了数据的安全。

存储过程的弊端

1.架构不清晰，不够面向对象

存储过程不太适合面向对象的设计，无法采用面向对象的方式将业务逻辑进行封装，业务逻辑在存储层实现，增加了业务和存储的耦合，代码的可读性也会降低，

2.开发和维护要求比较高

存储过程的编写直接依赖于开发人员，如果业务逻辑改动较多，需要频繁直接操作数据库，大量业务降维到数据库，很多异常不能在代码中捕获，出现问题较难排查，需要数据库管理人员的帮助。

3.可移植性差

过多的使用存储过程会降低系统的移植性。在对存储进行相关扩展时，可能会增加一些额外的工作。

使用场景

普通的项目开发中，不建议大量使用存储过程，对比SQL语句，存储过程适用于业务逻辑复杂，比较耗时，同时请求量较少的操作，例如后台大批量查询、定期更新等。

（1）当一个事务涉及到多个SQL语句时或者涉及到对多个表的操作时可以考虑应用存储过程

（2）在一个事务的完成需要很复杂的商业逻辑时可以考虑应用存储过程

（3）比较复杂的统计和汇总可以考虑应用后台存储过程

关注我们

可以关注“IT实战联盟”公众号并留言也可以加入交流群和作者互撩哦~~~

IT实战联盟.jpg