MySQL CPU takes up 100% of the resolution process

MySQL CPU takes up 100% of the resolution process

Server to solve the MySQL CPU 100% of the problem, slightly sorted as follows, I hope to help you.

Friend host (.

MySQL CPU takes up 100% of the resolution process

A careful examination this morning. At present this website 7th average day IP for 2000,pageview is about 30,000. Website a uses the database currently has 39 tables, records number 601,000, occupies the space 45MB. By this data, MySQL cannot occupy such a high resource.

Then run the command on the server, the MySQL current environment variable output to file Output.txt:
d:webmysql> MySQLd.exe--help >output.txt

found that the value of the tmp_table_size is the default 32M, so modify the My.ini and assign the tmp_table_size to 200M:
D:webmysql> Notepad C:windowsmy.ini
[MySQLd]
tmp_table_size=200m

Then restart the MySQL service. CPU consumption has a slight drop, the previous CPU consumption waveform is 100% a line, now 97%~100% between the ups and downs. This indicates that adjusting the tmp_table_size parameters can improve the performance of MySQL. But the problem has not been completely resolved.

So go into the MySQL shell command line, call show Processlist, view the current MySQL use frequent SQL statements:
Mysql> show Processlist;

Call this command repeatedly (brush two times per second) and discover that two SQL statements for site A often appear in the process list with the following syntax:
SELECT t1.pid, T2.userid, T3.count, t1.date
From _mydata as T1
Left JOIN _myuser as T3 on T1.userid=t3.userid
Left JOIN _mydata_body as T2 on T1.pid=t3.pid
ORDER BY T1.pid
LIMIT 0, 15

Call Show columns to check the structure of the three tables:
Mysql> show columns from _myuser;
Mysql> show columns from _mydata;
Mysql> show columns from _mydata_body;

Finally found the problem lies: _mydata table, only based on the PID set up a primary key, but did not establish an index for userid. And in the first left JOIN in clause of this SQL statement:
Left JOIN _myuser as T3 on T1.userid=t3.userid

The userid of _mydata is involved in the conditional comparison operation. So I built an index for the _mydata table based on the field UserID:
mysql> ALTER TABLE ' _mydata ' ADD INDEX (' userid ')

After this index was established, the CPU was immediately reduced to about 80%. Seeing that the problem was found, I checked another SQL statement that repeatedly appeared in show Processlist:
SELECT COUNT (*)
From _mydata as T1, _mydata_key as T2
WHERE t1.pid=t2.pid and t2.keywords = ' peacock '

After checking the structure of the _mydata_key table, found that it only for PID built primary key, did not establish index for keywords. _mydata_key currently has 330,000 records, without the index of 330,000 records for text retrieval matching, do not consume a lot of CPU time to blame. It seems to be a problem with the search for this table. The _mydata_key table is also indexed according to the field keywords:
mysql> ALTER TABLE ' _mydata_key ' ADD INDEX (' keywords ')

After the index is established, the CPU immediately drops down and swings between the 50%~70%.

Call show Prosslist again, and site A's SQL calls rarely appear in the results list. However, it was found that the host ran several Discuz forum programs, and several tables of the Discuz forum also had this problem. So smoothly together to solve, CPU occupancy down again.

So far, the problem is solved.

The experience of solving MySQL CPU occupancy 100%

1. Increase the tmp_table_size value. In MySQL's configuration file, the default size of the Tmp_table_size is 32M. If a temporary table exceeds that size, MySQL produces a full form of the table Tbl_name error, and if you do many advanced GROUP by queries, increase the tmp_table_size value. This is the MySQL official explanation for this option:

Tmp_table_size
This variable determines the maximum size for a temporary table in memory. If the table becomes too large, a MYISAM table is created on disk. Try to avoid temporary tables by optimizing the queries where possible, but where, isn't possible, try to ensure temp Orary tables are always stored in memory. Watching the processlist for queries with temporary tables, take too long to resolve can give your an early tha T tmp_table_size needs to be upped. Be aware this memory is also allocated per-thread. An example where upping this worked as more is a server where I upped this from 32MB (the default) to 64MB with Immediat E effect. The quicker resolution of queries resulted in less threads active at any one time, with being all-round for the s Erver, and available memory.

2. The fields used to determine the conditions in the clause of WHERE, JOIN, MAX (), MIN (), and order by, should be indexed index.

Indexes are used to quickly find rows that use a specific value on a column. Without an index, MySQL had to start with the first record and then read through the entire table until it found the relevant rows. The bigger the table, the more time it takes. If the table has an index to the query's column, MySQL can quickly reach a location to search the middle of the data file, and there is no need to consider all the data. If a table has 1000 rows, this is at least 100 times times faster than sequential reads. All MySQL indexes (PRIMARY, UNIQUE, and index) are stored in the B-tree.

According to MySQL's development documentation:

Indexed index is used to:

O Quickly find a row that matches a WHERE clause.

o retrieves rows from other tables when performing joins (join).

o Find the max () or MIN () value for a particular indexed column.

o If sorting or grouping is performed on the leftmost prefix of an available key (for example: ORDER by key_part_1, key_part_2), sorting or grouping a table. If all key values partially follow DESC, the keys are read in reverse order.

O In some cases, a query can be optimized to retrieve values without consulting the data file. If all the columns used for some tables are numeric and form the leftmost prefix of some keys, the value can be retrieved from the index tree for faster.

Suppose you issue the following SELECT statement:
Mysql> SELECT * from Tbl_name WHERE col1=val1 and Col2=val2;

If a multiple-column index exists on col1 and col2, the appropriate rows can be taken out directly. If separate row-column indexes exist on col1 and col2, the optimizer attempts to determine which index will find fewer rows and find more restrictive indexes and use the index to fetch rows.

When developers do SQL datasheet design, be sure to think about it in a holistic sense.