sql_mode 是解析后、执行前的语义校验与行为策略层，决定语句是否允许执行及非法值处理方式；它不改变语法解析，但影响语义合法性检查（如 only_full_group_by 触发 error 1055）、数据校验严格度（strict_trans_tables 仅限事务表，strict_all_tables 覆盖所有表）及少数词法解析行为（ansi_quotes、pipes_as_concat）。
sql_mode 不是“影响解析流程”的开关，而是在解析之后、执行之前起作用的校验与行为策略层。它不改变词法/语法解析器如何识别 SELECT 或 GROUP BY，但会决定“解析成功后的语句是否被允许执行”，以及“执行时对非法值怎么处理”。
为什么 SET sql_mode 后有些 SQL 突然报错（比如 ERROR 1055）？
典型现象：一条原本能跑通的 GROUP BY 查询，在开启 ONLY_FULL_GROUP_BY 后直接报错 ERROR 1055。
这不是解析失败，而是 MySQL 在语义分析阶段做了额外检查：
-
ONLY_FULL_GROUP_BY要求：所有非聚合列（如SELECT name）必须出现在GROUP BY子句中 - 检查发生在解析树生成后、优化器介入前，属于“语义合法性校验”
- 一旦不满足，MySQL 直接拒绝执行，不生成执行计划
换句话说：sql_mode 把一部分“运行时行为判断”提前到了“语义验证环节”。它让 MySQL 从“尽力执行”转向“按规则裁决”。
STRICT_TRANS_TABLES 和 STRICT_ALL_TABLES 的区别在哪？
两者都属于“严格模式”，但触发时机和覆盖范围不同：
-
STRICT_TRANS_TABLES：仅对事务型表（如InnoDB）启用严格插入校验；遇到超长字符串、非法日期等，直接报错中断 -
STRICT_ALL_TABLES：对所有表（包括MyISAM）都启用严格校验 - 关键差异：非事务表在
STRICT_TRANS_TABLES下仍可能静默截断或转为默认值（如插入'abcde'到VARCHAR(3)可能变成'abc'），而STRICT_ALL_TABLES会让它报错
生产环境推荐用 STRICT_TRANS_TABLES，因为绝大多数业务表是 InnoDB；若混用 MyISAM 且需统一行为，才考虑后者。
NO_ZERO_DATE 和 NO_ZERO_IN_DATE 实际影响哪些操作？
这两个模式常被一起启用，但作用对象不同：
-
NO_ZERO_DATE：禁止插入或更新为'0000-00-00'这种“零日期”字面量，报错ERROR 1292 -
NO_ZERO_IN_DATE：禁止日期中月份或日为零，例如'2023-00-15'或'2023-12-00'，同样触发ERROR 1292 - 注意：
NO_ZERO_IN_DATE在 MySQL 8.0.19+ 已被标记为 deprecated，但目前仍生效；新部署建议配合STRICT_TRANS_TABLES使用更明确的日期校验逻辑
它们不会影响函数返回值（如 NOW()），只约束显式写入的字面量或参数值。
ANSI_QUOTES 和 PIPES_AS_CONCAT 改变的是词法解析行为
这是少数真正影响“解析阶段”的 sql_mode 值：
-
ANSI_QUOTES：让双引号"col"被当作标识符（列名/表名）而非字符串字面量；此时字符串必须用单引号'value' -
PIPES_AS_CONCAT：把||解析为字符串拼接操作符（类似CONCAT()），而不是逻辑 OR；关闭时a || b是布尔运算，开启后是CONCAT(a, b)
这两个值一旦启用，会改变 MySQL 内部 lexer 的 token 分类逻辑，属于真正的“语法层面干预”。切换它们可能导致原有 SQL 报 ERROR 1054（未知列）或逻辑错误（|| 意外变成拼接）。
最容易被忽略的一点：这些模式是会话级的，应用连接池复用连接时，不能假设每次拿到的连接都具备相同的 sql_mode —— 必须在连接初始化时显式设置，或在配置文件中固化全局值。
