MySQL storage engine
Difference (MyISAM, InnoDB)
1, innodb supports transactions, myisam does not support transactions
2, innodb supports foreign keys, and myisam does not support. When converting an innodb that supports external to myisam, it will fail
3. InnoDB does not save the specific number of rows in the table. When you execute select count (*) from table, it will scan the entire table, and myisam uses a variable to save the number of rows in the entire table. To execute the above statement, just read the value of the variable, the speed is very fast
4, innodb does not support full-text search, and myisam supports full-text search, query efficiency is higher than innodb
5, innodb supports row-level locks, myisam lock granularity is table
6, myisam said to save in the form of files, in cross-platform data transfer, using myisam storage will save a lot of trouble.
==========
Myisam does not support primary foreign key
innodb support
Myisam manages non-transactional tables, provides high-speed storage and retrieval, and full-text search
innodb supports transactions, with many features, including ACID
A: atomicity
C: consistency
I: isolation
D: Permanent
What is the role of database index? What are the disadvantages?
Creating an index can greatly improve the performance of the system.
1. By creating a unique index, you can ensure the uniqueness of each row of data in the database table.
2. It can greatly speed up the data retrieval speed, which is also the main reason for creating indexes.
3. It can speed up the connection between tables and tables, especially in terms of achieving the reference integrity of data.
4. When using grouping and sorting, words and sentences for data retrieval, it can also significantly reduce the time for grouping and sorting in the query.
5. By using the index, you can use the optimization concealer during the query to improve the performance of the system.
Disadvantages:
a. It takes time to create and maintain indexes. This time increases with the increase of data and volume.
b. The index takes up physical space.
c. When the data in the table is added, deleted, or modified, the index should also be dynamically maintained, which reduces the speed of data maintenance.
Why choose B + tree for data structure in MySQL?
The search time complexity of Hash is O (1), and the search is really fast. No matter which number you find, you can find it at one time, but there is a problem. We usually find data according to the condition, where. . . . more than the. . . Less than. . . . . between and. . . . There is also sorting. . . At this time, the time complexity becomes O (n), which is more stable than the hash binary tree. Any time complexity is log (n), so MySQL does not use hash.
==============
Why not use a binary tree?
The definition of a binary tree is "small left and big right", but there will be extreme cases, such as the first number is 1, and then 2,3,4,5,6 ... will form a chain, this situation Is "rightward"
================ The
balanced binary tree will rotate, and the root node will change as the data changes. In theory, the number of comparisons and the number of searches are ideal at this time, but there is a problem that as the amount of data increases, the height of the tree also becomes larger, and the speed of the search is directly related to the height of the tree! And the number of disk IO is also positively related to the height of the tree.
==================
Only two nodes can be hung on a node of the binary tree, and a maximum of 3 nodes can be hung on a node of the B tree. The advantage of this is that the tree can be reduced. Height, because there is a node in the middle. B-tree nodes not only store data pointers but also data data, but the storage space of each page is limited, so compared to B + trees (non-leaf nodes of B + trees only store data pointers, data exists in leaves Node) height will increase, will increase the disk io.
======================
B + tree has two data structures, the bottom leaf node is a linked list, the non-linked list node is a tree structure, B + tree will all data All are placed on the leaf nodes, and all nodes no longer need to be traversed in order (left-center-right), and there is a pointer between the nodes. This speeds up the range search.
lock in mysql
In computer science, locks are a synchronization mechanism used to force restrictions on resource access when executing multithreading, that is, used to ensure the satisfaction of mutual teardown requirements in concurrency control.
Row-level lock
It is the finest granular lock in MySQL, which means that only the current operation row is locked. Row-level locking greatly reduces the conflict of database operations. The locking granularity is the smallest, but the locking overhead is also the largest.
Features: large overhead, slow locking, deadlock, minimum granularity, lowest possible conflict, and highest concurrency
Less conflicts and slow locking
(is the finest granular lock in MySQL, which means that only the current operation row is locked. Row-level locking greatly reduces the conflict of database operations. Its locking granularity is the smallest, but the The lock overhead is also the largest., Features: large overhead, slow lock, there will be deadlocks, the granularity is the smallest, the conflict may be the lowest, and the concurrency is the highest
Table-level lock
It is the most granular lock in MySQL, which means to lock the entire table of the current operation. It is simple to implement and consumes less resources, and is supported by most MySQL engines.
Features: small overhead, fast locking, no deadlock, high speed granularity, high probability of conflict, and lowest concurrency
Fast speed and many conflicts
(the most granular lock in MySQL, which means that the entire table of the current operation is locked. It is simple to implement and consumes few resources. It is supported by most MySQL engines. Features: small overhead, Fast locking, no deadlock, high speed granularity, high probability of conflict, and lowest concurrency)
Page-level lock
Is a lock between the row-level lock and the table-level lock in MySQL, is a kind of lock they compromise, lock a group of adjacent records at a time
Features: unlocking and locking are between table locks and row locks, deadlocks will occur, the granularity is also between row locks and table locks, and the degree of concurrency is general
Between the row lock and the table lock
(is the lock between the row-level lock and the table-level lock in MySQL, is a kind of lock they compromise, lock a group of adjacent records at a time, features: unlock and lock Between table locks and row locks, there will be deadlocks, the granularity is also between row locks and table locks, the concurrency is average)
Database optimization
What is optimization?
Reasonably arrange resources, adjust system parameters to make MySQL run faster and save resources
Optimization is multifaceted, including query, update, server, etc.
Optimization principle: reduce resource bottlenecks, reduce resource occupancy, and increase system response speed
Explain view the execution plan (add explain in front of the query statement)
Field explanation
select_type: indicates the type of select statement
- Simple
simple query, which does not include join query and subquery - primary
query, or the outermost query statement
The second or later query statement of the union connection query
The second or subsequent select statement in dependent union union depends on the query outside- union result
join query results
The first select statement of sub_query subquery- dependent_subquery
subquery first select statement, depends on the query outside - derived
select (from query sub-query)
type: indicates the connection type of the table
-
There is only one line for system, which is a special type of const type, which does not appear at ordinary times, this can be ignored
-
The const data table has only one matching row, which is often used for primary key or unique index queries. It can also be understood that const is optimal
-
eq_ref can be used to compare queries with an index using =, it is used in all parts of an index are connected and the index is the primary key or unique
-
The ref query condition is neither a primary key nor a unique case. Can be used for = or <or> operations
-
ref_or_null This type is like ref, but MySQL has been added to specifically search for rows that contain null values. The optimization of this connection type is often used in solving subqueries
-
index_merge This connection type indicates that the index merge optimization method is used
-
unique_subquery is an index lookup function that can completely replace subqueries with higher efficiency
-
index_subquery This connection type is similar to unique_subquery, and can replace subquery
-
range only retrieves rows in a specified range, use an index to select rows
-
index The connection type is the same as all, usually faster than all, because the index file is usually smaller than the data file
-
all performs a full table scan with the worst performance
These 5 situations are all ideal index usage
(system, const, eq_ref, ref, ref_or_null)
possible_keys
Indicate which index can be used in MySQL to find a row in the table. If the column is null, it means that no index is used. You can create an index on this column to improve performance
-
key: Displays the index (key) that MySQL actually decides to use. If no index is selected, the key is null. You can force the index or ignore the index
-
key_len: shows that MySQL decides to use the length of the key. If the key is null, the length is null
-
ref: Show which column or constant to use to select rows from the table together with key
-
rows: displays the number of rows that MySQL thinks it must check to execute the query
-
extra: This column contains detailed information for MySQL to resolve the query
Notes on using MySQL indexes
1. In the query statement that uses the Like keyword for query, if the first character of the matching string is%, the index does not work. Indexing only works if% is not in the first position
2. The compound index follows the principle of the leftmost prefix, that is, the first field of the compound index is used in the query condition before the index is used, so the position of the index column in the compound index is crucial.
3. As long as the column contains null values, it will not be held in the index. As long as there is a column in the composite index that contains null values, then this column is invalid for the composite index.
4. In the query condition of the query statement, only the OR keyword and the columns in the two conditions before and after the OR are both indexes, the index will take effect
Summary
(1. In the query statement that uses the Like keyword to query, if the first character of the matching string is%, the index does not work. The index will only work when% is not in the first position. 2. Compound The index follows the leftmost prefix principle, that is, the first field of the composite index is used in the query condition, the index will be used, so the position of the index column in the composite index is critical., 3. As long as the column contains null The value will not be held in the index. As long as there is a column in the composite index that contains null values, then this column is invalid for the composite index. 4. In the query condition of the query statement, there is only the OR keyword, and the two before and after the OR (The index will only take effect if the columns in each condition are indexes)
Subquery optimization:
During subqueries, MySQL needs to create temporary tables and delete them after the query, so the speed of subqueries will be affected to a certain extent, so you can use join queries to join instead of subqueries. Joined queries do not need to create temporary tables, which is faster than subqueries. .
Optimization of database structure
A good database design solution often has a multiplier effect on database performance.
Need to consider data redundancy, query and update speed, whether the field data type is reasonable, etc.
- Decompose a table with many fields into multiple tables
For tables with many fields, if some fields are used less frequently and some fields are used more frequently, you can separate those fields that are used less frequently to form a new table. Because when the amount of data in a table is large, it will become very slow due to the use of low fields.
- Increase the middle table
For tables that require frequent joint queries, you can create a new intermediate table.
Through the intermediate table, insert the data that needs to be queried into the intermediate table, and then change the original joint query to query the query on the intermediate table
- Add redundant fields
When designing the table, you should try to follow the specifications of the paradigm theory, try to reduce redundant fields, and make the database design look refined and elegant. However, it is reasonable to assume that redundant fields can increase the query speed.
Note: The value of the redundant field is modified in one table, and it must be modified in another table at the same time, otherwise there will be data inconsistency
- Server hardware optimization
-
Configure larger memory
-
The memory io is much faster than the hard disk, which can increase the buffer capacity of the system. The data stays in the memory for a longer time to reduce the disk io
-
Configuration tell disk, such as SSD
-
Reasonably allocate disk IO
-
Distribute disk io to multiple devices to reduce resource competition and improve parallel operation capabilities
-
Configure multi-core processor
MySQL is a multi-threaded database, multi-processor can improve the ability to execute multiple threads at the same time
MySQL query optimization method
-
Do not perform calculations on columns, as this will cause the index to fail and thus perform a full table scan
-
Try to avoid using! = Not in <> and other negative operations, you can use or to connect conditions
-
Always drive large result sets with small result sets
-
Always set an id for each table
-
Use limit 1 when there is only one piece of data
-
Try not to use functions in statements
-
Avoid using select *, which field should be written wherever it is used
-
(Do not perform calculations on the columns, this will cause the index to fail, so as to perform a full table scan, try to avoid using! = Not in <> and other negative operations, you can use or to connect conditions, and always use small result sets to drive large result sets, Always set an id for each table, use limit 1 when there is only one piece of data, try not to use functions in statements, avoid using select *, write which field should be used wherever it is used)
MySQL parameter optimization
MySQL configuration parameters are in the [mysqld] group in the my.conf or my.ini file
-
key_buf_size: the size of the index buffer. The index buffer is shared by all threads. Increasing the index buffer can get better processing index, but this value is not as large as possible. Its value depends on the memory size. If it is too large, it will cause the system to frequently page, and it will also reduce the performance of the system
-
table_cache: indicates the number of tables opened at the same time. The larger the value, the more the number of tables that can be opened at the same time. The larger the value, the better.
-
sort_buf_size: indicates the size of the sort buffer, the larger the value, the faster the sorting speed
-
innodb_buf_pool_size: indicates the maximum cache of innodb type tables and indexes. The larger the value, the faster the query speed, but too large will affect system performance
-
max_connections: indicates the maximum number of connections to the database, pay attention to the connection will occupy memory resources, too many connections will cause MySQL to die
-
thread_cache_size: indicates the number of threads that can be reused, if there are many new threads, you can increase the value of the parameter appropriately
-
wait_timeout: indicates the number of seconds the server waits for action when closing a connection. The default value is 28800
Transaction isolation level
- Read uncommitted
Allow dirty reads, that is, data that may be modified by uncommitted transactions in other sessions may be read-"dirty reads, non-repeatable reads, and virtual reads
- Read submitted
Only the submitted data can be read. Solve dirty reads, but non-repeatable reads, false reads still happen
- Repeatable read
The queries within a transaction are consistent at the beginning of the transaction, innodb default level. Solved dirty reads and non-repeatable reads, but virtual reads may still occur
- Serialize
Fully serialized reads. Every read requires a table-level shared lock. The reads and writes block each other, which guarantees mutual exclusion between different transactions and avoids dirty reads, non-repeatable reads, and magic reads.
Dirty read :
Refers to a transaction is accessing the data, and the data has been modified, but this modification has not yet been submitted to the database, this matter another transaction also access this data, and then use this data
Non-repeatable reading :
In the same transaction, two identical queries returned different results (comparison of the read data itself), for example: during transaction 1, transaction 2 modified the data of transaction 1 operation, due to the modification of transaction 2 , The data read before and after transaction 1 may be different
Phantom reading :
The first transaction modifies the data in a table. This modification involves all the data rows in the table. At the same time, the second transaction also modifies the data in this table. This modification is to insert a new row into the table. Data, then the first transaction will appear. I have obviously modified all the data, why there is one data that has not been modified, just like a magic read
