Akina

Если речь об автоинкрементном поле-первичном ключе, то забудь про сию хотелку, и чем скорее, тем лучше.

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

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

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

Столбец name из кодировки utf8mb3_general_ci в utfmb4_general_ci

Нужно потому что, в некоторых записях присутствуют некорректные символы.

Это безнадёжное занятие - данные УЖЕ повреждены.

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

Но в описанном случае можно выполнить изменение кодировки напрямую - UTF8MB3 есть подмножество UTF8MB4, и при смене кодировки опасности ошибки невалидного значения нет. DEMO fiddle. Впрочем, некорректные символы никуда не денутся.

===========================

Столбец name из кодировки utf8mb3_general_ci в utfmb4_general_ci

Это - не кодировки. Это COLLATION - набор правил сортировки символов.

SELECT CASE WHEN [column] IS NULL
            THEN 'sale'
            WHEN CHARINDEX([column], '.') > 0
            THEN LEFT([column], CHARINDEX([column], '.') - 1)
            ELSE [column] 
            END AS [column] 
FROM source_table;

как есть 2-я таблица с такимеже значениями только без .0 и без NULL . А мне в дальнейшем нужно сравнить эти 2 таблицы

Соответственно

SELECT *
FROM table1
JOIN table2 ON table1.[column] = CASE WHEN table2.[column] IS NULL
                                      THEN 'sale'
                                      WHEN CHARINDEX(table2.[column], '.') > 0
                                      THEN LEFT(table2.[column], CHARINDEX(table2.[column], '.') - 1)
                                      ELSE table2.[column] 
                                      END;

Про IP показывается его провайдер и организация.

Эта информация интерпретируется приблизительно такой фразой: "На текущий момент этот IP адрес дали подержать вон той организации".

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

Можно ли использовать коммутатор для соединения интернета, роутера и видео.

Если между местом планируемой установки коммутатора и микротиком есть (или можно проложить) два кабеля, а коммутатор управляемый - да, можно. Впрочем, в этом случае коммутатор как бы и не нужен.

Если кабель только один, предлагаю переместить микротик к точке входа оптики, а на его место поставить коммутатор - тогда он может быть и неуправляемый.

Если кабель один, а микротик неперемещаемый, то теоретически можно по одному кабелю пустить 2 соединения (скорость будет не более 100 мегабит) - но настоятельно не советую.

-- ...
CASE WHEN Rx <  10 THEN SET Rx= 10, Rz=Rz+1;
     WHEN Rx <  50 THEN SET Rx= 50, Rz=Rz+2;
     WHEN Rx < 100 THEN SET Rx=100, Rz=Rz+3;
     WHEN Rx < 150 THEN SET Rx=150, Rz=Rz+4;
     WHEN Rx < 200 THEN SET Rx=200, Rz=Rz+5;
     ELSE LOOP 
          END LOOP;
END CASE;
-- ...

Да тупо проверить все... DEMO fiddle (ищется строго одна единица в поле на всю таблицу). Возвращается имя первой по списку колонки, которая соответствует заданному критерию, либо 'none', если ни одна колонка не соответствует.

SELECT CASE WHEN SUM(CASE WHEN col1 = 1 THEN 1 END) = 1 THEN 'col1'
            WHEN SUM(CASE WHEN col2 = 1 THEN 1 END) = 1 THEN 'col2'
            WHEN SUM(CASE WHEN col3 = 1 THEN 1 END) = 1 THEN 'col3'
            ELSE 'none'
            END where_only_one_1
FROM test;

SELECT 
  SQL_CALC_FOUND_ROWS wp_posts.ID
FROM 
...
GROUP BY 
  wp_posts.ID
ORDER BY 
  MAX(bar_terms.term_id = 30) DESC -- , wp_posts.ID
...

Вторичную сортировку раскомментировать (и, возможно, отредактировать), если bar_terms.term_id = 30 может соответствовать более одного wp_posts.ID

WAN-интерфейс роутера может либо получать настройки по DHCP, либо настройки могут назначаться статически.

Касательно роутера, подключенного к провайдеру, всё очевидно. Провайдер желает DHCP - так и оставь.

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

Такая настройка позволит не выяснять каждый раз, какой IP присвоен роутеру, если потребуется подключиться к его административному интерфейсу со стороны WAN. Если для доступа к узлам сетей за вторичными роутерами используется port mapping или DMZ - не будет чехарды с адресом, можно будет использовать статические ссылки. Ну и ещё куча ситуаций, когда проблем со статическими адресами меньше, чем с динамическими. Да и правила доступа писать проще - как на основном роутере, так и на клиентских узлах его сети.

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

SELECT *
FROM ( запрос1 ) AS subquery1
JOIN ( запрос2 ) AS subquery2 USING (departments)

ORDER BY из подзапроса, само собой, убрать - но, возможно, добавить в объединённом запросе.