Akina

1) Как безопаснее и правильней писать имя таблицы и базы с кавычками или без кавычек . Если с кавычками то с двойными или одинарными.

В MySQL используется три разных типа кавычек.

1. Прямая кавычка '

Используется для обрамления литералов, требующих такого обрамления, а именно: строковые, даты-времени, JSON, компоненты имени учётной записи и пр. Подробнее см. Literal Values и Specifying Account Names

2. Обратная кавычка `

Используется для обрамления имён объектов (БД, таблиц, полей, имён функций/процедур и пр.).

Если имя объекта не содержит нелегитимных символов (подробнее см. Schema Object Names), не является служебным или зарезервированным словом (см. Keywords and Reserved Words), использование обратной кавычки опционально, иначе обязательно.

3. Двойная кавычка "

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

При включённом ANSI_QUOTES в SQL Mode указанные использования отменяются, и двойная кавычка используется для обрамления имён объектов (т.е. дублирует использование обратной кавычки).

ИТОГО с точки зрения безопасности:

- имена объектов ВСЕГДА обрамлять ТОЛЬКО обратной кавычкой
- литералы, требующие обрамления - обрамлять ТОЛЬКО одинарной кавычкой
- двойную кавычку использовать ТОЛЬКО как символ в составе литерала (строкового, JSON)

Нет, это явное нарушение RFC.

Адрес 192.168.40.40 относится к категории немаршрутизируемых в Интернете. Любой узел, если он получил пакет на этот адрес на интерфейсе с маршрутизируемым адресом, либо если он должен согласно своей таблице маршрутизации отправить его через интерфейс с маршрутизируемым адресом, должен отказать в маршрутизации (какое при этом применить правило - deny или drop,- не описано). В трассе имеется адрес 188.***.172, не принадлежащий какой-либо немаршрутизируемой сети - следовательно, в маршрутизации пакета должно было быть отказано.

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

Для передачи из одной записи в другую никакие транзакции нафиг не нужны.

UPDATE tablename
SET balance = balance + CASE WHEN userid = @sender
                             THEN -@amount
                             ELSE @amount
                             END
WHERE userid IN (@sender, @receiver);

Для решения задачи может быть использован триггер.

Решение 1. Более простое, но может давать дубликаты в конкурентной среде.

CREATE TRIGGER tr_name
BEFORE INSERT
ON articles
FOR EACH ROW
SET NEW.image = CONCAT('catalog/blog-image/', COALESCE((SELECT 1 + MAX(SUBSTRING_INDEX(image, '/', -1)) FROM articles), 1), '.jpg');

DEMO

Решение 2.Устойчиво в конкурентной среде.

Создаётся опорная таблица генерируемых номеров:

CREATE TABLE image_counter (id INT AUTO_INCREMENT PRIMARY KEY);

Триггер использует таблицу для генерации:

CREATE TRIGGER tr_name
BEFORE INSERT
ON articles
FOR EACH ROW
BEGIN
    INSERT INTO image_counter VALUES (DEFAULT);
    SET NEW.image = CONCAT('catalog/blog-image/', LAST_INSERT_ID(), '.jpg');
    DELETE FROM image_counter;
END

DEMO

как сделать регистронезависимый поиск по longblob?

Регистрозависимость операций поиска/сравнения определяется применяемым COLLATION.
LONGBLOB имеет по умолчанию binary collation (например, utf8mb4_bin) - поэтому сравнение выполняется бинарное.
Для регистронезависимого текстового сравнения надо явно определить требуемый COLLATION в запросе. Типа

WHERE column COLLATE utf8mb4_0900_ai_ci LIKE 'pattern'

Если надо ещё и charset подкорректировать, то дополнительно использовать функцию CONVERT().

А если будем просто через LIKE то придет вот так (так не нужно): Иван, Ваня, Ивановы...

Нет. Отбор записей и их сортировка - две совершенно независимые операции.

SELECT word 
FROM words 
WHERE word LIKE '%$search%'
ORDER BY LOCATE($search, word), word

Делаю так:
SELECT * FROM tbl1 EXCEPT SELECT * FROM tbl2

Структуры таблиц совпадают?

Тогда

SELECT t1.*
FROM tbl1
LEFT JOIN tbl2 ON tbl1.primary_key = tbl2.primary_key
WHERE t2.primary_key IS NULL

Это должно без проблем отображаться на синтаксис фреймворка.

Трата состоит из трех этапов. Чтение баланса пользователя, проверка хватает ли средств и собственно запись нового баланса.

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

баланс юзера расчитывается на лету и не хранится в юзере. Расчитывсется на основе истории его пополнений/расходов.

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

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

Как раз уровень изоляции. При правильно выбранном уровне хрен чего второй прочитает, пока первый не завершит свою транзакцию и не отпустит ресурсы.

при подключении провода подключение Wi-Fi автоматически гаснет.

Что значит "гаснет"? физически отключается адаптер? логически отключается привязанный к нему сетевой интерфейс? Старайтесь использовать более вменяемые термины, Вы же технический специалист.

Железка имеет DHCP, сразу выдаёт адрес

Не только адрес, но и ещё горсть параметров, включая шлюз по умолчанию. При этом уже имеющийся немедленно получает увеличение метрики и перестаёт использоваться.

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

Windows 10 игнорирует метрики, в зарубежных гайдах говорят "Перестала уважать метрики". Т.е. нет никакой разницы, если поставить "999" метрику на Ethernet и "1" на Wi-Fi

Явная и откровенная глупость. Абсолютное непонимание того, что есть метрика интерфейса и как она влияет на маршрутизацию.

Если я на каждый столбец, который используется в WHERE добавлю одиночные индексы, не ухудшит ли это производительность?

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

пока не понятно, какие индексы нужны, а какие нет.

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

Целевое поле - вычисляемое. Значит, фраза "не удаляя её значения" по отношению к нему не имеет смысла. Даже если это поле - хранимое, а не виртуальное.

Сколько учетных записей должно быть у администратора?

У одного администратора должна быть одна учётная запись. Которая является членом кучи групп, и каждая из групп даёт минимально необходимый набор прав для выполнения вполне определённой функции/работы.

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

Используем [NOT] EXISTS

SELECT *
FROM user_friend uf1
WHERE [NOT] EXISTS ( SELECT NULL
                     FROM user_friend uf2
                     WHERE uf2.friend_user_id = uf1.user_id )

При WHERE EXISTS выбираются пары друзей (записи, имеющие обратную пару), при WHERE NOT EXISTS - записи, не имеющие обратной пары.

Если для записей, имеющих обратную, нужна только одна пара из двух - добавляем во WHERE внешнего запроса ещё одно условие AND friend_user_id > user_id.

1. Переместить файлы таблицы.
2. Создать пустую таблицу, скопировав CREATE TABLE с другого сервера максимально близкой версии.
3. DISCARD TABLESPACE.
4. Заменить файлы на сохранённые.
5. IMPORT TABLESPACE.

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

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