Today, database operations have increasingly become the performance bottleneck of the entire application, which is especially obvious for Web applications. Regarding database performance, this is not just something that DBAs need to worry about, but it is something we programmers need to pay attention to. When we go to design the database table structure, when operating the database (especially the SQL statement when looking up the table), we all need to pay attention to the performance of the data operation.
Optimize your queries for query caching
Most MySQL servers have query caching enabled. This is one of the most effective ways to improve performance, and it is handled by MySQL's database engine. When many of the same queries are executed multiple times, these query results will be placed in a cache, so that subsequent identical queries can directly access the cached results without operating the table.
The main problem here is that for programmers, this matter is easily overlooked. Because some of our query statements will make MySQL not use the cache. Please see the following example:
the difference between the above two SQL statements is CURDATE(), MySQL's query cache does not work for this function. Therefore, SQL functions like NOW() and RAND() or other such SQL functions will not turn on query caching, because the return of these functions is variable. So, all you need is to replace the MySQL function with a variable to turn on the cache.
EXPLAIN your SELECT query
Use the EXPLAIN keyword to let you know how MySQL handles your SQL statement. This can help you analyze the performance bottleneck of your query or table structure.
EXPLAIN query results will also tell you how your index primary key is used, how your data table is searched and sorted... etc. etc.
Pick a SELECT statement of yours (it is recommended to pick the most complex one with multiple table joins) and add the keyword EXPLAIN to the front. You can use phpmyadmin to do this. Then, you will see a form. In the following example, we forgot to add the group_id index, and there is a table join:
when we add an index to the group_id field:
We can see that the first result shows that 7883 rows were searched, while the latter only searched rows 9 and 16 of the two tables. Looking at the rows column allows us to find potential performance issues.
Use LIMIT 1 1 when only one row of data is required
When you query the table for some time, you already know that there will only be one result, but because you may need to fetch the cursor, or you may check the number of records returned.
In this case, adding LIMIT 1 can increase performance. In the same way, the MySQL database engine will stop searching after finding a piece of data, instead of continuing to find the next piece of data that matches the record.
The following example is just to find out if there are "Chinese" users. Obviously, the latter will be more efficient than the former. (Please note that the first item is Select *, and the second item is Select 1)
Index the search field
Indexes are not necessarily for primary keys or unique fields. If there is a field in your table that you will often use for searching, then please create an index for it.
From the figure above, you can see the search string "last_name LIKE'a%'". One is indexed and the other is not indexed. The performance is about 4 times worse.
In addition, you should also need to know what kinds of searches cannot use normal indexes. For example, when you need to search for a word in a large article, such as: "WHERE post_content LIKE'%apple%'", the index may be meaningless. You may need to use MySQL full-text index or make an index yourself (for example: search keywords or tags)
Use a similar type of example in the Join table and index it
If your application has many JOIN queries, you should make sure that the Join fields in the two tables are indexed. In this way, MySQL will activate the mechanism to optimize the SQL statement of Join for you.
Moreover, these fields used for Join should be of the same type. For example: if you want to join the DECIMAL field and an INT field Join together, MySQL cannot use their indexes. For those STRING types, the same character set is also required. (The character sets of the two tables may be different)
At last
In view of the fact that many people have been interviewing recently, I have also compiled a lot of interview topic materials here, as well as experience from other major companies. Hope it helps everyone. Friends in
need can add group 1149778920 secret code: qf
