Mysql operation and maintenance optimization -mysql

Verbatim large column  https://www.dazhuanlan.com/2019/08/17/5d576c62e39a9/

Storage engine type

 • Myisam speed and fast response. Table-level locking is a fatal problem.
 • Innodb mainstream storage engine
   • row-level locking
     • Be sure to pay attention to the impact of what is defined in the result set
     • row-level locking overhead will bring updates, but usually worth it.
   • transaction commits
     • to enhance the efficiency considerations i o /
     • consideration of safety
 • HEAP memory engine
   will continue to exist under lock status and frequent updates • Massive reading situation

Memory usage considerations

 • In theory, more memory, more data in memory read occurs, the higher the efficiency
 • To take into account the realities and bottlenecks in the distribution of hardware resources
 • learn to understand hot data, and as a memory of hot data
   • The so-called hot data, most of the data is being accessed.
   • database access is usually uneven, few data are frequently read and write, but more rarely read and write data.
   • learn to make different rules hot data, and measure indicators.
     • hot data size, theoretically, hot data as possible, growth trends so we can better meet the business.
     • satisfaction response, the response rate to meet the higher the better.
     • For example, according to the last update time, indicators define the total number of visits, repeat visits, and other hot data, and estimated data at different definition of hot-scale model

Performance and security considerations

 • Data submission
   • innodb_flush_log_at_trx_commit = 1 automatically each submission, safe, i / o pressure
   • innodb_flush_log_at_trx_commit = 2 per automatically submitted, safety slight influence, i / o strong bearing.
 • Log Synchronization
   • Sync-binlog = 1 each automatic update, safe, i / o pressure
   • Sync-binlog = 0 automatically updated cache settings, the presence of missing data and synchronization delays risk, high i / o Carrying Capacity .
 • Performance and security inherent in the contrary case, the decision to choose the level of demand in the business
   • learn to distinguish between what the occasion focused performance, focusing on what occasion security
   • Learn the different levels of security policy management database with a different

Pressure storage optimization

 • sequential read and write performance is much higher than random read and write
 • the log data may be read or written using sequential
 • write the write data and the random data sequence into different physical disk, helps ease the i / o pressure, provided you sure you the i / o can pressures from the sequential write (random access interference caused by the order can not be written, but the order may be written does way of i / o operations).

Operation and maintenance monitoring system

 • System Monitoring
   • Server Resource Monitoring
     • Cpu, memory, disk space, i / o Pressure
     • setting a threshold alarm
   • server traffic monitoring
     • external network traffic, the network traffic
     • setting a threshold alarm
   • connection status monitoring
     • Show processlist setting a threshold value, each of minute monitoring, recording exceeds the threshold
 • application monitoring
   • slow query monitoring
     • slow query log
     multiple database servers • If there is, there should be summary review mechanism.
   • Request error monitoring
     • High frequency applications, the ratio change sporadic database connection error or execution error, an error message will be recorded in the log, view daily will appear.
     • sporadic error, if few in number, can not deal with, but often need to monitor trends.
     • there will be malicious input, the input boundary defining deficiency leads to the implementation of mistake, the need to prevent malicious intrusion detection based on this behavior.
   • Micro slow queries monitoring
     • high concurrency environments, more than 0.01 seconds of queries should look at.
   • Frequent monitoring of
     • write operation, based binlog, regular analysis.
     • read operation, the front end of the log increased sampling db package code, and outputs the execution time.
     • Analysis of the frequent request is the basis for further optimization of the development framework
     • The best optimization is to reduce the number of requests!

to sum up:

   • supervisory control and data analysis is the basis of all optimization.
   • There is no monitoring of operational data, do not jump on optimization!
Monitoring should be careful not to generate too much extra load, do not add much overhead due to monitoring

Guess you like

Origin www.cnblogs.com/petewell/p/11417815.html