The difference between MyISAM and InnoDB of MySQL database is
from the following aspects:
1. Storage structure
Each MyISAM is stored as three files on the disk. The name of the first file begins with the name of the table, and the extension indicates the file type.
.frm files store table definitions.
Data files have the extension .MYD (MYData).
Index files have the extension .MYI (MYIndex).
2. Storage space
MyISAM: It can be compressed, and the storage space is small.
InnoDB: requires more memory and storage, it builds its dedicated buffer pool in main memory for caching data and indexes.
The index and data of MyISAM are separated, and the index is compressed, and the memory usage is correspondingly improved a lot. More indexes can be loaded, and Innodb is tightly bound with indexes and data, and no compression is used, which will cause Innodb to be larger than MyISAM.
3. Transaction processing
The MyISAM type table emphasizes performance, and its execution is several times faster than the InnoDB type, but it does not support foreign keys and does not provide transaction support.
InnoDB provides advanced database features such as transaction support transactions, foreign keys, etc.
SELECT, UPDATE, INSERT, DELETE operations MyISAM is a better choice
if doing a lot of SELECTs.
If your data performs a lot of INSERTs or UPDATEs, you should use InnoDB tables for performance reasons.
When DELETE FROM table, InnoDB will not rebuild the table, but delete row by row. And MyISAM is to rebuild the table. On innodb, if you want to empty a table that holds a large amount of data, it is best to use the truncate table command.
AUTO_INCREMENT
MyISAM: You can build a joint index with other fields. The auto-growth column of the engine must be an index. If it is a composite index, the auto-growth can not be the first column. It can be sorted and incremented according to the previous columns.
InnoDB: InnoDB must contain an index for this field only. The auto-increment column of the engine must be an index, and if it is a composite index, it must also be the first column of the composite index.
4. The specific number of rows in the
table MyISAM: saves the total number of rows in the table, if select count(*) from table; will directly retrieve the value.
InnoDB: The total number of rows in the table is not saved. If you use select count(*) from table; it will traverse the entire table, which consumes a lot of money, but after adding where, both myisam and innodb handle the same way.
5. Full-text index
MyISAM: supports full-text index of FULLTEXT type. Chinese is not supported.
InnoDB: Full-text indexing of type FULLTEXT is not supported, but innodb can use the sphinx plugin to support full-text indexing, and the effect is better.
6. Differences in table locks
MyISAM: Only table-level locks are supported, and only table-level locks are supported. When users operate myisam tables, select, update, delete, and insert statements will automatically lock the table.
InnoDB: Support for transactions and row-level locks is the biggest feature of innodb. Row locks greatly improve the new performance of multi-user concurrent operations. However, the row lock of InnoDB 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, such as update table set num=1 where name like “%aaa%”
Generally speaking:
MyISAM is suitable for:
(1) Do a lot of count calculations;
(2) Inserts are infrequent and queries are very frequent;
(3) No transactions.
InnoDB is suitable for:
(1) Reliability requirements are relatively high, or transactions are required;
(2) Table updates and queries are quite frequent, and the chance of table locking is relatively large.
The main difference between the two types is that Innodb supports transactions with foreign keys and row-level locks . And MyISAM does not support. So MyISAM is often considered to be only suitable for use in small projects.
From the perspective of users who use MySQL, Innodb and MyISAM are both preferred. If the database platform needs to meet the requirements: 99.9% stability, convenient scalability and high availability, MyISAM is definitely the first choice.
The reasons are as follows:
1. Most of the projects carried on the platform are projects that read more and write less, and the read performance of MyISAM is much stronger than that of Innodb.
2. The index and data of MyISAM are separated, and the index is compressed, and the memory usage is correspondingly improved a lot. More indexes can be loaded, and Innodb is tightly bound with indexes and data, and no compression is used, which will cause Innodb to be larger than MyISAM.
3. It often happens every 1 or 2 months that application developers accidentally update a table where the written range is wrong, resulting in this table not being able to be used normally. At this time, the superiority of MyISAM is reflected, just copy it from the day Take out the file of the corresponding table from the compressed package, put it in a database directory, then dump it into sql and import it back to the main database, and add the corresponding binlog. If it is Innodb, I am afraid it cannot be so fast. Don't tell me to let Innodb use the export xxx.sql mechanism to back up regularly, because the data volume of the smallest database instance is basically tens of gigabytes.
4. From the application logic of contact, select count(*) and order by are the most frequent operations, which may account for more than 60% of the total SQL statement operations, and Innodb will actually lock the table in this operation. Many people think that Innodb is a row-level lock, that is only where is valid for its primary key, and non-primary keys will lock the entire table.
5. There are often many application departments who need me to give them the data of certain tables on a regular basis. MyISAM is very convenient. Just send them the frm.MYD and MYI files corresponding to that table, and let them own the corresponding version of the database. Just start it, and Innodb needs to export xxx.sql, because the other party cannot use it because of the influence of the dictionary data file.
6. If compared with MyISAM for insert write operations, Innodb cannot achieve the write performance of MyISAM. If it is an index-based update operation, although MyISAM may be inferior to Innodb, with such high concurrent writes, can the slave library be able to catch up? The above is also a problem, it is better to solve it through the multi-instance sub-database sub-table architecture.
7. If MyISAM is used, the merge engine can greatly speed up the development of the application department. They only need to do some select count(*) operations on the merge table, which is very suitable for a certain type of rows with a total amount of hundreds of millions of large projects (such as logs, survey statistics) business tables.
Of course, Innodb is not absolutely unnecessary. Innodb is used for projects that use transactions. Also, some may say that your MyISAM is not resistant to too many writes, but it can be compensated by the architecture.