Database-Interview Preparation

Database engine: INNODB MyIsam

Master-slave replication

CURD

insert into table name (,) values ​​(,)
update table name set field name = changed content where
select * from table name where
delete from table name where (delete the row corresponding to the condition)

Create index and delete index

create index index name on table name (field name)
drop index index name on table name

View execution plan command explain

12 fields
table,extra,type,possible_keys,key,select_type
extra: information that may appear
①using index uses index query
②using where uses where clause
③filesort File sorting performance is extremely poor

type:
system>const>eq_ref>ref>range>index>all
range is the most optimized form using range query
all means full table scan
ref and range are the more optimized positions we can do

possible_keys, key:
the index name that may be used, the index name used

select_type: Given the type of query used, is it simple or a
simple single-table query using a subquery?

for example:

select distinct<select_list> from


join <right_table> on <join_condition>
where <where_condition>
group by having
limit <limit_number>

The execution order of the above SQL query, according to the label:
(6) SELECT (6.5)DISTINCT<select_list>

(1) FROM <left_table>
(2) <join_type> JOIN <right_table>
ON <join_condition>
(3) WHERE <where_condition>
(4) GROUP BY <group_by_list>
(5) HAVING <having_condition>

(7) ORDER BY <order_by_list>
(8) LIMIT <limit_number>

Several ways of sql optimization

1. Optimize the query, try to avoid full table scans, first consider establishing indexes on the columns involved in where and order by

2. Don't use select * from t anywhere, replace "*" with a specific field list, and don't return any unused fields.

3. Avoid frequent creation and deletion of temporary tables to reduce the consumption of system table resources.

4. Try to avoid using the != or <> operator in the where clause, otherwise the engine will give up using the index and perform a full table scan.

5. Try to avoid using or in the where clause to join the condition, otherwise it will cause the engine to abandon the use of the index and perform a full table scan instead of union all (not union)

6. In and not in should also be used with caution, otherwise it will cause a full table scan.
For continuous values, do not use in if you can use between:
not between 1 and 3 instead of not in(1,2,3);

7. The following query will also cause a full table scan: (% put in front of the prohibition to use)
select id from t where name like'%abc';

8. Should try to avoid performing expression operations on the fields in the where clause, which will cause the engine to abandon the use of the index and perform a full table scan. Such as:
select id from t where num/2=100
should be changed to:
select id from t where num=100*2

9. Should try to avoid performing functions or operations on the fields in the where clause, which will cause the engine to abandon the use of the index and perform a full table scan. Such as:
select id from t where substring(name,1,3)='abc'-id whose name starts with abc
should be changed to:
select id from t where name like'abc %'

10. Use numeric fields as much as possible. If fields that only contain numeric information, try not to design them as characters, which will reduce the performance of queries and connections and increase storage overhead.
This is because the engine compares each character in the string one by one when processing queries and concatenations. For numeric types, only one comparison is sufficient.

11. Use varchar instead of char as much as possible, because the storage space of variable-length fields is small, which can save storage space.
Secondly, for queries, the search efficiency in a relatively small field is obviously higher.

Guess you like

Origin blog.csdn.net/BOWWOB/article/details/113780465