MySQL database table engine and character set
1. The server processes client requests
In fact, no matter which method the client process and server process use to communicate, the final effect is: **The client process sends a text (MySQL statement) to the server process, and the server process sends a text to the client process after processing. Text (processing result). **So what processing does the server process do to the request sent by the client process to produce the final processing result? The client can send various requests for addition, deletion, modification, and checking to the server. Here we take a more complex query request as an example to draw a diagram to show the general process:
Although query caching can sometimes improve system performance, it also has to incur some overhead due to maintaining this cache. For example, it must be retrieved from the query cache every time. After the query request is processed, the query cache needs to be updated to maintain the memory corresponding to the query cache. area. Starting from MySQL 5.7.20, query caching is not recommended, and it is deleted in MySQL 8.0.
2. Storage Engine
The MySQL server encapsulates data storage and retrieval operations in a module called a storage engine. We know that the table is composed of rows of records, but this is only a logical concept, how to physically represent records, how to read data from the table, how to write data to specific physical storage, this is all storage The engine is responsible for things. In order to achieve different functions, MySQL provides a variety of storage engines. The specific storage structures of tables managed by different storage engines may be different, and the access algorithms used may also be different.
The storage engine was formerly called the table processor. Its function is to receive instructions from the upper layer, and then extract or write the data in the table.
In order to facilitate management, people divide functions that do not involve real data storage, such as connection management, query caching, syntax analysis, and query optimization, into MySQLserver functions, and divide the real data access functions into storage engine functions. Various storage engines provide a unified call interface (that is, storage engine API) to the upper MySQLserver layer, including dozens of low-level functions, such as "read the first content of the index" and "read the next content of the index" ", "insert record" and so on.
Therefore, after MySQLserver has completed query optimization, it only needs to call the API provided by the underlying storage engine according to the generated execution plan, and return the data to the client after obtaining the data.
MySQL supports a wide variety of storage engines:
| Storage engine | description |
|---|---|
| ARCHIVE | Used for data archiving (the row cannot be modified after being inserted) |
| BLACKHOLE | Discard write operations, read operations will return empty content |
| CSV | When storing data, separate data items with commas |
| FEDERATED | Used to access remote tables |
| InnoDB | Transactional storage engine with foreign key support |
| MEMORY | Table in memory |
| MERGE | Used to manage a collection of tables composed of multiple MyISAM tables |
| MyISAM | The main non-transactional storage engine |
| NDB | MySQL cluster dedicated storage engine |
3. The difference between MyISAM and InnoDB table engine
1) Transaction support
MyISAM does not support transactions, while InnoDB does.
Things: The execution unit that accesses and updates data in the database. In the operation of things, either all are executed or not executed
2) Storage structure
MyISAM: Each MyISAM is stored as three files on the disk.
- The .frm file stores the table structure.
- .MYD files store data.
- .MYI file storage index.
InnoDB: mainly divided into two types of files for storage
- frm storage table structure
- .ibd stores data and indexes (may also be multiple .ibd files, or independent tablespace files)
3) Table lock difference
**MyISAM: Only table-level locks are supported. **When the user operates the myisam table, select, update, delete, and insert statements will automatically lock the table. If the table after locking meets the insert concurrency, the table can be locked. Insert new data at the end of the.
**InnoDB: Support for transactions and row-level locks is the biggest feature of InnoDB. ** Row locks greatly improve the new capabilities of multi-user concurrent operations. But InnoDB's row lock is only valid in the WHERE primary key, and the WHERE of the non-primary key will lock the entire table.
4) Table primary key
MyISAM: Allows the existence of tables without any indexes and primary keys. The indexes are the addresses where rows are stored.
InnoDB: If the primary key is not set or a non-empty unique index is not set, a 6-byte primary key (not visible to the user) will be automatically generated. The data is part of the main index, and the additional index stores the value of the main index. InnoDB has a larger primary key range, up to 2 times that of MyISAM.
5) The specific number of rows in the table
MyISAM: Save the total number of rows of the table, if select count() from table; will directly retrieve the value.
InnoDB: The total number of rows in the table is not saved (it can only be traversed). If you use select count() from table; it will traverse the entire table, which consumes a lot of money, but after adding the where condition, myisam and innodb handle the same way.
6) CURD operation
MyISAM: If you perform a large number of SELECTs, MyISAM is a better choice.
InnoDB: If your data performs a large number of INSERT or UPDATE, for performance reasons, you should use InnoDB tables. DELETE is better for InnoDB in terms of performance, but when DELETE FROM table, InnoDB will not re-create the table, but delete row by row. If you want to clear a table with a large amount of data on InnoDB, it is best to use the truncate table command.
7) Foreign key
MyISAM: Does not support InnoDB: Support
8) Query efficiency
MyISAM is relatively simple, so it is better than InnoDB in efficiency, and small applications can consider using MyISAM.
It is recommended to consider using InnoDB to replace the MyISAM engine, because InnoDB has many good features, such as transaction support, stored procedures, views, row-level locking, etc. In the case of a lot of concurrency, I believe that InnoDB's performance is definitely better than MyISAM. .
In addition, any kind of table is not a panacea. Only by choosing the appropriate table type for the business type can the performance advantages of MySQL be maximized. If it is not a very complicated Web application or non-critical application, you can continue to consider MyISAM. This specific situation can be considered by yourself.
9) Application scenarios of both MyISAM and InnoDB:
MyISAM manages non-transactional tables. It provides high-speed storage and retrieval, and full-text search capabilities. If the application needs to execute a large number of SELECT queries, then MyISAM is a better choice. InnoDB is used in transaction processing applications and has many features, including ACID transaction support. If the application needs to perform a large number of INSERT or UPDATE operations, you should use InnoDB, which can improve the performance of multi-user concurrent operations. InnoDB is now used by default.