Improve performance

Improve performance

The following is some discussion and analysis of performance tuning:

  • Generally speaking, the key production DBMS should run on its own dedicated server.
  • MySQL is pre-configured with a series of default settings, and it is usually good to start with these settings. But after a while, you may need to adjust the memory allocation, buffer size, etc. (To view the current settings, you can use show variables; and show status;.)
  • MySQL is a multi-user and multi-threaded DBMS. In other words, it often performs multiple tasks at the same time. If one of these tasks is slow, all requests will be slow. If you encounter significant performance problems, you can use show processlist to display all active processes (and their thread IDs and execution time). You can also use the kill command to terminate a specific process (you need to log in as an administrator to use this command).
  • There is always more than one way to write the same select statement. You should experiment with joins, unions, subqueries, etc., to find the best way.
  • Use the explain statement to let MySQL explain how it will execute a select statement.
  • Generally speaking, stored procedures execute faster than executing each MySQL statement one by one.
  • The correct data type should always be used.
  • Never retrieve more data than required. In other words, don't use select * (unless you really need each column).
  • Some operations (including insert) support an optional delayed keyword. If you use it, control will be immediately returned to the calling program, and the operation will actually be executed as soon as possible.
  • When importing data, you should turn off automatic submission. You may also want to delete indexes (including fulltext indexes) and then rebuild them after the import is complete.
  • The database tables must be indexed to improve the performance of data retrieval. Determining what to index is not a trivial task. You need to analyze the select statement used to find repeated where and order by clauses. If it takes too long for a simple where clause to return results, you can conclude that the column (or several columns) used in it is the object that needs to be indexed.
  • Do you have a series of complex or conditions in your select statement? By using multiple select statements and union statements that connect them, you can see tremendous performance improvements.
  • Indexes improve the performance of data retrieval, but damage the performance of data insertion, deletion, and update. If you have some tables that collect data and are not searched often, do not index them until it is necessary. (The index can be added and deleted as needed.)
  • like is very slow. Generally speaking, it is better to use fulltext rather than like.
  • The database is a constantly changing entity. A set of well-optimized tables may be completely different after a while. Due to table usage and content changes, the ideal optimization and configuration will also change.
  • The most important rule is that every rule will be broken under certain conditions.

Guess you like

Origin blog.csdn.net/weixin_49984044/article/details/109047599