Ипатьев

Сделать первичный индекс на вторую таблицу.

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

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

Стандартный способ:

SELECT count(*) FROM shop LEFT JOIN shopData ON shopData.shop_id=shop.id WHERE shopData.shop_id IS NULL

Но следующий способ должен быть быстрее

SELECT count(*) FROM shop WHERE NOT EXISTS (SELECT 1 FROM shopData WHERE shop_id=shop.id)

Это называется словом "трассировка".
Пошаговое выполнение программы средствами IDE, с контролем значений всех переменных.
На определенной строке программы ставится специальная метка, брекпойнт.
Дойдя до неё, интерпретация кода остановится, и дальше можно будет выполнять каждую строчку по одной, видя при этом значения всех переменных. Причем именно всех, а не только тех, которые ты добавил в дд.
То есть трассировка средствами IDE удобнее, быстрее и даёт больше информации, чем ручное колупание с вардамп.

В РНР этим занимается xdebug в связке с IDE

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

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

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

И тогда вопроса как прочитать значение никогда не возникнет

Без вариантов.

При ближайшем рассмотрении создание объектов прямо из пдо оказывается довольно бесполезной фичей.

По данному вопросу либо цикл, как например здесь, либо просто два запроса, второй по списку id из первого