How does a web server know which key pair to use for SSL decryption?

Originally, the web server didn't know. This was the reason that you needed a separate IP address for every SSL vhost you wanted to host on the server. This way, the server knew that when a connection came in on IP X, he needed to use the configuration (including certificates) for the associated vhost.

This changed with Server Name Indication, a TLS extension that indeed allows a client to indicate the required hostname in the handshaking process. This extension is used in all modern OS, but old browsers or servers don't support it, so if you expect clients to still use IE 6 on WinXP, you would be out of luck.

It seems you have some misconceptions about TLS/SSL. The HTTP request is not encrypted by server's public key. It is encrypted by a symmetric cipher using a key negotiated in previous handshake.

Brief description of TLS handshake: Server and client negotiate some ciphersuite, symmetric key(s) and some other details. In order to prevent MITM, server usually sends its certificate (chain) to the client and authenticates the handshake using the key in certificate. (There are also some other variants, e.g. client authentication or TLS-PSK, but they are not much used with HTTP.) Client can either validate the certificate (the usual way) or ignore it.

While SNI is important when using multiple TLS certificates at one IP, it is not essential for server being able to decrypt the request. Without SNI, server does not know which certificate chain should be sent, so server usually picks one (e.g. the first vhost), which could be of course a wrong one. If server picks wrong certificate chain, client should refuse it (so it does not continue with sending the HTTP request). However, if client ignores certificate (or if the invalid certificate is marked as trusted for this site), it can successfully continue. Since the symmetric key used for encryption does not depend on the certificate (TLS is designed to also work without certificates), the server can decrypt it.

Just a minor note why I am writing about TLS, while you asked about SSL: TLS is new version of SSL. All version of SSL are considered as insecure for general usage, so we are mostly using TLS (1.0, 1.1, 1.2) now.