Te dare una pista que utilizo bastante... y que muchos DBA suelen utilizar ya que es un requisito indispensable para optimizacion de consultas y procedimientos almacenados.

TUNNING....

indaga y conoce la funcion EXPLAIN dentro del motor MySQL    esta te ayudara mas de lo que te imaginas y tus consultas quedaran bastantes optimizadas.

ID es precisamente eso el indice o la llave primaria de la tabla.... el campo identificador como llave primaria de la tabla, puede llamarse ID, codigo, nombres, como gustes... 

Sobre tu pregunta Sempus si es valido, podrias obtener todos los registros de la tabla A donde sus id no sean iguales a los de la tabla B con esa subconsulta, aunque aun desconozco porque utilizas la clausula DISTINC en la consulta al id de la tabla B, si id es una llave primaria o unica de la tabla B no deberia acceptar duplicados, por lo tanto DISTINC no ejerceria ninguna funcion aca, a no ser que como te explico id de la tabla B no sea ningun indice primario y tenga campos repetidos o sea un indice primario secundario.

La consulta es valida para obtener lo que se busca si son datos chiquitos, pero para optimizacion necesitan verificar todo con EXPLAIN

http://dev.mysql.com/doc/refman/5.0/es/query-speed.html

en esta consulta :

SELECT * FROM tabla_A
WHERE id  NOT IN( SELECT id DISTINCT FROM tabla_B );

la tabla B es una subconsulta de la A, y si id es un indice en la tabla B vamos bien en esa parte de optimizacion pero.. la tabla A le estamos haciendo un Select Todo donde su id no este dentro de lo que la subconsulta genera... por lo tanto para que el id de la tabla A obtenga una respuesta para comparar o saber que datos debe devolver, primero tiene que recorrer todos los indices y data de sus archivos devueltos por la tabla B.... y ahi entra el dilema, se puede semi optimizar la tabla A si por ejemplo el campo id no accepta valores Nulos por defecto podrias hacer :

SELECT * FROM tabla_A
WHERE id  NOT IN( SELECT id DISTINCT FROM tabla_B ) and A.id is not null;

Saludos