每分钟存储过程mysql_MySql实战篇：写一个简单的存储过程，完成订单定时任务...

r囧r小猫 2023-01-12 07:49 122阅读 0赞

前言之前我们分享了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());

如下图所示：

编写存储过程定时任务

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(已失效)。

设置定时计划

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

总结

存储过程的优点

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

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

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

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

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

存储过程的弊端

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

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

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

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

3.可移植性差

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

使用场景

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

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