CHECK约束不能防止SQL注入，它仅在INSERT/UPDATE时校验字段值合法性，而SQL注入发生在SQL解析执行阶段，二者作用层级完全不同；真正有效的防护手段是参数化查询。
检查约束（CHECK）本身**不能防止SQL注入**，它只在数据写入时校验值是否满足逻辑条件，对恶意SQL语句毫无拦截能力。混淆这两者，容易在生产环境留下严重安全盲区。
为什么CHECK约束对SQL注入完全无效
CHECK 是表级数据完整性机制，发生在 SQL 执行的「语义层」之后——也就是说，攻击者的恶意语句必须先成功解析、编译、执行，才会走到插入/更新校验阶段。如果攻击者用 ' OR '1'='1 绕过登录验证，这条语句根本不会触发任何 CHECK；如果用 UNION SELECT password FROM mysql.user 盗取数据，也完全不涉及写操作，CHECK 压根不会被调用。
- SQL注入是语法层面的代码执行劫持，
CHECK是数据层面的值合法性过滤 -
CHECK不影响查询语句结构，只约束INSERT/UPDATE的字段值 - MySQL 8.0+ 默认启用
check_constraint_checks=ON，但该开关只控制约束是否生效，不改变执行时机
真正能防SQL注入的只有参数化查询
所有语言驱动（PDO、mysql2、pymysql、JDBC）都要求把用户输入作为**独立参数绑定**，而非字符串拼接。这是唯一经过验证、不可绕过的防护手段。
- PHP 示例：
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?"); $stmt->execute([$user_id]); - Python 示例：
cursor.execute("UPDATE accounts SET balance = %s WHERE uid = %s", (new_bal, uid)) - 错误做法：
"SELECT * FROM users WHERE id = " . $_GET['id']—— 无论后面加多少CHECK都拦不住
CHECK约束该用在哪儿？别错配场景
CHECK 的合理用途是兜底业务规则，且必须配合应用层校验。它不是安全机制，而是数据质量守门员。
- 适合场景：确保
age字段 ≥ 0 且 ≤ 150、status只能是'active'/'inactive'、price > 0 - 注意兼容性：MySQL 5.7 不支持
CHECK（会被忽略），MariaDB 10.2+ 行为略有差异 - 性能影响：复杂表达式（如嵌套函数、子查询）会拖慢写入，且 MySQL 8.0.16+ 才支持函数索引加速部分
CHECK条件 - 不要依赖它防越权：比如用
CHECK (created_by = CURRENT_USER())无法阻止攻击者伪造会话后直接连数据库执行INSERT
最常被忽略的一点：即使你写了完美的 CHECK，只要应用代码里存在一处字符串拼接，整个防护体系就形同虚设。安全链条的强度取决于最弱一环，而这一环永远在代码里，不在表定义中。
