理解 MySQL SQL Modes：快速指南
Tony Darnell
February 24, 2026 原文
如果你曾经深入研究过 MySQL 配置，你可能见过"SQL modes"这个术语。这些是强大的设置，可以改变 MySQL 解释 SQL 查询、处理数据验证甚至强制执行某些标准的方式。但能力越大责任越大——选择错误的 mode 可能会导致意外行为、数据不一致或兼容性问题。在本文中，我们将分解什么是 SQL modes，列出 MySQL 中所有可用的不同 modes（重点关注最新的 8.4 版本），解释它们的用途，并讨论何时应该使用它们……或避开它们。无论你是第一次设置数据库的初学者，还是为生产环境进行优化的资深 DBA，本指南都能满足你的需求。让我们从基础开始。
什么是 SQL Modes 以及它们如何工作？
MySQL 中的 SQL modes 本质上是服务器的行为修饰符。它们控制诸如支持的 SQL 语法、在插入或更新期间如何验证数据，以及某些操作是产生错误还是警告等方面。这种灵活性使 MySQL 能够适应不同的环境——例如，模拟其他数据库系统或强制执行更严格的数据完整性规则。
这里的关键角色是 sql_mode 系统变量，你可以在 全局级别（影响所有客户端）或 每个会话（仅针对当前连接）进行设置。Modes 可以影响从日期处理到运算符优先级的方方面面，帮助你根据应用程序的需求定制 MySQL。
例如，在 严格 modes 下，MySQL 将无效数据视为 outright 错误，而在更宽松的 modes 下，它可能只是调整值并发出警告。
为什么要使用它们？它们能促进更好的代码实践、确保兼容性并防止微妙的 bug。但如果误用，你可能会遇到数据损坏或查询神秘失败的情况。MySQL 8.4 中的 默认 modes 包括 ONLY_FULL_GROUP_BY、STRICT_TRANS_TABLES、NO_ZERO_IN_DATE、NO_ZERO_DATE、ERROR_FOR_DIVISION_BY_ZERO 和 NO_ENGINE_SUBSTITUTION——对于大多数用户来说，这是一个可靠的起点。
如何设置和管理 SQL Modes
在我们深入探讨 modes 本身之前，让我们先谈谈如何配置它们：
启动时： 在 MySQL 命令行或选项文件（如 my.cnf）中添加 --sql-mode="modes"。使用逗号分隔多个 modes，例如 --sql-mode="STRICT_TRANS_TABLES,NO_ZERO_DATE"。要禁用所有内容，将值设置为空字符串。
运行时： 使用 SQL 语句，如 SET GLOBAL sql_mode = 'modes'; 进行服务器范围的更改（需要管理员权限），或 SET SESSION sql_mode = 'modes'; 仅针对你的会话。
检查 Modes： 运行 SELECT @@GLOBAL.sql_mode; 或 SELECT @@SESSION.sql_mode; 查看当前激活的 modes。
注意事项： 不要在创建分区表后更改 modes，否则可能导致数据损坏。此外，在复制设置中，保持源服务器和副本服务器之间的 modes 一致。
完整的独立 SQL Modes 列表
MySQL 提供了 多种 modes，每种都针对特定行为。以下是概述，包括它们的作用、用途、何时使用以及为什么要避免使用。为了清晰起见，我将相似的 modes 分组在一起。
日期和时间处理 Modes
ALLOW_INVALID_DATES： 不执行完整的日期检查。它只检查月份是否为 1-12，日期是否为 1-31，忽略诸如 2 月有 30 天之类的事情。适用于单独处理日期部分而无需完整验证的应用程序；忽略诸如 '2004-04-31' 的插入错误。但如果你想要严格的数据完整性，请避免使用它——它可能导致存储无意义的日期。
NO_ZERO_DATE（已弃用）： 将 '0000-00-00' 视为无效。在严格模式下，它会报错；否则，它会发出警告。非常适合确保日期有意义，但由于它已被弃用，请依靠严格模式来避免未来的兼容性问题。
NO_ZERO_IN_DATE（已弃用）： 不允许月份或日期部分为零（例如 '2010-00-01'）。与上述类似——用于验证，但由于它正在被集成到严格模式中，应逐步淘汰。
TIME_TRUNCATE_FRACTIONAL： 在插入到精度较低的时间列时，截断小数秒而不是四舍五入。如果你更喜欢截断以保持时间数据的一致性，这很有用；否则，坚持默认的四舍五入。例如，未启用此功能时，TIME(1) 的值 1.55 将四舍五入为 1.6。启用此功能后，截断的值将为 1.5。
语法和引号 Modes
ANSI_QUOTES： 将双引号（"）视为标识符引号——与单反引号（`）引号字符相同——而不是字符串引号。你不能使用双引号来引用字面量字符串，因为它们会被解释为标识符。非常适合 ANSI SQL 合规性，但如果你的代码使用双引号表示字符串，请避免使用——它会破坏你的查询。
HIGH_NOT_PRECEDENCE： 在诸如 NOT a BETWEEN b AND c 的表达式中给予 NOT 更高的优先级。适用于期望旧版 MySQL 行为的遗留应用程序；现代代码应使用括号来避免歧义。诸如 NOT a BETWEEN b AND c 的表达式被解析为 NOT (a BETWEEN b AND c)。
IGNORE_SPACE： 允许函数名和括号之间有空格，将它们视为保留字。有助于防止标识符冲突（例如，名为 count 的列），但它需要引用此类标识符，这可能会很麻烦。例如，因为存在 COUNT() 函数，使用 count 作为表名会导致错误——CREATE TABLE count (i INT); 相反，请使用 CREATE TABLE `count` (i INT);
NO_BACKSLASH_ESCAPES： 在字符串中禁用反斜杠（\）作为转义字符。适用于避免转义的环境，但它会更改默认行为，如 LIKE 子句中的行为——不适合标准 SQL。启用此 mode 后，反斜杠变成与其他字符一样的普通字符。
PIPES_AS_CONCAT： 使 || 充当字符串连接而不是逻辑 OR。非标准但适用于自定义语法；为了 SQL 可移植性请避免使用。
数据验证和错误 Modes
ERROR_FOR_DIVISION_BY_ZERO（已弃用）： 在除以零时产生警告或错误。对于捕获数学问题至关重要；与严格模式一起使用，但由于已弃用，应逐步淘汰。
NO_AUTO_VALUE_ON_ZERO： 防止在插入 0 时自增；只有 NULL 才会触发它。在数据转储期间对于保留序列至关重要，但其他情况下很少使用——不建议正常使用。
NO_UNSIGNED_SUBTRACTION： 允许无符号减法产生负数结果。当你需要从无符号类型获得有符号输出时很有用；没有它，负数会产生错误。
ONLY_FULL_GROUP_BY： 强制执行标准 GROUP BY 规则，拒绝模糊查询。默认设置且强烈推荐以防止 bug；仅对非常旧的应用程序避免使用。
PAD_CHAR_TO_FULL_LENGTH（已弃用）： 在检索时将 CHAR 列填充到完整长度，保留尾随空格。（默认情况下，检索时会从 CHAR 列值中修剪尾随空格。）注意：此 mode 不适用于 VARCHAR 列，VARCHAR 列在检索时会保留尾随空格。
存储和创建 Modes
NO_DIR_IN_CREATE： 在 CREATE TABLE 中忽略目录子句。在复制中非常有用，可以避免路径问题；否则，如果你需要自定义目录，请启用它。
NO_ENGINE_SUBSTITUTION： 如果指定的存储引擎不可用，则报错，而不是替换。这是默认启用的，有利于严格控制；如果你想要带警告的回退，请禁用它。
REAL_AS_FLOAT： 使 REAL 成为 FLOAT 的同义词（而不是 DOUBLE）。用于 ANSI 合规性；如果你期望 REAL 表示 DOUBLE，请避免使用（因为默认情况下，MySQL 将 REAL 视为 DOUBLE 的同义词）。
严格 Modes
STRICT_ALL_TABLES： 为所有存储引擎启用 严格 验证，对无效数据报错。非常适合完整性，但可能导致非事务性表的部分更新——谨慎使用。
STRICT_TRANS_TABLES： 对事务性表启用 严格 模式；对于其他表，在第一行之后调整无效值并发出警告。大多数场景下的平衡默认选择。
便捷组合 Modes
MySQL 还提供了 组合（简写）modes，将多个 modes 捆绑在一起：
ANSI： 包括 REAL_AS_FLOAT、PIPES_AS_CONCAT、ANSI_QUOTES、IGNORE_SPACE、ONLY_FULL_GROUP_BY。非常适合 标准 SQL 合规性，但要注意语法变化。
TRADITIONAL： 捆绑严格 modes 以及日期和除法处理。就像以"严格传统"模式运行 MySQL——非常适合强大的错误检查。它等效于 STRICT_TRANS_TABLES、STRICT_ALL_TABLES、NO_ZERO_IN_DATE、NO_ZERO_DATE、ERROR_FOR_DIVISION_BY_ZERO 和 NO_ENGINE_SUBSTITUTION。
严格 SQL Mode：数据完整性的支柱
严格 mode（通过 STRICT_ALL_TABLES 或 STRICT_TRANS_TABLES）的核心是拒绝不良数据。它将无效的插入/更新转换为错误，并在需要时回滚事务。它非常适合尽早捕获问题，但在非事务性表中，它可能允许部分更改——如果这是问题，请使用 IGNORE 降级为警告。总体而言，启用它以获得更好的可靠性。
何时使用 SQL Modes（以及何时不使用）
在开发中： 提高严格 modes，如 TRADITIONAL 或 STRICT_ALL_TABLES，以快速发现错误。添加 ONLY_FULL_GROUP_BY 以获得清晰的查询。这有助于在问题进入生产环境之前进行调试。
在生产中： 坚持默认设置以保持平衡，或根据你的应用程序进行自定义。使用全局设置以保持一致性，但允许会话调整。避免使用已弃用的 modes 以使你的设置面向未来。如果你在处理遗留代码，像 HIGH_NOT_PRECEDENCE 这样的 modes 可以弥合差距，但应尽可能进行重构。
使用的原因： 增强验证、兼容性和错误预防。
避免的原因： 可能导致旧代码中断、在非常宽松的设置中产生性能开销，或者你需要非标准行为。
总结
SQL modes 是 MySQL 微调数据库行为的超能力。从默认设置开始，在开发环境中进行实验，并始终彻底测试更改。通过理解这些 modes，你将编写更健壮的应用程序并避免常见陷阱。
