Write lock
Incompatible |
Incompatible |
|
Read lock
Incompatible |
Compatible |
|
In actual situations, the results may be different from the results in the above table, mainly because the lock mechanism in Innodb is a very complicated thing, and there are many locks that affect the final result.
5.2.3.4 Lock granularity:
- Table-level lock
- Row-level lock
5.2.3.5 Blocking and deadlock
Blocking: Blocking is due to the compatibility relationship between different locks. At some point, the lock in one transaction needs to wait for the lock of another transaction to be released. The resources it occupies form a blockage.
Deadlock: Deadlock refers to an exception that occurs when two or more transactions occupy the resources that the other party is waiting for during the execution of the transaction. As can be seen from the definition, multiple blocked transactions occupy the resources that the blocked transaction is waiting for, and deadlock is when multiple blocked transactions occupy the resources that each other is waiting for.
5.3 CSV storage engine
The CSV storage engine can process csv files as mysql table files. The storage format of this storage engine is an ordinary csv file. The data storage method of the csv storage engine is very unique. If we store the table in MyISAM or Innodb, we cannot directly view the data files because these two files are stored in binary format. The CSV storage engine is different. CSV data is stored in files in the form of text. That is, we can view it through the command to view the file, such as more, or use the vi command to view and edit the table in the CSV storage engine. As long as the format and requirements of the CSV file are met, we don't have to worry about corrupting the data.
When we create the CSV storage engine table in mysql, we should be able to see files in 3 file systems. These three file names are all based on the table name, but have csv, csm, and frm as suffixes respectively. The csv file is the data file in the CSV storage engine. The csm file stores the metadata of the table and the table status and data volume. The frm file stores table structure information.
5.3.1 Features of CSV storage engine
- The biggest feature is that data is stored in CSV format
Each column in CSV is ,
to separate, and the text content is enclosed in double quotes, as shown in the following figure:
- All columns must not be NULL
When creating a table, all columns must be non-empty and cannot be stored as NULL values
- Does not support indexes
Not suitable for large tables and online processing
- Data files can be edited directly
Save text file contents
5.3.2 Applicable scenarios of CSV storage engine
CSV storage engine is suitable for data exchange Intermediate table
##5.4 Archive storage engine
5.4.1 File system storage characteristics
Archive storage engine caches all writes and uses zlib to compress inserted rows. Therefore, Archive storage engine saves disk I/O compared to tables of MyISAM storage engine. For data of the same order of magnitude, Archive The storage engine saves storage space compared to MyISAM and Innodb. A several-terabyte Innodb table stored in the Archive storage engine may only require a few hundred megabytes of storage space. The table data of the Archive storage engine is a file with the suffix ARZ. Like other engines, there is also a system file with the suffix frm used to store the structural information of the table.
5.4.2 Features of Archive storage engine
Only supports - insert
and
select operations
Only indexes are allowed on auto-incrementing ID columns-
##5.4.3 Archive storage engine usage scenariosScenario 1: Log and data collection class Data
Because Archive does not support modification and deletion, our ORDB will definitely modify the data, but it is still useful for some warehouse-type applications or some special tables, such as log tables or Data collection tables are more suitable for using the Archive storage engine because they need to collect a large amount of data. Because the Archive storage engine has the smallest storage space among all engines, it should be noted that even in data collection or logging applications, the Archive storage engine cannot update these data, so when recording logs Or if you modify the data in a data collection application, you may not be able to use the Archive storage engine.
5.5 Memory storage engine
5.5.1 File system storage characteristicsMemory storage engine is also called HEAP storage engine, so the data is stored in memory. This means that the data table is disposable. Once the MySQL service is restarted, all Memory storage engine data will disappear. However, the table structure will be retained, because creating a table under the Memory storage engine will only generate a frm system file, which is used to save the table structure. This is why data will be lost when restarting the MySQL server, but the table structure will not.
From its file storage characteristics, we can know that the I/O efficiency of the Memory storage engine will be much higher than that of MyISAM, because only the index of MyISAM is stored in the memory, and the data is cached by the operating system, while the Memory storage engine All data and indexes of the engine are stored in memory. Let's take a look at the functional features of the Memory storage engine.
5.5.2 Functional features of Memory
Functional features:
- Supports HASH index (default) and BTree Index
If it is a HASH index, it will be very fast when doing equivalent queries. If it is doing a range query, the HASH index cannot be used, so we need to pay attention when creating the table. If the table requires a large number of equivalent queries, use the HASH index, and use the BTree index for range queries. Different index types can have a big impact on performance.
- All fields are of fixed length varchar(10) = char(10)
This requires us to meet the minimum field length requirements when defining the table structure, otherwise a lot of memory is wasted.
- Does not support large fields such as BLOG and TEXT
- Memory storage engine uses table-level locks
- The maximum size is determined by the max_heap_table_size parameter
The default value of this parameter is only 16 megabytes , if we want to store a large amount of data in the Memory storage engine table, we need to modify this parameter, and this parameter modification will not take effect on the existing Memory storage engine table. If we need to take effect on the existing table, we need to modify it. Existing tables are rebuilt.
5.5.3 Confusing concepts in Memory
Memory storage engine table:
It can be used on all systems, it is not the same A temporary table.
Temporary table:
There are two types of temporary tables. One is the temporary table used by the system when the query optimizer optimizes the query, which is the internal temporary table. The system uses temporary tables when the limit is exceeded (using BLOB or TEXT large field), use the MyISAM temporary table, and use the Memory table if the limit is not exceeded.
The other is a temporary table created through the command create temporary table
. The created table can use any storage engine.
No matter what kind of temporary table it is, it is only visible internally.
5.5.4 Memory usage scenarios
- is used for search or mapping tables, such as postal code and region correspondence tables
- is used for Save the intermediate table generated during data analysis
- The result table used to cache periodic aggregation data
Memory data is easy to lose, so the data is required to be reproducible.
5.6 Federated Storage Engine
5.6.1 Features of Federated
- Provides access to remote MySQL servers Table method
Since the Federated storage engine only establishes a local connection to the remote server, it can be said that all the tables we want to access are still placed on the remote server, and no data is stored locally. Each time a Federated storage engine table is accessed, the query is sent to the remote server to run and the relevant data is obtained from the remote MySQL server.
- No data is stored locally, all data is placed on the remote server
- The table structure and the connection information of the remote server need to be saved locally
Therefore, there will also be a frm file in the system, use Information about storing remote information and how to connect to remote tables.
5.6.2 How to use Federated
The Federated storage engine can realize the function of SQL Server connecting to the server, but due to its own performance is not very good, usually The same purpose can be achieved through replication, etc., so in the current MySQL version, the Federated storage engine is disabled by default. If you need to use the Federated storage engine, you need to add federated=1
to /usr/local/mysql/my.cnf
, and then restart the MySQL server. We can use show engine
to confirm whether the current MySQL server supports the Federated storage engine.
And use the following connection string in the create table
statement,
mysql://user_name[:password]@host_name[:port_num]/db_name/tbl_name
Remote server binding connection:
grant select,update,insert,delete on remote.remote_fet to fred_link@'127.0.0.1' identified by '123456'
You can decide the query Information about the remote server and some information about the related database tables.
5.6.3 Applicable scenarios for Federated
- Occasional statistical analysis and manual query
Due to the slow performance of Federated, it is only suitable for occasional Statistical analysis and manual query.
6 How to choose the correct storage engine
Reference conditions:
- Transaction
- Backup
- Crash recovery
- Unique features of storage engines
Try to avoid mixing storage engines.
More related free learning recommendations: mysql tutorial(Video)