Akina

Будет ли разница в результате между двумя вариантами

Да. См. fiddle

CREATE TABLE a SELECT 'a' x UNION SELECT 'b';
CREATE TABLE b SELECT 'a' x UNION SELECT 'c';
CREATE TABLE c SELECT 'b' x UNION SELECT 'c';

select a.*, b.*, c.*
from a left join b using (x) left join c using (x)

x	x	x
a	a	null
b	null	b

select a.*, b.*, c.*
from a left join (b left join c using (x))  using (x)

x	x	x
a	a	null
b	null	null

Есть ли какое-то правило, которое определяет порядок связывания таблиц?

Да. Порядок связывания определяется требуемой логикой.

PS. В качестве самостоятельного задания - найди истинную причину разницы.

PPS. При абсолютной эквивалентности обеих форм - разницы нет.

NOTIFY
LISTEN
Хотя как по мне, один запрос в 10 минут - это ни о чём.

Я бы

1. Убрал неуправляемый коммутатор и соединил серверы напрямую (необязательно, но зачем лишняя фигня в сети?)
   
2. Поставил на обоих серверах гигабитные интерфейсы в автополучение адреса
   
3. Отключил на 100-мегабитных картах NetBIOS over TCP/IP (хотя это уже зависит от того, какие ресурсы и через какие пространства имён нужны в сети)
   
4. Дождался бы самовыделения APIPA-адресов (169.254) на обоих серверах
   
5. Прописал перекрёстно полученные адреса и соответствующие им имена серверов в HOSTS и в LMHOSTS
   

Итоги:

1. Серверы доступны друг другу по имени
   
2. При обращении по имени связь будет устанавливаться через этот канал (через гигабитные карты), а не через 100-мегабитные карты
   
3. Гарантированно не будет пересечения по диапазону адресов с другими системами в сети
   

Я в упор не понимаю, зачем тут вообще маршрутизация.

Все интерфейсы 10G - NAS, компьютер и Mikrotik,- помещаем в одну подсеть.
Интерфейс 1G - компьютер и Mikrotik,- помещаем в другую подсеть.
Для исключения L3-петли в файрволе Микротика блокируем любой трафик от и на адрес 10G интерфейса компьютера.

На компе дефолтным шлюзом адрес 1G интерфейса Mikrotik.
На NAS дефолтным шлюзом адрес 10G интерфейса Mikrotik.

Микрот - с компьютером и NAS общается напрямую, ибо одна подсеть, а в Инет идёт через свой WAN.
NAS - с компьютером и Микротом общается напрямую, ибо одна подсеть, а в Инет идёт через Микрот.
Компьютер - с NAS и Микротом общается напрямую, ибо одна подсеть, а в Инет идёт через Микрот.

Т.е. никакие маршруты, кроме маршрутов по умолчанию, в системе вообще не требуются.

Хотя согласен с предыдущими ораторами - дополнительный 1G линк явно избыточен.

Keenetic / Руководство пользователя / Управление
Режим "Усилитель/Ретранслятор"

А уж может ли это конкретно ваша модель - смотрите на практике...

Обратите внимание. Режим ретранслятора и режим NAT-роутера - несовместимы.

Это верно или нет???

В общем случае нет. Точнее, зависит от настроек при установке/конфигурировании. ЕМНИП при использовании предопределённого профиля разработчика сервер настраивается только на использование socks/shared memory, соответственно сетевой интерфейс (даже локалхост) не слушается и внешние подключения невозможны.

Смотрите настройки. skip_networking, bind_address и т.п.

Server Option, System Variable, and Status Variabl...

столкнулся с ошибкой

ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'IDENTIFIED BY '123' WITH GRANT OPTION' at line 1

Позорище... вот что мешает читать не всякую срань в интернете, а официальную документацию, причём для именно той версии ПО, которая используется?

хотелось бы больше подробностей

Если коротко.

Из Инета можно обратиться только к "белому" адресу. На NAS - "серый" адрес. Значит, нужен посредник (NAT-роутер). На нём будет работать port forwarding.

Работает оно так. На роутере-посреднике два интерфейса - внешний белый и внутренний серый. Создаётся правило: "Если что-то пришло на внешний адрес на порт XXX, переслать это на внутренний адрес YYY на порт ZZZ". В соответствии с этим правилом клиент снаружи стучится на внешний белый адрес на порт XXX, роутер от своего имени шлёт этот пакет с внутреннего адреса на адрес YYY (NAS) порт ZZZ. То есть с точки зрения самого NAS к нему обращается не внешний клиент, а роутер. Он отвечает роутеру. Роутер по запомненным характеристикам соединения делает обратное преобразование и шлёт ответ NAS клиенту от своего имени.

Если внутренний сервис требует для работы более одного порта - для каждого будет создано своё правило преобразования.

Да, избавиться от снапшота в условиях нехватки места не получится. Необходимо любыми способами изыскать том минимум на 14Т свободного пространства на время выполнения операции слияния. Если нет такого накопителя - собрать несколько штук в страйп.

Если гипервизор не единственный, придётся на рабочем выполнить экспорт, потом перенести накопитель на другой, там импортировать по месту и затем сливать. Если же гипервизор единственный, или придётся собирать страйп, понадобится 18Т пространства (или два тома - 9 для экспорта и 14 для импорта и слияния), потому что нужно будет делать импорт с созданием нового идентификатора и, соответственно, с копированием.

К слову, все эти операции можно проводить и на примонтированной шаре. Только сетевушку желательно на 10Г, или это будет очень долго.

Конечно, не исключено, что слияние даст суммарно финальный том не 5+4=9, а меньше... но я бы на это не рассчитывал. А если в процессе кончится место, и слияние оборвётся по ошибке, то виртуалка, скорее всего, умрёт. Именно поэтому операцию следует выполнять на экспортированной и реимпортированной копии.

Есть и ещё вариант. Выполнить внутри виртуалки бэкап тома с данными на подключенный третий диск. А потом пересоздать рабочий диск и восстановить.

Либо подключить ещё один, пустой, образ, и внутри виртуалки собрать и синхронизировать софт-mirror, потом развалить, оставив только том-копию, убрать том-оригинал и мигрировать на его место копию. Тогда получится обойтись дополнительным томом на 9Г, но геморроя куда как больше. Зато плюс этого способа - он допускает выполнение всех операций без остановки виртуалки.

Пинг гарантированно увеличится. Но при полностью исправном, неперегруженном и правильно настроенном оборудовании зарегистрировать эту разницу не получится.

По смыслу происходящего во втором блоке кода - значение в поле SteamID таблицы qq_player_acc должно быть уникальным.

Соответственно два вопроса.

1. Объявлено ли указанное поле в структуре указанной таблицы уникальным? Если нет - то почему? Добавьте требование уникальности.

2. Что мешает выполнить обычный INSERT IGNORE или, если надо обновлять существующую запись введёнными значениями, то INSERT ODKU или REPLACE INTO?

PS. INSERT {table} .. WHERE EXISTS ( {table} ) - вообще-то недопустимый синтаксис.

мне необходимо удалить строку из одной таблицы и эту же строку добавить в другую таблицу.

В PostgreSQL это вообще элементарная операция. Можно удалить запись в CTE и вставить её во внешнем запросе, можно наоборот. То, как выполнять, определяется возможными зависимостями и интерференциями.

WITH cte AS (
    DELETE
    FROM table1
    WHERE {criteria}
    RETURNING *
)
INSERT 
INTO table2
SELECT *
FROM cte;

-- или 

WITH cte AS (
    INSERT 
    INTO table2
    SELECT *
    FROM table1
    WHERE {criteria}
    RETURNING id
)
DELETE
FROM table1
WHERE id IN (
    SELECT id
    FROM cte
);

Sample fiddle

Само собой, вместо звёзд может быть (даже правильнее сказать - должен быть) перечень определённых полей и выражений.

PS. Хотя намного разумнее оставить одну таблицу и выполнять "мягкое удаление". Внимательнейшим образом прочитайте ответ alexalexes. При очень большом количестве записей, влияющем на производительность, такую таблицу можно и секционировать.

Но таблиц стало много и неопределённо много.

Вижу два варианта.

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

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

Отдельно стоИт вариант, который является подвариантом первого, с той лишь особенностью, что тексты запросов абсолютно совпадают. В этом случае возможным решением может служить хранимая процедура, куда передаётся в виде параметров и имя таблицы, и значение критерия, а внутри выбирается либо строится с помощью CASE текст запроса, выполняемый потом динамическим SQL.
Поясню вариант "строится" - имя таблицы передаётся как параметр хранимой процедуры, там он сравнивается с набором предопределённых литералов, и уже этот предопределённый литерал, а не переданный параметр, участвует в построении текста запроса.

На строго в рамках PDO - полностью согласен с предыдущим оратором. Никак.

Первым делом в свойствах старого скопа корректируется время выделения адреса. Для стационарных узлов обычно по умолчанию ставится 5 или 7 дней. Первым делом меняем это время на 1 час. Это не сильно увеличит нагрузку на сеть. Ждём, пока все не перейдут на это время выделения. Затем, непосредственно перед переездом, ужимает это время до 5 минут. И через час начинаем собственно переезд. для чего просто (в зависимости от того, что умеет сервер) либо повышаем приоритет нового скопа относительно старого, либо просто отключаем старый. За час все перепрыгнут в новый скоп. После чего там можно поднять время выделения в новом скопе до старого значения в неделю, а старый вообще удалить.

Но это просто процесс перевода всех динамиков в новую подсеть. А чтобы всё работало, нужно ещё много предварительных телодвижений, которые обеспечат отсутствие сбоев в работе.

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

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

Отслеживать - нет.
Можно написать скрипт, который будет получать текущую таблицу (interface bridge host print либо interface ethernet switch host print) и сравнивать с предыдущей версией. По результатам сравнения сообщать. Период запуска, само собой, меньше времени жизни записи в кэше.
Хотя разумнее одним скриптом сливать в файл, а потом другим скриптом обрабатывать и кляузничать - но уже не так часто. Или вообще в БД писать, для истории...