Akina

Обычно если в запрос может быть передано значение, а может и нет, делают так:

... AND (column = {parameter} OR {parameter} IS NULL) ..

При подстановке параметра сервер уже на этапе построения плана выполнения запроса, зная значение {parameter}, получит либо
... AND (column = {parameter} OR FALSE) .. ==> ... AND (column = {parameter}) ..
либо
... AND (column = {parameter} OR TRUE) .. ==> ... AND (TRUE) ...

PS. Чтобы не геморроиться с определением, когда ставить WHERE, начальный шаблон делают такой:

SQL = "SELECT * FROM USERS WHERE 1=1 {} LIMIT %s OFFSET %s"

и все дополнительные условия формируют в виде
AND {условие}
Тогда не надо оглядываться, первое это условие или нет.

Само же условие 1=1 будет обращено в TRUE и отброшено опять-таки на этапе построения плана.

WITH
cte AS (
  SELECT *, ROW_NUMBER() OVER (PARTITION BY document_id ORDER BY job_id DESC) rn
  FROM my_table
  )
SELECT document_id, job_id, person_id
FROM cte 
WHERE rn = 1;

И в качестве бонуса

SELECT DISTINCT 
       document_id,
       MAX(job_id) OVER (PARTITION BY document_id) job_id,
       FIRST_VALUE(person_id) OVER (PARTITION BY document_id ORDER BY job_id DESC) person_id
FROM my_table

LIKE регистронезависим.
GLOB регистрозависим.
REGEXP - как напишешь регулярку, так и будет.

WITH cte AS (
    SELECT a, b, c, COUNT(*) OVER (PARTITION BY a, c) cnt
    FROM table
)
SELECT a, b, c
FROM cte 
WHERE cnt > 1

не пойму что ей надо

Надо, чтобы в поле cat_id таблицы post уже присутствовало значение, которое ты присваиваешь полю id во вставляемой записи.

Запомните одну вещь. Многие её забывают или не знают, и из этого проистекают все их проблемы.

Внешний ключ (FOREIGN KEY) - это ПРАВИЛО. Всё остальное - либо дополнения, либо следствия. Народ начинает рассказывать про индексы и прочее - НЕТ! Не включайте всё это в определение собственно внешнего ключа.

Хотя оно хранится в структуре таблицы, оно является не частью структуры таблицы, а инструкцией, которая будет обрабатываться подсистемой контроля целостности и непротиворечивости данных - есть такая в составе SQL-сервера.

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

Это правило может быть дополнено опциями каскадной операции ON DELETE/UPDATE - в этом случае после контроля нового значения подсистема даёт дополнительную команду на выполнение указанных в опции изменений зависящих данных.

Впрочем, создание внешнего ключа может и приводить к изменению структуры. Но не той таблицы, в которой создаётся внешний ключ, а в той, на которую этот ключ ссылается. дело в том, что для эффективной работы подсистемы контроля в ссылающейся таблице должен существовать индекс, который может и будет использоваться для эффективного контроля. То есть либо выражение внешнего ключа должно совпадать с выражением индекса, либо быть его префиксом. Некоторые СУБД при отсутствии такого индекса создают его автоматически, некоторые завершают попытку создания с ошибкой.

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

SELECT 
  *,
  FIRST_VALUE(CASE WHEN banner_id IN (13,14,15,17)
                   THEN banner_id 
                   END) OVER (PARTITION BY id
                              ORDER BY CASE WHEN banner_id IN (13,14,15,17)
                                            THEN banner_id 
                                            END DESC NULLS LAST) max_banner_id_1,
  FIRST_VALUE(CASE WHEN banner_id IN (4,177,178)
                   THEN banner_id 
                   END) OVER (PARTITION BY id
                              ORDER BY CASE WHEN banner_id IN (4,177,178)
                                            THEN banner_id
                                            END DESC NULLS LAST) max_banner_id_2
FROM test
ORDER BY banner_id

PRIMARY KEY - первичный ключ. Поле, комбинация полей либо выражение (последнее MySQL не поддерживает), которое не может быть NULL и не допускает дубликатов (уникально для каждой отдельной записи в пределах таблицы). Поддерживается путём создания соответствующего уникального индекса и наложением ограничения NOT NULL на все используемые в выражении поля. По факту - однозначно идентифицирует запись. Кроме того, в MySQL выражение первичного ключа является кластерным индексом. См. Индекс -> Уникальный индекс -> Первичный индекс.

CONSTRAINT - ограничение. Правило, которое не допускает создания записи, для которой значение выражения ограничения имеет значения FALSE (можно TRUE или NULL).

FOREIGN KEY - внешний ключ. Ограничение, которое требует, чтобы указанное выражение для текущей записи присутствовало среди значений указанного выражения референсной таблицы (допускается и внешний ключ на ту же таблицу). Точнее, чтобы такая проверка присутствия не возвращала FALSE (можно TRUE или NULL).

REFERENCES - определяет референсную таблицу и референсное выражение.

INSERT INTO - запрос, вставляющий новые записи в таблицу.

SELECT rule.id, rule.path, rule.content, rule.cat_id 
FROM rule
JOIN rule_options ON rule.id = rule_options.rule_id
WHERE rule_options.option IN (4670, 5492)
GROUP BY 1,2,3,4
HAVING COUNT(DISTINCT rule_options.option) = 2;

Во-первых, надо создать в таблице уникальный индекс по полю, которое не должно содержать дубликатов.
Во-вторых, надо использовать INSERT IGNORE INTO, чтобы дублирование одного значения не обваливало весь вставляемый массив. Либо REPLACE INTO, если при дублировании надо полностью заменить старую запись новой. Либо INSERT ODKU, если надо обновить старые данные новыми по некоей логике (например, вставить значения в поля, в которых раньше было NULL, а теперь пришло что-то определённое). Это - для MySQL, в других СУБД синтаксис с аналогичными возможностями будет иным.