Vitsliputsli

Постройте индекс btree для research_uuid.

могу неделями почти не спать и работать, при этом выдавать вроде бы продуктивность, но делать все на редкость тупо.

Когда вы не спите, ваш мозг перестает работать нормально и способен только на тупую работу. Именно поэтому он выдает поощрения, когда вы позволяете ему этим заниматься.

Как решить эти проблемы?

Больше отдыхать.

Контроллер, представление, модель - это элементы MVC, к ООП отношения не имеют.
Контроллер получает от пользователя запрос в определенном виде (запрос браузера, обращение к API, команда, все это разные группы контроллеров). Распарсив запрос передает его в модель для обработки.
Модель содержит бизнес-логику, т.е. по-сути то, что должно делать ваше приложение, без привязки к способам обращения пользователей и способам вывода. Возможно будут вызываться модели работающие с БД, а может и не будут, это неважно, не превозносите БД как сверхсущность, это обычный инструмент, один из множества.
Далее модель передает подготовленные для вывода данные в контроллер (в классической MVC сразу в представление), и контроллер передает их в нужное представление.
Вот и все, простая схема, которая позволит отделить мух от котлет, создавать API, видоизменять вывод, не трогая основную логику. А работа с БД, совсем другой вопрос.

Вы хотите странного. Не нравится pretty url, не используйте его, в оригинальном виде контроллер/экшен задаются параметром в адресе. Но зачем изобретать свой роутинг при использовании фреймворка?
И, обычно, когда говорят о rest, подразумевают одну из моделей Ричардсона, т.е. использование http-методов, в данном случае post или put.

И как бы все правильно написали в ответах. Но я каких только не видел безопасников, и по образованию, и по навыкам, поэтому некий флер и образ элитарности сформированный ответами вызывает усмешку. Просто, как и в любой профессии раздолбаев предостаточно.
Но автору все равно не стоит надеяться. Лучше сходите на собеседования и большинство вопросов отпадет, там и узнаете, чего вы стоите и на что можно рассчитывать. И лучшее, что вы можете сделать сейчас - это почитать, как составлять резюме и вести себя на интервью.

А какова разница? В цифрах.
Post обычно подразумевает отправку данных в теле, а get в адресе. В принципе на размер запроса это не особо влияло бы, но обычно данные шлют в формате form-data, и используют громадные разделители, поэтому запрос в лёгкую может вырасти раза в 2 по сравнению с get. Второй момент, на другой стороне это все нужно ещё распарсить. Но, конечно, совсем не обязательно данные передавать как form-data.
Т.е. теоретически - да, post медленней, практически - не думаю, что эта разница сколько-нибудь существенна. И как правильно заметили, адрес не предназначен для передачи конфиденциальных данных, т.к. попадает в логи.

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

Перепишите ваши условия так, чтобы не требовалось их прерывать на полпути. То что вы хотите очень сильно ухудшает читаемость, поэтому оператор goto крайне не рекомендуют к использованию, а это тоже самое.

Ratchet

Если нет нужды писать эксепшен для не float в запросе, тогда преобразуйте так:
$var = (float)strtr($input, ',', '.');
Если нужно, то конвертните обратно в string и сравните.
Имхо, это нагляднее и очевиднее, чем регулярка.

Если у вас "четкое" разделение на фронт и бэк, значит, по сути у вас 2 технических проекта, взаимодействующих между собой. И у них не может быть одной и той же задачи, т.к. делают они разное.
Судя по остальному тексту, вы не декомпозируете задачи, отсюда и такие вопросы. Тогда, у вас 2 варианта, начать декомпозировать задачи на отдельные подзадачи, где будет отдельный исполнитель, можно прикинуть трудозатраты, указывать зависимости и т.п. К тому же, в redmine из коробки можно строить древовидную структуру задач. Тогда у вас появится хоть какой-то контроль и вы сможете планировать. Либо не заморачиваться, т.к. 1 или 2 задачи на ситуацию не повлияют, и пусть разработчики сами делят задачи и планируют.

А что вы теряете? Боитесь, что возьмут, а вы не вытяните? Не парьтесь за них, придите и расскажите, что знаете. Не нужно говорить, что ничего не знаете, говорите о том, что реально делали, пусть и несложные вещи. Пусть они уже решают сами, быть может им и нужен начинающий специалист, которого они подготовят под себя, и который, быть может, не требует сотни денег. В любом случае, это бесценный опыт для вас.

PDO лучше только в плане универсальности (драйвера, а не вашей работы, это не ORM), mysqli как специализированный драйвер к примеру более производителен (несущественно). Защиту от sql инъекций вам дадут только подготовленные запросы, где вы их будете применять, в pdo или mysqli, без разницы.
Но все современные orm и просто обертки пишутся для PDO. Про mysqli забыли. Нативная работа с mysqli ужасна, т.к. очень устарела, эксепшены отсутствуют, да и порой просто не очень адекватна.

Он цепляет файл по пути из include_path. Почему раньше работало можете знать только вы, может include_path был другой, может HTML/Common.php там существовал, может иная комбинация.

select
 count(port) ports_count,
 count(case when abonent!='' then 1 else null end) abonents_count
from ports

Считает кол-во строк port и abonent, исключая null и пустую строку для abonent. Если null и пустая строка одно и тоже, то case не нужен.

1) в /proc обычно монтируют виртуальную файловую систему дающую доступ к различной информации и ресурсам, предоставляемым ядром.
2) можно, при наличии прав, смотрите устройства tty, или что-то вроде этого.
3) можете при наличии прав.
4) лимиты операционной системы и файловой системы не контролируют содержимое файлов. Но в зависимости от задачи, можно решить, например, с помощью pipe, или ротацией.

Как уже советовали git-flow (например от Винсента Дрейзена). У разработчиков есть право мержить в dev свои ветки, поэтому request не нужны (они хороши при запросах от удаленных разработчиков), из dev собираете и прогоняете тесты ежедневно (CI), затем из dev собираете релиз и кидаете его в master, это уже делает отдельный человек. На сервере (если речь про прод) git быть не должно, должен быть нормальный CD. И да, никаких доступов к боевым у разработчиков. В остальном верно описали.

Вы предлагаете проверять перед каждым созданием наличие такой записи?

У вас это и так происходит, иначе бы не было ошибки. Если вам действительно все равно на недобавившиеся строки, тогда скажите об этом СУБД, on conflict do nothing, или что-то в этом роде в зависимости от СУБД.
Но почему-то мне кажется, что ваши пользователи не согласятся с такой логикой.

Включите вывод ошибок или загляните в логи. У вас в 8 строке вывод, поэтому отправка заголовка и не работает.