Could hashing prevent SQL injection?

So, hashing the user password before entering it into the query is a coincidental security feature to prevent SQL injection, but you can't necessarily do that with all user input. If I'm looking up a Customer by their Name and I have a query like

Select * from Customer Where Name like '%userInput%'

If I set userInput as a hashed version of what was typed in, it wouldn't work correctly even if Name was also hashed in the database, it would only work for exact search query. So if I had a Customer with Name "Sue" and I typed in a search for "sue", it wouldn't work. I also wouldn't know the name of the customers unless there was an exact match in my search, which isn't practical.

The way you want to prevent SQL injection is to not make your queries like above, you'll want to process and parameterize inputs into a query, stripping out things like =s and other symbols that don't make sense in context of the input. A good guide for preventing SQL injection can be found here.

Basically yes, if you hash input (represented in Hex or Base64 format) before passing it to SQL, it can no longer be an effective SQLi attack vector. The same goes if you parseInt the input. Those simply do not support the characters needed for a useful SQLi. (namely to break out of the quoted string)

This technique has only limited utility in practice. i.e. it would not be compatible with some of the famous SQL features such as LIKE, <, >,
or indexed equality searches (= and <> using index)

As a side note, I would point out that password hashes really should be salted. If that criteria were met in your example, then I think you would no longer be including a hash in the SQL WHERE clause.