Дмитрий Энтелис

Ладно, отвечу серьезно.

По поводу самой проблемы:
Можно в режиме телепата гадать 100500 раз о том что происходит.
По факту вопрос слишком абстрактный, научитесь дебажить код.

Конкретный пример: у вас есть ваш "код фильтрации".
Идеально было бы поставить xdebug и ide которая умеет с ним работать, но на крайний случай вас спасут print_r и var_dump.
Прямо с начала, берете, и для каждой строчки по очереди проверяете - те ли данные вам пришли, что вы ожидали, те ли строки сформировались что вы ожидали, итд.

Скорее всего вы поймете в чем проблема сами.
Даже если не поймете - сможете задать уже конкретный вопрос.
Ну и хорошо бы вывод всех ошибок и нотисов включать.

<?php
ini_set('error_reporting', E_ALL);
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);

Теперь в целом по коду:
1. Почитайте про MVC. mysqli функции вперемешку с html версткой - недопустимы.
2. Вынесите всю работу с базой в отдельную либу. есть 100500 готовых решений на гитхабе.
sql connect в filterTable - очень плохо.
3. В базу нельзя отправлять user input без обработки! Как минимум нужно делать mysqli_real_escape_string
4. За запрос where concat(`fullName`, `group_name`) = ... в реальном проекте, увольняют сразу. Запрос не использует индексы и должен для каждой строки таблицы выполнить объединение 2х полей, а потом еще и сравнить. Это дико медленно.
Нужна такая строка для поиска - собирайте её отдельным полем в базе.

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

START TRANSACTION;
select * from users where id = 54 FOR UPDATE
//проверка бизнес логики на наличие денег
update `users` set `balance` = `balance` - 150 where `id` = 54;
COMMIT;

Запрос "where `id` = 54 and `balance` >= 150" - опасен.
Innodb лочит не конкретные записи, а диапазоны индексов - при таком запросе в блокировку будут попадать все записи с балансом >= 150, со всеми вытекающими.

Средствами mysql - нет.

your_uncle такое ощущение что вы не пробовали читать свой собственный код.
при чем тут тексты запросов?
Команда mysqli_query($link, $query) отправляет $query на исполнение.
Все что было записано-перезаписано в $query до этого абсолютно не важно.
Важно только что там хранилось конкретно в момент вызова mysqli_query.

вам нужно вместо строчки print_r($arr); поставить mysqli_query и все будет работать (разумеется если у вас правильная структура таблицы, итд)

SELECT поле1, поле2, поле3, users_2.title as user_2_title, users_3.title as user_3_title
FROM таблица1
left join users as users_2 on  users_2.id = таблица1.поле2
left join users as users_3 on  users_3.id = таблица1.поле2
WHERE поле4 = '10';

Таблица врачей - ок.
Таблица категорий - ок.

В реальном мире связь между ними many2many.

Дальше тоньше.
Я бы делал слоты для записи отдельной таблицей, в которую писал datetime начала и datetime окончания слота.
Слоты генерим кроном на N суток вперед.

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

Ну и соответственно отдельная таблица для талонов.

Связь между слотами и талонами many2one, т.к талоны в реальности могут отменяться итд.

Да ладно вам, простой запрос же.

select
	films.*
from meta
left join films on films.id = meta.id_films
where meta_value in (13,15,27)
group by id_films
having count(meta.id) = 3

В IN подставляете все нужные категории
having count = общее количество категорий запрошенных пользователем.

Если нужен не четкий поиск, можно например сделать вот так:

select
	films.*,
	count(meta.id) as cnt
from meta
left join films on films.id = meta.id_films
where meta_value in (13,15,27)
group by id_films

и дальше показывать юзеру по убыванию cnt

WHERE обрабатывается ДО формирования кортежей, соответственно concat_url просто не определен в этот момент.
Вариантов в лоб два:
a) использовать HAVING вместо WHERE
b) в запросе вместо concat_url писать само выражение WHERE CONCAT(c.id,'-',c.url) = ...

Но в любом случае лучше так никогда не делать.
Получившийся запрос не будет использовать никакие индексы.
Правильно - добавить UNIQUE KEY (id, url) и искать WHERE id = ... AND url = ...

Не очень понял описание, с живыми примерами было бы понятней.
Модификации у всех товаров одинаковые?
Т.е условно - у всех товаров модификация №1 - цвет, значение 1 - красный, 2 - синий итд?

В таком случае храним 5 табличек - справочников с расшифровкой значений модификаторов.
В таблице товаров храним 5 полей со значениями этих модификаторов