MySQL-[SIGNAL/RESIGNAL/GET DIAGNOSTICS]的使用

  最近在做 SQL Server 到 MySQL 的迁移(migration),相较于对表和数据的迁移,最令人犯难的还是在功能性存储过程脚本的改写转换(convert),虽说 MySQL 如今是蓬勃发展,不断的更新迭代的优化,但是在存储过程等脚本方面与 Oracle、SQL Server 相比,个人感觉是有所欠缺的,无论是灵活性还是实用性,有时真的是很难达到自己想要的效果,或许这就是为什么存储过程在 MySQL 中使用较少的原因吧……

  承接上一篇关于MySQL的异常处理,继续异常处理的扩展性用法:

异常处理语句:

1、DECLARE … CONDITION …

2、DECLARE … HANDLER …

3、SIGNAL …

4、RESIGNAL …

5、GET DIAGNOSTICS …

一、常规声明的异常处理

1、条件声明

  condition_name:标准的变量命名;

  condition_value:SQLSTATE 值或者 MySQL 自身的 ERROR CODE ;

注:单独的 condition 语句不能直接运行,只能作为【条件处理】的一部分。

2、条件处理

  handler_action:代表处理的动作,常用的是继续(CONTIUE)和直接退出(EXIT);

  condition_value:异常处理捕获条件或情况,包括【条件声明】里的 SQLSTATE, MYSQL EEROR CODE, condition_name 以及范围混淆的其他两种;

注:SQLWARNING、SQLEXCEPTION、NOT FOUND 表示任何不存在的 WARNING 或者 ERROR。

 

二、SIGNAL 与 RESIGNAL

  SIGNAL 与 RESIGNAL 可以通过自定义伪装系统的错误信息以及代码,刷新当前警告缓冲区域。

1、SIGNAL

  SIGNAL是“返回”错误的方法,向处理程序,应用程序的外部部分或客户端提供错误信息。

  此外,它还可以控制错误的特征(错误号,SQLSTATE值,消息)。 如果没有SIGNAL,则必须采用诸如故意引用不存在的表之类的解决方法来导致例程返回错误。

 2、RESIGNAL

  同样的,RESIGNAL 也可以异常处理并返回错误信息。

  通过对比 SIGNAL 与 RESIGNAL 的语法,在使用 SIGNAL 方法的时候必须指定 condition_value ,也就是说其不能单独使用,需要先定义异常处理,可以在存储过程中的任何位置使用 SIGNAL 语句。

  而 RESIGNAL 可以省略RESIGNAL语句的所有属性,甚至可以省略SQLSTATE值,但必须在错误或警告处理程序中使用 RESIGNAL 语句,否则将收到一条错误消息,指出“RESIGNAL when handler is not active”。如果单独使用RESIGNAL语句,则所有属性与传递给条件处理程序的属性相同。

3、常见对比使用实例

  推荐使用 SIGNAL,灵活随机,在定义好后即可将 SIGNAL 语句放到任何你想放的地方进行判断预警处理。

、GET DIAGNOSTICS

  5.6开始支持的语法,从而获取错误缓冲区的内容,然后把这些内容输出到不同范围域的变量里,以便后续灵活操作处理。

  statement_information_item:statment 执行情况信息捕获反馈,包括 NUMBER、ROW_COUNT;

  condition_information_item:捕获异常情况信息;

  当条件发生,可以通过变量去接收条件项目信息,但也不是说有的 MySQL 都会进行填充赋值,也会出现空值的(例如:SCHEMA_NAME and TABLE_NAME is null when drop table)。

注:个人认为,因为使用 GET DIAGNOSTICS 略有些鸡肋,使用选择上更多的会是用 SIGNAL 语句进行异常处理,所以在此不做深究 GET DIAGNOSTICS 的使用。

@author:http://www.cnblogs.com/geaozhang/

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注