There are all kinds of experimental approaches that try to prevent SQL injection attacks, some of which are quite clever. It's possible that you've found some paper or article where somebody claims that homomorphic encryption helps against SQL injection.
However, this is research – or just playing around. If you have an actual system that you have to protect, then doing experiments is the absolutely last thing you want. In practice, you should always use the most simple, robust and widely accepted solution.
In the case of SQL injections, the primary solution are prepared statements. The idea is that the database system pre-compiles a fixed query template which has parameters for dynamic values. This completely separates the structure of the query from the data used by the query, making it impossible for an attacker to change the query itself. As a concrete example:
SELECT price FROM books WHERE title = ? AND category_id = ?
Each question mark denotes a parameter. The first parameter is for a string which contains the book title, the second parameter is for a numeric category ID.
Once the prepared statement has been created, it's possible to bind concrete values to the parameter (like "The Trial" for title and 57 for category_id) and execute the statement with those values. There's no risk of untrusted values leading to an SQL injection, because the attacker cannot do more than specify the string and the integer which will be used by the query.
Sometimes escaping is recommended as an alternative to prepared statements, but this a very fragile approach. It's far too easy to forget the escaping, run into character encoding issues or use the wrong technique. This risk should only be taken if it's absolutely impossible to use prepared statements.
If you need to dynamically insert SQL identifiers or query fragments rather than values, this cannot be done with prepared statements. In this case, you have to validate and possibly escape the input for the specific target context. For example, if you want to let the user specify which column of a table should be searched, then a possible solution would be to have a whitelist of acceptable column names. This restricts the user to a set of predefined option, making it impossible to inject anything else.
Encryption can be used to limit the effects of an SQL injection attack, so this is a valid defense-in-depth measure. However, the primary protection is to prevent injection attacks from happening in the first place. And the encryption shouldn't be homomorphic, unless there's a specific reason for why you need its features.
