sql_mode 的真正定位：解析之后、执行之前的“裁判员”
对于 sql_mode，不少开发者容易陷入一个常见误解：将其视为直接影响 SQL 解析流程的控制开关。实际上，它是在词法解析与语法解析全部完成之后、语句真正执行之前发挥关键作用的中间层——主要负责语义校验以及运行时行为策略的裁定。
换言之，它并不参与 SELECT 或 GROUP BY 语句的构建过程，但会决定“刚才解析完成的那条语句，是否真正被允许执行”，以及“执行过程中遇到不合规的数据应当如何处理”。
为什么 SET sql_mode 后有些 SQL 突然报错（比如 ERROR 1055）？
许多开发者可能曾遇到这样的情形：一条原本运行正常的 GROUP BY 查询，在启用了 ONLY_FULL_GROUP_BY 之后，立刻抛出 ERROR 1055 错误。这背后的机制是什么？
这并非解析阶段出现问题，而是 MySQL 在语义分析环节增加了一道额外检查——它将一部分运行时行为判断提前到了这一阶段执行。
ONLY_FULL_GROUP_BY的规则非常明确：SELECT子句中所有非聚合列，都必须出现在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"被当作标识符（列名或表名），而不是字符串字面量。此时字符串必须使用单引号。PIPES_AS_CONCAT：将||从逻辑 OR 操作符变为字符串拼接操作符，行为类似CONCAT()函数。关闭状态下a || b是布尔运算，一旦开启就变成了CONCAT(a, b)。
这两个模式一旦启用，会直接改变 MySQL 内部 lexer 对 token 的分类逻辑，属于真正的“语法层面干预”。切换它们可能导致原有的 SQL 报出 ERROR 1054（未知列）或产生逻辑错误（|| 意外被当作拼接处理）。
这里有一个容易被忽略的细节：这些模式是会话级的。如果应用使用了连接池复用连接，不能假设每次获取的连接都具备相同的 sql_mode——必须在连接初始化时显式设置，或者在配置文件中固化全局值。否则，同样的 SQL 在不同连接上可能表现出完全不同的行为，排查起来相当棘手。
