返回目录：word文档
私信我或关注微信号：猿来如此呀，回复：学习，获取免费学习资源包。
某网站cpu最近经常飙到100%，并居高不下，今天早上仔细检查了一下。目前此网站的七日平均日 IP 为2000，PV 为 3万左右。网站A 用的 database 目前有39个表，记录数 60.1万条，占空间 45MB。按这个数据，MySQL 不可能占用这么高的资源。
于是在服务器上运行命令，将 mysql 当前的环境变量输出到文件 output.txt：
d:\\web\\mysql> mysqld.exe --help >output.txt
发现 tmp_table_size 的值是默认的 32M，于是修改 My.ini, 将 tmp_table_size 赋值到 200M:
d:\\web\\mysql> notepad c:\\windows\\my.ini
[mysqld]
tmp_table_size=200M
然后重启 MySQL 服务。CPU 占用有轻微下降，以前的CPU 占用波形图是 100% 一根直线，现在则在 97%~100%之间起伏。这表明调整 tmp_table_size 参数对 MYSQL 性能提升有改善作用。但问题还没有完全解决。
于是进入 mysql 的 shell 命令行，调用 show processlist, 查看当前 mysql 使用频繁的 sql 语句：
mysql> show processlist;
反复调用此命令，发现网站 A 的两个 SQL 语句经常在 process list 中出现，其语法如下：
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
调用 show columns 检查这三个表的结构 :
mysql> show columns from _myuser;
mysql> show columns from _mydata;
mysql> show columns from _mydata_body;
终于发现了问题所在：_mydata 表，只根据 pid 建立了一个 primary key，但并没有为 userid 建立索引。而在这个 SQL 语句的第一个 LEFT JOIN ON 子句中：
LEFT JOIN _myuser AS t3 ON t1.userid=t3.userid
_mydata 的 userid 被参与了条件比较运算。于是我为给 _mydata 表根据字段 userid 建立了一个索引：
mysql> ALTER TABLE `_mydata` ADD INDEX ( `userid` )
建立此索引之后，CPU 马上降到了 80% 左右。看到找到了问题所在，于是检查另一个反复出现在 show processlist 中的 sql 语句：
SELECT COUNT(*)
FROM _mydata AS t1, _mydata_key AS t2
WHERE t1.pid=t2.pid and t2.keywords = '孔雀'
经检查 _mydata_key 表的结构，发现它只为 pid 建了了 primary key, 没有为 keywords 建立 index。_mydata_key 目前有 33 万条记录，在没有索引的情况下对33万条记录进行文本检索匹配，不耗费大量的 cpu 时间才怪。看来就是针对这个表的检索出问题了。于是同样为 _mydata_key 表根据字段 keywords 加上索引:
mysql> ALTER TABLE `_mydata_key` ADD INDEX ( `keywords` )
建立此索引之后，CPU立刻降了下来，在 50%~70%之间震荡。
再次调用 show prosslist，网站A 的sql 调用就很少出现在结果列表中了。
增加 tmp_table_size 值。mysql 的配置文件中，tmp_table_size 的默认大小是 32M。如果一张临时表超出该大小，MySQL产生一个 The table tbl_name is full 形式的错误，如果你做很多高级 GROUP BY 查询，增加 tmp_table_size 值。 这是 mysql 官方关于此选项的解释：
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 this is not possible, try to ensure temporary tables are always stored in memory. Watching the processlist for queries with temporary tables that take too long to resolve can give you an early warning that tmp_table_size needs to be upped. Be aware that memory is also allocated per-thread. An example where upping this worked for more was a server where I upped this from 32MB (the default) to 64MB with immediate effect. The quicker resolution of queries resulted in less threads being active at any one time, with all-round benefits for the server, and available memory.
对 WHERE, JOIN, MAX(), MIN(), ORDER BY 等子句中的条件判断中用到的字段,应该根据其建立索引 INDEX。索引被用来快速找出在一个列上用一特定值的行。没有索引，MySQL不得不首先以第一条记录开始并然后读完整个表直到它找出相关的行。表越大，花费时间越多。如果表对于查询的列有一个索引，MySQL能快速到达一个位置去搜寻到数据文件的中间，没有必要考虑所有数据。如果一个表有1000行，这比顺序读取至少快100倍。所有的MySQL索引(PRIMARY、UNIQUE和INDEX)在B树中存储。
根据 mysql 的开发文档:
索引 index 用于：
快速找出匹配一个WHERE子句的行
当执行联结(JOIN)时，从其他表检索行。
对特定的索引列找出MAX()或MIN()值
如果排序或分组在一个可用键的最左面前缀上进行(例如，ORDER BY key_part_1,key_part_2)，排序或分组一个表。如果所有键值部分跟随DESC，键以倒序被读取。
在一些情况中，一个查询能被优化来检索值，不用咨询数据文件。如果对某些表的所有使用的列是数字型的并且构成某些键的最左面前缀，为了更快，值可以从索引树被检索出来。
假定你发出下列SELECT语句：
mysql> SELECT * FROM tbl_name WHERE col1=val1 AND col2=val2;
如果一个多列索引存在于col1和col2上，适当的行可以直接被取出。如果分开的单行列索引存在于col1和col2上，优化器试图通过决定哪个索引将找到更少的行并来找出更具限制性的索引并且使用该索引取行。
开发人员做 SQL 数据表设计的时候，一定要通盘考虑清楚。
总结：
占用CPU过高，可以做如下考虑：
1）一般来讲，排除高并发的因素，还是要找到导致你CPU过高的哪几条在执行的SQL，show processlist语句，查找负荷最重的SQL语句，优化该SQL，比如适当建立某字段的索引；
2）打开慢查询日志，将那些执行时间过长且占用资源过多的SQL拿来进行explain分析，导致CPU过高，多数是GroupBy、OrderBy排序问题所导致，然后慢慢进行优化改进。比如优化insert语句、优化group by语句、优化order by语句、优化join语句等等；
3）考虑定时优化文件及索引；
4）定期分析表，使用optimize table；
5）优化数据库对象；
6）考虑是否是锁问题；
7）调整一些MySQL Server参数，比如key_buffer_size、table_cache、innodb_buffer_pool_size、innodb_log_file_size等等；
8）如果数据量过大，可以考虑使用MySQL集群或者搭建高可用环境。
9）可能由于内存latch（泄露）导致数据库CPU高
10）在多用户高并发的情况下，任何系统都会hold不住的，所以，使用缓存是必须的，使用memcached或者redis缓存都可以；
11）看看tmp_table_size大小是否偏小，如果允许，适当的增大一点；
12）如果max_heap_table_size配置的过小，增大一点；
13）mysql的sql语句睡眠连接超时时间设置问题（wait_timeout）
14）使用show processlist查看mysql连接数，看看是否超过了mysql设置的连接数
关于慢SQL
慢SQL有如下三个特征：
1，数据库CPU负载高。一般是查询语句中有很多计算逻辑，导致数据库cpu负载。
• 系统执行应用提交查询（包括数据修改操作）时需要大量的逻辑读
• 实例的 QPS（每秒执行的查询次数）高
• 查询执行成本（查询访问表数据行数 avg_lgc_io）高
• 可能被SQL注入，及时做好应用防护。
解决方案
• 登录DMS，生成诊断报告，查看诊断报告提供的优化建议进行SQL优化
• 对于由应用负载高导致的 CPU 使用率高的状况，使用 SQL 查询进行优化的余地不大，建议从应用架构、实例规格等方面来解决，例如：
i. 升级实例规格，增加 CPU 资源。
ii. 增加只读实例，将对数据一致性不敏感的查询（比如商品种类查询、列车车次查询）转移到只读实例上，分担主实例压力。
iii. 使用阿里云 DRDS 产品，自动进行分库分表，将查询压力分担到多个 RDS 实例上。
iv. 使用阿里云 Memcache 或者云 Redis 产品，尽量从缓存中获取常用的查询结果，减轻 RDS 实例的压力。
v. 对于查询数据比较静态、查询重复度高、查询结果集小于 1 MB 的应用，考虑开启查询缓存（Query Cache）。
vi. 定期归档历史数据、采用分库分表或者分区的方式减小查询访问的数据量。
vii. 尽量优化查询，减少查询的执行成本（逻辑 IO，执行需要访问的表数据行数），提高应用可扩展性。
• 针对avg_lgc_io的情况解决办法是定位效率低的查询、优化查询的执行效率、降低查询执行的成本
2，IO负载高导致服务器卡住。这个一般和全表查询没索引有关系。
3，查询语句正常，索引正常但是还是慢。如果表面上索引正常，但是查询慢，需要看看是否索引没有生效。
来源网络，侵权联系删除
私信我或关注微信号：猿来如此呀，回复：学习，获取免费学习资源包。