Is there any simple way to prevent SQL injection once and for all?

Is there any simple way to prevent SQL injection once and for all? I searched it just now and it seems complicated.
Let me talk about my thoughts:
First of all, I don't know if MySQL can add single quotation marks for all types of data. I just tried to add single quotation marks around the integer.
If it is true that all types of data can be enclosed in single quotes, a single quotation mark will be added to any data when a MySQL statement is generated, use mysql_escape_string to escape all special characters in the received characters. In this way, the received string is completely "restricted" between single quotes.

However, it seems that the conversion and normal strings in strings similar to the like clause are different once and for all. In addition, if any update in the AMP involves escaping, problems may occur. Are there solutions to these two problems once and for all? Is there any other problem?

Can all types of data in other databases be enclosed in single quotes?

Reply to discussion (solution)

Php and mysql have filter functions, which can give you peace of mind.

Niu has been very enthusiastic about helping others.

I recommend that you use the php framework because the framework has an SQL injection prevention mechanism.
Such as thinkphp and yii

There is no permanent method
Although no attack methods other than SQL attacks have been reported yet, it cannot be said that there will be no new methods
If you can, once and for all, you have to guard against the future (a little sci-fi)

Php once thought it could help you prevent SQL attacks.
Therefore, the limit that only one SQL command can be executed at a time and the magic_quotes_gpc automatic Escape Switch are enabled.
However, as they expected, there are still many php programmers talking about the so-called SQL attacks.
In view of the inability to establish trust relationships, php gave up the support for automatic escape and relaxed the constraints on sending SQL commands.

As a result, the so-called security issues are completely on the programmer's own ....