MySQL Load high reason analysis

Some processes/services consume more CPU resources (the service responds to more requests or there are some application bottlenecks);
A more severe swap occurs (insufficient physical memory available);
A more severe outage occurred (due to an outage in the SSD or network);
Disk I/O is slow (causes the CPU to wait for disk I/O requests);

Absolutely not due to the small amount of table data, SQL statements can be written casually, any join will not be a performance bottleneck, must not have this
Kind of thinking.
Try to avoid join table join table Cartesian product
If you want the join table to write the Where condition, it is best to add a limit for security.
A request to read and write data is too large, resulting in large disk I/O read and write values, such as a SQL to read or update tens of thousands of > rows of data or even more, this is the best way to reduce the amount of data read and write;

There are no appropriate indexes in the SQL query that can be used to complete conditional filtering, sorting (order by), grouping (group by)
, Data aggregation (MIN/MAX/COUNT/AVG, etc.), add indexes or make SQL rewrite;
Sudden burst has a large number of requests, this general as long as the peak can be carried over the good, insurance or to properly improve the server > configuration, in case the peak resistance is not over the possibility of avalanche effect;
Because of the increased load caused by certain scheduled tasks, such as data analysis and backup, this is the CPU, memory, disk
I/O consumption is very large, preferably placed on a separate slave server execution;
The server's own energy-saving strategy finds that the CPU is lowered when the load is low, and then automatically rises when the load is increased, but
Often not so timely, resulting in a lack of CPU performance, anti-sudden requests;
When using a RAID card, usually equipped with a BBU (backup battery of the cache module), the early general use of lithium battery technology,> need to periodically charge and discharge (Dell Server 90 days, IBM is 30 days), we can monitor the next charge and discharge
Time before the business trough in advance to discharge it, but the new generation of servers mostly use capacitive batteries, > does not exist this problem.
File systems using EXT4 or even ext3, rather than XFS, are likely to cause%util to reach 100% when high I/O pressure, but ioPS can no longer be improved, with XFS generally gaining a significant boost;
The kernel's IO scheduler strategy uses CFQ rather than deadline or noop, can be directly adjusted online, and can also be significantly
Improve.

MySQL Load high reason analysis