Akina

Столбец 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 из подзапроса, само собой, убрать - но, возможно, добавить в объединённом запросе.

На уровне СУБД я бы не заморачивался и использовал разреженную таблицу. Т.е. таблица содержит поля, необходимые для объекта любого типа, но заполнены только те, что относятся к текущему типу, а остальные NULL.

Но вот насколько это реализуемо в Laravel - даже предсказать не берусь...

with cte (cnt) as (
  select count(*)
  from test_sender 
  where statuse='crash'
  )
delete 
  from test_sender 
  using cte
  where cte.cnt = 0;

Во-первых, практически все версии SQL Server обратно совместимы. Т.е. всё, что было в предыдущей версии, поддерживается последующей. Если какие-то фичи удалены или изменены - это явно описано в соответствующем документе (который What's new).

Во-вторых, поддерживаемые фичи определяются не только версией сервера, но и уровнем совместимости БД (compatibility level). Если уровень совместимости не поддерживал фичу - она не будет использоваться, даже если версия сервера позволяет. А если фича изменила поведение - её поведение будет определяться именно уровнем совместимости БД, а не версией СУБД. Любая версия сервера поддерживает определённый диапазон уровней совместимости - а потому изменение версии на 1-2 поколения вполне может производиться без длительного перелопачивания БД в новый формат (правда, и новые фичи могут быть недоступны).

Выполняем SELECT .. INTO OUTFILE, полученный CSV прекрасно читается в Excel. Т.е. PHP выполняет указанный запрос, а потом, если надо, организует перемещение полученного CSV в нужное место.