använder LAGRADE PROCEDURER:olika resultat i mysqli->query(CALL select_procedure) VS mysqli->query(SELECT ...)

överväg Förberedda uttalanden används med concat() som de ofta är.

DROP PROCEDURE if exists myStoredProc101;
DELIMITER $$
CREATE PROCEDURE myStoredProc101
(   pSanitized VARCHAR(124)
)
BEGIN
    set @mySql:=concat("SELECT DISTINCT ID FROM user where match(name) against ('* *",pSanitized,"* *')");
    PREPARE stmt1 FROM @mySql;
    EXECUTE stmt1;
    DEALLOCATE PREPARE stmt1;
END 
$$
DELIMITER ;

Din lagrade proc hade ingen chans att fungera eftersom den inte ens använde din parameter. Vad du gjorde var att begrava något inuti en bokstavlig sträng. Dessutom är varchar(124) lite udda :p

Ungefär den enda framgång människor har med förberedda uttalanden är att använda en användarvariabel (med en @ ) kontra misslyckade försök att använda lokala variabler (från DECLARE). Så, det kan spara dig några timmars huvudsnack i framtiden.

Från PHP-manualsidan Lagrade procedurer :

När det gäller att anropa den lagrade procen från mysqli , ta en titt på svaret från Pablo Tobar. Det ser inte speciellt trevligt ut med många variabler, men det verkar vara där det är. Spoiler Alert:använd mysql-variabler, inte PHP-variabler.

Visst, Pablo returnerade inte en resultatuppsättning, utan skrev till en OUT var i den lagrade proc. Du kanske måste göra vad han gjorde för IN parametrar och anropa multi_query() , sedan en store_result() , sedan en fetch_all() (kort sagt, PHP refererar en sida upp).

Alternativt kan ett samtal göras av Palladium här .

I båda fallen måste fallet tas för att undvika den kända sårbarheten att passera SQL Injection över till lagrade procedurer.