MySQL存储过程传递列名参数时出现#1064语法错误的问题

问题根源分析 #

1. 不兼容数据类型：表定义使用了Oracle专属的VARCHAR2类型，MySQL虽会自动兼容转为VARCHAR，但易引发语法解析的潜在问题。
2. 存储过程结构缺失：仅提供了内部动态SQL逻辑，缺少CREATE PROCEDURE的完整包裹结构，直接执行必然触发语法错误。
3. 列名未转义：动态拼接列名时未用反引号(`)包裹，若列名与MySQL关键字冲突，会导致语法解析失败。

修正后的完整代码 #

-- 修正表字段类型（可选但推荐）
ALTER TABLE Clase MODIFY clasa VARCHAR(30);
ALTER TABLE Clase MODIFY tip VARCHAR(12);
ALTER TABLE Clase MODIFY tara VARCHAR(30);
ALTER TABLE Clase MODIFY diametru_tun VARCHAR(20);
ALTER TABLE Clase MODIFY deplasament VARCHAR(20);

-- 创建标准存储过程
DELIMITER //
CREATE PROCEDURE get_country_pairs(IN p_col1 VARCHAR(30), IN p_col2 VARCHAR(30))
BEGIN
    SET @s = CONCAT(
        'SELECT c1.tara, c2.tara 
         FROM clase c1 JOIN clase c2 ON (c1.clasa > c2.clasa) 
         WHERE c1.`', p_col1, '` = c2.`', p_col1, '` 
           AND c1.`', p_col2, '` = c2.`', p_col2, '`'
    );
    PREPARE stmt FROM @s;
    EXECUTE stmt;
    DEALLOCATE PREPARE stmt;
END //
DELIMITER ;

关键修正说明 #

• 统一数据类型：将表中所有VARCHAR2改为MySQL原生VARCHAR，消除类型解析歧义。
• 完整存储过程结构：用DELIMITER临时修改语句结束符，包裹完整的存储过程定义，这是MySQL存储过程的标准写法。
• 列名安全转义：用反引号(`)包裹动态拼接的列名，确保即使列名是关键字也能正确解析。
• 参数类型规范：存储过程参数使用MySQL标准的VARCHAR类型，替代Oracle的VARCHAR2。

测试调用示例 #

-- 传入原查询的列名，验证功能
CALL get_country_pairs('deplasament', 'tip');

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