Melkij

Для поиска самих link_id

select link_id from tablename
group by link_id
having count(*) = sum(flag  = 1)

Либо

select id from links
where exists(select null from tablename where flag  = 1 and link_id = links.id) -- возможно это условие вам по задаче не нужно
and not exists(select null from tablename where flag != 1 and link_id = links.id)

Вычитывать сами строки можно попробовать через

select ...
from tablename t
where t.flag = 1
and not exists(select null from tablename sq where sq.link_id = t.link_id and sq.flag != 1)

При том, какой из вариантов эффективнее - критично зависит от распределения данных. При большой числе различающихся link_id с малым числом строк на каждый link_id и малым ожидаемом числе подходящих строк под задачу может быть эффективнее именно

select ... from tablename t where t.link_id in (
select q.link_id from tablename q
group by q.link_id
having count(*) = sum(flag  = 1)
)

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

Третий запрос по ожиданию лучше отзовётся на случай малого числа flag = 1 строк в таблице.

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

https://dev.mysql.com/doc/refman/8.0/en/encryption...

and returns a binary string containing the encrypted output

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

Вопрос в том, какие константы использовать вместо ??? при типе данных Int?

Вы так спрашиваете, будто для чисел есть что-то кроме PDO::PARAM_INT
Их вообще полтора землекопа только: https://www.php.net/manual/en/pdo.constants.php

будет ли при нулевом значении запрос изменяться

Нет, не будет. Это ваша задача составить верно запрос. При том не пытайтесь сделать универсальный запрос.

Ооо.... Вы это сейчас вообще серьёзно?

Если вы запускаете DBaaS платформу и не знаете что делать собственно с базами - то у вас не

Запускаю свою облачную платформу, код и архитектура создана с нуля.

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

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

Значит этому юзеру достаточно ходить только на мастер.
Для сферического в вакууме приложения нет средств автоматически распределять запросы по репликам. И такое сделать вовсе невозможно без накладывания ограничений на использование. Например,
select somefunc();
Что делает эта функция? Она только читает данные и потому можно отправить на реплику или она пишет и потому должна быть на мастере? Хотите правильный ответ от контрибьютора postgresql? Это достоверно не знает даже сама база до тех пор пока не выполнит функцию.

Другой пример:

begin isolation level repeatable read;
select ...
update ...
commit;

Как максимум на запросе select вы должны уже знать можете ли вы эту транзакцию отправить на читающую реплику. Откуда бы вам это узнать заранее?
И прочие принципиально-нерешаемые вопросы.

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

Это синтаксис именно MS SQL.
Но sqlite его для совместимости тоже умеет: https://www.sqlite.org/lang_keywords.html

Следовательно, импортируйте сперва в sqlite, затем экспортируйте нормально. В нормальных стандартных кавычках - если ваш mysql в sql_mode=ANSI_QUOTES - или в специфичных для mysql апострофах `.

ON DUPLICATE KEY UPDATE. Сверяйте по буквам.

А если делаю ON DUBLICATE KEY UPDATE `pipeline_name` = '$pipelinename' ,
то записи дублируются

Удивительно. Верится слабо.

Никакого парадокса, задокументированное поведение. Скопирую недавний ответ отсюда:

Потому что вообще не надо сравнивать строки и числа. Если поле строковое - сравнивайте только со строкой. Хоть при этом происходит и вполне задокументированное поведение.

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

Мне кажется вам нужен вовсе:

select product_id, min(price), max(price) from prices group by product_id having max(price)>= ?

А отвечая на вопрос в лоб - lateral join'ом перенести подзапрос в секцию from и всё.

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

https://mariadb.com/kb/en/library/reserved-words/

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

Объединение нескольких колонок в одну, для однотипных данных. Они будут храниться в формате JSON.

JSON объёмнее плоской таблицы хотя бы из-за необходимости в хранении ключей.
И, насколько знаю, mysql пока умеет только btree. Что подходит для произвольного поиска от слова никак. Только для заранее известного критерия.

3. Партиционирование.

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

Слово неплохое упомянуто. Осталось понять зачем всё остальное. Партицировать таблицы умеет штатно даже такая удивительная штука как mysql и очень давно.

Профилируйте где время теряете и смотрите что с данными делаете.
Озвученные цифры не впечатляют от слова совсем. Если человек хочет поиграться с разными подходами индексирования и производительностью сложных запросов - я посоветую с миллиона записей только начинать.

Типичная ошибка - пытаетесь строить аггрегаты и прочие count(*) поверх миллионов строк налету.

Типичный race condition. Для исправления вам необходимо найти некоторое место для сериализации транзакции. Транзакция, разумеется, нужна. Но и некоторый ресурс для сериализации этих транзакций нужен.
Например, через добавление подходящего уникального ключа (чтобы конкурентный insert споткнулся на нём), advisory lock, serializable isolation level не должен разрешить такое закоммитить.