The following is my personal opinion. I have written it wrong, or I understand it wrong. Please understand
If there is a problem with self built MySQL using the information in this article, please don’t come to me
If you have a better solution, or suggestions, you are welcome to submit the version
TimAutumnWind (please indicate the source of the reprint https://learnku.com/articles/50270 )
InnoDB has better CPU and IO performance, better backup and lock table mechanism, and improves the efficiency of statistics and debugging.
In addition, as a system, InnoDB supports a variety of key functions, the most important of which are transaction log and row level lock. Transaction log records real database transactions, but more importantly, data crash recovery and rollback.
IO based on inoodb mode can give more secure data protection and better performance. In addition, in most cases, row level locking can provide higher concurrency performance, because users only lock the data they are writing, and the read data is never blocked
2. The data table and data field must be annotated in Chinese
It is convenient for future newcomers to understand and be familiar with faster, and has better readability
At the same time, the status field is marked with 0 for deletion and 1 for normal enumeration value.
Utf8 is a universal character set. Mb4 is extended on utf8 to support Emoji and other new characters.
For the Internet business with high concurrency and big data, the architecture design idea is to “liberate the database CPU and transfer the calculation to the service layer”. The database is good at storing and indexing, and the CPU computing is more reasonable in the business layer.
If it is low concurrency, small traffic, when I did not say
When there are many pictures, the paging query speed is significantly slower. The response time is within 1 second before, and it takes about 4-5 seconds to respond after adding the photo field. Large files and photos are stored in the file system, and it is better to store URIs in the database
- Increasing primary key and writing data rows can improve insertion performance, avoid page splitting, reduce table fragmentation, and improve the use of space and memory
- Using digital type primary key, shorter data type can effectively reduce the disk space of index and improve the efficiency of index cache
- From the schema, the primary key will be deleted from the primary and secondary database
- More use of business primary keys will make it more convenient to use sub databases and tables.
7. Prohibit the use of foreign keys. If there are foreign key integrity constraints, application control is required
Foreign keys will cause coupling between tables. Update and delete operations will involve associated tables, which will greatly affect the performance of SQL and even cause deadlock.
- Null columns make index / index statistics / value comparisons more complex and more difficult to optimize for MySQL.
- This type of MySQL needs special processing to increase the complexity of database processing records; under the same conditions, when there are many empty fields in the table, the processing performance of the database will be greatly reduced.
- Null values require more storage space, and the null columns in each row of the table or index need additional space to identify.
- When processing null, you can only use is null or is not null, instead of =, in, <, < >,! =, not in
It will waste more disk and memory space, and unnecessary large field queries will eliminate hot data, resulting in a sharp decrease in memory hit rate and affect database performance.
All 0202, use integer bar, decimal easy to lead to money on the wrong or precision problems
- When it comes to area code or country code, + – ()
- Will mobile phone numbers do math?
- Varchar can support fuzzy queries, such as “138%”
- Adding a new enum value requires DDL operation
- The actual internal storage of enum is an integer. Do you think you define a string?
It is suggested that the number of single table indexes should be controlled within 5
The more indexes, the better! Indexing can improve efficiency, but it can also reduce efficiency.
Index can increase query efficiency, but it will also reduce the efficiency of insertion and update, and even reduce the efficiency of query in some cases.
When the MySQL optimizer chooses how to optimize the query, it will evaluate each available index according to the unified information to generate the best execution plan. If there are many indexes available for query at the same time, it will increase the time for the MySQL optimizer to generate the execution plan, which will also reduce the query performance.
It is forbidden to build indexes on attributes that are updated frequently and with low discrimination, such as age and gender
Updating will change the B + tree, and indexing frequently updated fields will greatly reduce database performance
For the attribute of gender, which is not distinguished, it is meaningless to establish an index. It can not effectively filter data, and its performance is similar to that of full table scanning
To build a composite index, we must put the field with high discrimination in front, which can filter data more effectively
Do not use insert into t_ XXX values (xxx), must display the column attribute of the specified insertion, which is easy to appear program bug after adding or deleting fields
Do not use functions or expressions on the properties of where conditions
This will cause a full table scan
SELECT uid FROM t_user WHERE from_unixtime(day)>=’2019-10-09’
SELECT uid FROM t_user WHERE day>=unix_timestamp(‘2019-10-09 00:00:00’)
Do not negative queries, and fuzzy queries beginning with%
Negative query conditions: not,! =, < >,! <,! >, not in, not like, will cause full table scanning
%The first fuzzy query will result in a full table scan
If you need to search, you can use full-text indexing
Do not use join queries in large tables and prohibit sub queries in large tables, which will produce temporary tables, consume more memory and CPU, and greatly affect database performance
Try not to use the or condition, you must change to in query. Old version of MySQL or query can not hit the index, even if it can, it is not necessary
The application must catch SQL exceptions and handle them accordingly
To optimize mysql, we should make good use of explain to view SQL execution plan
The following is a comment on the optimization
Key column = > the index name used. If no index is selected, the value is null. Index can be forced
Type column = > connection type. A good SQL statement should reach the range level. Eliminate all level
Rows column = > the number of rows to scan. This value is an estimated value. It would be good if you knew it in mind
Extra column = > for details, note that the common unfriendly values are: using filesort, using temporary
key_ Len column = > index length
When using in, MySQL optimizes in accordingly, that is, all constants in in in are stored in an array, and the array is ordered. However, if the value is large, the consumption is also relatively large. Another example: select id from table_ Name where num in (1,2,3) for consecutive values, use between instead of in, or use the connection to replace it.
Select * increases a lot of unnecessary consumption (CPU, IO, memory, network bandwidth); increases the possibility of using overlay index. When the table structure changes, the front break also needs to be updated. Therefore, the field name should be directly followed by the select.
This is to make the type column in explain a const type
If one of the fields on both sides of or is not an index field, and other conditions are not index fields, the query will not be indexed. Many times, using union all or Union (when necessary) instead of “or” will get better results
The main difference between union and union all is that the former needs to merge the result set before performing unique filtering operation, which will involve sorting, increasing a large number of CPU operations, increasing resource consumption and latency. Of course, the premise of union all is that there is no duplicate data in the two result sets.
select id from
table_name order by rand() limit 10000;
The above SQL statement can be optimized to
select id from
table_name t1 join (select rand() * (select max(id) from
table_name) as nid) t2 ont1.id > t2.nid limit 1000;
select id,name from table_name limit 866613, 20
When using the above SQL statements for pagination, some people may find that with the increase of the table data, using limit paging query directly will become slower and slower.
The optimization method is as follows: you can take the ID of the maximum number of rows in the previous page, and then limit the starting point of the next page according to the maximum ID. In this column, the largest ID on the previous page is 866612. SQL can be written as follows:
select id,name from table_name where id> 866612 limit 20
The judgment of null will cause the engine to abandon the use of index and scan the whole table. As mentioned above, null is not used
select user_id,user_project from table_name where age*2=36;
In the database, arithmetic operations are performed on the fields, which will cause the engine to abandon the use of indexes. It is suggested that the following should be changed:
select user_id,user_project from table_name where age=36/2;
For example, the index contains the fields ID, name and school. You can use the ID field directly or the order of ID and name, but name; school can’t use this index. Therefore, when creating a federated index, we must pay attention to the order of index fields, and the commonly used query fields are put at the top
Sometimes the MySQL optimizer uses the index it thinks is appropriate to retrieve SQL statements, but maybe the index it uses is not what we want. In this case, we can use force index to force the optimizer to use the index we have made. At the same time, it can also be used to force index search for statements without index under certain conditions
For a federated index, if there are range queries, such as between, >, < and other conditions, the following index fields will be invalid.
- Pay attention to query sentence optimization
- Optimize subquery
- Use index
- Breakdown table, cold field can also be separated from hot field
- Intermediate table
- Use as much as possible inner join**, avoid**left join
- Use the small table to drive the large table
- Analysis table, check list, optimization table
- Increase**Redundant fields, reduce queries, do not split everything very scattered**
- Sub database and sub table One master and many subordinates Or directly Multi master and multi subordinate
- Cache cluster
a. Configuration of multi – core and high – frequency CPU, multi – core can execute multiple threads
b. If you configure large memory and increase memory, you can increase the cache capacity, so that you can reduce the disk I / O time and improve the response speed
c. Configure high speed disk or distribute disk reasonably: high speed disk can improve I / O, distributed disk can improve the ability of parallel operation
d. To make a analogy, alicloud servers do self built databases. The server hard disk should be at the level of ESSD. Don’t put me on an efficient cloud disk
- The configuration parameters of MySQL service are all in the my.cnf Or my.ini The following is a list of parameters that have a significant impact on performance
- key_ buffer_ Size = > index buffer size
- table_ Cache = > the number of tables that can be opened at the same time
- query_ cache_ Size = > query buffer size
- query_ cache_ Type = > the switch of the previous parameter, 0 means no buffer is used, 1 means buffer is used
- But you can use SQL in queries_ NO_ Cache means not to use buffers
- Indicates that the buffer is used only when it is explicitly pointed out in the query, that is, SQL_ CACHE.
- sort_ buffer_ Size = > sort buffer
- More parameters = >www.mysql.com/cn/why-mysql/perform…
This work adoptsCC agreementThe author and the link to this article must be indicated in the reprint