Foreword
For a data-centric application, the quality of the database directly affects the performance of the program, so database performance is very important. Therefore, everyone should understand the optimization operations of the MySQL database. This article mainly summarizes the common optimization operations in the MySQL database. I won’t say much more about it below, let’s take a look at the detailed introduction.
1. Index index
Putting Index first, needless to say, we have been quietly using this optimization method, that is, the primary key index. Sometimes we may not care, if you define a suitable index, the database query performance (speed) will be improved several times or even dozens of times.
normal index
The effect is to improve the query speed.
Create table, create index
CREATE TABLE tbl_name (
field name field type [integrity constraint],
~
index [index name] (column_name)
);
create index
CREATE INDEX index_name ON tab_name (column_name)
delete index
DROP INDEX index_name FROM tab_name
view index
SHOW index FROM tab_name
primary key
index is used to speed up queries and unique constraints
Create tables and create indexes
CREATE TABLE tbl_name(
field name field type [integrity constraints],
~
PRIMARY KEY(column_name)
);
create index
ALTER TABLE tab_name ADD PRIMARY KEY( column_name) DROP
INDEX
ALTER TABLE tab_name DROP PRIMAY KEY(column_name)
unique index
The role is to speed up queries and unique
constraints , create a table, create an index
CREATE TABLE tbl_name (
field name field type [integrity constraint],
~
unique [index name] (column_name)
);
create an index
CREATE UNIQUE INDEX index_name ON tab_name (column_name)
delete Index
DROP UNIQUE INDEX index_name FROM tab_name
Second, use less SELECT*
When some people query the database, they will select whatever they want to query, which is inappropriate behavior. We should fetch the data we want to use instead of fetching all, because when we select, it will increase the burden of the web server, increase the load of network transmission, and the query speed will naturally decrease.
3. EXPLAIN SELECT
It is estimated that many people have not seen this function, but it is strongly recommended here. The explain shows how MySQL uses indexes to process select statements and join tables. Can help choose better indexes and write more optimized query statements. The main use is to add explain before select.
EXPLAIN SELECT [lookup field name] FROM tab_name …
Fourth, open the query cache
Most MySQL servers have query caching turned on. This is one of the most efficient ways to improve performance, and this is handled by MySQL's database engine. When many identical queries are executed multiple times, the results of these queries will be placed in a cache, so that subsequent identical queries will not need to operate the table and directly access the cached results.
The first step is to set query_cache_type to ON, and then query whether the system variable have_query_cache is available: After
show variables like 'have_query_cache'
, allocate memory size to the query cache to control the maximum value of cached query results. Related operations are modified in the configuration file.
5. Use NOT NULL
Many tables contain NULLable (null) columns, even if the application does not need to hold NULLs, because NULLable is the default attribute for columns. It is usually best to specify NOT NULL for columns unless you really need to store NULL values.
If a query contains NULLable columns, it is more difficult for MySQL to optimize because NULLable columns make indexes, index statistics, and value comparisons more complicated. NULLable columns will use more storage space and require special handling in MySQL. When a NULLable column is indexed, each index record requires an extra byte, which in MyISAM can even cause a fixed-size index (eg, an index with only one integer column) to become a variable-size index.
Usually the performance gain from changing a NULLable column to NOT NULL is small, so (when tuning) there is no need to first look in the existing schema and fix it unless it is determined that this will cause problems. However, if you plan to build an index on a column, you should try to avoid columns that are designed to be NULLable. Of course there are exceptions. For example, it is worth mentioning that InnoDB uses a separate bit (bit) to store NULL values, so it has good space efficiency for sparse data. But this does not apply to MyISAM.
6. Selection of storage engine
For how to choose between MyISAM and InnoDB, if you need transaction processing or foreign keys, then InnoDB may be the better way. If you need a full text index, MyISAM is usually a good choice because it's built into the system, however, we don't actually test 2 million rows very often. So, even slower, we can get the full text index from InnoDB by using Sphinx.
The size of the data is an important factor that affects what storage engine you choose. Large-sized data sets tend to choose the InnoDB method because it supports transaction processing and failure recovery. The size of the database determines the length of time for failure recovery. InnoDB can use transaction logs for data recovery, which will be faster. Whereas MyISAM can
take hours or even days to do this, InnoDB only takes a few minutes.
Your habits of manipulating database tables can also be a big factor in performance. For example: COUNT() will be very fast in MyISAM tables, but can be painful under InnoDB tables. The primary key query will be quite fast under InnoDB, but we need to be careful that if our primary key is too long, it will also cause performance problems. Bulk inserts are faster under MyISAM, but updates are faster under InnoDB - especially when there is a lot of concurrency.
So, which one do you use? From experience, if it is some small application or project, then MyISAM may be more suitable. Of course, there are times when MyISAM is used with great success in large environments, but not always. If you are planning to use a very large data volume project and need transaction processing or foreign key support, then you should really go the InnoDB way directly. But keep in mind that InnoDB tables require more memory and storage, and converting 100GB MyISAM tables to InnoDB tables may give you a very bad experience.
7. Avoid using or to connect in where clauses
If a field has an index and a field does not have an index, it will cause the engine to give up using the index and perform a full table scan, such as:
select id from t where num=10 or Name = 'admin'
You can query like this:
select id from t where num = 10
union all
select id from t where Name = 'admin'
Eight, use varchar/nvarchar more
Use varchar/nvarchar instead of char/nchar, because first of all, the storage space of variable-length fields is small, which can save storage space, and secondly, for queries, the search efficiency in a relatively small field is obviously higher.
9. Avoid returning large amounts of data
Consider using limit here to limit the amount of data returned. If you return a large amount of data you do not need each time, it will also slow down the query speed.
Ten, where clause optimization
The use of parameters in the where clause will result in a full table scan, because SQL will only resolve local variables at runtime, but the optimizer cannot defer the choice of an access plan until runtime; it must choose it at compile time. However, if the access plan is built at compile time, the value of the variable is unknown and cannot be used as an input for index selection.
You should try to avoid expression operations on fields in the where clause, and avoid performing function operations on fields in the where clause. This will cause the engine to give up the use of indexes and perform full table scans. Do not perform functions, arithmetic operations, or other expression operations to the left of the "=" in the where clause, or the index may not be used correctly.
Original source: http://www.jb51.net/article/111762.htm