Czy mysql_real_escape_string() będzie wystarczającym zabezpieczeniem przed SQL Injection?
A jeżeli nie to dlaczego i czy też są jakieś inne lepsze sposoby?

Wrstarczy. Innym sposobem jest funkcja addshlashes. Dodaja one przed cudzygłosami i apostrofami shlshe przez co Uniemozliwiają SQL Injecton. Dlaczego .? To pytanie zadaj sobie sam po przeczytaniu co to wgl jest i na czym polega ten atak

Słyszałem też takie opinie, że od mysql_real_escape_string() lepsza będzie parametryzacja zapytań SQL. To by mogło znaczyć, że funkcja mysql_real_escape_string() w pełni nie zabezpiecza przed atakiem SQL Injection. Pytanie, dlaczego?

Na stronki i serwisy jakie my tworzymy w zupelnosci westarczą takie zabezpieczenia jako, ze nie będą chyba na nią się włamywac hakerzy z anonymous. Bez przesady.

Nie. Używaj PDO kiedy tylko to możliwe, mysql_ to stary wynalazek.
Dlaczego mysql_real_escape_string() nie zabezpiecza w 100%? Bo może trafić się dziura w PHP, co kompletnie omijamy używając podpinania parametrów (baza wie, co jest zapytaniem, a co zmienną).

Ja przeciw SQL Injection używam prostej funkcji

[PHP] pobierz, plaintext 
function safe($msg) {
	$msg = str_replace("'", "'", $msg);
	$msg = str_replace("--", "--", $msg);
	return $msg;
}
[PHP] pobierz, plaintext 

Czy to jest złe?

A co to ma niby robić?

Masz rację - w PDO byłoby najlepiej, tyle tylko, że ja do tej pory na swojej stronie pisałem wszystko w czystym MySQL i musiałbym wszystkie zapytania przerobić.

A może gdyby zastosować dwie funkcje:

[PHP] pobierz, plaintext 
$zmienna = strtolower(mysql_real_escape_string($zmienna);
$zmienna = ereg_replace("[^ 0-9a-zA-Z]", " ", $zmienna);
[PHP] pobierz, plaintext 

Wówczas funkcja ereg_replace() usunęłaby wszystkie niepożądane znaki i po sprawie. Czy też tylko tak mi się wydaje i takie rozwiązanie też nie gwarantuje pełnej ochrony przed SQL Injection?

Jak się nie myle to w PHP 5.3 już nawet nie ma ereg.

Temat był już poruszany na forum wiele razy. Proszę poszukać. Zamykam.