Problems should be addressed at the root and not (insufficiently) taped over.
The root of the problem in your case (SQL injection) is that unexpected and unverified user input can be injected as SQL instructions into your SQL statements. This is due to concatenating strings with SQL instructions together with untrusted user input and treating the result as a trusted SQL statement.
The easiest and fullest protection against this problem is to make injection impossible by eliminating this flawed string concatenation. This can be done using prepared statements.
While only validating the user input could be sufficient too if it would be perfect, it is usually more complex and usually not as perfect as needed either. But validation and normalization of user input should still be done to protect against other attacks like XSS.
This less than ideal approach of only input validation and normalization could also be done by a Web Application Firewall, if the WAF had full knowledge what user input your application expects. To achieve this the WAF would need to be fully adapted to your application. But, WAF installations instead often contain only general rules against typical attacks and are not tightly tuned to the specific instance of the web application. And even if they were tuned once against the application this protection might not be sufficient anymore after the developers changed the application.
Therefore a WAF should only be used as an additional defense as part of defense in depth but not as the only and ultimate protection.