Twist

1) делаем адаптер PSR-7 (или HttpKernel) к вашему движку
2) делаем приложеньку на симфони
3) ставим мидлвэр который будет разруливать на какое приложение какие запросы кидать. Это можно разруливать и через nginx но как-то не круто.
4) когда начинаем пилить функционал на симфони и нужно что-то реюзать из старой кодобазы, стараемся отделить то что мы хотим заюзать от старой инфраструктуры (можно скажем сервис-декоратор запилить для старого движка) и регистрируем его в DI
5) постепенно переносим код, модель можно оставить старую если это возможно.

По сути основная сложность отделить модель от инфраструктуры движка и почистить сервисный слой.

А поле `phone` случаем не текстового типа? Если да, то сравнение должно быть с текстом, иначе включается приведение типа для поля и индекс не работает.
SELECT `name` FROM `phones` WHERE `phone` = '500'

С точки зрения производительности - без разницы, так как второй вариант эквивалентен циклу. Но сами понимаете что первый вариант лучше. Если вас парит производительность - то бинарный поиск. Но ни в коем случае не тот ад что вы привели. Быстрее всего поиск производить по хэш-мэпе, так как там сложность выборки всегда O(1).

Вообще как, для большинства языков, в том числе для интерпритируемых, развертка цикла дает прирост производительности. За счет чего происходит ускорение? А за счет того что все эти инструкции внутри цикла независимы друг от друга, у нас нет конфликтов по записи (и не может быть) и посему процессор спокойно так паралелит выполнение инструкций. Это удобно когда надо посчитать какой-нибудь длинный массив (например добавить на картинку яркости).

Пример. Возьмем массив на 1 000 000 чисел, и попробуем сделать его копию, с увеличенным в два раза значением:

var data = range(1000000);
var result = range(1000000);
// обычный вариант
for(var i = 0;i<1000000;i++) {
    result[i] = data[i] * 2;
}

// развертка цикла
for(var i = 0;i<1000000;i+=4) {
    result[i] = data[i] * 2;
    result[i+1] = data[i+1] * 2;
    result[i+2] = data[i+2] * 2;
    result[i+3] = data[i+3] * 2;
}

jsperf.com/loop-unroll-simple

На этом примере уже видно что развертка работает, хоть и прирост производительности не такой большой. Оптимизирующий компилятор JS-а и там умеет это делать.

В вашем же случае у вас есть условия, которые уже вызывают ограничения по тому насколько что можно паралелить (посути при условиях вообще ничего нельзя паралелить), так что за счет развертки цикла профита не будет никак.

Вы должны понимать зачем вообще нужны паттерны. Со временем вы можете и без книг придти к каким-то типовым решениями и т.д. То есть вы можете как-нибудь взять туже "банду четырех" и так вот... смотришь свой код и "а, так вот как это называется".

Например почти каждый javascript разработчик писал что-то в духе...

var api = (function() {
    // какие-то приватные вещи, к которым не стоит давать доступ из вне
    // что бы все было чистенько
    var privateVars =  {};
 
    // публичный метод
    return function () {
         
    }
}();

Но сказать что это "шаблон модуль" могут не все. В случае с CommonJS оно происходит автоматически, но суть остается той же. Думаю добрая половина даже не знают что все это ради инкапсуляции.

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

p.s. пользуюсь постоянно, в контексте Angular реализую даже сервисный слой, что бы вся бизнес логика была вне контроллера и последний использовался для отделения бизнес логики от логики представления.

Проблема простая - JS однопоточный. Более того, он работает в том же потоке, в котором и UI обрабатывается. То есть если вы залочили выполнение перебором - то печаль беда.

Варианты - самый наилучший - вынести тяжелую задачу в WebWorker-ы. Их для этого и придумали.

Другой вариант, если вам важна поддержка старых браузеров - делать паузы через каждые N операций. То есть у вас скажем массив с миллионом айтемов. Можно попробовать все делать асинхронно через setTimeout, что разгрузит event loop и позволит в перерывах UI-ке реагировать. И да это кастыль.

в курсе сюрпризов JavaScript относительно замыкание внутри closures.

Если для вас это все еще сюрпризы - рекомендую перештудировать какой-нибудь туториал или документацию. В JS все как-будто асинхронно, на самом деле там просто есть event loop.

Давайте разберемся на примере:

for(var i = 0; i < 10; i++) {
    setTimeout(function() {
        console.log(i);
    }, 1000);
}

Что у нас тут будет происходить. Мы берем цикл и 10 раз создаем отложенный вызов. Что при этом происходит... давайте представим себе что в JS все разбито на кадры. Цикл - один кадр, и пока он не отработает, какой бы он длинный не был - новый кадр так же не отработает. setTimeout не просто выполняет код с задержкой, через 1000 милисекунд в event loop будет добавлен очередной кадр. И любой "асинхронный" вызов так же просто добавляет кадр в event loop. Внутри же event loop все выполняется синхронно и по порядку.

Так вот, на момент, когда закончит выполнение кадр с циклом, значение i уже будет установлено в 9. А как мы выяснили ранее, JS ничего более не будет выполнять до этого момента. Посему отложенный код выведет нам одно и то же значение так как все они ссылаются на одну и ту же переменную.

Теперь, что происходит тут:

for(var i = 0; i < 10; i++) {
    (function(e) {
        setTimeout(function() {
            console.log(e);
        }, 1000);
    })(i);
}

Да собственно то же самое. Только за счет того что мы при публикации setTimeout используем замыкание и передаем i в качестве аргумента, срабатывает механизм называемый copy-on-write. То есть в замыкании не i а его копия (когда цикл перезаписывает значение i - все кто ссылался на это значение не по ссылке, копируют себе переменную, для простоты можно просто думать что каждый раз когда вы передаете что-то не по ссылке, происходит копирование).

Так как у каждого кадра, выполняемого в setTimeout есть своя копия i с нужным значением - все будет хорошо.