Довольный Айтишникъ

Добрый день.
Имена полей возьмите в обратные кавычки, значения
`id` = '" . $pid1 . "'
Обработка данных перед записью в базу, htmlspecialchars() тут не место.

p.s. Не скрин добавлять надо, а не лениться копировать код и вставлять в сообщение, обрамляя соответствующими тегами.
На крайний случай, если код объёмный - воспользоваться сервисами, которые специально предназначены для размещения кода в сети.
Пример

Никак.
Это не позволяет стандарт.
Если вы такое сделаете, это уже будет не WiFI - т.е придется заново писать протокол, создавать железо, и.т.д.

То, как вы это себе представляете не реализуем через wifi, в рамках текущих стандартов (теоретически возможно, смотрите ниже).
Самый близкий вариант это multicast, но все-равно это не одностороннее общение.
И multicast поддерживают не все смартфоны и планшеты на аппаратном уровне, например, большая часть (не последних моделей) процессоров mtk для мобил, не поддерживают мультикаст на аппаратном уровне, тем более HD. И тот же HD multicast на программном уровне не все процессоры вытянут.

Если будете делать на мультикасте, то через wifi это будет работать плохо, не ставбильно, с рассыпанием картинки у клиента, и не будет вообще работать на части устройств. Это связано с реализацией протокола udp и с зоопарком устройств, которые не поддерживают multicast.

Единственный доступны и дешевый вариант, для лучшей совместимости, это hls. Но, тут нужно 2мб/с на клиента (отдельный поток на каждое устройство), то есть на 100 мб/с роутер (точку доступа), максимум 50 клиентов. На 1Гб/с - 500 клиентов, но тут уже вопрос потянет ли железо роутера (обычного) 500 клиентов (думаю больше 200 не вытянет).

Дальше помечтаем:
В теории, возможно сделать как вы себе это представили, но нужна собственная программно-аппаратная платформа. То есть, собственное передающее оборудование и собственное принимающее: Серверная часть с возможность раздачи по какой-то из частот wifi (тут уже можно любую частоту выбрать), и приемник типа маленького телевизора (которые вы будете раздавать клиентам на входе). Это не будет работать с смартфонами и с другими массовыми устройствами. Ну, и стоимость такой системы вместе с разработкой будет начинаться от 3000000$, хотя возможно заблуждаюсь и в эту сумму вам только проектирование на бумаге обойдется...

Разделить на мелкие независимые части (типа микросервисов). Изолировано-самодостаточные.

ПС:
Навык декомпозиции - это самый важный навык для программиста, разрабатывающего сложные системы.

обучиться серверному администрированию на Linux

Лучше начать с обучающего видео на тему "как пользоваться гуглом".

никак

Приветствую.

1) Лучше заводить отдельные поля под каждое свойство. Сейчас нет необходимости искать - в будущем может появится такое желание. Переделывать всегда сложнее. Лучше сразу сделать "по уму".
2) Ощутимой разницы в скорости работы не будет, не зависимо от того как будете хранить. Но как уже сказал, лучше хранить отдельно для более удобного доступа к хранимой информации.

Если очень грубо, то посмотрите на рисунок:

В вашем кабеле идет сигнал с третьего графика, полученный сложением сигналов с первых двух графиков.
Пропустив третий сигнал через фильтр, можно получить исходные два.
В реальности - сигналов может быть больше чем два, каждый из которых может быть модулирован по частоте, амплитуде, фазе.
Однако с одного спутника 10 каналов вполне могут идти на одной частоте.
Возьмите для примера эфирный DVB-T2 сигнал - на каждой частоте (полосе частот) идет сразу по 10 цифровых каналов - примерно так же как вы можете по одному провайдеру качать сразу 10 торрентов.

Моё личное imho - пока у Вас нет какой то значимой нагрузки (и тонко-настраиваемой системы профилирования) - query cache лучше отключить вообще.

Поясню зачем: включив cache Вы наблюдаете прирост производительности на nn% запросов, но вместе с тем теряете возможность оперативно обнаруживать не оптимизированные запросы.
С отключенным кешом вы СРАЗУ видите просадку производительности, сразу применяете меры (добавляете индексы, денормализацию, просто переписываете запросы etc).

слово advertising перевести или сами догадаетесь :) Срабатывает какой-то блокировщик рекламы. Давать сайтам такие имена - верный путь в банлист :)
Скорее всего срабатывать будет и на avdert и даже на adv, поскольку это наиболее распространенные сокращения.

Это два противоположных хранилища. Mysql подразумевает четкую структуру и однообразие данных в первую очередь, в то время как монго вообще не следит по сути за структурой данных, хотите массив? пожалуйста, хотите однородные данные? пожалуйста!
В mysql вы создаете структуру данных и затем вам придется следовать ей, хотите вы этого или нет, бд сама решит можно писать данные или они не подходят, в монге вам придется все контролировать руками, может быть такое что вместо инфы пользователя вам придет структура лишь с одним полем, если вы что-то пропустите при записи, и это нормально.

По этому выбирать нужно сугубо исходя из нужд.
У вас есть список полей? Нужна строгость данных? Мускуль.
У вас разнородные данные? весь профиль состоит из многих полей, некоторых может вообще не быть и это норма? Монго.

Никакой. Всё зависит от конкретной ситуации, а безопасность определяется организацией хранения.

Нужна библиотека для создания видео из изображений, например ffmpeg, ее можно "прикрутить" к любому серверному языку, например PHP, а вообще-то, если обратился заказчик и деньги платит вам а не пополам со мной, то и спрашивать надо не у меня, а у вас!

Перефразирую ваш вопрос: на каком уровне нужно знать про трубопровод, если хочешь построить дом?
На достаточном для решения это задачи.

А так как я использую оболочку phpmyadmin то мне же не нужно знать много команд SQL?

wat? При чем тут phpmyadmin?

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

Вы пытаетесь написать книгу, не зная слов.

я пытался писать, есть рабочий прототип, работает в связке с node. js.
Тема мультиплеера такого характера очень сложная. Даже при маленьком пинге присутствовали дерганья, долго не мог понять почему, пока гдето статью не вычитал про этот "глюк" (там типа про то что сервер должен как бы жить в будущем и просчитывать уже все наперед и т. д.)
Советую начать с подробнейшей теории проблем мультиплеера в плане клиент-серверного взаимодействия, там очень много нюансов и техник, статей в инете предостаточно. Эти знания помогут обойти (частично) проблемы fps.

p. s. Исходники свои могу дать, пишите в личку.