What is a table engine
The table structure we see, its essence is the storage of data in the hard disk. According to different characteristics, the data storage method is different. For example: For each piece of data, how is it stored in the hard disk, how it is compressed, how it is indexed and optimized, and how is its reading and writing achieved. These complete paths are called table engines.
Basis for selection
The basis of choice is our needs, and our needs largely determine our choice. Sometimes our habits decide this process. Here, we focus on the following aspects:
Concurrency, write and read features supported at the same time;
Security, physical storage structure, whether the data is reliable when an exception occurs;
Transactionality, the granularity of data execution, and the characteristics provided to define atomic operations;
Query optimization, here we refer to query cache and index;
In terms of development, we mainly focus on: (1,3,4), at the operation and maintenance level, we focus on (2).
In the selection of tables, the most commonly used are as follows:
MyIsam
Innodb
Memory（Heap）
Start with the case
Now we are going to make a message board, we found that this message board may have several situations:
Many people leave messages at the same time, and at the same time, many people check the messages;
Few people leave messages, and a lot of people check the messages every day;
Our function has message rewards, the first 10 messages every day will be rewarded with points;
Our message board is a bit like a real-time chat device, which has very high performance requirements and real-time requirements;
Mysius
In the 5.0 era, this table is very common, and the Discuz I know uses this table. Its advantage: query speed is valued by many people. Let's take a look at some of its features:
Theoretically unlimited storage (related to the file system of the operating system)
There is a text/blob full-text index
Index cache
data compression
Low storage space and low memory footprint
High-speed writing
Query cache
During serial writing, full table lock (read and write)
Does not support transactions
Cluster support
B-Tree index
create table a_myisam (.....) ENGINE = MYISAM;
With the above characteristics, we see that MyIsam is mainly designed for query, and it is also something that everyone considers when doing data storage.
InnoDB Since 5.1, InnoDB has developed slowly and has become a storage engine for important data. Its characteristics are as follows:
Limited storage
Index cache
Support affairs
Query cache
Write row lock
B-Tree index
create table a_myisam (.....) ENGINE = InnoDB;
InnoDB is more stable and mature, and it also provides solutions for more needs.
Memory
Fast query speed
Lost after mysql restart
B-Tree and HASH index
Just for fast, small amount of data.
A: Many people leave messages at the same time, and many people read them
what does this mean? Our writing speed must be fast enough and writing does not affect reading. Or we can write in parallel. In this case, if we choose MyIsam, the increase in write volume will cause the entire table to be locked, so that when reading, we have to wait for the lock to be released; then, obviously, MyIsam will cause a table performance bottleneck. In this case, we choose Innodb. The reasons are as follows:
When Innodb writes, the lock is a row lock; it does not affect other writes, but affects a small amount of reads (possibly a large number);
Innodb's query performance is theoretically slightly worse than Myisam, but it is very small and can be ignored;
B: There are very few people who leave messages, and a lot of people check the messages every day
At this time, there is no problem with choosing MyIsam. (Read/write relatively high)
C: Our function has message rewards, the first 10 messages every day will be rewarded with points
We need some atomic-level operations, that is, when judging that a message is the top 10, mark it, and this mark needs to be atomic: during the marking process, others are not allowed to query and write (full table lock ). What does it mean? Since our operations are not strictly sequential, the computer's CPU operation slices are essentially serial. Suppose you have two commands at this time:
Check whether the top 10
Increase points
Assuming that there are already 9 messages, then two requests come at this time, both of which inquire whether they are the top 10. The first user found that he was the 10th, and when it was about to execute the second step, the 11th user came, and he also inquired that he was the 10th. If there is no protection mechanism, then the 11th is also He will get points if he thinks that he meets the conditions.
How to achieve?
Under normal circumstances, we will add a field to mark, this field is assumed to be: lock, then when updating, ensure that there is no other operation in the middle. We call it a transaction.
start
select ... from table where lock = 0 for update;
update table set lock = 1;
commit
D: Our message board is a bit like a real-time chat device, with very high performance requirements and real-time requirements
呵呵，这个不用说了，使用innodb和memory都可以。一般我们使用内存存储，会把它当做K-V来使用，根据设计的情况来选择。（不过，业内很少时候，内存的存储一般都会选择Memcache和Redis）。
总结一下
如果读/写 比很大的话，假设这个尺度为10，那么，就使用myisam（写入并发小的情况）
如果需要事务的支持，使用innodb
如果需要对并发性（写入）有要求的话，使用innodb
其它情况，可以根据实际场景选择
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。互联网+时代，时刻要保持学习，携手千锋PHP,Dream It Possible。