It is not uncommon to snap up diamonds, but the strange thing is that there is no money to make. The incident happened on May 20, 2015, and the good day is naturally indispensable for the participation of merchants. You can restore the scene for you, and dedicate the solution to everyone. Please enjoy Show Time, everyone~
1. Reasons for optimization and preparation for work
At 3:40 p.m. on May 20, 2014, I received a call from the leader of "Wang Dachui" who did not want to disclose his name. The other party hurriedly provided only one piece of information about the slow website access. At that time, the blogger had ten thousand XX in his heart. , As the saying goes, wine and meat pass through the intestines, and taking people's money will eliminate disasters for them.
For bloggers, website access is slow. First of all, they should not be in a mess. The first thing that comes to mind is to look at the web and static. If the static is ok, look at the dynamic. If it is not ok, look at the storage. . At this point, the cause can be located. There will be no other reason. If you are too naive, then you can recite my ideas. I believe it will be a good help for you. At this time, it is more likely to get more information while communicating with the other party, but the other party does not understand at all, so there is nothing you can do. Immediately log in to the server after negotiating the relevant responsibility system with the other party (I am a part-time technical consultant of XX Diamond World Group).
Based on personal experience, the web load is not high, and the static access speed is normal. Since online activities are ongoing, one minute later is a loss to the merchant. At this time, many system investigations cannot be carried out, and it is directly judged whether it is a problem with the back-end DB. ? Check the load with the login DB. When it is found that the DB load is abnormal, no other judgments are made (look at the IO, look at the memory, look at the network card, and look at the company's bankruptcy.), the emergency recovery problem is to maximize the recovery problem, find the problem where to solve the problem immediately. At this point, it is judged that the database has a slow query.
1 ================= 2015-05-20 13:38:08 The load is as follows: ================ 2 [lcp@ZCdb01 ~]$ uptime 3 13:50:36 up 122 days, 21:51, 1 user, load average: 6.44, 5.76, 5.38 4 5 [lcp@ZCdb01 ~]$ uptime 6 13:51:38 up 122 days, 21:22, 1 user, load average: 8.01, 6.30, 5.58
2. Determine where the problem lies
Show full processlist with the login database; this tool is a must for operation and maintenance personnel, not to mention you will not be able to do it for several years of operation and maintenance. If not, you should be able to read my blog.
After catching it twice, I found that this bunch of things didn't move, and the updates in the front row were locked, and I couldn't write it if I wanted to. There are too many selects, and you can't read them.
1 mysql> show processlist; 2 +----+-------------+-----------+------+---------+------+-----------------------------------------------------------------------------+------------------+
3. Locate the statement to be optimized
Come back and see that the following query statement is queried through three conditions. So the statement to be optimized is located, that is, the statement with the most occurrences of select below
↑↑↑Query statement as above↑↑↑
Then I grabbed a command explain, added SQL_NO_CACHE after multiple confirmations to prevent it from going to the cache, and then confirmed it again and again. Finally, it was judged that the statement did not create an index or go to the index. It took a surprising amount of time to look up more than 73,000 pieces of data.
1 mysql> select SQL_NO_CACHE id from **_**_detail where ader='**_**-jazz_flash' and dateline='**_**' and pos='**_**';
At this time, the index and index that may be seen do not exist. Running independently in more than 70,000 sentences
1 possible_keys：NULL 2 3 key：NULL 4 5 rows: 71328 #close to full scan
I remember that this machine is a very old Dell server 2850, but this is obviously not a hardware problem. I asked the supervisor of the other party if anyone has optimized this machine, and checked it while calling to confirm myself. The idea is to use show to view the table structure show create table **_**_detai\G, as expected, except for the primary key index, no index has been established (proud of this old and disrepaired server, it has been granted for so long Brother bye).