Melkij

В запросе этой таблицы нет. Парсер не знает, к чему вы пытаетесь обратиться по имени personality.

Channel bonding, EtherChannel, link aggregation, LACP 802.3ad. Разные названия, а суть одна. Есть разные схемы работы, грабли и поддержка железом.
Лучше LACP, но его должен уметь коммутатор.

Вот этот странный колхоз - это вы кастрированный iconv в cp1251 сделать пытаетесь? Вроде по поведению похоже.

Страница вывода ленты у меня в UTF-8.

И simplexml всегда в UTF8. Что вы тут пытаетесь сделать с бедным юникодом я не очень понимаю.

1. Поле типа varchar всегда занимает минимум 1 или 2 байта на диске, в зависимости от максимальной длины этого поля. В индексах и при операциях в памяти разворачивается до своего максимального размера (подобно char). Больше данных -> меньше данных влезает в кеш -> больше нагрузка на диски -> медленнее работа.
На таком смешном размере таблицы не имеет никакой роли. Если это уже потребовалось оптимизировать - огромные грабли в другом месте.
2. Да, на диске varchar хранит только то, что положили в поле. Плюс 1 или 2 байта оверхеда на хранению длины записанной строки.

Нет, отдельный индекс по id_product использоваться не будет. Зачем брать индекс, находить значения по нему и затем искать их по первичному ключу (в innodb кластеризация по первичному ключу же), если можно искать сразу по первичному ключу?
Вот если бы первичный индекс был id_shop & id_product - тогда да, индекс по id_product был бы полезен.

update table2 
join table1 using(user_id)
 set table2.unicnumber = table1.unicnumber 
where table1.accept = 1

?

А что, rucenter начал давать SSD?

Чем, по вашему мнению, вам поможет переход на другой язык, если примерно 99% времени вы находитесь в ожидании сетевой операции?

В простом случае используйте curl_multi.

InnoDB все запросы выполняет только в транзакции. Если открытой транзакции не было, то этот запрос неявно оборачивается в транзакцию.
Вот только сами по себе транзакции не помогут, надо ещё правильно ими пользоваться. Тут я бы хотел дополнительно обратить внимание Андрей:
Попробуйте в двух терминалах написать:
сначала begin; в обоих
потом select из таблички. Значения одинаковые, правда?
потом update этой же таблички, сделайте set fieldname = разные значения в терминалах. Второй терминал запрос принял, но не вернул управление, верно?
потом commit; в первом терминале. update из второго терминала сразу же ответил OK.
Теперь сделайте commit во втором терминале и посмотрите, что произошло с данными. Это то, на что вы рассчитывали? Или всё-таки не совсем?

N пользователей запрашивают услугу одновременно, корректно ли произойдет списание средств?

Нет, некорректно, если только вы не в одной транзакции и не читаете баланс специально с select .. for update.
Потому что для выполнения действия $this->balance -= $sum; у вас уже должен быть известен баланс, но это ещё не операция записи.
В итоге у вас было 1000 рублей.
Пришёл один клиент, прочитал баланс, хочет списать 200 рублей. Обновил циферку в PHP, никто ему не мешает.
Пришёл второй клиент, прочитал баланс, хочет списать 100 рублей. Обновил циферку в PHP, никто ему тоже не мешает.
И на шаге save оба отправили запросы на update: один клиент считает, что на балансе осталось 800 рублей, второй - что 900.
Сколько запишется на баланс? 800 или 900, как повезёт. Правильно ли это? Сколько должно было быть? 700 ведь.
Потому что клиенты не мешали друг другу обновлять циферку в PHP.

Как же заставить клиентов не делать глупости?
В простом случае:
update tablename set balance = balance - :amount where balance >= :amount and user_id=:uid
И на приложении проверять affected_rows. Если строка изменена - у пользователя достаточно денег, платёж прошёл. Если изменённых строк нет - вероятно, у пользователя нет столько денег. СУБД разберётся с очерёдностью исполнения и в результате на балансе будет правильная сумма, сколько бы параллельных запросов ни пришло. И, что не менее важно - приложение ответит на все запросы корректно, кому денег хватило, а кому - уже нет.

В более сложных случаях - можно самому попросить СУБД взять блокировку на строку, о чём чуть ранее я уже заикался:
begin;
select balance from tablename where user_id=:uid for update; -- все параллельные транзакции будут выстраиваться в очередь здесь
/* произвольные запросы (в mysql кроме вызова хранимок, DDL - они делают неявный коммит). Среди этих запросов - обновляете баланс */
commit; -- только здесь эта транзакция освобождает блокировку select .. for update и с этой строкой начинает работать следующий запрос

Как вообще работать с деньгами и делать это правильно - Кирилл даёт правильное направление. Изучите, как это делает бухгалтерия, за многие десятилетия работы они придумали, как обходить много странных граблей.

insert into test2 (test_id, type)
select test.id, type_value from test1 
join (
select 1 as type_value
union all
select 2
) as types ON TRUE -- нужно декартово произведение
where not exists (select 1 from test2 where test2.test_id = test.id)

Если mysql древний, то, возможно, эффективнее будет test left join test2 on test2.test_id = test.id where test2.test_id is null