В настоящее время все вызовы данных MySQL / API обрабатываются удаленным кластером БД (т.е. сетевая задержка является фактором общего времени выполнения скрипта).
Чтобы сократить время выполнения в этом контексте, было бы разумно запускать локальный экземпляр MySQL на каждом сервере приложений для обработки вызовов API mysql_real_escape_string? Кто-нибудь когда-нибудь делал это?
Вы будете выполнять вызовы процессов через TCP-соединение, даже если это на localhost. Кроме того, вы будете использовать дополнительную память для процесса mysql и усложните свой код.
Лучшим методом было бы найти функцию, которая дублирует функциональность mysql_real_escape_string без использования mysql. Вы должны убедиться, что эта функция работает точно так же, как mysql_real_escape_string, иначе вы можете открыть для себя проблемы с безопасностью.
Я также хотел бы спросить, следует ли вам пересмотреть свой дизайн, если ваш скрипт делает так много вызовов экранирования строк, что это становится значимым. Как вы обнаружили, что проблема в этих вызовах? Вы профилировали свой код? Если вы этого не сделали, вы вполне могли лаять не на то дерево.
То, что вы думаете, что хотите делать, не то, что вы хотите делать.
Звонок в mysql_real_escape_string
на самом деле ничего не отправляет на сервер (это можно подтвердить, посмотрев на tcpdump
вывод). Все, что для этого вызова требует текущего соединения, - это определить используемый набор символов (и, следовательно, то, что может потребоваться цитировать).
Бегом mysql_real_escape_string
на чем-либо, кроме вашей реальной, живой, актуальной базы данных, вы не улучшаете производительность вообще, и вы рискуете, что конфигурация подключения изменится, что приведет к всевозможным потенциальным рискам.
У меня никогда не было необходимости в этом, но это кажется вполне разумным поступком.
Я был бы очень осторожен, чтобы ваши локальные версии и конфигурация mysqld совпадали друг с другом, а также с реальным сервером, поскольку несоответствие может вызвать очень интересные проблемы.