mysql消息队列满的时候怎么处理？
① 请求消息处理线程负责端口监听，如果有新连接进入则验证连接合法性，如果成功则加入连接池，连接池只能容纳一定量的连接监听连接池中所有连接是否有消息输入，如果有则读取请求消息处理连接非协议性关闭（如断电）
② 将请求消息写入消息队列这时必须换过消息格式，在原来的消息头中加入进队列的时间戳和所属连接。
③ 通知连接无法处理请求由于消息队列可容纳的消息个数有限，并且消息队列是循环可丢弃型的，只有在消息处理线程组太忙而客户又有大量请求进来时才须要抛弃最旧的消息。在抛弃最旧消息时查一下时间戳，如果未超时则可产生一个‘系统太忙未处理请求’的结果消息加到结果队列去。如果消息队列已满，可以考虑动态增加处理线程的个数，但处理线程组的个数必须是有限的。
数据库导致服务器CPU过高怎么优化？
mysql数据库导致cpu过高一般从执行状态分析：
执行状态分析
Sleep状态
通常代表资源未释放，如果是通过连接池，sleep状态应该恒定在一定数量范围内
实战范例：因前端数据输出时（特别是输出到用户终端）未及时关闭数据库连接，导致因网络连接速度产生大量sleep连接，在网速出现异常时，数据库too many connections挂死。
简单解读，数据查询和执行通常只需要不到0.01秒，而网络输出通常需要1秒左右甚至更长，原本数据连接在0.01秒即可释放，但是因为前端程序未执行close操作，直接输出结果，那么在结果未展现在用户桌面前，该数据库连接一直维持在sleep状态！
Waiting for net, reading from net, writing to net
偶尔出现无妨
如大量出现，迅速检查数据库到前端的网络连接状态和流量
案例:因外挂程序，内网数据库大量读取，内网使用的百兆交换迅速爆满，导致大量连接阻塞在waiting for net，数据库连接过多崩溃
Locked状态
有更新操作锁定
通常使用innodb可以很好的减少locked状态的产生，但是切记，更新操作要正确使用索引，即便是低频次更新操作也不能疏忽。如上影响结果集范例所示。
在myisam的时代，locked是很多高并发应用的噩梦。所以mysql官方也开始倾向于推荐innodb。
Copy to tmp table
索引及现有结构无法涵盖查询条件，才会建立一个临时表来满足查询要求，产生巨大的恐怖的i/o压力。