Difference between `nmap local-IP-address` and `nmap localhost`

If you have services that are only bound to the localhost/127.0.0.1 address, they will only show in a 127.0.0.1 nmap scan, and not in others scans to IP addresses on the same host.

Such is the case usually, for security reasons, of binding to 127.0.0.1, MySQL, postgresql and mongo DBs for only localhost use, redis and others.

Conversely, you can find sometimes other ports on non-localhost IPs, especially when you have vhosts in webservers bound to non-localhost IP addresses, and to only listen on those addresses.

On your specific 192.168.0.142 case, I would enquire wether that MySQL could not also be bound to 127.0.0.1.

PS A very old adage that I was taught when as a trainee, was: "More important than using the tools, is understanding how they work/the data we are given."

Concerning @roaima answer, as an example mentioned on this answer, the default port of a widely used DB, mongodb, is not on the list of ports scanned by default by nmap.

TLDR It is not a rule that scanning different IP addresses of the same equipment, that all the scanning data/open ports will be the same.

Alas, by network design most often than not, we do not want them to be the same. For instance in firewalls/switching equipment, we define interfaces/VLANs on a specific control network that users cannot reach for having the web management/ssh services active, and only on those interfaces. e.g. normal users cannot reach those services, they can only be reached by a VPN and/or a control room. (this is a more extreme example. I have worked in organisations where the SSH service of VMs is only present via a control network too).

Almost, but not quite.

By default nmap scans only 1000 ports for any given protocol (tcp, udp, whatever). So your port scans are subject to that filter. You'll see from the documentation that you can define the set of ports to be scanned with the -p option, and that -p- means scan ports 1-65535. (Strangely, out 0 is still omitted; you have to specify it explicitly if you want to include it.)

The other two answers both raise very important points. But in addition, you appear to have only scanned TCP and not UDP :-). So there might also be UDP services you want to worry about.

UDP scanning has a number of issues that do not apply to TCP scanning. In either case, I would start by querying the OS instead: How do I list all sockets which are open to remote machines?

Port scanning is still useful as a confirmation though. Port scanning from a different host is a particularly good idea if you have set up a firewall, to confirm that the firewall is doing what you want.