Если "в лоб" решать, то в простейшем варианте можно добавить ещё два запроса с соответствующими условиями и объединить результаты через UNION.

Выражение clients.* выглядит странным. Какие конкретно данные (запись) оно должно вернуть, когда под условия выборки попадают несколько записей? Что-то вроде GROUP_CONCAT(id) кажется более внятным.

dok11система постоянно отслеживает появление таких записей и предлагает модератору объединить таких клиентов в одногоА чего сразу не поставить уникальные индексы, исключающие повторение номеров телефонов и почты?

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

dok11Значит не будет возможности внести запись в БД, с дублем, правильно?В общем, да, так как идентификатор пользователя (покупателя) уже имеется в базе. Его вполне можно определить и использовать в данной транзакции или покупке.

dok11Значит мне юзеру нужно чего то сказатьНесомненно, нужно!

dok11почему он не может купить "Здесь и сейчас", правильно?Это глупости, конечно.
Скажите, покупателю, что рады его вновь видеть в магазине, что не забыли его, что по соответствию почтового адреса добавили в ЛК в качестве контактного новый его номер телефона или по соответствию номера телефона добавили новый почтовый адрес.

dok11Нужно максимально упростить схему покупки, вот и всё)Гипотетически, на этапе оформления заказа можно было бы и адрес доставки предложить из прежних вариантов, которые использовал покупатель с ранее зафиксированным номером телефона или почтовым адресом. Они же есть в базе. Но делать этого нельзя, так как пользователь не авторизован и поэтому должен напечатать адрес ручками. А будь он авторизован - тады дело другое, тады проще.

Вопросов валидности или подтверждения адреса и номера на данном этапе можно не касаться, хотя, вопрос безопасности, конечно, остается. Однако, в ЛК это можно автоматизировать по довольно простым алгоритмом, не слишком привлекая администратора для "слияния".

dok11Спрашивается накой ему такие качели?Вообще, вариантов идентификации пользователя есть гораздо более двух. Насколько понимаю, в существующей схеме сущность "Покупатель" отсутствует, как таковая и Вы пытаетесь создать ее неявным образом, группируя некоторые признаки сущностей "Покупка". Ну так себе качели.

dok11вопрос же в другом... можете помочь?Выше я уже высказался по исходному вопросу, предложил вариант объединения нескольких запросов в один. Не годится такой вариант - так и скажите, что не годится. Мне лично такой вариант тоже не нравится. Будет ли он ресурсоемким? Несомненно, как любой статистический запрос по таблице в целом.

dok11В задницу они слали, наше приветствия и личные кабинетыНе хотите - можете не говорить. Сам ЛК суть сущность "покупатель" с его контактными данными, историей покупок и т.п. Вне зависимости, заходит в него покупатель или нет. Вы же одновременно и пытаетесь определить покупателя по его данным и, если правильно Вас понимаю, отрицаете необходимость существования такой сущности как лишней.

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