Database Face-to-face 4

What are the ideas for SQL optimization?

  • create index

    • To try to avoid full table scans, first consider building indexes on the columns involved in where and order by.

    • Create indexes on fields that are frequently retrieved.

    • The number of indexes in a table is best not to exceed six.

  • Avoid using calculations on indexes

    • In the where clause, if the index column is part of a calculation or a function, the DBMS optimizer will not use the index but use the full table query. The function is a type of calculation. Colleagues usually use exists in in and exists, because in does not take the index.

  • Try to compress multiple sql statements into one sql

    • Every time you execute sql, you need to establish a network connection, perform permission verification, optimize the query of sql statements, and send the execution results. This process is very time-consuming, so you should avoid excessive execution of sql statements and be able to compress a sentence of sql Do not execute multiple statements to execute.

  • Replace having clause with where clause

    • Avoid using having clauses, because having will only filter the results after retrieving all the records, while where is to select records before aggregation. If you can limit the number of records through where clauses, you can reduce the cost of this aspect Small.

  • Query select statement optimization

  • Do not use selct * form t anywhere, replace * with a specific field list, and do not return unused fields.

  • Try to avoid judging the null value in the where clause, otherwise the engine will give up using the index and perform a full table scan.

  • Update update statement optimization

  • If you only update one or two fields, do not update all fields, otherwise frequent calls will cause detailed new energy consumption and bring a lot of logs.

  • Insert inset statement optimization

  • When creating a new temporary table, if you insert a large amount of data at one time, you can use select into instead of create table to avoid creating a large number of logs and daily high data.

  • Large table optimization: When the number of MySQL single table records is too large, the CRUD performance of the database will drop significantly. Some common optimization measures are as follows:

    • Limit the scope of the data: Be sure to disallow search statements that do not subject to any conditions that limit the scope of the data. For example: when our current users query the order history, we can control it within one month;

    • Separation of reading and writing: classic database splitting scheme, the main library is responsible for writing, and the secondary library is responsible for reading

    • Vertical partition: split according to the correlation of the data tables in the database. For example, if the user table contains both the user's login information and the user's basic information, the user table can be split into two separate tables, or even placed in a separate library as a sub-database. Simply put, vertical splitting refers to the splitting of data table columns, and splitting a table with more columns is called multiple tables.

      • Advantages: It can make column data smaller, reduce the number of blocks read during query, and reduce the number of I/O times. In addition, the vertical distribution can simplify the structure of the table, which is easy to maintain.

      • Disadvantages: The primary key will be redundant, and redundant columns need to be managed. Vertical partitioning makes things more complicated.

    • Horizontal partitioning: Keep the structure of the data table unchanged, and store data fragments through a certain strategy. In this way, each piece of data is dispersed into different tables or libraries, achieving the purpose of distribution.

      • Advantages: support very large data volume storage, and the application-side modification is also small

      • Disadvantages: Fragmentation transactions are difficult to solve, cross-node join performance is poor, and logic is complex

Lock mechanism and InnoDB lock algorithm

There are three lock algorithms for the InnoDB storage engine:

  • Record lock: a lock on a single row record

  • Gap lock: Gap lock, locking a range, excluding the record itself

  • Next-key lock: record+gap locks a range, including the record itself

Relevant knowledge points:

  1. InnoDB uses next-key lock for row queries

  2. Next-locking keying in order to solve the Phantom Problem phantom reading problem

  3. When the query index contains unique attributes, downgrade the next-key lock to record key

  4. The purpose of Gap lock design is to prevent multiple transactions from inserting records into the same range, which will lead to phantom reading problems

  5. There are two ways to explicitly close the gap lock: (except for foreign key constraints and uniqueness checks, only record locks are used in other cases) A. Set the transaction isolation level to RC B. Set the parameter innodb_locks_unsafe_for_binlog to 1

Are foreign keys used in the application? Foreign key role? What should be paid attention to when using foreign keys?

The role of foreign keys: foreign keys are used to associate with another table. It is a field that can determine another table record and is used to maintain data consistency.

Advantages: The database itself can guarantee data consistency, integrity, and more reliability, because it is difficult for programs to guarantee 100% data integrity, and using foreign keys can maximize data integrity even when the database server is down or other problems occur. Ensure data consistency and integrity.

Disadvantages: Poor performance. When inserting data every time, when there is a foreign key constraint, the record must be scanned every time to see if it is qualified. Generally, more than one field has a foreign key, so the number of scans increases in series.

important point:

  • Both parent and child tables must use the same storage engine, and temporary tables are prohibited

  • The database storage engine can only be InnoDB (MySQL)

  • The data type of the foreign key column and the reference column must be the same

Guess you like

Origin blog.csdn.net/slave_of_life/article/details/130650150