MySQL是一个成熟的数据库，也是一个应用非常广泛的数据库。MYSQL数据库在运行的时候，难免会遇到问题。在遇到这些问题的时候应该如何处理，爱可生今天的技术提供MySQL DBA培训，培训内容是MySQL应用占用的CPU怎样情况下考虑优化。

首先，MySQL应用占用的CPU超过10%就应该考虑优化了。

1、如果此服务可以被其他非数据库应用程序替代(例如，许多基于数据库的计数器可以被WEB日志统计完全替代)，最好将其禁用。：

有必要使用数据库吗？虽然数据库可以简化很多应用程序的结构设计，但它也是一个消耗大量系统资源的应用程序。在某些情况下，DBM是比数据库更好的选择。比如很多应用对实时统计没有很高的要求，可以先记录在文件日志中，定期导入数据库进行后续统计分析。如果您仍然需要记录一个简单的二维键值对应结构，您可以使用类似于DBM的HEAP类型的表。由于HEAP表都是在内存中访问的，所以效率很高，但是服务器突然断电时数据可能会丢失，所以非常适合存储在线用户信息、日志等临时数据。即便需要使用数据库，应用程序也完全可以在没有太复杂的数据完整性要求的情况下完全不使用那些支持 MySQL等外键的商业数据库。Oracle这样的大型数据库只在需要完全商业逻辑和事务完整性时才需要。对高负载的应用而言，可以将日志文件、 DBM、 MySQL等轻量级方式作为前端数据采集格式，然后再使用 Oracle MSSQL等DB2Sybase作为数据库仓库，来完成对数据库的复杂挖掘分析工作。

有朋友和我说用标准的MyISAM表代替了InnoDB表以后，数据库性能提高了20倍。

2、数据库服务的主要瓶颈：单个服务的连接数

作为一种应用，如果数据库表结构的设计能够遵循数据库原理的范例，并且已经使用了最新版本的 MySQL，并以一种比较优化的方式运行，那么最终的主要瓶颈通常是单个服务的连接数量，即使一个数据库可以支持500个并发连接，但最好不要在应用中使用此值，因为并发连接数量太多数据库服务本身用于调度的线程的开销也会很大。因此，如果应用程序允许：让一台机器多运行一些 MySQL服务共享。将服务均衡的规划到多个MySQL服务端口上：比如app_1 ==> 3301 app_2 ==> 3302...app_9 ==> 3309。一个1G内存的机器跑上10个MySQL是很正常的。让10个MySQLD承担1000个并发连接效率要比让2个MySQLD承担1000个效率高的多。当然，这样也会带来一些应用编程上的复杂度；

3、使用单独的数据库服务器(不要让数据库和前台WEB服务抢内存)，MySQL如果内存多，可以有效缓存结果集；在前面的启动脚本中，有一个-O key_buffer=32M的参数，用来将默认的8M索引缓存增加到32M。（当然对于）

4、应用尽量使用PCONNECT和polling机制，用于节省MySQL服务建立连接的开销，但也会造成MySQL并发链接数过多（每个HTTPD都会对应一个MySQL线程）；

5、表的水平拆分:让10%最常访问的数据放在一个小表中，90%的历史数据放在一个存档表中(所谓的快慢表)。在数据的中间，通过定期移动和定期删除无效数据来保存。毕竟大部分应用(比如论坛)两个月前访问数据的几率非常小，价值也不是很高。这样，对于应用程序来说，数据选择总是在相对较小的结果级别上进行，这有利于数据缓存。不要指望MySQL在单个表的记录数超过10万的情况下效率更高。而且有时候也没必要把数据搞的那么准。举个例子，如果在一个快表中找到某人发表的60篇文章，快表和慢表的比例是1:20，那么就可以简单的估计这个人发表了1200篇文章。谷歌的搜索结果是一样的:对于几十万个结果，后面的许多数字是通过某些算法估计出来的。

6、数据库字段设计：表的垂直拆分(转换规范化):放入所有固定长度的字段(char、int等)。)和所有可变长度字段(varchar、text、blob等)。)在另一个表中，并且两个表通过主键关联，这样就可以大大优化定长字段表(这样就可以使用HEAP表类型，在内存中可以完全访问数据)，这里也有说明MySQL4中还出现了支持外键和事务的InnoDB类型表、标准MyISAM格式表和基于HASH结构的HEAP内存表。MySQL之所以支持多表类型，其实是为了给不同的应用提供不同的优化方法。

7、仔详细检查应用程序的索引设计:-log-slow-查询[= file]可以添加到服务启动参数中，以跟踪和分析应用程序瓶颈。跟踪服务瓶颈最简单的方法就是检查MySQL服务的运行统计，用MySQL状态显示processlist来检查当前服务中正在运行的SQL。如果某个SQL经常出现在进程列表中，那么就有一个。此时有许多可能的查询。其次，有些字段在没有索引的情况下会影响查询。第三，返回的结果太多。数据库正在排序；所以做一个脚本:比如每2秒运行下面的show processlist将结果输出到一个文件中，查看哪些查询正在消耗CPU。

8、全文检索：若对应的字段不做全文索引，则全文检索将是一个很消耗 CPU的功能，因为全文检索无法使用普通数据库的索引，因此需要进行对应的字段记录遍历。在介绍基于 Java的全文索引引擎 lucene时，可以参考全文索引。

9、前台应用程序的记录缓存:例如，经常使用数据库验证。如果需要更新用户的上次登录时间，最好在记录更新后将用户放入缓存中(设置为2小时后过期)，这样如果用户在2小时内再次登录，可以直接从缓存中进行身份验证，避免过于频繁的数据库操作。

查询优先表应该尽可能多地按句子的位置和顺序向字段添加索引，数据库更新插入优先级的应用程序索引越少越好。

总之：很难优化单个表中记录超过100万的任何数据库。关键是把应用转化成数据库擅长的数据上限。那就是把复杂的需求简化成更成熟的解决方案。