3 Essential MySQL Interview Questions *

Since the text1 and text2 columns are marked as NOT NULL and have no explicit DEFAULT clauses, attempts to insert implicit NULL values into these columns should presumably fail (note that you can use the SHOW CREATE TABLE statement to see which columns have an explicit DEFAULT clause). So accordingly, these two INSERT statements should fail since they don’t specify a value for one or more of these columns.

If strict SQL mode is enabled, an error will indeed occur and the statements will be rolled back. (Note: In the case of a multi-row statement on a non-transactional table, an error occurs, but if this happens for the second or subsequent row of the statement, the preceding rows will have been inserted.)

However, if strict SQL mode is *not enabled,* MySQL sets the column to the implicit default value for the column data type rather than failing.

In MySQL, implicit defaults are determined as follows:

• For numeric types, the default is typically zero.
• For date and time types, the default is the appropriate “zero” value for the type. (This actually a bit more complicated for fields with the type TIMESTAMP.)
• For string types (other than ENUM), the default value is the empty string. For ENUM, the default is the first enumeration value.

Therefore, after the above two INSERT statements are executed, the contents of the table will be as follows:

mysql> SELECT * FROM example;
+----+-------+-------+
| id | text1 | text2 |
+----+-------+-------+
|  1 |       | foo   |
|  0 | test  | foo   |
+----+-------+-------+

As shown, MySQL has inserted an empty string into column text1 on the first row, and zero into column id on the second row, even though each column is defined as NOT NULL with no DEFAULT clause.

The updated table will then be as follows:

+-----------+--------+---------------------+---------------------+
| team1     | team2  | start               | end                 |
+-----------+--------+---------------------+---------------------+
| uruguay   | brazil | 2014-07-17 20:50:10 | 2014-07-17 20:44:35 |
+-----------+--------+---------------------+---------------------+

Note that, in addition to the team1 column being modified, the start column was automatically updated as well, but the end field remained unchanged. Why?

The reason the start column was automatically updated is that its type is TIMESTAMP. Fields of type TIMESTAMP have the behavior that when a record in the table is updated, the TIMESTAMP field (i.e., the start field in this example) gets updated to reflect the then-current time.

But surprisingly, if we have multiple columns of type TIMESTAMP, only the first TIMESTAMP column has this behavior but the others do not. That is why the end field remains unchanged in this example.

Creating a grant in MySQL can effectively create the user as well. MySQL users are implemented in a very rudimentary fashion. The biggest misunderstanding in this area surrounds the idea of a user. In most databases a username is unique by itself. In MySQL, however, it is the combination of user and hostname that must be unique. So, for example, if I create user john@localhost, john@server2 and john@server3, they are actually three distinct users, which can have distinct passwords and privileges. It can be very confusing that “john” logging in from the local command line has different privileges or password than john logging in from server2 and server3.