Try not to let the database do too many operations
The database is mainly used for storage. We should avoid letting the database do operations, such as writing timing tasks, stored procedures, etc. Complex calculations should be implemented in program code. We should use the database as simple as possible.
Control the amount of data
The data volume of a single table in a year generally contains no more than 500W chars, and we need a reasonable split table. The recommended table for a single library is between 300 and 400.
Number of fields in a single table
The fields of a single table should be few and refined, so how much is appropriate? Generally, there are 20 to 50 single table fields online.
In development, we must pay attention to avoid using large SQL, large transactions.
Avoid using NULL fields
I found that many children's shoes like to default NULL fields when building tables. It is difficult to optimize queries using NULL. If we add indexes to NULL columns, additional space is needed, and the conforming index containing NULL is invalid.
`a` char(32) DEFAULT NULL
`b` int(10) NOT NULL
Such as the above.
Use TEXT sparingly
We can use VARCHAR instead of TEXT, because TEXT type processing performance is lower than VARCHAR, TEXT will force the generation of temporary tables, thus wasting more space. Under UTF-8, VARCHAR(65535) takes up approximately 64K of space.
If you must use it, split it into a separate table.
CREATE TABLE t1 (
id INT NOT NULL AUTO_INCREMENT,
data text NOT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB;
About the index
Recommended number of indexes
Although the index can improve the query, if the index column is updated frequently, index maintenance will also become a burden. If we do not add an index, try not to add it, and it is best not to exceed 20% of the number of fields.
About function operations
Do not perform mathematical operations or function operations on the index column, because this will invalidate the index.
-- 不要这样用
select * from table WHERE to_days(current_date) – to_days(date_col) <= 10
-- 推荐使用
select * from table WHERE date_col >= DATE_SUB('2011-10-22',INTERVAL 10 DAY);
Self-incrementing column as primary key
Self-incrementing columns are used as the primary key, which is conducive to index maintenance, and the primary key should not be modified in general. Do not use strings as primary keys, for example, do not use UUIDs as primary keys.
It is recommended to use a business-independent AUTO_INCREMENT column or a global ID generator as the surrogate primary key.
We know that in InnoDB, the primary key index is created by the primary key column by default, so the problem is coming.
“If no primary key is specified, will a primary key index be created?
”
Minimize the use of foreign keys
If foreign keys are used, deadlock is likely to occur under high concurrency. We should guarantee the constraints by the program.
The SQL statement should be simple
I have seen hundreds of lines of SQL. I think this is not good. Generally, a SQL can only be operated on a CPU, and a large SQL may crash the database.
We should split the big SQL into multiple simple small SQLs. Simple SQL will make the cache hit rate higher.
About affairs
We should try our best to put operations that have nothing to do with the transaction outside the transaction, which can reduce the occupation of lock resources.
Simple to use
We use stored procedures and triggers as little as possible, and use MySQL functions to process results as little as possible. The calculation of the data should be left to the program.
About SQL efficiency
Rewrite OR to IN()
In the same field, rewrite or as in()
-
OR efficiency: O(n)
-
IN efficiency: O(Log n)
-
When n is large, OR will be much slower
Select * from table WHERE phone='12347856' or phone='42242233';
-- 推荐使用in
Select * from table WHERE phone in ('12347856' , '42242233')
Different fields, change or to union
Select * from table WHERE phone='010-88886666' or cellPhone='13800138000';
-- 推荐使用 union
Select * from table WHERE phone='010-88886666'
union
Select * from table WHERE cellPhone='13800138000';
Use UNION ALL instead of UNION
There will be deduplication overhead when using UNION.
About JOIN
Many children's shoes like to use JOIN to query the tables. In the Alibaba Development Manual, it is recommended not to exceed three tables of JOIN.
It is recommended to split the table.
Select * from tag JOIN tag_post on tag_post.tag_id=tag.id JOIN post on tag_post.post_id=post.id WHERE tag.tag='二手玩具';
It is recommended to do this:
Select * from tag WHERE tag='二手玩具';
Select * from tag_post WHERE tag_id=1321;
Select * from post WHERE post.id in (123,456,314,141)
About counting statistics
-
Real-time statistics: use memcache, two-way update, benchmark run in the early morning
-
Non-real-time statistics: try to use a separate statistics table and recalculate regularly
About limit paging
We may usually have written such SQL:
Select * from table limit 10000,10;
But this will be very slow, the larger the offset, the slower.
We recommend this way
select * from table WHERE id>=23434 limit 11;
Someone on the Internet did a test:
Do not display locks on the database in the terminal
“
External locks are not controllable to the database
Disaster when high concurrency
Extremely difficult to debug and troubleshoot
Recommended in the past
Scan the QR code to get more exciting. Or search Lvshen_9 on WeChat , you can reply to get information in the background
1.回复"java" 获取java电子书；
2.回复"python"获取python电子书；
3.回复"算法"获取算法电子书；
4.回复"大数据"获取大数据电子书；
5.回复"spring"获取SpringBoot的学习视频。
6.回复"面试"获取一线大厂面试资料
7.回复"进阶之路"获取Java进阶之路的思维导图
8.回复"手册"获取阿里巴巴Java开发手册(嵩山终极版)
9.回复"总结"获取Java后端面试经验总结PDF版
10.回复"Redis"获取Redis命令手册，和Redis专项面试习题（PDF）
11.回复"并发导图"获取Java并发编程思维导图（xmind终极版）Another: Click [ My Benefits ] to have more surprises.