防止SQL注入的核心是永远不拼接用户输入，而用参数化查询；需遵循最小权限原则、严格输入验证、禁用危险配置并启用MySQL安全参数。
防止 SQL 注入的核心是：**永远不拼接用户输入到 SQL 语句中**，而是通过参数化查询（预处理语句）让数据库严格区分“代码”和“数据”。这是最有效、最基础的防线。
使用预处理语句（PreparedStatement）
无论用哪种编程语言连接 MySQL（如 PHP 的 PDO/MySQLi、Python 的 pymysql、Java 的 JDBC、Node.js 的 mysql2），都必须使用带占位符的预处理方式，而非字符串拼接。
- ✅ 正确示例（PHP + PDO）：
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ? AND status = ?");<br>$stmt->execute([$user_input, 'active']); - ❌ 错误示例（拼接导致注入）：
$sql = "SELECT * FROM users WHERE username = '" . $_GET['u'] . "'"; // 危险！
MySQL 服务端会将占位符后的值作为纯数据处理，不参与语法解析，从根本上杜绝注入可能。
最小权限原则配置数据库账户
应用连接数据库时，使用的账号不应拥有超出需要的权限。避免使用 root 或高权限账号部署业务系统。
- 只授予业务库的 SELECT/INSERT/UPDATE/DELETE 权限，禁用 DROP、ALTER、CREATE、FILE、EXECUTE 等高危权限
- 限制登录主机（如
'app_user'@'192.168.10.%'），禁止从任意地址（'%'）登录 - 定期审查账号权限：
SELECT user, host, account_locked FROM mysql.user;
输入验证与输出转义要分清场景
验证（Validation）应在业务逻辑层对用户输入做格式、长度、类型检查；转义（Escaping）不是防注入的可靠手段，仅在极少数无法使用预处理的遗留场景下临时补救（如动态表名、列名）。
- ✅ 对数字 ID：用
(int)$id或filter_var($id, FILTER_VALIDATE_INT)强制转整型 - ✅ 对邮箱、手机号等：用正则或内置过滤函数校验格式
- ⚠️ 避免依赖
mysql_real_escape_string()（已废弃）或addslashes()—— 它们无法防御所有编码绕过场景
启用安全相关 MySQL 配置
在 my.cnf 中调整关键参数，提升服务层防护能力：
-
sql_mode = STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION：开启严格模式，阻止非法数据静默截断 -
secure_file_priv = /var/lib/mysql-files/：限制 LOAD DATA / SELECT … INTO OUTFILE 的读写目录，防范文件类攻击 -
skip_symbolic_links = ON：禁止符号链接访问，防止绕过路径限制 - 关闭不必要的组件：
disabled_storage_engines = "MyISAM,ARCHIVE"（若不用）
修改后需重启 MySQL 生效，并用 SHOW VARIABLES LIKE 'sql_mode'; 确认生效。
