Q: Should password hash be stored in binary or hexadecimal number? I usually store it in hexadecimal number but realize I could save half of the space if I store it in binary inside MySQL. Are there any issues I should be aware of if I decide to store it in binary?

A: From a usability standpoint, it's probably best to store the hash as a hexadecimal.  Storing them in binary means one more step is required to compare a plain text input to the stored password.  It also has the potential to add a layer of confusion to anyone who make work on your project after you've moved on.  "Why is this password stored in binary?"

A: Disclaimer: Let's be real, this question must be on the border of being closed as purely opinion based. So any answer you get is a matter of preference and expierence.
Just to add my common sense answer to this question: You should store it the way you get it from your encryption tool/method.
Any good encryption has an encrypt and a decrypt or compare method. Normally the output of the encrypt is what you need to pass as input to the decrypt/compare.
Whatever output encrypt is producing, should be the prefered way of storing it.
You can convert the output to whatever you like, whether it is binary, hex, base64 or write it down using pen and paper, the encrypted value will not become more or less secure. Somebody that finds the value, will need the encryption keys to decrypt it.
But everytime you convert something, you also need to convert it back to it's previous state. Which means you add a new layer of potential problems and add overhead on the whole proces. However negligible it might be, it still is more complex/slower then not doing it at all.

A: How many passwords are you expecting to store? Does half the space mean that much to you really?
You are probably representing the passwords in hexadecimal form in your application, so storing them in binary adds another layer of complexity and processing overhead when you perform any operations on those passwords.
My opinion is that you should store them in a way that is convenient for you to work with, rather than one that saves you tiny amounts of space.
Edit:
Going to make some assumptions and take the opportunity to help you a little further.
Since your passwords are in hex, I'm going to assume you're not using crypt, and if you're not, you should be. Worst case scenario, you're using md5... and god is killing kittens.
There's a lot of questions and answers about bcrypt on stack overflow already, so I'll not cover the information again here. 
The question SHA512 vs. Blowfish and Bcrypt is a good place to start though.
Also have a read of a couple of @ircmaxell's blog posts on the subject:


*

*Introducing PasswordLib

*The Secure Programmers Pledge

A: The main motive when it comes to password is How secured it is rather than just scaling for the sizes or space taken by it in the databases and because of this your password must contain all the security entities such as Algorithm , Algorithm Options (for eg: time cost, memory cost, threads),Salts,Hashed Password.This all together make your password far more stronger than a simple hex or binary password.
References:
Safe Password Hashing
Password Hash
And as per the first link The suggested algorithm to use when hashing passwords is Blowfish, which is also the default used by the password hashing API, as it is significantly more computationally expensive than MD5 or SHA1, while still being scalable.
You can use the
echo password_hash("rasmuslerdorf", PASSWORD_DEFAULT);

Output
$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a

Here your password consists of all Algorithm , Algorithm Options (for eg: time cost, memory cost, threads),Salts,Hashed Password
