Foreword:
In various technical job interviews, it seems that MySQL-related questions are often asked. Whether you are interviewing for a development or operation and maintenance position, you will always ask a few database questions. There are often small partners who write to me privately, asking how to deal with MySQL interview questions. In fact, many interview questions are similar, so it is necessary to prepare in advance. This article briefly talks about a few common interview questions, let's learn together.
1. What is a relational database? Talk about your knowledge of MySQL.
This is a basic question to examine the interviewer’s understanding of the database. Generally speaking, you can simply talk about your own knowledge and be organized. such as:
A relational database refers to a database that uses a relational model to organize data, and stores data in the form of rows and columns. The biggest feature of relational databases is to support transactions. Common relational databases include MySQL, Oracle, SQLServer, etc. MySQL is currently the most popular open source database. Due to its small size, high speed, low total cost of ownership, especially the characteristics of open source, many companies use MySQL database to reduce costs. It is currently widely used in small and medium-sized websites on the Internet, especially suitable for OLTP field.
2. What are the common storage engines of MySQL and what are the differences?
This question is also often asked, similar to the question "The difference between InnoDB and MyISAM engines".
Several common storage engines:
- InnoDB : MySQL's default storage engine, supports transactions, MVCC, foreign keys, row-level locks, and auto-increment columns.
- MyISAM : Supports full-text indexing, compression, spatial functions, table-level locks, does not support transactions, and inserts fast.
- Memory : The data is in the memory, the data processing speed is fast, but the security is not high.
- ARCHIVE : Often used in historical archive tables, it takes up a small space and data cannot be updated or deleted.
Several differences between InnoDB and MyISAM engines:
- InnoDB supports transactions, MyISAM does not support transactions.
- InnoDB supports foreign keys, but MyISAM does not.
- InnoDB does not support full-text indexing, while MyISAM does.
- InnoDB is a clustered index, MyISAM is a non-clustered index.
- InnoDB does not store the specific number of rows in the table, while MyISAM uses a variable to store the number of rows in the entire table.
- InnoDB's smallest lock granularity is row locks, and MyISAM's smallest lock granularity is table locks.
- The storage structure is different. MyISAM tables are divided into three frm MYD MYI, and InnoDB is generally divided into two frm ibd.
3. Describe the MySQL infrastructure.
This question examines the interviewer's understanding of the MySQL architecture, and is similar to the question "The process of executing a select statement".
MySQL's logical architecture diagram (source: "MySQL 45 Lectures")
The logical architecture of MySQL is mainly divided into 3 layers:
- The first layer: For client connection processing, security authentication, authorization, etc., each client connection will have a thread on the server side, and the query initiated by each connection will be executed in a corresponding separate thread.
- The second layer: MySQL's core service function layer, including query resolution, analysis, query cache, built-in functions, stored procedures, triggers, views, etc. The select operation will first check whether the query cache is hit, and if it hits, the cached data will be returned directly, otherwise Parse the query and create the corresponding parse tree.
- The third layer: storage engine, responsible for data storage and extraction, MySQL server communicates with the storage engine through API, shielding the differences between various engines, common storage engines are: InnoDB, MyISAM.
The execution flow of a select statement:
- The client through the connector to establish connection to MySQL server and obtain the user read and write permissions, and then submit the query.
- First, MySQL will query the submitted statement in the query cache . If it hits and the user has operation permissions on the table, it will directly return the query result in the query cache as the result of this query. The query ends here.
- If the query cache misses, it will come to the analyzer , and the analyzer will parse the statement and check its validity. If the statement does not conform to MySQL's grammatical specification, the executor will report an error, and the query ends here.
- If the statement is valid, it will come to the optimizer, and the optimizer will choose the best execution plan for the SQL statement.
- Finally, it comes to the executor . If the user has operation permissions on the table, the executor will call the interface provided by the storage engine to execute the SQL statement, and then return the query result to the client. The query ends here.
4. Talk about several commonly used field types.
This question examines the interviewer's understanding of MySQL field types, and can extend to many small questions, such as the difference between char and varchar.
Commonly used field type classification:
Numerical:
String type:
Date and time type:
The M in int(M) represents the maximum display width. "Maximum display width" Our first reaction is that the value of this field is the maximum allowable width of the value stored, thinking that we have built int(1), we cannot store the data 10. , In fact, this is not the meaning, int(5) and int(10) can store the same range.
The CHAR type is fixed-length, and MySQL always allocates enough space according to the defined string length. When saving CHAR values, fill spaces to the right of them to reach the specified length. When the CHAR value is retrieved, the trailing spaces are deleted. The VARCHAR type is used to store variable-length character strings. When storing, if the character does not reach the defined number of digits, it will not add a space after it. The M in char(M) and varchar(M) both represent the maximum number of characters to be saved. A single letter, number, Chinese, etc. all occupy one character.
5. Talk about the role and structure of the index and its usage specifications.
Regarding the index, there can be many, many questions, and I may not understand a few articles. Simply share the answers to such questions:
The purpose of indexing is to improve query efficiency. It can be analogous to the directory in the dictionary. When looking up the contents of the dictionary, you can find the storage location of the data according to the directory, and then get it directly. The index is a table of contents. You can find the index position in the table of contents before searching the contents, so as to quickly locate the query data.
Under the InnoDB engine, the B+Tree index is mainly used. Each index is actually a B+ tree. The B+ tree is a balanced search tree (not a binary tree) designed for disks and other storage auxiliary devices. In the B+ tree In, all the data is in the leaf nodes, and each leaf node has a pointer to the next node, forming an ordered linked list.
From a physical storage perspective, InnoDB indexes can be divided into clustered indexes and secondary indexes or auxiliary indexes. The leaf nodes of a clustered index store the entire row of data. When a query uses a clustered index, you only need to scan a B+ tree of the clustered index to get the required records. If you want to search through the secondary index For complete records, you need to go through the table-back operation, that is, find the complete record in the clustered index after finding the primary key value through the secondary index.
The advantage of the index is obviously that it can speed up the query, but there is a price to create an index. First of all, a B+ tree must be created for each index created, which will occupy additional storage space; secondly, when the data in the table is added, deleted, or modified, the index also needs to be dynamically maintained, which reduces the data maintenance speed . Therefore, there are principles when creating and using indexes. Generally, indexes are only created for columns used for searching, sorting, grouping, and joining, and indexes are not created for columns with poor selectivity.
6. Talk about the characteristics and isolation levels of MySQL transactions.
MySQL transaction-related issues are often asked, and some principles still need to be studied in depth.
Four characteristics of ACID:
- A (Atomicity, atomicity): The operations in a transaction either all succeed or all fail.
- C (Consistency, consistency): The database always transitions from one consistency state to another consistency state. If the constraint is broken, the consistency condition is not met.
- I (Isolation, isolation): The execution of a transaction cannot be interfered by other transactions. That is, the internal operations and data used by a transaction are isolated from other concurrent transactions, and each transaction executed concurrently cannot interfere with each other.
- D (Durability, durability): After the transaction is committed, the changes it makes will be permanently saved to the database.
Transaction isolation level:
- Read Uncommitted: Modifications in a transaction, even if they are not committed, are visible to other transactions.
- Read Committed (Read Committed): Modifications in a transaction are only visible to other transactions after they are committed.
- Repeatable Read: The same record is queried multiple times in a transaction, and the result is always the same (the default isolation level).
- Serializable (Serializable): Transactions are executed serially. Reading will add a read lock, and writing will add a write lock.
Problems caused by concurrent transactions:
- Dirty Reads: Transaction A reads the uncommitted data of transaction B, and then B rolls back the operation, then the data read by A is dirty data.
- Non-Repeatable Reads: Transaction A reads the same data multiple times, and transaction B updates and commits the data in the process of transaction A reading multiple times, causing transaction A to read the same data multiple times , The results are inconsistent.
- Phantom Reads: Phantom Reads are similar to non-repeatable reads. It happens when a transaction A reads a few rows of data, and then another concurrent transaction B inserts some data. In the subsequent query, transaction A will find that there are more records that do not exist originally, as if an illusion has occurred, so it is called a phantom reading.
reference: