MySQL为什么会有一大堆在Sleep的进程？

以前我一直认为，当php的页面执行结束时，会自动释放掉一切。相信很多人都跟我想的一样。但事实证明并不是这样。比如session就不会随着页面执行完毕而释放。php的垃圾回收机制，其实只针对于php本身。对于mysql，php没权利去自动去释放它的东西。如果你在页面执行完毕前不调用mysql_close()，那么mysql那边是不会关闭这个连接的。如果你是用的是pconnect方式，即使你在页面执行完毕前调用mysql_close()，也无法另mysql关闭这个连接。也许在负载低的情况下，你感受不到有何不妥。下面我就来解释这两天我观察出的现象:在php中使用pconnect方式建立连接，然后到mysql客户端下执行show processlist；如果你的负载到一定程度的话，你可以看到很多sleep的进程，这些进程就是人们常说的死连接，它们会一直保持sleep，直到my.cnf里面设置的wait_timeout这个参数值的时间到了，mysql才会自己杀死它。在杀死它的时候，mysql还会在error-log里面记录一条Aborted connection xxx to db: 'xxx' user: 'xxx' host: 'xxx'的日志，用google翻译一下，会得到一个相当强悍的解释"胎死腹中的连接"!那么造成sleep的原因，有三个，下面是mysql手册给出的解释:1.客户端程序在退出之前没有调用mysql_close().2.客户端sleep的时间在wait_timeout或interactive_timeout规定的秒内没有发出任何请求到服务器.3.客户端程序在结束之前向服务器发送了请求还没得到返回结果就结束掉了.上面是我根据google的翻译改了下，可能有某些地方翻译的不准确。原文请见下面:1 The client program did not call mysql_close() before exiting.2 The client had been sleeping more than wait_timeout or interactive_timeout seconds without issuing any requests to the server.3 The client program ended abruptly in the middle of a data transfer如果你的sleep进程数在同一时间内过多，再加上其他状态的连接，总数超过了max_connection的值，那mysql除了root用户外，就无法再继续处理任何请求无法与任何请求建立连接或者直接down了。所以，这个问题在大负载的情况下还是相当严重的。如果发现你的mysql有很多死连接存在，首先要先检查你的程序是否使用的是pconnect的方式，其次，检查在页面执行完毕前是否及时调用了mysql_close()，还有一个办法，你可以在my.cnf里面加上wait_timeout和interactive_timeout，把他们的值设的小一些，默认情况下wait_timeout的值是8小时的时间，你可以改成1个小时，或半个小时。这样mysql会更快的杀死死连接。防止连接总数超过max_connection的值。或者把max_connection的值设置的更大，不过这样显然不妥，连接的数量越多，对你服务器的压力越大。实际上那些连接都是冗余的，把它们尽快杀死才是上策。以前总是说，在使用php连接mysql的时候，尽量不要使用pconnect的方式，看完我上面所说的那些，应该可以明白为什么了吧，因为我们使用php大多数情况下都是做web开发，web开发是面向多用户，那么用户的数量与mysql连接数是成正比的。使用pconnect的方式，即使你的调用mysql_close()也是无法释放数据库连接的，那么mysql中的死连接的数量就会越来越多了。我认为，只有当你的应用属于那种点对点方式，或者你能保证连接数量很少的情况，才有必要去采用pconnect的方式，因为连接数量少，那么让它一直处于连接状态，避免了重复打开关闭的过程。这样可能会比传统方式更好一些。至于何时该去调用mysql_close()，最正确的做法是如果下面不再执行mysql的 *** 作了，在你上一次执行完mysql *** 作后，立刻就调用mysql_close()。这才是最正确的做法，并不是总要把mysql_close()写在页面最后一行就可以了。

首先要明白县城和进程的区别和关系

一个进程至少拥有一个线程，一个线程只属于一个进程。

进程是拥有资源和调度的基本单位，线程是调度的基本单位。

进程独立拥有内存，线程共享所属进程的内存。

ORACLE在windows上也是多线程。

传统的unix系统，早期没有提供多线程，只有多进程。linux是最近的版本才加入多线程支持，以前一直都是多进程。windows很早就支持多线程，本地应用大部分也是多线程。因此oracle在windows上一直都是多线程，在unix上才是多进程。多进程的好处是，一个进程崩溃不会影响其他进程，多线程的好处是不需要共享内存这样的手段来访问数据库缓冲区。mysql很可能是从windows发站起来的，pg和oracle都是最早从unix发站起来的，因此前者是多线程，后两者是多进程。

最根本的原因就如方圆说的，主要是当年 *** 作系统对线程支持不给力，而MySQL是特例，因为开发者喜欢挑战(不过事实上，那个时候的线程支持已经基本完善了。MySQL后于Oracle和POSTGRES)

希望能帮到您！

一台服务器解决了 Mysql cpu 占用 100% 的问题。稍整理了一下，将经验记录在这篇文章里。

朋友主机(Windows 2003 + IIS + PHP + MYSQL )近来 MySQL 服务进程 (mysqld-nt.exe) CPU 占用率总为 100% 高居不下。此主机有10个左右的 database, 分别给十个网站调用。据朋友测试，导致 mysqld-nt.exe cpu 占用奇高的是网站A，一旦在 IIS 中将此网站停止服务，CPU 占用就降下来了。一启用，则马上上升。

MYSQL CPU 占用 100% 的解决过程

今天早上仔细检查了一下。目前此网站的七日平均日 IP 为2000，PageView 为 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.dateFROM _mydata AS t1

LEFT JOIN _myuser AS t3 ON t1.userid=t3.useridLEFT JOIN _mydata_body AS t2 ON t1.pid=t3.pidORDER 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 调用就很少出现在结果列表中了。但发现此主机运行了几个 Discuz 的论坛程序， Discuz 论坛的好几个表也存在着这个问题。于是顺手一并解决，cpu占用再次降下来了。(2007.07.09 附注：关于 discuz 论坛的具体优化过程，我后来另写了一篇文章，详见：千万级记录的 Discuz! 论坛导致 MySQL CPU 100% 的 优化笔记 http://www.xiaohui.com/dev/server/20070701-discuz-mysql-cpu-100-optimize.htm)解决 MYSQL CPU 占用 100% 的经验总结

增加 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 数据表设计的时候，一定要通盘考虑清楚。

---