strict_trans_tables通过强制报错拦截非法数据写入，堵住隐式截断与类型转换导致的越权绕过路径，使应用层权限校验真正生效；它仅对innodb等事务表生效，需全局配置并验证。
开启严格SQL模式（STRICT_TRANS_TABLES）本身不防越权，但它能切断一类典型的“隐式绕过”路径：当应用层校验依赖字段类型或长度做逻辑判断时，宽松模式下的静默截断、隐式转换会让校验失效，从而让攻击者用畸形输入绕过本该生效的权限控制。
为什么STRICT_TRANS_TABLES会影响越权判断逻辑
MySQL默认使用宽松模式，对超长字符串、非法数字、空值插入等行为会自动截断、补零或转成0，而不报错。这种“容错”在业务逻辑中极易被利用：
- 比如用户ID字段是
VARCHAR(8)，应用代码假设“只要传入的是8位以内数字字符串，就一定是合法UID”，但攻击者传入'123456789' || ' OR 1=1'，宽松模式下自动截成'12345678'，绕过长度校验后仍拼进SQL - 再如状态字段是
TINYINT，应用只允许0或1，但攻击者传入'1admin'，MySQL转成1并静默接受，导致WHERE条件失效 - 这类截断/转换不会触发错误，日志里也看不到异常，但实际已破坏了应用层“输入即可信”的前提假设
STRICT_TRANS_TABLES如何堵住这个缺口
启用后，上述操作全部变为报错（ERROR 1265 (01000): Data truncated for column ... 或 ERROR 1366 (HY000): Incorrect integer value），强制应用必须显式处理非法输入：
- 截断不再静默发生，
INSERT INTO users (uid) VALUES ('123456789')直接失败，无法进入后续查询逻辑 - 类型强转失败，
WHERE status = '1admin'不再被当成status = 1，而是报错中断执行 - 空字符串插入
NOT NULL字段、非法日期等均被拦截，避免因数据失真导致的权限校验错位
它和权限配置的关系不是替代，而是协同
严格模式不能代替GRANT SELECT ON app_db.users TO 'app_user'@'10.20.%'这类最小权限设置，但它能让权限真正“落在实处”：
- 没有严格模式时，一个本该被
WHERE user_id = ? AND tenant_id = ?双校验拦住的请求，可能因tenant_id被截断为固定值而漏过 - 有严格模式后，这类数据异常会在第一层就被数据库拒绝，根本不会走到权限校验环节——相当于把“越权前的越界输入”提前卡死
- 注意：
STRICT_TRANS_TABLES只对事务型存储引擎（InnoDB）生效；MyISAM表需配合STRICT_ALL_TABLES
真正容易被忽略的是：很多团队开了sql_mode但没验证是否全局生效，比如只在会话级SET，或配置写在[client]段而非[mysqld]段。上线前务必用SELECT @@sql_mode;确认服务端全局值已包含STRICT_TRANS_TABLES。
