Talk about conclusions first

The root cause of this problem is caused by the rigorous SQL. Because there is no strict restrictions before the 5.7 version, there is no error, but after 5.7, the default restrictions are required. The DBA needs to be decided to ignore the error based on the actual production situation, or optimize the SQL to solve the error.

If you want to ignore the error, then remove the default restrictions of version 5.7, that is, remove the "only_full_group_by" in the sql_mode. Your SQL, the specific analysis method will give a simple chestnut to explain.

cause

There are often various errors in development, and there are often many solutions. There are often many solutions. There are roughly "covering methods", "indirect solutions", and "direct solutions". The use of "covering the law" will sooner or later occur more serious problems in other times or other scenes, and it will be worthless; although the "indirect solution" can solve the current problem, it is known that it is not known, and often the code can solve the code. Reading and understanding are not high, and even introduced other potential bugs; so the most suitable is of course "direct solution", but the problem of directly solving the problem requires the root cause. So this is also a foundation for polishing the product, and it is slowly grinded.

When it comes to home, I will give a little chestnut to explain the reason.

CREATE TABLE tbl_a (
  ID BIGINT (20) Not Null Auto_increment Comment 'Main Key',
     a_Name Varchar (20) Not Null Comment 'A name',
  PRIMARY KEY (id)
 ) ENGINE = InnoDB Default Charset = UTF8MB4 Comment = 'A A;

CREATE TABLE tbl_b (
     ID BIGINT (20) Not Null Auto_increment Comment 'Main Key',
     `Code` varchar (32) NOT NULL Comment 'Unique Code',
     B_Name Varchar (20) Not Null Comment 'B Name',
  PRIMARY KEY (id),
	UNIQUE KEY uni_code (`code`)
 ) ENGINE = Innodb Default Charset = UTF8MB4 Comment = 'B Table';

CREATE TABLE tbl_c (
     ID BIGINT (20) Not Null Auto_increment Comment 'Main Key',
     c_name varchar (20) not null comments 'C name',
  PRIMARY KEY (id)
 ) ENGINE = Innodb Default Charset = UTF8MB4 Comment = 'C Table';

CREATE TABLE tbl_d (
     ID BIGINT (20) Not Null Auto_increment Comment 'Main Key',
     `code` varchar (32) not null comments 'b encoding',
  a_id BIGINT(20) NOT NULL COMMENT 'aID',
     c_name varchar (20) not null comments 'C name',
     d_name varchar (20) not null comments 'd name',
  PRIMARY KEY (id)
 ) ENGINE = Innodb Default Charset = UTF8MB4 Comment = 'D Table';

CREATE TABLE tbl_e (
     ID BIGINT (20) Not Null Auto_increment Comment 'Main Key',
  d_id BIGINT(20) NOT NULL COMMENT 'dID',
     E_Name Varchar (20) Not Null Comment 'E Name',
  PRIMARY KEY (id)
 ) ENGINE = Innodb Default Charset = UTF8MB4 Comment = 'E Table';

Create 5 tables, where A, B, and C are all basic information tables, and D, E tables are a comprehensive information table. It establishes a connected relationship because it associates a field in the basic information table.

Now we execute the following SQL, let's see what will happen to the execution results?

SELECT a.*, b.*, c.id, d.*, e.*
FROM tbl_d d
LEFT JOIN tbl_c c ON c.c_name = d.c_name
LEFT JOIN tbl_b b ON b.`code` = d.`code`
LEFT JOIN tbl_a a ON a.id = d.a_id
LEFT JOIN tbl_e e ON e.d_id = d.id
GROUP BY d.id;

turn out
> 1055 - Expression #11 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'ppay.c.id' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by
> Time: 0.042s

What will happen to this SQL?

SELECT a.*, b.*, d.*
FROM tbl_d d
LEFT JOIN tbl_c c ON c.c_name = d.c_name
LEFT JOIN tbl_b b ON b.`code` = d.`code`
LEFT JOIN tbl_a a ON a.id = d.a_id
LEFT JOIN tbl_e e ON e.d_id = d.id
GROUP BY d.id;

turn out
> OK
> Time: 0.043s

What will happen to this SQL?

SELECT a.*, b.*, c.id, d.*, e.*
FROM tbl_d d
LEFT JOIN tbl_c c ON c.c_name = d.c_name
LEFT JOIN tbl_b b ON b.`code` = d.`code`
LEFT JOIN tbl_a a ON a.id = d.a_id
LEFT JOIN tbl_e e ON e.d_id = d.id
GROUP BY c.id, d.id, e.id;

turn out
> OK
> Time: 0.043s

What will happen to this SQL?

SELECT a.*, b.*, ANY_VALUE(c.id), d.*, e.*
FROM tbl_d d
LEFT JOIN tbl_c c ON c.c_name = d.c_name
LEFT JOIN tbl_b b ON b.`code` = d.`code`
LEFT JOIN tbl_a a ON a.id = d.a_id
LEFT JOIN tbl_e e ON e.d_id = d.id
GROUP BY d.id, e.id;

turn out
> OK
> Time: 0.042s

why?

From the wrong literal meaning, the field of SELECT and the Group By field cannot be logically dependent. The vernacular is that there may be multiple fields after the group by group. Restriction, you will directly report an error.(Official error code manual）

So why can the latter SQL be successfully executed? In fact, it is essentially solved the problem that cannot be dependent on deduction, but there are many solutions.

The first one is well understood. We removed the selct field that will produce ambiguity; the second is that since the select is ambiguous, I will bring you on the group, so that you do not have ambiguity; the third is Mingming. Knowing ambiguity, but I do n’t care about the consequences of this ambiguity, you just return to a value at will;

Next, let's talk about why the ID of Table D is paid, and table A and B will not produce ambiguity, and table C and E will produce ambiguity? Because there is a table A ID in the D table, that is, a D.id can only derive an A.ID. Similarly, for Table B, it is stored in a Code field containing the unique index. Through a D d .id can also deduce a B.Code. But for Table C, it is stored in ordinary field names, and a D.id can derive countless B.Name. You may have doubts when you see here. Isn't the D table the ID of the Dets stored? Why is there still ambiguity? The answer is simple, because the dependency is reversed. E.id can derive the only D.ID through E.ID, but it cannot derive the only E.ID through D.ID.

At the end

I believe that you can optimize your SQL according to the actual production scenario. I want to talk about the "ignoring error" solution at the beginning of the article, that is, the method of solving the problem by removing the "only_full_group_by". Because he told his colleagues to solve it at the time, he said that he had modified but did not take effect. The following method should be specifically explained and what the best practice should be.

MySQL is a multi -threaded application. For the connection to each establishment, a new thread will be opened, and each thread will have a session session, which is preserved with the unique configuration of the session, including "only_Full_group_by" discussed in this article. Where did the configuration in the session come from? The answer is read from the global configuration, so when a new session is turned on, its configuration comes from the global configuration. Where did the global configuration come from? The answer is MySQL configuration file (Linux's*.cnf file, Windows*.ini file), which contains configuration items about sql_mode. When the service starts, it is initialized through this value. Okay, see here, I believe you should know which values ​​need to be restarted, that is:

To modify the global configuration, you only need to disconnect and re -connect to establish a new session, but after the MySQL service restarts, it will still roll back (disconnecting and re -connection. For the web service, it is to restart the web service), and modify the session of the session. Do not disconnect the consecutive company (that is, for web services, do not restart the service), otherwise the global configuration is used. Finally, if you modify the configuration file, you need to restart mysql to take effect.

In summary, the best practice should be to modify the configuration items in the MySQL configuration file, and modify the global configuration item. This only needs to be disconnected and re -connected. The establishment of a new session can take effect immediately.

        have a nice time！（Original link）