MySQL interview questions and answers

Original link: https://article.itxueyuan.com/eoJEMj

Related Index

1. What is the index?

• The index is a data structure that can help us to find data quickly.

2. The index is what kind of data structure?

• Data structure and specific storage engine indexes related to use more of the index in MySQL there Hash index, B + tree indexes, and the default storage engine InnoDB index we often use to achieve: B + tree index.

3. Hash B + tree index and what is the difference or all the pros and cons of it?

Hash index must first know and B + tree index underlying implementation principles:

hash index is the underlying hash table, when to find, call a hash function can get to the appropriate key, followed by the query back to the table to get the actual data .B + tree underlying implementation is more than balanced search trees. For every query starting from the root, find leaf node parties may obtain the search key, and then back to the table query data according to the query whether it is necessary.

We can see that they have the following differences:

• hash index equivalent queries faster (in general), but it can not be the scope of the query.

Since then indexed through hash function hash index, the index of the sequence with the original order can not be consistent, can not support range queries. And all the nodes B + tree's are to follow (left node is less than the parent node, right node is greater than the parent, and more tree is similar), native support range.

• hash indexes do not support the use of indexes sort principle above.
• hash indexes do not support fuzzy queries and multi-column index of the most left-prefix match principle but also because of the unpredictable .AAAA and AAAAB index hash function is not relevant.
• hash index can not be avoided at all times to query the data back to the table, while the B + tree queries can be done when certain conditions are met (clustered indexes, covering indexes, etc.) only by the index.
• Although faster hash index on the equivalence queries, but unstable. unpredictable performance, when there are a large number of duplicate keys when hash collision occurs, then efficiency may be poor. The query efficiency B + tree is relatively stable, for all queries are from the root node to the leaf node, and low height of the tree.

Therefore, in most cases, to directly select B + tree index can obtain stable and better query speed without the need to use hash indexes.

4. The above mentioned B + tree does not need to query the data back to the table in time to meet clustered indexes and covering indexes, what is the clustered index?

• The index B + tree leaf node may store the current key value, may also be stored in the current key value and the entire row of data, which is clustered index and non-clustered index. In InnoDB, only the primary key index is clustered index, if no primary key, then choose a unique key to establish a clustered index. If there is no unique key, then implicitly generated to build a clustered index key.

When a query using a clustered index, the corresponding leaf node, you can get the entire row of data, so do not be back to the table this time.

5. Non-clustered index table query will return it?

• Not necessarily, this involves a query whether all the required fields hit the index, if the index all hit, then you do not have to be back to the table query.

Here is a simple example, suppose we have created an index on the age of the employee table, then when the select age from employee where age Queries <20, in the leaf nodes of the index, already contains the information age, not again back to the table query.

6. When indexed, what are the factors to consider it?

• When the general index to take into account the frequency of use fields, often query field as conditions are suitable. If you need to establish a joint index, it is also the order of the joint index needs to be considered. In addition also consider other aspects, such as to prevent excessive All cause too much pressure on the table. these are the actual table structure and query related.

7. What index is the joint? Why pay attention to the order of the joint index?

• MySQL can use multiple fields while building an index, called the joint index. In the joint index, the index if you want to hit, field need to follow the order of indexing one by one, otherwise it can not hit the index.

Specific reasons are:
the need to use MySQL index when the index orderly, assuming now established a "name, age, school" joint index, the index of the sort: first name in accordance with the order, if the same name, then sort according to age, if age values are equal, then sorted according to school.

When queried, only this time the index name in accordance with strict and orderly, it must first be equivalent query using the name field, and then for a match to the column, according to their age fields strict and orderly, then you can use fields with age do index lookup, and so on. Therefore, when the establishment of joint index should be noted that the order of the index column, under normal circumstances, the query field frequently demand or high selectivity columns on the front. Also a special case can query or table structure based on separate adjustments.

8. Create the index has not been used to? Or how can know the reason for this statement is running very slow?

• MySQL provides explain command to view the execution plan statement, MySQL before executing a statement, that statement go over the query optimizer, will get after the analysis of the sentence, that is, the execution plan, which contains a lot of information. and index information by which to analyze whether the relevant index hit, for example possilbe_key, key, key_len and other fields, respectively, illustrate this statement may use the index, the index actually used and the length of the index used.

9. So what happens in the index is created but not used when the query it for this column?

• Use is not equal to the query,
• Column involved in math or function
• When the string is a wildcard like left Like '% aaa'.
• When a full table scan analysis mysql does not use index than when using index fast.
• When used in conjunction index, a condition for the front range queries, even the most left-prefix in line with the principles behind, you can not use the index.

The above case, MySQL can not use indexes.

Transaction-related

1. What is a transaction?

• Understand what matters most classic is the transfer of chestnuts, I believe we all know, there is not to say aside.
• A transaction is a series of operations, they have to comply with the ACID properties of the most common understanding is: operations in the transaction either all succeed, or all fail but only this is not enough.

What 2. ACID yes? Details can be said about it?

• A = Atomicity ------ atomicity, which is above either all succeed or all fail. Impossible to carry out only part of the operation.
• C = Consistency ------ system (database) is always a consistent transition from state to another consistent state, without an intermediate state.
• I = Isolation ------ Isolation: Generally speaking: a transaction before it is fully committed, other transactions are not visible to the attention of the front of the general, the addition of red, which means there are exceptions.
• D = Durability ----- persistence, once the transaction is committed, then it will always be like this, even if the system crashes will not affect the outcome of the transaction.

3. At the same time there are multiple transactions during what will happen?

• Multiple concurrent transactions will generally cause the following questions ::
  • Dirty read: A transaction to read the content B uncommitted transaction, the transaction was rolled back behind the B.
  • Non-repeatable read: A transaction can only be set when reading section B of the transaction has been submitted, the transaction will result in a A two queries, the result was different, because in the meantime been submitted to the transaction B operation.
  • Magic Reading: A transaction reads a content range B while this transaction data during insertion causing a "illusion"..

? 4. how to solve these problems it MySQL transaction isolation level to understand it?
MySQL four isolation levels are as follows:

• Uncommitted read (READ UNCOMMITTED): This is the exception to the above mentioned, this isolation level, other transactions can see part of the transaction does not modify this submission therefore cause problems of dirty read (read to the other transactions. part of the submission, and after the transaction has been rolled back).

This level of performance is not big enough advantage, but there are a lot of problems, and therefore rarely used.

• Read Committed (READ COMMITTED):. Results of other transactions can only read part of this transaction has been submitted to this isolation level there is a problem of non-repeatable read, read twice in the same transaction, does not even get the same because another transaction data has been modified.
• REPEATABLE READ (repeatable read): Repeatable Read isolation level to solve the problem of non-repeatable read above (see also know the name), but still there is a new problem, that phantom read, when you read the id> 10 rows of data next, all rows involved plus a read lock, then insert a new exception to a transaction data a id = 11, because it is newly inserted, so the above exclusion will not trigger lock, then carry out this affairs one will find that there is a id = 11 data query, and the query was not the last to get, and then insert will have a primary key conflict.
• SERIALIZABLE (serialization): This is the highest level of isolation can solve all the problems mentioned above, it will be because he forced the operation of the serial execution, which can lead to the concurrent decline in performance speed, and therefore not very common.

5. Innodb use what kind of isolation level it?

• InnoDB default is repeatable read isolation level.

6. MySQL locks understand it?

• When the database has concurrent transactions, may produce inconsistent data, this time need some mechanism to ensure access to the order, the lock mechanism is such a mechanism.
• Like hotel rooms, if you wander in and out, the situation will be more than snatch the same room, but the room locked coat, apply to key personnel can stay in the room and locked up, others only when he used up it can be used again.

7. MySQL What are lock it? It looks like the above lock is it not hinder the efficiency of concurrent?

• From the lock category is concerned, there are shared locks and exclusive locks.

  • Shared lock: also called a read lock when the user wants to read the data, plus the data shared lock shared lock can simultaneously add more...
  • Exclusive lock: write lock is also called when the user attempts to write data, the data plus exclusive lock exclusive lock can only be a plus, he and other exclusive locks, shared locks are repulsive...

• Using the above example is the user's behavior, there are two, one is the view room, with multiple users showings are acceptable. One is truly one night, during which both want to stay or may not want to see the room.

• Lock granularity depending on the particular storage engine, InnoDB row level locking achieved, page-level locking, table lock.

• Their large size from locking overhead, concurrent capacity is descending.

Table Design

1. Why should we try to set a primary key?

• A primary key is database to ensure data row after an entire table guarantee uniqueness, even if this tables without primary keys on business, but also proposed to add a self-growth ID column as the primary key. Set the primary key, may follow when pruning investigation more quickly and ensure that the operating range of data security.

2. The primary key increment ID or UUID?

• Recommended increment ID, do not use UUID.
  • Because InnoDB storage engine, the primary key index is a clustered index exists, that is, the primary key index B + stores the primary key index and all data (order) on the leaves node, if the primary key index is incremented ID, so just need to keep back arrangement can, if it is UUID, due to the arrival of the ID with the original size of the uncertainty will cause a lot of data insertion, data movement, and then lead to a lot of memory fragmentation, which causes decreased performance insert .

In short, the amount of data in some cases, with the increment primary key performance will be better.

Photos from the "High Performance MySQL": where the default suffix to use the increment ID, _uuid to use UUID-based key test, test performance 100w insert rows and rows of 300w.

• About primary key clustered index, if not the primary key, InnoDB selects a unique key as a clustered index, if there is no unique key, generates a primary key implicitly.
• If you define a PRIMARY KEY on your table, InnoDB uses it as the clustered index.
  If you do not define a PRIMARY KEY for your table, MySQL picks the first UNIQUE index that has only NOT NULL columns as the primary key and InnoDB uses it as the clustered index.

3. Why requirement field is defined as not null?

• MySQL官网这样介绍:：NULL columns require additional space in the rowto record whether their values are NULL. For MyISAM tables, each NULL columntakes one bit extra, rounded up to the nearest byte.
• null value uses more bytes, and will result in many cases is inconsistent with the expectations in the program.

4. If you want to store the user's password hash, which fields should be used for storage?

• Fixed-length string of a cryptographic hash, a salt, a user ID number and other char should be used instead to store varchar, which can save space and improve the retrieval efficiency.

Storage Engine Related

1. What MySQL storage engine support?

• MySQL supports multiple storage engines, such as InnoDB, MyISAM, Memory, Archive, etc. In most cases, directly choose to use InnoDB engine is the most appropriate, MySQL InnoDB is the default storage engine.

2.InnoDB and MyISAM What is the difference?

• InnoDB support things, but MyISAM does not support things
• InnoDB supports row-level locking, and support MyISAM table-level locking
• InnoDB support MVCC, but MyISAM does not support
• Support InnoDB foreign keys, and MyISAM does not support
• InnoDB does not support full-text indexing, and MyISAM support.

Scattered problems

1. MySQL varchar, and char in what is the difference.

• char is a fixed-length field, if applied for a char (10) of space, then no matter how much the actual content storage. The field occupies 10 characters, while the varchar is variable length, that is just the application of the maximum length, occupied space is the actual length +1 character, the last character is stored using a long space.
• In the search terms of efficiency, char> varchar, therefore, in use, if the length value of a field is determined, may be used char, or should try to use varchar. E.g. password storing user MD5 encryption should be used char.

2. varchar (10) and int (10) What is the meaning?

• varchar 10 represents the length of the application space, the maximum length of data that can be stored is, the int represents the length of only 10 show, to less than ten zeros. That is, int (. 1) and int (10) and it can store digital footprint size is the same, but in accordance with the length of the display when the display.

3. MySQL's binlog There are several entry format? What is the difference respectively?

• There are three formats, statement, row and mixed.
  • Under statement mode, the recording unit for the statement. That is the impact of each sql will be recorded due to the implementation of sql there is a context, it is necessary to save relevant information to save time, as well as some used functions such statements recording can not be copied.
  • The row level, changes to a recording unit of each row, may all be written down substantially due to the many operations, however, can lead to large changes in the line (such alter table), thus saving the file information of this mode too, so the amount of log Big.
  • mixed. a compromise solution, normal operation with the statement recorded statement can not be used when using the row.

In addition, the new version of MySQL in the level of the row have done some optimization, when the table structure changes, it will record the statement rather than progressive recording.

4. Large paging how to deal with?

• Oversized pages generally from two directions for the settlement.
  • Database level, and this is our main focus of attention (although the effect is not so large), similar to the select * from table where age> 20 limit 1000000,10 this query there is also a room for optimization of this statement needs load1000000 data then substantially all of the discarded, of course, only take 10 slow. At that time we can modify the select * from table where id in (select id from table where age> 20 limit 1000000,10). Although this load of one million data, but because the index covering all fields to be queried are in the index, so the speed will be soon. and if ID consecutive good, we can also select * from table where id> 1000000 limit 10, is also a good efficiency, optimization there are many possibilities, but the core idea is the same, it is to reduce the data load.
  • From the perspective of reducing the demand for such a request ... The main is not similar needs (jump directly to a specific page after page of several million only allowed to go page by page view or in accordance with a given route, so that predictable, cacheable) and to prevent leakage and consecutive ID have been maliciously attacked.

Paging solve large, in fact, mainly by caching, the predictability of the content found in advance, such as cache to redis kV database, can be returned directly.

Ali Baba "Java Development Manual", the solution for large pagination is similar to the above-mentioned first.

5. cared about business systems inside sql consuming it? Statistics slow query anyway? Queries on how slow optimized?

• In the business system, in addition to the query using the primary key, the other I will test it took on a test library, slow query statistics mainly by the operation and maintenance in doing business on a regular basis will slow query feedback to us.
• Slow query optimization first wants to understand what is the reason for slow? Query is not hit the index? Is a load of unnecessary data column? Or too much data?

So also for the optimization of these three directions,

• Firstly, the statement to see if load additional data, the query may be redundant line and discarded, and may be loaded with many of the results column does not need to analyze and rewrite the statement.
• Implementation plan analysis statement, then get it using the index, after modification statements or modify the index, so that statement can hit the index as much as possible.
• If the optimization of the statement has not performed, consider the amount of data in the table is too large, and if so may be horizontal or vertical part table.

6. The above-mentioned lateral and longitudinal partition table part tables, they can give an example of a suitable difference?

• Table row is divided by a transverse partition table. Suppose we have a user table, the primary key ID is incremented, and while the user's ID. Large amount of data, there are more than 100 million, then the time on a query table effect is not very satisfactory. we can primary key sub-table ID, whether it is divided by the tail number, ID or press section points are possible. assumed accordance 0-99 ending into 100 table, each table data is only 100w. At this time of the query efficiency is undoubtedly meet the requirements.
• Longitudinal partition table is divided by columns table assumes that we now have a table that contains a field id- article summary -... Content display system in the form of a list is refreshed, the list contains only the title and summary, when a user clicks on an article article text content only need to enter the details. At this time, if the data is large, this will be great and do not frequently used are listed together original query speed will slow down the table. we can table above is divided into two .id- summary, id- content. when the user clicks on the details, and that the primary key once again to take the content. and only a small increase in the storage capacity of the primary key field. small price.
• Of course, in fact, sub-table and the associated high degree of service, before sub-table be sure to do research as well as benchmark. Do not follow their own conjecture blind operation.

7. What is a stored procedure? What are the advantages and disadvantages?

• Stored procedures are prebuilt SQL statements. 1, more straightforward to understand: the process can be a stored record set, which is a code block by a number of T-SQL statements, such as T-SQL statement codes as a method to achieve some of the features (single table or multiple tables CRUD), and then give the block a name, call him on the line when use this function. 2, a stored procedure is precompiled code blocks, the efficiency is relatively high, a large number of alternative stored procedure T_SQL statements, network traffic can be reduced to improve the communication rate, data security can be ensured to a certain extent
• However, in the Internet project, in fact, is not recommended stored procedure, is more famous Ali's "Java Development Manual" prohibit the use of stored procedures, I understand that in the Internet project, fast iteration, the project life cycle is relatively short, compared to traditional mobility projects more frequently, in this case, the management of the stored procedure really is not so easy, but, reusability did not write in the service layer so good.

8. talk about three paradigms

• The first paradigm: Each column may not subdivided second paradigm: non-primary key column is fully dependent on the primary key, and not dependent on a third part of the primary key paradigm: non-primary key column only dependent on the primary key, does not depend on other non-primary key.
• In the design of the database structure, when to try to follow three paradigms, if you do not comply, there must be sufficient grounds, such as performance. In fact, we often compromise performance for database design.

This section Reference: 100 MySQL common interview questions summary

First, why use an auto-increment primary key?

1, if we define the primary key (PRIMARY KEY), then InnoDB will select as the primary key clustered index.

If the primary key is not explicitly defined, it selects the first InnoDB a unique index that does not contain a NULL value as there are primary key index.

If there is no such unique index, the built InnoDB selects ROWID 6 bytes long as aggregated implicit index (writing rows ROWID as the primary key of the record is incremented, the ORACLE ROWID like may be cited as the ROWID is implied).

2 the leaf node, recording the data itself is stored in the main index (a B + Tree), which requires a leaf node within the same pieces of data (the size of a memory page or pages disk) storing records by primary key sequence

Thus whenever a new record is inserted into, MySQL based on its primary key inserted into an appropriate position of the node and, if the load factor reaches a page (the InnoDB default 15/16), then open a new page (node)

3, if the table using the increment primary key, each time a new record is inserted, it will record a subsequent sequence added to the current position of the index node, when a filled, it will automatically open up a new page

4, if the non-increment primary key (if the ID number or student number, etc.), because each insertion primary key value is approximated by a random, each time a new record is inserted into an existing index page must have a location intermediate

At this point MySQL had to order a new record into the proper position and movement data, even the target page may have been written back to disk and cleared from the cache, then you have to read back from the disk, which adds a lot of overhead

At the same time frequent moves, paging operation caused a lot of debris, was not compact index structure, the follow-up had to rebuild the table by filling pages and optimizing OPTIMIZE TABLE

Second, why use the index data to improve efficiency?

1. The index data storage is ordered
2. In the case ordered by the index data is a query without having to traverse the index records
3. In extreme cases, the data query efficiency index for dichotomy search efficiency approaches log2 (N)

Third, the difference between the B + tree index and hash index?

B + Tree is a balanced tree more, the difference in height from the root to each leaf node is no more than 1, and has a pointer to each other links between nodes in the same hierarchy, are ordered, as shown below:

hash index is employed certain hash algorithm, the key terms of the new hash values, similar to a B + tree does not need to look like step by step from the root to leaf nodes with a single hash algorithm to retrieve, it is disorderly

As shown below:

Fourth, the hash index advantage

Equivalent queries, hash index has an absolute advantage (the premise is: not a lot of duplicate key values, if a large number when duplicate key values, hash index is inefficient because there is so-called hash collision)

Fifth, the hash index NA scene

1. It does not support range queries

2. It does not support indexing complete sequencing

3. It does not support the joint index of the most left-prefix matching rule

Usually, B + tree index structure suitable for most scenes, such as the following scene with hash indexes are more advantages:

在HEAP表中，如果存储的数据重复度很低（也就是说基数很大），对该列数据以等值查询为主，没有范围查询、没有排序的时候，特别适合采用哈希索引，例如这种SQL：

# 仅等值查询

select id, name from table where name=‘李明’;

而常用的 InnoDB 引擎中默认使用的是B+树索引，它会实时监控表上索引的使用情况。

如果认为建立哈希索引可以提高查询效率，则自动在内存中的“自适应哈希索引缓冲区”建立哈希索引（在InnoDB中默认开启自适应哈希索引）。

通过观察搜索模式，MySQL会利用index key的前缀建立哈希索引，如果一个表几乎大部分都在缓冲池中，那么建立一个哈希索引能够加快等值查询。

注意：在某些工作负载下，通过哈希索引查找带来的性能提升远大于额外的监控索引搜索情况和保持这个哈希表结构所带来的开销。

但某些时候，在负载高的情况下，自适应哈希索引中添加的read/write锁也会带来竞争，比如高并发的join操作。like操作和%的通配符操作也不适用于自适应哈希索引，可能要关闭自适应哈希索引。

六、B 树和 B+ 树的区别？

1、B树，每个节点都存储key和data，所有节点组成这棵树，并且叶子节点指针为nul，叶子结点不包含任何关键字信息。

2、B+树，所有的叶子结点中包含了全部关键字的信息，及指向含有这些关键字记录的指针，且叶子结点本身依关键字的大小自小而大的顺序链接

所有的非终端结点可以看成是索引部分，结点中仅含有其子树根结点中最大（或最小）关键字。(而B 树的非终节点也包含需要查找的有效信息)

七、为什么说B+比B树更适合实际应用中操作系统的文件索引和数据库索引？

1、B+的磁盘读写代价更低。

B+的内部结点并没有指向关键字具体信息的指针，因此其内部结点相对B树更小。

如果把所有同一内部结点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多。相对来说IO读写次数也就降低了。

2、B±tree的查询效率更加稳定。

由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。

八、关于 MySQL 联合索引

1、联合索引是两个或更多个列上的索引。

对于联合索引:Mysql从左到右的使用索引中的字段，一个查询可以只使用索引中的一部份，但只能是最左侧部分。

例如索引是key index (a,b,c). 可以支持a 、 a,b 、 a,b,c 3种组合进行查找，但不支持 b,c进行查找 .当最左侧字段是常量引用时，索引就十分有效。

2、利用索引中的附加列，您可以缩小搜索的范围，但使用一个具有两列的索引不同于使用两个单独的索引。

复合索引的结构与电话簿类似，人名由姓和名构成，电话簿首先按姓氏对进行排序，然后按名字对有相同姓氏的人进行排序。

如果您知道姓，电话簿将非常有用；如果您知道姓和名，电话簿则更为有用，但如果您只知道名不知道姓，电话簿将没有用处。

九、什么情况下应不建或少建索引？

1、表记录太少

2、经常插入、删除、修改的表

3、数据重复且分布平均的表字段，假如一个表有10万行记录，有一个字段A只有T和F两种值，且每个值的分布概率大约为50%，那么对这种表A字段建索引一般不会提高数据库的查询速度。

4、经常和主字段一块查询但主字段索引值比较多的表字段

十、什么是表分区？
　
　表分区，是指根据一定规则，将数据库中的一张表分解成多个更小的，容易管理的部分。从逻辑上看，只有一张表，但是底层却是由多个物理分区组成。

十一、表分区与分表的区别？

分表：指的是通过一定规则，将一张表分解成多张不同的表。比如将用户订单记录根据时间成多个表。

分表与分区的区别在于：分区从逻辑上来讲只有一张表，而分表则是将一张表分解成多张表。

十二、表分区有什么好处？
　
1、存储更多数据。分区表的数据可以分布在不同的物理设备上，从而高效地利用多个硬件设备。和单个磁盘或者文件系统相比，可以存储更多数据

2、优化查询。在where语句中包含分区条件时，可以只扫描一个或多个分区表来提高查询效率；涉及sum和count语句时，也可以在多个分区上并行处理，最后汇总结果。

3、分区表更容易维护。例如：想批量删除大量数据可以清除整个分区。

4、避免某些特殊的瓶颈，例如InnoDB的单个索引的互斥访问，ext3问价你系统的inode锁竞争等。

十三、分区表的限制因素
1. 一个表最多只能有1024个分区

2. MySQL5.1中，分区表达式必须是整数，或者返回整数的表达式。在MySQL5.5中提供了非整数表达式分区的支持。

3. 如果分区字段中有主键或者唯一索引的列，那么多有主键列和唯一索引列都必须包含进来。即：分区字段要么不包含主键或者索引列，要么包含全部主键和索引列。

4. 分区表中无法使用外键约束

5. MySQL的分区适用于一个表的所有数据和索引，不能只对表数据分区而不对索引分区，也不能只对索引分区而不对表分区，也不能只对表的一部分数据分区。

十四、如何判断当前MySQL是否支持分区？

命令：show variables like ‘%partition%’ 运行结果:

mysql> show variables like ‘%partition%’;
±------------------±------+| Variable_name | Value |±------------------±------+| have_partitioning | YES |±------------------±------+1 row in set (0.00 sec)

have_partintioning 的值为YES，表示支持分区。

十五、MySQL支持的分区类型有哪些？

1. RANGE分区：这种模式允许将数据划分不同范围。例如可以将一个表通过年份划分成若干个分区

2. LIST分区：这种模式允许系统通过预定义的列表的值来对数据进行分割。按照List中的值分区，与RANGE的区别是，range分区的区间范围值是连续的。

3. HASH分区 ：这中模式允许通过对表的一个或多个列的Hash Key进行计算，最后通过这个Hash码不同数值对应的数据区域进行分区。例如可以建立一个对表主键进行分区的表。

4. KEY分区 ：上面Hash模式的一种延伸，这里的Hash Key是MySQL系统产生的。

十六、四种隔离级别

1.Serializable (串行化)：可避免脏读、不可重复读、幻读的发生。
2. Repeatable read (可重复读)：可避免脏读、不可重复读的发生。
3. Read committed (读已提交)：可避免脏读的发生。
4. Read uncommitted (读未提交)：最低级别，任何情况都无法保证

十七、关于MVVC

MySQL InnoDB存储引擎，实现的是基于多版本的并发控制协议——MVCC (Multi-Version Concurrency Control)

注：与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control

MVCC最大的好处：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，现阶段几乎所有的RDBMS，都支持了MVCC。

1. LBCC：Lock-Based Concurrency Control，基于锁的并发控制

2. MVCC：Multi-Version Concurrency Control

基于多版本的并发控制协议。纯粹基于锁的并发机制并发量低，MVCC是在基于锁的并发控制上的改进，主要是在读操作上提高了并发量。

十八、在MVCC并发控制中，读操作可以分成两类：

1.快照读 (snapshot read)：读取的是记录的可见版本 (有可能是历史版本)，不用加锁（共享读锁s锁也不加，所以不会阻塞其他事务的写）

2.当前读 (current read)：读取的是记录的最新版本，并且，当前读返回的记录，都会加上锁，保证其他事务不会再并发修改这条记录

十九、行级锁定的优点：
1、当在许多线程中访问不同的行时只存在少量锁定冲突。

2、回滚时只有少量的更改

3、可以长时间锁定单一的行。

二十、行级锁定的缺点：
　
1.比页级或表级锁定占用更多的内存。

2.当在表的大部分中使用时，比页级或表级锁定速度慢，因为你必须获取更多的锁。

3.如果你在大部分数据上经常进行GROUP BY操作或者必须经常扫描整个表，比其它锁定明显慢很多。

4.用高级别锁定，通过支持不同的类型锁定，你也可以很容易地调节应用程序，因为其锁成本小于行级锁定。

二十一、MySQL优化
1.开启查询缓存，优化查询开启

2. explain你的select查询，这可以帮你分析你的查询语句或是表结构的性能瓶颈。EXPLAIN 的查询结果还会告诉你你的索引主键被如何利用的，你的数据表是如何被搜索和排序的

3. 当只要一行数据时使用limit 1，MySQL数据库引擎会在找到一条数据后停止搜索，而不是继续往后查少下一条符合记录的数据

4. 为搜索字段建索引

5. 使用 ENUM 而不是 VARCHAR。如果你有一个字段，比如“性别”，“国家”，“民族”，“状态”或“部门”，你知道这些字段的取值是有限而且固定的，那么，你应该使用 ENUM 而不是VARCHAR

6. Prepared StatementsPrepared Statements很像存储过程，是一种运行在后台的SQL语句集合，我们可以从使用 prepared statements 获得很多好处，无论是性能问题还是安全问题。

Prepared Statements 可以检查一些你绑定好的变量，这样可以保护你的程序不会受到“SQL注入式”攻击
7. 垂直分表

8. 选择正确的存储引擎

二十二、key和index的区别

1.key 是数据库的物理结构，它包含两层意义和作用，一是约束（偏重于约束和规范数据库的结构完整性），二是索引（辅助查询用的）。包括primary key, unique key, foreign key 等

2. index是数据库的物理结构，它只是辅助查询的，它创建时会在另外的表空间（mysql中的innodb表空间）以一个类似目录的结构存储。索引要分类的话，分为前缀索引、全文本索引等；
　　
二十三、Mysql 中 MyISAM 和 InnoDB 的区别有哪些？

区别：

1. InnoDB支持事务，MyISAM不支持

对于InnoDB每一条SQL语言都默认封装成事务，自动提交，这样会影响速度，所以最好把多条SQL语言放在begin和commit之间，组成一个事务；

2. InnoDB支持外键，而MyISAM不支持。对一个包含外键的InnoDB表转为MYISAM会失败；

3. InnoDB是聚集索引，数据文件是和索引绑在一起的，必须要有主键，通过主键索引效率很高。

但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此主键不应该过大，因为主键太大，其他索引也都会很大。

而MyISAM是非聚集索引，数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。

4. InnoDB不保存表的具体行数，执行select count(*) from table时需要全表扫描。而MyISAM用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快；

5. Innodb不支持全文索引，而MyISAM支持全文索引，查询效率上MyISAM要高；

如何选择：

1. 是否要支持事务，如果要请选择innodb，如果不需要可以考虑MyISAM；

2. 如果表中绝大多数都只是读查询，可以考虑MyISAM，如果既有读写也挺频繁，请使用InnoDB

3. 系统奔溃后，MyISAM恢复起来更困难，能否接受；

4. MySQL5.5版本开始Innodb已经成为Mysql的默认引擎(之前是MyISAM)，说明其优势是有目共睹的，如果你不知道用什么，那就用InnoDB，至少不会差。

二十四、数据库表创建注意事项

1、字段名及字段配制合理性

剔除关系不密切的字段；

字段命名要有规则及相对应的含义（不要一部分英文，一部分拼音，还有类似a.b.c这样不明含义的字段）；

字段命名尽量不要使用缩写（大多数缩写都不能明确字段含义）；

字段不要大小写混用（想要具有可读性，多个英文单词可使用下划线形式连接）；

字段名不要使用保留字或者关键字；

保持字段名和类型的一致性；

慎重选择数字类型；

给文本字段留足余量；

2、系统特殊字段处理及建成后建议

添加删除标记（例如操作人、删除时间）；

建立版本机制；

3、表结构合理性配置

Polytype processing field, whether there is a field can be decomposed into several smaller separate parts table (for example: one can be divided into men and women);

Multi-value processing field, the table can be divided into three tables, search and sort such that more conditioning, and to ensure data integrity!

4. Other suggestions

For large data field, a separate table is stored, so as to affect performance (for example: Introduction field);

Varchar type instead of using char, because dynamic allocation length will varchar, char specified length is fixed;

Table to create a primary key, no primary key for the table, have a certain impact on the query and index definitions;

Field avoiding operation is null, recommended to set the default value (for example: int set a default value of 0) on the indexing query efficiency is significant legislation;

Index, based on the best and the only non-empty field, create too many indexes late insert, update, there is some impact (considering the actual situation created);

This section Reference: wrote 24 MySQL interview questions Java programmer, took no thanks!

To be added ...

This section Reference: MySQL classic face questions