MySQL-存储过程-尝试使用输出参数时的怪异
说实话,我现在感觉自己很傻。但这根本不起作用。
场景
我有一个包含输出参数的存储过程。我正在尝试在该参数中选择一个值。这看起来很简单,但它仍然给我错误的结果。我检查了很多在线资源,并且我确信我正在努力正确地做到这一点。
代码
DELIMITER //
CREATE PROCEDURE `spGetId`(
IN ParamA VARCHAR(32),
OUT OutputId INT
)
BEGIN
SELECT `id` INTO OutputId
FROM `Table`
WHERE `column_a` = ParamA;
END//
CALL spGetId('foobar', @Bloop)//
SELECT @Bloop//
结果
我在这个表中有两行,它们的 ID 是“1”和“2”。无论 SELECT 语句是否匹配任何内容,我返回的结果都是“31”。 我尝试了很多变体,包括完全删除 WHERE 子句并让 SELECT 返回 COUNT(1) 到参数中(这给了我结果“32”,尽管只有 2 行),并且我尝试过“声明" 在存储过程调用中使用 @Bloop 变量之前,使用 SET @Bloop = 0
。
如果您对为什么会发生这种情况以及我能做些什么来使其返回正确的值有任何见解,我将非常感激。另外,如果您可以向我展示如何使用带有返回值的存储函数来实现相同的预期结果,我会很感激更多!我想要的方法是使用存储函数,但我遇到了类似的问题,然后放弃并尝试使用存储过程,却发现我得到了类似的结果。
您能提供的任何内容都会有帮助!
编辑:
CREATE TABLE `Table` (
`id` int(11) NOT NULL auto_increment,
`column_a` varchar(32) character set utf8 NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
mysql> SELECT * FROM Table;
+------+----------+
| id | column_a |
+------+----------+
| 1 | asdf |
| 2 | foobar |
+------+----------+
当我使用任何参数调用 spGetId() 时,它返回值“31”(即使参数是“foobar”,它应该返回整数值“2”(或 ascii 0x32))。如果我修改 spGetId() 以返回表的总行数,则它返回“32”,而不是返回“2”。
To be honest, I'm feeling pretty stupid right now. But this simply isn't working.
Scenario
I have a stored procedure that includes an output parameter. I'm trying to SELECT a value INTO that parameter. This seems simple, but it continues giving me faulty results. I've checked many online sources, and I'm certain that I'm trying to do it properly.
Code
DELIMITER //
CREATE PROCEDURE `spGetId`(
IN ParamA VARCHAR(32),
OUT OutputId INT
)
BEGIN
SELECT `id` INTO OutputId
FROM `Table`
WHERE `column_a` = ParamA;
END//
CALL spGetId('foobar', @Bloop)//
SELECT @Bloop//
Results
I have two rows in this table, their IDs being '1' and '2'. The result I get back is '31', whether the SELECT statement matches anything or not.
I have tried many variations, including removing the WHERE clause entirely and having the SELECT return a COUNT(1) into the parameter (which gives me a result of '32', despite there being only 2 rows), and I have tried "declaring" the @Bloop variable before using it in the sproc call by using SET @Bloop = 0
.
If you have any insight on why this is happening, and what I can do to make it return the proper value, I would be much obliged. Also, if you can show me how to achieve the same desired result using a Stored Function instead, with a return value, I'd appreciate that even more! My desired approach is using a stored function, but I had similar problems with that, then gave up and tried using a stored proc, only to find I was getting similar results.
Anything you can offer would be helpful!
Edit:
CREATE TABLE `Table` (
`id` int(11) NOT NULL auto_increment,
`column_a` varchar(32) character set utf8 NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
mysql> SELECT * FROM Table;
+------+----------+
| id | column_a |
+------+----------+
| 1 | asdf |
| 2 | foobar |
+------+----------+
When I call spGetId() with any argument, it returns the value '31' (even if the argument is 'foobar', which should return an integer value of '2' (or ascii 0x32)). If I modify spGetId() to return the total rowcount of Table, instead of returning '2', it returns '32'.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您的存储过程正在运行。我认为它返回的是字符“1”的 ascii 值而不是整数值 1。
Your stored proc is working. I think it is returning the ascii value of the character '1' instead of the integer value 1.
我需要学习改变我的测试环境。
我仍然不确定问题是什么,但看起来 phpMyAdmin 正在执行自己的某种类型转换,并且我一直通过该特定客户端运行所有测试。
将我自己的快速 PHP 脚本组合在一起并手动调用存储过程(在进一步的测试中,还调用存储的函数)提供了所需的结果。
所以,吸取的教训是:永远不要相信客户。一定要记得稍微切换一下。
I need to learn to vary my testing environments.
I'm still not sure exactly what the problem was, but it looks like phpMyAdmin was performing some kind of type conversion of its own, and I had been running all my tests through that particular client.
Throwing together a quick PHP script of my own and manually calling the sproc (and in further testing, calling a stored function as well) provided the desired results.
So, lesson learned: don't ever trust the client. Got to remember to switch it up a bit.