table of Contents
1. What are the transaction isolation levels of MySQL? What problems are they used to solve?
2. How to realize MySQL's repeatable reading?
3. How to troubleshoot the problem of full mysql connections?
4. What are the differences between MyISAM and InnoDB in Mysql?
1. What are the transaction isolation levels of MySQL? What problems are they used to solve?
Mainly used to solve dirty reads, non-repeatable reads, and phantom reads.
- Dirty read: A transaction reads data that has not yet been committed by another transaction.
- Non-repeatable read: When the same data is read multiple times in a transaction, the results are inconsistent.
- Phantom read: Use the same SQL to read twice in a transaction, and the new row inserted by another transaction is read the second time.
Non-repeatable reading focuses on data modification, while phantom reading focuses on data insertion.
| Isolation level |
Dirty read |
Non-repeatable |
Phantom reading |
| Read Uncommitted |
Have |
Have |
Have |
| Read Committed |
no |
Have |
Have |
| Repeatable Read |
no |
no |
Have |
| Serializable |
no |
no |
no |
2. How to realize MySQL's repeatable reading?
Implemented using MVCC, namely Mutil-Version Concurrency Control, multi-version concurrency control. Regarding MVCC, the more common statements are as follows, including the introduction of "High Performance MySQL".
InnoDB saves two hidden columns behind each row of records, which respectively store the created version number and the deleted version number of the data row . Every time a new transaction is started, the system version number is incremented. The version number at the start of the transaction will be used as the version number of the transaction to be compared with the version number of each row of the query. How does MVCC operate at the repeatable read level:
- SELECT: The following two conditions must be met at the same time to be able to query. 1) Only check the data rows whose version number is earlier than the current version; 2) The deleted version of the row is either undefined or greater than the current transaction version number.
- INSERT: Save the current system version number as the creation version number for each row inserted.
- DELETE: Save the current system version number as the delete version number for each row deleted.
- UPDATE: Insert a new piece of data and save the current system version number as the created version number. At the same time, save the current system version number as the original data row and delete the version number.
MVCC only works on RC (Read Committed) and RR (Repeatable Read) levels, because RU (Read Uncommitted) always reads the latest data version, not the data row that conforms to the current transaction version. And Serializable will lock all read rows. Neither of these levels requires the help of MVCC.
At first I also believed in this statement, but later I discovered that this statement is actually a bit problematic in certain scenarios.
For a simple example: if thread 1 and thread 2 have started the transaction successively, the transaction version number is 1 and 2. If thread 1 has not yet committed the transaction when thread 2 starts the transaction, then thread 2’s transaction is at this time You should not see the contents of the transaction modification of thread 1.
But if you follow the above statement, because the transaction version of thread 1 is earlier than the transaction version of thread 2, the transaction of thread 2 can see the transaction modification content of thread 1.
3. How to troubleshoot the problem of full mysql connections?
Abnormal database connection
3.1 First connect to the mysql server remotely
mysql -h ip -u root -p -P 3306
例如：mysql -h ××.××..××..××. -P 3306 -u xx-p
-h指定远程 ip地址 -P指定端口号 -u 指定用户名 -p 指定密码Fortunately, the remote connection is successful, indicating that there should be no problem with the mysql service, which may be a problem with the number of connections.
3.2 Query the number of available connections and the maximum number of connections, and found that the number of connections is full
Connection usage
3.3 Query the 10 longest running SQL execution time
Select * from information_schema.processlist where info is not null order by time desc limit 10 ;It is found that the same sql occupies a large number of mysql connections, which causes the number of mysql connections to be full. The investigation is triggered by a bulk push service. First, block the bulk push function, reissue the version, and restart the service.
3.4 Generate kill process script through command
`select concat('KILL',id,';') from information_schema.processlist where user='root' into outfile '/var/lib/mysql-files/a.txt'；`
或者增加时间条件
`select concat('KILL',id,';') from information_schema.processlist where user='root' and time>100 into outfile '/var/lib/mysql-files/aa.txt'; `3.5. Execute the script to kill connections
source /var/lib/mysql-files/a.txt3.6. Query thread execution status
show status like 'Threads%'After batch kill adjust the number of connections, the service is normal;
After intensive and orderly investigation, the online unexpected problems were successfully resolved.
related articles
4. What are the differences between MyISAM and InnoDB in Mysql?
Innodb engine overview
The Innodb engine provides support for database ACID transactions and implements the four isolation levels of the SQL standard. The engine also provides row-level locks and foreign key constraints. Its design goal is to handle large-capacity database systems. It itself is actually a complete database system based on the MySQL background. When MySQL is running, Innodb will create a buffer pool in memory for Buffer data and index. However, the engine does not support FULLTEXT type indexes, and it does not save the number of rows in the table. When SELECT COUNT(*) FROM TABLE, it needs to scan the entire table. When you need to use database transactions, this engine is of course the first choice. Because the lock granularity is smaller, the write operation will not lock the entire table, so when the concurrency is high, using the Innodb engine will improve efficiency. However, the use of row-level locks is not absolute. If MySQL cannot determine the range to be scanned when executing a SQL statement, the InnoDB table will also lock the entire table.
InnoDB's performance and automatic crash recovery features make it popular in non-transactional storage requirements. Unless there is a very special reason to use other storage engines, the InnoDB engine should be given priority.
Overview of MyISAM engine
In MySQL 5.1 and earlier versions, MyISAM is the default engine. MyISAM provides a large number of features, including full-text indexing, compression, spatial functions (GIS), etc., but MyISAM does not support transactions and row-level locks, and there is no doubt that it cannot be safely recovered after a crash . MyISAM is the default engine of MySQL, but it does not provide support for database transactions, nor does it support row-level locks and foreign keys. Therefore, when INSERT (insert) or UPDATE (update) data, write operations need to lock the entire table, which is efficient It will be lower. However, unlike Innodb, MyISAM stores the number of rows in the table, so when SELECT COUNT(*) FROM TABLE, you only need to directly read the saved values without performing a full table scan. If the table has more read operations than write operations and does not require the support of database transactions, then MyISAM is also a good choice.
the difference:
- InnoDB supports ACID transactions, MyISAM does not support transactions. This is one of the important reasons why MySQL changed the default storage engine from MyISAM to InnoDB; transaction-safe (ACID compliant) with commit, rollback, and crash recovery capabilities Type table .
- InnoDB supports foreign keys, but MyISAM does not. Converting an InnoDB table containing foreign keys to MYISAM will fail;
- InnoDB is a clustered index, MyISAM is a non-clustered index. The files of the clustered index are stored on the leaf nodes of the primary key index, so InnoDB must have a primary key, and the efficiency of the primary key index is very high. However, the secondary index requires two queries, the primary key is first queried, and then the data is queried through the primary key. Therefore, the primary key should not be too large, because the primary key is too large, and other indexes will also be large. MyISAM is a non-clustered index, the data file is separated, and the index saves the pointer of the data file. The primary key index and the secondary index are independent.
- InnoDB does not save the specific number of rows in the table, and a full table scan is required when executing select count(*) from table. MyISAM saves the number of rows of the entire table with a variable, and only needs to read the variable when executing the above statement, which is very fast;
- InnoDB's smallest lock granularity is row locks, and MyISAM's smallest lock granularity is table locks. An update statement will lock the entire table, causing other queries and updates to be blocked, so concurrent access is limited. This is also one of the important reasons why MySQL changed the default storage engine from MyISAM to InnoDB;
how to choose:
- Whether you want to support transactions, if you want to, please choose InnoDB, if you don't need to consider MyISAM;
- If most of the tables are only read queries, you can consider MyISAM. If both read and write are frequent, please use InnoDB.
- After the system crashes, it is more difficult for MyISAM to recover. If it is acceptable or not, choose InnoDB;
- Starting from MySQL 5.5, Innodb has become the default engine of Mysql (previously MyISAM), indicating that its advantages are obvious to all. If you don't know what storage engine to use, use InnoDB, at least not bad.
related articles