MySQL: @variable vs variable. Quelle est la différence? (Part2)

Question

Ok, hors de la construction the last question I asked, Comment gérer le Mysql où statment dans le code suivant:

DELIMITER ;// 
DROP PROCEDURE IF EXISTS `test`;// 
CREATE PROCEDURE `test` 
(
    id INT 
) 
BEGIN 
    SELECT * 
    FROM some_table 
    WHERE id = id; 
END;// 

Qu'est-MySQL faire dans ce cas? Est-il traiter la clause where

some_table.id = id 

ou faut-il traiter comme

some_table.id = some_table.id 

En ce moment je suis en train de faire quelque chose comme

WHERE id = @id 

parce que je ne savais pas qu'il y avait Variables de session dans MySQL et il ne s'est pas plaint et j'ai pensé que c'était une manière explicite de dire "où cette colonne est égale à cette variable".

Certains pourraient dire "duh .. bien sûr, il traite comme colonne = variable" mais je pourrais facilement avoir dit où "variable = colonne." Alors, comment gère-t-il cela?

Answer 1

Le schéma de nommage des variables de MySQL est un peu étrange, quand on y regarde d'abord. En général, MySQL distingue trois types de variables:

• variables système (global ou session SCOPED): @@varname
• les variables user defined (ils sont la session scope): @varname
• local variables dans les programmes stockés: varname

Ainsi, les conflits de nommage, tels que ceux que vous avez mentionnés ci-dessus, ne surviennent que dans les programmes stockés. Par conséquent, vous devez d'abord essayer d'éviter ces conflits de nommage en attribuant des noms de paramètres non ambigus, par ex. en préfixant les paramètres avec p tels que pId. Si MySQL rencontre une ambiguïté il interprétera la référence comme le nom d'une variable (see here):

[...] Les noms de variables locales ne devraient pas être les mêmes que les noms de colonnes.Si une instruction instruction SQL , comme un SELECT ... INTO , contient une référence à une colonne et une variable locale déclarée avec le même nom, MySQL actuellement interprète la référence comme le nom d'une variable. [...]

Le libellé actuellement donne en quelque sorte l'impression que ce comportement pourrait changer dans les futures versions.

Answer 2

Je suis assez sûr que le @ signifie qu'il s'agit d'une variable dans la procédure, plutôt que de référencer une colonne de table. Il n'y a qu'une colonne de table nommée id, donc dans ce cas, elle est sans ambiguïté. Si vous faites une jointure, alors vous devez le préfixe:

select * 
from table1, table2 
where table1.id = @id 
and table2.some_field = table1.id 

Peu importe où il est, la variable exigera toujours le préfixe @, comme dans cette requête:

select id, @id 
from table1 

le premier id est la colonne de table non ambiguë table1.id, et le @id fait référence à la variable de procédure stockée.