MySQL存储过程返回0行：单独脚本正常，封装后无结果

嘿，我碰到过好多次这种存储过程参数不生效的情况，咱们一步步拆解排查，大概率能找到问题所在：

1. 参数名和表列名撞车了！ #

这绝对是最常见的坑！比如你的存储过程参数叫lat或者lng，刚好你的地点表字段也用了同样的名字——MySQL会优先把它解析成表的列名，而不是你传入的参数值。举个反例：

CREATE PROCEDURE find_nearby(IN lat DECIMAL(10,8), IN lng DECIMAL(11,8), IN radius INT)
BEGIN
  SELECT * FROM locations
  WHERE ST_Distance_Sphere(POINT(lng, lat), POINT(locations.lng, locations.lat)) <= radius * 1000;
END;

这里的lng和lat会被当成locations表的字段，而不是你传入的参数，自然计算出来的距离完全不对，返回0行。

解决方法：给参数加个前缀，比如p_lat、p_lng，明确区分开：

CREATE PROCEDURE find_nearby(IN p_lat DECIMAL(10,8), IN p_lng DECIMAL(11,8), IN p_radius INT)
BEGIN
  SELECT * FROM locations
  WHERE ST_Distance_Sphere(POINT(p_lng, p_lat), POINT(locations.lng, locations.lat)) <= p_radius * 1000;
END;

2. 参数数据类型不匹配 #

比如你表中的经纬度字段是DECIMAL(10,8)，但存储过程参数定义成了DECIMAL(5,2)——传入的数值会被截断，精度丢失后计算出来的坐标完全偏离目标区域。或者你调用时传了字符串类型的经纬度，而参数定义是数值类型，也会导致参数值异常。

解决方法：确保存储过程参数的数据类型、精度、小数位数和表中对应的字段完全一致，调用时也要传入对应类型的数值。

3. 调用存储过程时参数顺序搞反了 #

比如你定义的参数顺序是纬度、经度、半径，但调用时写成了：

CALL find_nearby(116.403874, 39.915168, 5);

把经度先传了，这样计算出来的坐标完全不在你要的区域，自然查不到数据。

解决方法：调用时严格按照存储过程定义的参数顺序传值，或者用参数名=值的方式明确指定：

CALL find_nearby(p_lng=116.403874, p_lat=39.915168, p_radius=5);

4. 存储过程里误用了会话变量（@开头的变量） #

单独执行查询时你可能用了SET @lat = 39.9;这种会话变量，封装成存储过程时不小心没把@lat换成传入的参数，这时候存储过程里的@lat可能是NULL，导致计算出来的距离为NULL，筛选不到任何数据。

解决方法：检查存储过程代码，确保所有用到经纬度的地方都是你定义的参数，而不是会话变量。

5. 先确认参数是否真的传进去了 #

可以在存储过程里先打印参数值，验证传入是否正确：

CREATE PROCEDURE find_nearby(IN p_lat DECIMAL(10,8), IN p_lng DECIMAL(11,8), IN p_radius INT)
BEGIN
  -- 先打印参数，确认是否正确传入
  SELECT p_lat AS input_latitude, p_lng AS input_longitude, p_radius AS input_radius;
  -- 再执行查询逻辑
  SELECT * FROM locations
  WHERE ST_Distance_Sphere(POINT(p_lng, p_lat), POINT(locations.lng, locations.lat)) <= p_radius * 1000;
END;

调用后先看第一部分的结果，如果参数是NULL或者和你传入的不一样，那就是参数传递环节出了问题。

6. SQL模式不一致的问题 #

有时候单独执行查询时的SQL模式和存储过程执行时的不一样，比如ONLY_FULL_GROUP_BY等模式可能导致结果被过滤（不过你说没报错，这个可能性稍低）。可以先执行SELECT @@sql_mode;拿到单独查询时的模式，然后在存储过程开头设置相同的模式：

CREATE PROCEDURE find_nearby(IN p_lat DECIMAL(10,8), IN p_lng DECIMAL(11,8), IN p_radius INT)
BEGIN
  SET sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';
  -- 后续查询逻辑
END;

建议先从第1、3、4点开始排查，这几个是最容易踩的坑。如果还是解决不了，可以把你的存储过程代码和调用语句贴出来，能更精准地定位问题。

内容的提问来源于stack exchange，提问作者CGarden