У нас не будет работать - организация процесса взаимодействия сотрудников такое не потянет.
Там если нагрузка ниже определённого уровня (дежурное питание выключенного ПК или монитора), то ИБП сам выключается.
Сообщать пользователям (чем я регулярно занимаюсь) о том, что не стоит так делать, что надо смотреть на лампочки питания и работы жёсткого диска, и что только после их выключения можно выключать бесперебойник или удлинитель - не сильно помогает!
Оно так не работает.
доктрина из коробки не знает о существовании OVER()
Роутер микротик RB3011 раздает провайдера РТК. У данного роутера айпи 10.0.1.2
...
Затем к коммутатору CRS328 подключаются точки доступа hAP ac2 для раздачи вай фая клиентам.
Клиенты через вай фай получают айпи 10.0.2.*. Данные же клиенты должны видеть оборудование, подключенное к роутеру RB3011.
Есть пустая таблица, которая связанна с другой таблицей(не пустой) один к одному
как можно написать запрос, что бы заполнить данными пустую таблицу что бы все записи были связанны с другой, не пустой таблицей
причём здесь текущая сессия
как ваши ответы связаны с тем, что при вливании данных из дампа с utf8mb4_unicode_ci в таблицах отображается utf8mb4_0900_ai_ci?
SET SESSION collation_connection = {нужный collation};
, либо указывать collation непосредственно в тексте запроса. вообще ничего не выводится, и ошибок нету
В зависимости от статистики при разных критериях выборки планировщик может выбирать разный порядок сканирования таблиц, и неудивительно, что один из них оказывается более производительным, чем другой. Может, нужен вульгарный STRAIGHT_JOIN...
Вот и хотелось бы увидеть EXPLAIN двух запросов, с разными критериями и сильным различием во времени выполнения. Для подтверждения (или нет) гипотезы.
Ну и вообще, плакаться на производительность, и при этом не дать ни CREATE TABLE, ни EXPLAIN (я уж молчу о статистике данных) - это как-то непрофессионально.