MySQL执行环境中的SQL_MODE设置如何影响SQL解析流程？

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 —— 必须在连接初始化时显式设置，或在配置文件中固化全局值。