Akina

Сведения об UNIQUE constraint (включая и PRIMARY KEY) могут быть получены запросами

SELECT *
FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE
WHERE TABLE_SCHEMA = DATABASE() /* либо 'database_name' */
  AND TABLE_NAME = 'table_name'

SELECT *
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'table_name'

The INFORMATION_SCHEMA KEY_COLUMN_USAGE Table
The INFORMATION_SCHEMA COLUMNS Table

Правильно ругается. Документацию читать надо, а не сомнительные комментарии к ней.

Выражение при использовании операторов ALL, SOME, ANY может быть только и исключительно набором данных, а не набором скалярных значений. Применительно к SQL Server - только подзапросом. Можно, конечно, попробовать использовать функцию, возвращающую набор данных, но сильно сомневаюсь, что получится.

ALL (Transact-SQL)

Так что синтаксически правильно так:

Select * 
from Employees
where [Employee ID] != ALL ( SELECT 90 UNION SELECT NULL );

Хотя и неправильно логически - наличие в списке NULL однозначно приведёт к пустому набору данных.

SELECT categories.id, 
       categories.slug,  
       ct_ru.title title_ru,  
       ct_en.title title_en,  
       ct_de.title title_de
FROM categories
LEFT JOIN category_translations ct_ru ON category_translations.category_id=categories.id 
                                     AND category_translations.locale = 'ru'
LEFT JOIN category_translations ct_en ON category_translations.category_id=categories.id 
                                     AND category_translations.locale = 'en'
LEFT JOIN category_translations ct_de ON category_translations.category_id=categories.id 
                                     AND category_translations.locale = 'de';

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

WITH cte AS (
    SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY score DESC) rn
    FROM source_table
)
SELECT *
FROM cte
WHERE rn = 1
-- ORDER BY score DESC LIMIT nnn
;

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

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

CREATE TRIGGER trigger_name
EVENT ACTION ON table_name
FOR EACH ROW
BEGIN
    SET @trigger_name_table_name = CONCAT('executed, ', 'column_value=', NEW.column);
-- trigger action
    SET @trigger_name_table_name = NULL;
END;

Если в теле триггера определены EXIT хэндлеры - они тоже должны выполнять соответствующие сбросы.

будет ли использоваться индекс в запросе вида WHERE `field1` LIKE '_aa_a_'?

50/50 - или будет, или нет.

Однако если он будет использоваться, то не как индекс (сортированный список для выполнения index seek), а как компактная копия таблицы (как несортированный список для выполнения index scan).

Тем не менее профит от использования индекса таким образом может быть, и весьма значительный. Главным образом он определяется соотношением размера записи к размеру поля. И чем это соотношение выше, тем более вероятен профит.

SELECT p.name, p.id 
FROM products AS p
JOIN product_country AS cp ON cp.product_id = p.id 
WHERE cp.country_id IN (1,2)
GROUP BY 1, 2
HAVING COUNT(DISTINCT cp.country_id) = 2;

начать поиск элемента в таблице в БД с конца

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

как получить id последнего элемента в таблице?

Последний (при какой-то сортировке) - это первый при обратной сортировке.
Так что надо просто указать сортировку (обратную той, которую ты считаешь "прямой") и взять только первую запись.