Se que Enecumene ha dado una respuesta correcta, aunque a mi no me deja de sonar un poco raro el asunto.
A mi ver, ese tipo de consulta no elimina cierto defecto de diseño.
¿Cuál es el defecto? Que no se ha eliminado la necesidad de hacer doble verificación. Con la consulta obtienes la info de las 2 tablas a la vez, pero de todas formas para leer la data vas a tener que volver a hacer la evaluación de si existe el dato a buscar en sus campos. Fíjate que es lo que se está haciendo:
1) El motor lee la consulta "Traeme los campos de las tablas 1 y 2 que cumpla la condición de que el dato a buscar esté en tabla 1 O en la tabla 2". Cantidad de ORs = 1, pero el motor tuvo que proceder a buscar en ambas.
2) Ahora desde PHP, tu necesitas leer el campo 1 primero, y luego si no está vas a leer en el campo 2. La lógica es más o menos así:
Si (DatoBuscado = Campo1)
entonces ...
SINO SI (DatoBuscado = Campo2)
entonces ...
SINO Mostrar "No existe"
Cantidad de IFs en peor caso: 2, mejor caso: 1
Has tenido que hacer doble trabajo. Primero te lo hizo el motor MySQL y luego vuelves a hacer el mismo trabajo desde tu script php. Ya que eso es lo mismo que hacer esto:
Buscar en tabla1
Encontrado1 = (DatoBuscado = Campo1)
Buscar en tabla2
Encontrado2 = (DatoBuscado = Campo2)
Existe = Encontrado1 OR Encontrado2
Cantidad de OR = 1
El problema de hacerlo así, es que para poder determinar donde fue encontrado necesitas hacer evaluaciones adicionales:
SI Existe
entonces SI Encontrado1
entonces Mostrar "Lo encontré en tabla1"
SINO Mostrar "Lo encontré en tabla2"
SINO Mostrar "No existe"
Cantidad de IFs = 2
No hay mejor ni peor caso. Los 2 son necesarios.
La forma tradicional de trabajo:
Buscar en tabla1
SI DatoBuscado = Campo1
entonces ...
SINO buscar en tabla2
SI DatoBuscado = Campo2
entonces ....
SINO Mostrar "No existe"
Tiene la cantidad la misma cantidad de IFs en su peor caso.
Cuando se trata de un sólo campo por evaluar no hay tanto drama, pero cuanto más campos sean necesarios buscar la complejidad ciclomática se empezará a duplicar.
Lo que me hace ruido es que tengas dos tablas. ¿Para que son? ¿O que es lo que te motiva a diseñarlo así? Si ambas tablas son idénticas y resulta ser que por lógica un usuario va a estar en una U otra exclusivamente, una forma de encararlo es hacer una única tabla y añadir un campo adicional en el que almacene en que "lista" va a estar. Con eso consigues que con buscar una sola vez en esa tabla sea suficiente. Si devuelve registros es porque existe, y para saber a que lista pertenece solo basta con leer dicho campo.
Fíjate que ese diseño permite tener N listas. No tiene porque ser unicamente un dato booleano.
Saludos.