Al menos yo los haria por separado. Puede que mi razones no sean del todo validas pero, son campos de diferentes tipos de datos (Uno es numerico el otro es alfanumerico). Si fueran del mismo tipo de datos lo consideraria mas viable hacerlos compuestos. Y otra de mis razones es, que me parece que por cada insercion o actualizacion que realices en MySQL, el motor tendra que volver a restructurar los indices (porque estan compuestos agrupados no confundir con clustered  ).  Puede que si son pocos los cambios o pocos los indices compuestos que tengas en existencia no se afecte tanto el desempeno, pero si tienes muchos o muchas entradas puede que si afecte en algo a la larga.

Y puedo equivocarme, me estoy basando en una logica superficial que conste, y que pasara si en un futuro agregas a tu tabla otro campo llamado SECTOR crearas otro indice compuesto para el? porque habran momentos que querras consultar por CALLE y SECTOR nada mas.. y habran momentos que querras consultar por CALLE, SECTOR, NUMERO y otros por CALLE y NUMERO.

 

Recuerda:

por cada insercion o actualizacion que realices en MySQL, el motor tendra que volver a restructurar los indices (porque estan compuestos agrupados no confundir con clustered  )

Yo pense que CALLE era alfanumerico  (Nombre de calle por ejemplo) pero si dices que no, que ambos son numericos y estas seguro que no vas a agregar un campo indice 'extra' mas adelante ... pues si te saldria mas efectivo hacerlos compuestos estos dos.  pero intenta no crear demasiados indices compuestos en tus tablas, por la situacion que te expuse anteriormente, si luego requieres alterar la tabla para agregar otro indice, tendras nuevamente que crear otra definicion compuesta    pero si estas seguro que no alterararas en un futuro la tabla, hazlo asi.

Un saludito.