According to the interview feedback from the group friends, 3 MySQL interview questions have been sorted out, which may be a piece of cake for many people. If you are familiar with these and have a better understanding, you can leave a message to supplement and continuously improve our question bank.
MySQL query field area is case insensitive?
MySQL innodb transaction and log implementation
Several log entry formats and differences of MySQL binlog
MySQL query field area is case insensitive?
The answer is no distinction
How to Solve the Scenarios That Need to Be Case-sensitive
For example, if the login user is admin, you can also log in by filling in ADMIN. If the user name needs to be case-sensitive, what would you do?
Solution one
MySQL's default character retrieval strategy: utf8_general_ci, which means case insensitive.
You can use utf8_general_cs, which means case sensitivity, or utf8_bin, which means binary comparison, which is also case sensitive.
Note: In Mysql5.6.10 version, utf8_genral_cs is not supported
When creating a table, directly set the collate attribute of the table to utf8_general_cs or utf8_bin; if the table has been created, directly modify the Collation attribute of the field to utf8_general_cs or utf8_bin.
– 创建表：
CREATE TABLE testt(
id INT PRIMARY KEY,
name VARCHAR(32) NOT NULL
) ENGINE = INNODB COLLATE =utf8_bin;
– Modify the Collation property of the table structure
ALTER TABLE TABLENAME MODIFY COLUMN COLUMNNAME VARCHAR(50) BINARY CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL;
Solution 2
Modify the sql statement directly and add the binary keyword in front of the field to be queried
– add binary keyword before each condition
select * from user where binary username = 'admin' and binary pass *word = 'admin';
– Surround parameters with binary('')
select * from user where username like binary('admin') and pass*word like binary('admin');
MySQL innodb transaction and log implementation
How many kinds of logs are there
Error log: record error information, and also record some warning information or correct information.
Query Log: Records information about all requests made to the database, regardless of whether these requests were executed correctly.
Slow query log: Set a threshold and record all SQL statements whose running time exceeds this value to the log file of slow query.
Binary log: Logs all operations that perform changes to the database.
Relay log: The relay log is also a binary log, which is used to restore the slave library
Transaction log: redo log redo and rollback log undo
4 isolation levels for things
Read Uncommitted (RU)
Read Committed (RC)
Repeatable Read (RR)
serial
How transactions are implemented through the log, the more in-depth the better
The transaction log is implemented by the storage engine log buffer (Innodb log buffer) of redo and innodb. When a transaction is started, the lsn (log sequence number) number of the transaction will be recorded;
When the transaction is executed, the transaction log is inserted into the log cache of the log of the InnoDB storage engine;
When a transaction is committed, the log buffer of the storage engine must be written to disk (controlled by innodb_flush_log_at_trx_commit), that is, the log needs to be written before data is written. This method is called "write-ahead log method"
Several log entry formats of MySQL binlog and the difference
Statement: each sql that modifies data will be recorded in binlog.
Advantages: It is not necessary to record the changes of each line, which reduces the amount of binlog logs, saves IO, and improves performance.
How much performance and log volume can be saved compared to row depends on the SQL situation of the application. Normally, the volume of logs generated by modifying or inserting the same record in row format is less than the volume of logs generated by Statement, but considering the conditional update operation , and operations such as whole table deletion, alter table, etc., ROW format will generate a large number of logs, so when considering whether to use ROW format logs, it should be based on the actual situation of the application, how much the amount of logs generated will increase, and the IO performance brought by it question.
Disadvantage: Since only the executed statements are recorded, in order for these statements to run correctly on the slave, it is necessary to record some relevant information of each statement when it is executed to ensure that all statements can be obtained on the slave and executed on the master side. the result of.
In addition, mysql replication, like some specific functions, the slave can be consistent with the master, there will be many related problems (such as sleep() function, last_insert_id(), and user-defined functions (udf) will have problems).
Statements using the following functions also cannot be replicated:
LOAD_FILE()
UUID()
USER()
FOUND_ROWS()
SYSDATE() (unless the --sysdate-is-now option was enabled at startup)
At the same time INSERT ...SELECT will generate more row-level locks than RBR
Row: Does not record the context-related information of the SQL statement, only saves which record is modified.
Advantages: The context-related information of the executed SQL statement can not be recorded in the binlog, and only the record needs to be recorded what has been modified.
Therefore, the log content of rowlevel will clearly record the details of each row of data modification. And there will be no problems that the stored procedures, or functions, and trigger calls and triggers cannot be copied correctly under certain circumstances.
Disadvantage: When all executed statements are recorded in the log, they will be recorded with the modification of each line, which may generate a large amount of log content.
For example, if an update statement modifies multiple records, each modification in the binlog will have a record, which will result in a large amount of binlog logs, especially when executing statements such as alter table, due to the modification of the table structure, each record will be changes, then each record in the table will be recorded in the log.
Mixedlevel: Mixed use of the above two levels.
The general statement modification uses the statment format to save the binlog. For example, some functions, if the statement cannot complete the master-slave replication operation, the binlog is saved in the row format. MySQL will distinguish the log format to be recorded according to each specific SQL statement executed. It is to choose between Statement and Row.
The row level mode has also been optimized in the new version of MySQL. Not all modifications will be recorded at the row level. For example, when the table structure is changed, it will be recorded in the statement mode. As for statements that modify data such as update or delete, the changes of all rows will still be recorded.