Akina

Они идут я так понял для каждого пк со своим кодом (onedrive Standate Task-S-1-5-21-3362628...) и у каждого ПК свой код и они не дублируются.

schtasks /query /fo list | find "OneDrive"
Само собой от имени администратора.
А дальше очевидно - FOR /F и SCHTASKS /Delete.

Вот какая связь между VLAN и адресом внутреннего интерфейса коммутатора? Никакой, от слова вообще. Данный адрес - именно адрес внутреннего интерфейса коммутатора. Запись просто утверждает, что внутренний интерфейс коммутатора доступен по указанному адресу в указанном VLAN. Т.е. если, находясь в данном VLAN, узел обратится по данному адресу - то он будет обращаться к коммутатору. Ну захотелось человеку, который настраивал сетку, присвоить коммутаторам адреса из разных подсетей, но в одном VLAN - имеет право. Неясно, правда, какой с того профит, но проблем с этого уж точно никаких. У меня в сети, например, для коммутаторов выделены аж три разные подсети в трёх разных management VLAN, различающихся по назначению, и некоторые из коммутаторов имеют адреса в двух, а магистральные даже во всех трёх, VLAN.

Я понимаю, если бы что-то бы интерферировало - скажем, один и тот же адрес, или один адрес был бродкастом подсети второго адреса. Тогда бы был предмет для беспокойства.

Если с такой настройки корячит - ну перенастрой.

SELECT SUM(some), SUM(some * noone)
FROM table

?

SELECT ebids.*
     , SUM(comment_system.itemtype='qqq') AS has_qqq_comment 
     , SUM(comment_system.itemtype='www') AS has_www_comment 
     , SUM(comment_system.itemtype='eee') AS has_eee_comment 
FROM ebids
JOIN comment_system ON comment_system.item_id = ebids.id
WHERE ebids.status != 'auto'
GROUP BY ebids.id
ORDER BY ebids.id DESC
LIMIT 0, 100

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

Определитесь. Или в приоритете скорость, или нагрузка. Но не то и другое одновременно.

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

Если приоритетна нагрузка - то поиск следует производить средствами СУБД.

Пример.

На стороне PHP имеется массив строк:

aaa
bbb
ccc

Необходимо записать его в таблицу. Причём уложиться в один запрос. Длина списка, понятно, не фиксирована.

Первое - объединяем/сериализуем этот массив в одно значение. Допустим, выбрали JSON массив. То есть ["aaa", "bbb", "ccc"]
И именно этот JSON мы передадим в запрос.

Далее на стороне MySQL надо разобрать JSON на элементы и вставить в таблицу. Это делается одним запросом.

INSERT INTO destination_table (single_value)
SELECT single_value
FROM JSON_TABLE( ? ,
                 '$[*]' COLUMNS ( single_value VARCHAR(255) PATH '$' )) jsontable;

И... а, собственно, всё.

Осталось только убедиться, что размер строкового представления данных не превышает установленный в MySQL размер входящего пакета, и, если превышает, то соответствующим образом подрихтовать сессионную переменную max_allowed_packet. Впрочем, дефолтно там 67108864 байтов, это порядка 1480 байтов на элемент - должно хватить.

как сделать один компьютер в сети Б доступным из интернета?

Именно из Интернета? или из сетки 192.168.1.0/24?

У меня только такая идея: вставить в нужный компьютер в сети Б(которая без интернета) вторую сетевую карту и подключить её к сети А(с интернетом), выдать адрес из диапазона 192.168.1.1-254, дальше как-нибудь настроить одновременную работу обеих карт, метрики там, всё такое.

Ну правильная идея. Причём карты будут работать одновременно, и ничего настраивать не нужно. Ведь, как я понимаю, в 198.148.46.0/24 ни дефолтного шлюза, ни статических маршрутов нет.

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

Гибридные, транковые порты на коммутаторах, это всё порты для коммутаторов? Не для конечных устройств?

В общем - нет. Как правило - да.

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

подружить 2 VLAN (2 сети) на одном конечном устройстве?

Так вланы, и в них сети, разные, или разные сети в одном влане?

При всей неизбывной глупости такого решения:

INSERT INTO main (table1_id, table2_id) 
WITH 
cte1 AS ( SELECT id, ROW_NUMBER() OVER (ORDER BY id) rn FROM table1 ),
cte2 AS ( SELECT id, ROW_NUMBER() OVER (ORDER BY id) rn FROM table2 )
SELECT cte1.ID, cte2.ID
FROM cte1
JOIN cte2 USING (rn);

pfSense
Интерфейс WAN, который должен смотреть в Инет - VMNet8 (NAT), адрес по DHCP, либо VMNet0 (direct), статический адрес.
Интерфейс LAN - любой внутренний VMNet (например, VMNet2), статический адрес.

Cервер Metasploitable, интерфейс в этом сегменте - тот же VMNet (VMNet2), адрес статический.
Клиенты Ubuntu и Kali - тот же VMNet, адреса статические либо динамические, дефолт-шлюзом LAN-адрес pfSense. Статический маршрут в подсеть частного клиента Ubuntu через адрес Metasploitable в этом сегменте.

Второй интерфейс сервера Metasploitable - в другой внутренний VMNet (скажем, VMNet3), статический адрес из другой подсети.
Клиент Ubuntu за ним - к тому же VMNet (VMNet3), адрес статика или динамика. Дефолтным шлюзом адрес Metasploitable из этого сегмента.

Пинг, вернее, ответ на него - самая низкоприоритетная из всех задач коммутатора. Так что если он занят чем-то более важным, то просто не ответит. Бывает, что даже на пинги устройству, подключенному непосредственно к коммутатору, получают только половину ответов. Это нормально.
А другие пингуемые нагружены, видимо, меньше, или производительность у них больше - вот потерь и нет.

WITH
cte AS (
  SELECT *, COALESCE(LEAD(id) OVER (ORDER BY id),
                     MIN(id) OVER ()) next_row_id
  FROM comments
)
SELECT * 
FROM cte