在 MySQL 5.7.5 中, ONLY_FULL_GROUP_BY 默认情况下启用 SQL 模式,因为
GROUP BY
处理已经变得更复杂,包括检测功能依赖。但是,如果您发现已 ONLY_FULL_GROUP_BY 启用导致现有应用程序的查询被拒绝,则这些操作中的任何一个都应恢复操作:
GROUP BY
列,或者通过使用非聚合列引用 ANY_VALUE() 。
sql_mode
在服务器启动时将系统变量设置为不启用 ONLY_FULL_GROUP_BY 。
在 MySQL 5.7.4,的 ERROR_FOR_DIVISION_BY_ZERO , NO_ZERO_DATE 和 NO_ZERO_IN_DATE SQL 模式已被弃用。从 MySQL 5.7.4 到 5.7.7,这些模式在明确命名时不做任何事情。相反,它们的效果包含在严格 SQL 模式( STRICT_ALL_TABLES 或 STRICT_TRANS_TABLES )的效果中。换句话说,严格模式在这些版本中意味着与严格模式加上,和 ERROR_FOR_DIVISION_BY_ZERO , 之前的 5.7.4 含义相同的东西 。 NO_ZERO_DATE NO_ZERO_IN_DATE
MySQL 的 5.7.4 的变化,使通过包括严格的模式更加严格 ERROR_FOR_DIVISION_BY_ZERO , NO_ZERO_DATE 以及 NO_ZERO_IN_DATE 引起了一些问题。例如,在具有严格模式但未 NO_ZERO_DATE 启用的 MySQL 5.6 中 , TIMESTAMP 可以使用定义列
DEFAULT '0000-00-00 00:00:00'
。在具有相同模式设置的 MySQL 5.7.4 中,严格模式包含的效果 NO_ZERO_DATE 和 TIMESTAMP 无法定义的列 DEFAULT '0000-00-00 00:00:00'
。这会导致 CREATE TABLE 从 5.6 到 5.7.4 的语句复制,如果它们包含这样的 TIMESTAMP 列,则会失败。
长期计划仍然是将三种受影响的模式纳入严格的 SQL 模式,并将其作为明确的模式在未来的 MySQL 版本中删除。但为了恢复 MySQL 5.7 与 MySQL 5.6 严格模式的兼容性,并为受影响的应用程序提供更多的时间修改,MySQL 5.7.8 中进行了以下更改:
通过上述更改,更严格的数据检查在默认情况下仍处于启用状态,但可以在当前需要或必需的环境中禁用各个模式。
虽然在 MySQL 5.7.8 及更高版本 ERROR_FOR_DIVISION_BY_ZERO 中 NO_ZERO_DATE ,并且 NO_ZERO_IN_DATE 可以与严格模式分开使用,但它们的目的是一起使用。提醒一下,如果在不启用严格模式的情况下启用警告,则会发生警告,反之亦然。
以下讨论仅适用于 MySQL 版本 5.7.4 到 5.7.7。对于从 MySQL 5.7.4 以前的版本升级,我们建议升级到 MySQL 5.7.8 或更高版本,这使得讨论不必要。
本节的其余部分描述了在 MySQL 5.7.4 到 5.7.7 中使用的 SQL 模式设置,以实现与 5.7.4 之前相同的语句执行,包括给出的情况 INSERT 和 UPDATE 在其中的
IGNORE
情况。它还提供了确定应用程序是否需要修改以在 SQL 模式更改之前和之后表现相同的指导原则。
下表显示了如何控制 MySQL 5.7.4 到 5.7.7 以及 MySQL 5.7.4 到 5.7.7 以外版本的除零处理。
期望的行为 | MySQL 5.7.x 版本除了 5.7.4 到 5.7.7 | MySQL 5.7.4 到 5.7.7 |
---|---|---|
插入 ,不会产生警告 |
未启用 |
严格模式未启用 |
插入 ,产生警告 |
,或 + 严格模式 +
|
严格模式 +
|
错误 | + 严格模式 |
严格模式 |
下表显示了如何控制服务器是否允许
'0000-00-00'
MySQL 5.7.4 到 5.7.7 以及 MySQL 5.7.4 到 5.7.7 以外的其他版本的有效日期。
期望的行为 | MySQL 5.7.x 版本除了 5.7.4 到 5.7.7 | MySQL 5.7.4 到 5.7.7 |
---|---|---|
插入 ,不会产生警告 |
未启用 |
严格模式未启用 |
插入 ,产生警告 |
,或 + 严格模式 +
|
严格模式 +
|
错误 | + 严格模式 |
严格模式 |
下表显示了如何控制服务器是否允许 MySQL 5.7.4 到 5.7.7 以外版本和 MySQL 5.7.4 到 5.7.7 版本的零部件日期。
期望的行为 | MySQL 5.7.x 版本除了 5.7.4 到 5.7.7 | MySQL 5.7.4 到 5.7.7 |
---|---|---|
插入日期,不会产生警告 | 未启用 |
严格模式未启用 |
插入 ,产生警告 |
,或 + 严格模式 +
|
严格模式 +
|
错误 | + 严格模式 |
严格模式 |
下面的讨论描述了在 5.7.4 到 5.7.7 的 SQL 模式变化下,给定语句产生相同或不同结果的条件。它只考虑严格模式( STRICT_ALL_TABLES 或 STRICT_TRANS_TABLES )和三个弃用模式( ERROR_FOR_DIVISION_BY_ZERO , NO_ZERO_DATE ,和 NO_ZERO_IN_DATE )。其他 SQL 模式(如 ANSI_QUOTES 或) ONLY_FULL_GROUP_BY 假定在升级之前和之后保持不变。
本讨论还介绍了如何准备从 5.7.4 以前的版本升级到 5.7.4 到 5.7.7。 升级前应做任何修改。
对于以下 SQL 模式设置,MySQL 5.6 和 5.7 之间的行为没有任何变化。在这些设置下执行的语句不需要修改就可以在 5.6 和 5.7 中产生相同的结果:
以下 SQL 模式设置会发生 MySQL 5.6 中的警告更改为 MySQL 5.7 中的警告。语句执行的结果在 5.6 和 5.7 中是相同的,因此语句不需要修改,除非警告被认为是重要的:
在以下 SQL 模式设置下发生行为更改。在这些设置下执行的语句必须修改,以在 5.6 和 5.7 中产生相同的结果:
'0000-00-00'
并产生一个警告。
NULL
并不产生警告。启用 ERROR_FOR_DIVISION_BY_ZERO 会导致一个错误,而不是。
要准备升级到 MySQL 5.7.4 到 5.7.7,主要原则是确保您的应用程序在 MySQL 5.6 和 5.7 中以相同的方式运行。例如,您可以采用以下任一方法来实现应用程序兼容性:
SET sql_mode
=
IF
(
LEFT
(
VERSION
(
)
,
3
)
<
'5.7'
,
5.6 mode
,
5.7 mode
);
在评估 MySQL 5.6 和 5.7 之间的 SQL 模式兼容性时,特别考虑这些语句执行上下文:
IGNORE
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE, SQL_MODE
FROM INFORMATION_SCHEMA.ROUTINES
WHERE SQL_MODE LIKE '%STRICT%'
OR SQL_MODE LIKE '%DIVISION%'
OR SQL_MODE LIKE '%NO_ZERO%';
SELECT TRIGGER_SCHEMA, TRIGGER_NAME, SQL_MODE
FROM INFORMATION_SCHEMA.TRIGGERS
WHERE SQL_MODE LIKE '%STRICT%'
OR SQL_MODE LIKE '%DIVISION%'
OR SQL_MODE LIKE '%NO_ZERO%';
SELECT EVENT_SCHEMA, EVENT_NAME, SQL_MODE
FROM INFORMATION_SCHEMA.EVENTS
WHERE SQL_MODE LIKE '%STRICT%'
OR SQL_MODE LIKE '%DIVISION%'
OR SQL_MODE LIKE '%NO_ZERO%';
来源: http://www.cnblogs.com/sunsky303/p/8033333.html