Vladson

И опять мифическая «защита»…

Проснитесь люди, от «SQL-inj» надо не защищаться, это не угроза. Наличие SQL-дыр это простой баг. Хотите избежать, не допускайте ошибок в коде.

Каким путём вы передаёте данные в запрос дело ваше, можно даже с помощью bin2hex
SELECT * FROM `table`
WHERE `word`=0x4841434b454420425920564c4144534f4e;
(хотя есть способы и проще и логичнее)
Главное поймите что данные и то что SQL сервер воспримет за данные, это разные вещи.

Но перестаньте называть это защитой, это не защита, а просто «код без бага».
(Защита подразумевает угрозу которая существует даже в случае грамотного, как в случае с DDOS это вполне нормальные пакеты, только их много.)

Полностью поддерживаю господина Elkaz, решения идеального не может быть в принципе.

Я лично рекомендовал бы ставить то с чем умеет управляться админ (не умеет ставить, а вообще, даже в критической ситуации когда всё идёт не так как должно быть...) Это самый важный фактор.

И да, многие движки требуют обязательно апачевский rewrite так что иногда выбора как такового и нет. Однако если выбор всё же есть, я бы предпочёл всё же варианты с nginx.

Была как-то задача переписать чат чтоб были минимальные тормоза (сервак был и так перегружен) я воспользовался APC (в БД закидывал только отправленные сообщения «для истории») в принципе могу посоветовать подобный подход…