Today, we will share with you the differences between the actual application of InnoDB and MyISAM In the MySQL storage engine, as well as the differences in related functions and their advantages and disadvantages, if you are interested, you can click the following articles to view them.
Explain the differences between "InnoDB" and "MyISAM"
InnoDB and MyISAM are the two most commonly used table types when many people use the MySQL storage engine. The two table types have their own advantages and disadvantages, depending on the specific application.
The basic difference is:
The MyISAM type does not support advanced processing such as transaction processing, whereas the InnoDB type does. MyISAM tables emphasize performance, and the execution speed is faster than that of InnoDB, but transactions are not supported. InnoDB provides advanced database functions such as external keys for transactions.
MyIASM is a new version of the IASM table and has the following extensions:
Binary hierarchy portability.
NULL column index.
There are fewer fragments for Long-varying rows than the ISAM table.
Supports large files.
Better index compression.
Better key? statistical distribution.
Better and faster auto_increment processing.
The following are some differences between details and specific implementations:
1. InnoDB does not support FULLTEXT indexes.
2. innoDB does not store the specific number of rows in the table. That is to say, when you execute select count (*) from table, InnoDB needs to scan the entire table to calculate the number of rows, however, MyISAM simply needs to read the number of lines saved. Note that when the count (*) statement contains the where condition, the operations on the two tables are the same.
3. For fields of the AUTO_INCREMENT type, InnoDB must contain only the index of this field. However, in the MyISAM table, you can create a joint index with other fields.
4. When deleting FROM table, InnoDB does not create a new table, but deletes a row.
5. the load table from master operation does not work for InnoDB. The solution is to first change the InnoDB TABLE to the MyISAM TABLE, and then change the imported data to the InnoDB TABLE, however, it is not applicable to tables that use additional InnoDB features such as foreign keys.
In addition, the row lock of the InnoDB table is not absolute. If the MySQL storage engine cannot determine the scope to scan when executing an SQL statement, the InnoDB table will also lock the entire table, for example, update table set num = 1 where name like "% aaa %"
To sum up, any type of table is not omnipotent. Only by selecting the appropriate table type for the business type can we maximize the performance advantages of the MySQL storage engine.