mysql数据库的存储过程创建语句之中需要使用begin表示存储过程要执行的语句从这里开始,在结尾使用end表示存储过程的语句要结束了。而在mysql数据库之中无论是查询还是添加语句都要使用分号去分隔,但是在存储过程之中创建sql语句的时候却被mysql数据库的编译器把分号当做了结束语句,没有end就被检测成语法错误了。
二、解决方法
一般来说上面这个问题都是因为mysql数据库版本所导致的,如果确定语句没有错误的话就要更新版本或者将语句的结束符改成别的符号,只要能够让mysql数据库编译器解析到end就可以了。使用delimiter即可更改sql语句结束符,示例如下:
delimiter // --更改结束符create procedure course_id_name(in cid varchar(20))beginselect namefrom coursewhere id = cidend//delimiter --将结束符换回分号
以上就是关于“mysql数据库存储过程语法报错为什么?原因和解决方法看这里”的全部内容了,想要了解更多python的实用知识和代码示例可以持续关注这个频道,每次更新都会有很多新的知识技术分享给大家。
在执行一个sql文件时 mysql -h 127.0.0.1 -uroot study -e"source b.sql" ,报错 MySQL server has gone away 。上网查解决办法,按照网上的解决方法一步步 *** 作,最终找到原因并且解决了,觉得有必要总结下这个问题发生的原因及解决办法,避免后面再继续踩坑。
执行以下命令,查看mysql的运行时长。
uptime数值很大,表明mysql服务运行很久,说明最近MySQL服务器没有重启过。
或者查看MySQL的报错日志,看看有没有重启的信息。
如果日志没有相关信息,也表明mysql服务最近没有重启过,可以继续检查下面几项情况。
如果程序使用的是长连接,则这种情况的可能性会比较大。
即,某个长连接很久没有新的请求发起,达到了server端的timeout,被server强行关闭。
此后再通过这个connection发起查询的时候,就会报错server has gone away。
如下命令设置连接超时为5秒。
再执行 SELECT NOW(),通过这个connection发起查询的时候,就会报错server has gone away。
实际上wait_timeout=28800,不是造成文章开头的原因。
这种情况和情况2相似,只是发起者是DBA或者其他job。发现有长时间的慢查询执行kill xxx导致。
当查询的结果集超过 max_allowed_packet 也会出现这样的报错。
查看执行SQL执行文件大小是否超过 max_allowed_packet ,如果超过则需要调整参数,或者优化语句。
计算发现SQL执行文件最大只能是16M,而文章开头执行的a.sql有24M。
修改参数,max_allowed_packet 调整为28M。
重新再执行`mysql -h 127.0.0.1 -uroot study -e"source b.sql"``成功,说明原因是情况4造成的。
此种情况下报错的原因一般为:外键命名冲突即是你正在创建的此表的外键约束名字已经在别的表中用过了
解决办法为:给正在创建表的外键约束换个新名字呗!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)