作者：老王

问题：主从服务器表类型的选择

一般的共识是主服务器使用innodb，从服务器使用myisam，以便各尽其能。

问题：主从服务器字段类型的选择

字段类型对于分页等操作有很大影响。主服务器一般是innodb，因为不涉及查询，所以可以使用varchar等来存储字符串来节省空间，从服务器一般是 myisam，因为涉及查询，所以必须在char和varchar之间仔细权衡，没有varchar, text, blob字段的表是静态表，反之是动态表，静态表的检索效率要比动态表好若干倍，一般来说，所有涉及大结果集的查询都应该尽可能保证在静态表上完成，这里 说一个例子：比如说常见的articles表有title(varchar), body(text)等字段，在做文章列表的时候，因为不是静态表，所以查询不会很快，下面开始重构解决方案：把原来的articles表拆分成 subjects表和contents表，title字段设置为一个足够的char类型放在subjects表里，body字段还保持是text类型放到 contents表里，subjects和contents表之间的关系是一对多，这样，顺带着也方便的实现了多页文章的功能，而且更重要的是在查询文章 列表的时候，操作都是在subjects静态表里完成，效率肯定会比前一种方案提升很多。

问题：主从服务器NOW()函数造成数据不一致

假设在主服务器上执行一条INSERT …. VALUES ( …, NOW())，那么在从服务器上也会同样执行一条的SQL语句，但是一来主从服务器各自的时间设置可能就不一致，二来主从服务器间的SQL同步也可能存在 时间上的的延迟，这样，NOW()在两台服务器上的结果就可能不一致。解决方法是显而易见的，就是不要使用NOW()，时间的计算在应用程序里完成。这里 介绍一个额外的小技巧：在PHP里如果想获得当前时间的时间戳，不要用time()，而应该使用$_SERVER[‘REQUEST_TIME’] （PHP版本大于5.1有效），这样少做了一次系统调用，更有效率。

问题：主从服务器读写分离时读操作失败

先重现一下问题：比如说添加一条新数据，添加成功后根据last_insert_id跳转到新添加数据的浏览页面。在此过程中添加新数据的操作是在主服务 器上完成的，浏览新数据的操作实在从服务器上完成的，不过由于主从服务器间SQL同步存在延迟，所以当使用last_insert_id在从服务器上查询 的时候，从服务器很可能还没有还没来得及同步到此记录，所以读操作失败。解决思路也不复杂，在代码里加入一个缓存层（可以使用memcached），新添 加的数据都顺手放到缓存层里一份，新数据的读操作也先查询缓存层，这样就不会再有读操作失败的问题了，当然删除或者更新数据的时候也要顺带着处理好缓存数 据，可以使用观察者模式来搞定。不过这样缓存方案只限于读取单一的记录，对于读取列表的记录的情况，则是无效的。

问题：主从服务器索引是否有必要保持一致

一般都是利用主从服务器完成读写分离，从服务器上进行读操作，主服务器进行写操作，这样的话，主服务器上仅保留主键，外键，唯一索引等必要的索引即可，以 便保持数据合法性，而对于那些原本用于优化SELECT操作的索引，可以全部删除，如此的话主服务器的写操作效率会提升很多。

转自：http://hi.baidu.com/thinkinginlamp/blog/item/5d72dd5469b1885fd0090633.html

mysql 分组 group by, 排序 取每条记录中，时间最大的一条记录

SELECT A.* FROM test A,
(SELECT aid, MAX(day) max_day FROM test GROUP BY aid) B
WHERE A.aid = B.aid AND A.day = B.max_day
ORDER BY a.install DESC

以下是 test 表，测试sql

CREATE TABLE IF NOT EXISTS `test` (
`id` int(10) unsigned NOT NULL auto_increment,
`install` int(10) unsigned NOT NULL,
`day` int(10) unsigned NOT NULL,
`aid` int(10) unsigned NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=12 ;

INSERT INTO `test` (`id`, `install`, `day`, `aid`) VALUES
(1, 1232, 20080808, 1),
(2, 2321, 20080809, 2),
(3, 1236, 20080810, 3),
(5, 4212, 20080809, 1),
(6, 2312, 20080810, 1),
(7, 1432, 20080811, 1),
(8, 2421, 20080808, 2),
(9, 4245, 20080811, 2),
(10, 5654, 20080810, 2),
(11, 412, 20080808, 3);

可以先看看这里的简介 DBA数据库 （这里没有提到db4，现在应该使用db4）

安装：

打开php.ini 确定 php_dba.dll 已经载入。

之后就可以使用dba函数库了。

这个数据，就是简单的 key=>value模式，和memcache差不多。

写入和查询速度都是非常快的。

如果是本机简单测试，可以使用 inifile 模式。

不过正式服务器上，一定要使用db4模式读写，因为其他模式比较慢，inifile就更慢了，还没有fopen快，所以inifile只能测试。

现在测试一下dba数据库的写入速度

每条数据是1k，写入速度分别是： 
10000条       1.71057009697
100000条      21.7869038582
1000000条    765.130697012

每条数据是2k，写入速度分别是： 
10000条       1.13584280014
100000条      25.066011906
1000000条     704.676019907

每条数据是3k，写入速度分别是： 
10000条       0.865121126175
100000条      24.7635490894
1000000条     745.992260933

每条数据是6k，写入速度分别是： 
10000条       4.17641997337
100000条      102.979793072
1000000条     1891.55883002

 可以看出，如果每条数据不超过3k的情况下，写入速度还是非常快的，而且大致都在一个范围内。（当然，这个速度还和服务器性能有关系）

 这是对测试结果做出的压力测试：

读取1000000数据的bdb库（3.9G左右），每次读取10-100条数据，每条数据的键，分别是1-1000000之间

This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking si.adtest.com (be patient)
Server Software:        Apache/2.2.9
Server Hostname:        si.adtest.com
Server Port:            80

Document Path:          /test_bdb/r.php
Document Length:        37 bytes

Concurrency Level:      700
Time taken for tests:   2.558 seconds
Complete requests:      700
Failed requests:        555
   (Connect: 0, Receive: 0, Length: 555, Exceptions: 0)
Write errors:           0
Total transferred:      193705 bytes
HTML transferred:       26405 bytes
Requests per second:    273.62 [#/sec] (mean)
Time per request:       2558.262 [ms] (mean)
Time per request:       3.655 [ms] (mean, across all concurrent requests)
Transfer rate:          73.94 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   1.4      2       7
Processing:    82  471 118.6    517     559
Waiting:       26  443 118.9    484     544
Total:         82  473 119.2    519     559

Percentage of the requests served within a certain time (ms)
  50%    519
  66%    524
  75%    528
  80%    533
  90%    539
  95%    542
  98%    547
  99%    552
 100%    559 (longest request)

转自：http://blog.s135.com/read.php/362.htm

这么牛X的数据库，为什么没人广泛采用呢？

估计

1、大部分人 不了解这东西；

2、项目管理层的人也许了解，但不敢尝试。

希望能有机会用到这样的好东西。

Tokyo Cabinet 是日本人 平林幹雄 开发的一款 DBM 数据库，该数据库读写非常快，哈希模式写入100万条数据只需0.643秒，读取100万条数据只需0.773秒，是 Berkeley DB 等 DBM 的几倍。

---

Tokyo Tyrant 是由同一作者开发的 Tokyo Cabinet 数据库网络接口。它拥有Memcached兼容协议，也可以通过HTTP协议进行数据交换。

Tokyo Tyrant 加上 Tokyo Cabinet，构成了一款支持高并发的分布式持久存储系统，对任何原有Memcached客户端来讲，可以将Tokyo Tyrant看成是一个Memcached，但是，它的数据是可以持久存储的。这一点，跟新浪的Memcachedb性质一样。

相比Memcachedb而言，Tokyo Tyrant具有以下优势：

1、故障转移：Tokyo Tyrant支持双机互为主辅模式，主辅库均可读写，而Memcachedb目前支持类似MySQL主辅库同步的方式实现读写分离，支持“主服务器可读写、辅助服务器只读”模式。

这里使用 $memcache->addServer 而不是 $memcache->connect 去连接 Tokyo Tyrant 服务器，是因为当 Memcache 客户端使用 addServer 服务器池时，是根据“crc32(key) % current_server_num”哈希算法将 key 哈希到不同的服务器的，PHP、C 和 python 的客户端都是如此的算法。Memcache 客户端的 addserver 具有故障转移机制，当 addserver 了2台 Memcached 服务器，而其中1台宕机了，那么 current_server_num 会由原先的2变成1。

引用 memcached 官方网站和 PHP 手册中的两段话：

引用

http://www.danga.com/memcached/
If a host goes down, the API re-maps that dead host’s requests onto the servers that are available.

http://cn.php.net/manual/zh/function.Memcache-addServer.php
Failover may occur at any stage in any of the methods, as long as other servers are available the request the user won’t notice. Any kind of socket or Memcached server level errors (except out-of-memory) may trigger the failover. Normal client errors such as adding an existing key will not trigger a failover.

---

2、日志文件体积小：Tokyo Tyrant用于主辅同步的日志文件比较小，大约是数据库文件的1.3倍，而Memcachedb的同步日志文件非常大，如果不定期清理，很容易将磁盘写满。

---

3、超大数据量下表现出色：

但是，Tokyo Tyrant 也有缺点：在32位操作系统下，作为 Tokyo Tyrant 后端存储的 Tokyo Cabinet 数据库单个文件不能超过2G，而64位操作系统则不受这一限制。所以，如果使用 Tokyo Tyrant，推荐在64位CPU、操作系统上安装运行。

---

一、安装
1、首先编译安装tokyocabinet数据库

wget http://blog.s135.com/soft/linux/memcached/tokyocabinet-1.3.1.tar.gz
tar zxvf tokyocabinet-1.3.1.tar.gz
cd tokyocabinet-1.3.1/
./configure
make
make install
cd ../

2、然后编译安装tokyotyrant

wget http://blog.s135.com/soft/linux/memcached/tokyotyrant-1.0.0.tar.gz
tar zxvf tokyotyrant-1.0.0.tar.gz
cd tokyotyrant-1.0.0/
./configure
make
make install
cd ../

---

二、配置
1、创建tokyotyrant数据文件存放目录

mkdir -p /ttserver/

2、启动tokyotyrant的主进程（ttserver）
(1)、单机模式

ulimit -SHn 51200
ttserver -host 127.0.0.1 -port 11211 -thnum 8 -dmn -pid /ttserver/ttserver.pid -log /ttserver/ttserver.log -le -ulog /ttserver/ -ulim 128m -sid 1 -rts /ttserver/ttserver.rts /ttserver/database.tch

(2)、双机互为主辅模式
服务器192.168.1.91：

ulimit -SHn 51200
ttserver -host 192.168.1.91 -port 11211 -thnum 8 -dmn -pid /ttserver/ttserver.pid -log /ttserver/ttserver.log -le -ulog /ttserver/ -ulim 128m -sid 91 -mhost 192.168.1.92 -mport 11211 -rts /ttserver/ttserver.rts /ttserver/database.tch

服务器192.168.1.92：

ulimit -SHn 51200
ttserver -host 192.168.1.92 -port 11211 -thnum 8 -dmn -pid /ttserver/ttserver.pid -log /ttserver/ttserver.log -le -ulog /ttserver/ -ulim 128m -sid 92 -mhost 192.168.1.91 -mport 11211 -rts /ttserver/ttserver.rts /ttserver/database.tch

(3)、参数说明
ttserver [-host name] [-port num] [-thnum num] [-tout num] [-dmn] [-pid path] [-log path] [-ld|-le] [-ulog path] [-ulim num] [-uas] [-sid num] [-mhost name] [-mport num] [-rts path] [dbname]

-host name : 指定需要绑定的服务器域名或IP地址。默认绑定这台服务器上的所有IP地址。
-port num : 指定需要绑定的端口号。默认端口号为1978
-thnum num : 指定线程数。默认为8个线程。
-tout num : 指定每个会话的超时时间（单位为秒）。默认永不超时。
-dmn : 以守护进程方式运行。
-pid path : 输出进程ID到指定文件（这里指定文件名）。
-log path : 输出日志信息到指定文件（这里指定文件名）。
-ld : 在日志文件中还记录DEBUG调试信息。
-le : 在日志文件中仅记录错误信息。
-ulog path : 指定同步日志文件存放路径（这里指定目录名）。
-ulim num : 指定每个同步日志文件的大小（例如128m）。
-uas : 使用异步IO记录更新日志（使用此项会减少磁盘IO消耗，但是数据会先放在内存中，不会立即写入磁盘，如果重启服务器或ttserver进程被kill掉，将导致部分数据丢失。一般情况下不建议使用）。
-sid num : 指定服务器ID号（当使用主辅模式时，每台ttserver需要不同的ID号）
-mhost name : 指定主辅同步模式下，主服务器的域名或IP地址。
-mport num : 指定主辅同步模式下，主服务器的端口号。
-rts path : 指定用来存放同步时间戳的文件名。

如果使用的是哈希数据库，可以指定参数“#bnum=xxx”来提高性能。它可以指定bucket存储桶的数量。例如指定“#bnum=1000000”，就可以将最新最热的100万条记录缓存在内存中：

ttserver -host 127.0.0.1 -port 11211 -thnum 8 -dmn -pid /ttserver/ttserver.pid -log /ttserver/ttserver.log -le -ulog /ttserver/ -ulim 128m -sid 1 -rts /ttserver/ttserver.rts /ttserver/database.tch#bnum=1000000

如果大量的客户端访问ttserver，请确保文件描述符够用。许多服务器的默认文件描述符为1024，可以在启动ttserver前使用ulimit命令提高这项值。例如：

ulimit -SHn 51200

3、停止tokyotyrant（ttserver）

ps -ef | grep ttserver

找到ttserver的进程号并kill，例如：

kill -TERM 2159

---

三、调用
1、任何Memcached客户端均可直接调用tokyotyrant。

2、还可以通过HTTP方式调用，下面以Linux的curl命令为例，介绍如何操作tokyotyrant：
(1)、写数据，将数据“value”写入到“key”中：

curl -X PUT http://127.0.0.1:11211/key -d “value”

(2)、读数据，读取“key”中数据：

curl http://127.0.0.1:11211/key

(3)、删数据，删除“key”：

curl -X DELETE http://127.0.0.1:11211/key

mysql服务器的主从配置，本来是一件很简单的事情，无奈不是从零开始，总是在别人已经安装好的mysql服务器之上 ，这就会牵扯到，mysql的版本，启动文件，等一些问题。

不过没关系，先问清楚两点

1、mysql配置文件my.cnf的位置

2、如何启动、停止mysql，找好启动文件

假设有两台机器，已经安装好了mysql（尽量同版本，且两台机器同一网络，可以ping通）

有朋友说：“从服务器，不能低于主服务器的版本”，不过我是低于的，没有出现问题。

主机A: 192.168.1.100

从机B:192.168.1.101

可以有多台从机

1、先登录主机 A

mysql>GRANT REPLICATION SLAVE ON *.* TO ‘backup’@’192.168.1.101‘ IDENTIFIED BY ‘123456’;

赋予从机权限，有多台丛机，就执行多次

2、 打开主机A的my.cnf，输入

server-id               = 1    #主机标示，整数
log_bin                 = /var/log/mysql/mysql-bin.log   #确保此文件可写
read-only       =0  #主机，读写都可以
binlog-do-db    =test   #需要备份数据，多个写多行
binlog-ignore-db=mysql #不需要备份的数据库，多个写多行

3、打开从机B的my.cnf，输入

server-id               = 2
log_bin                 = /var/log/mysql/mysql-bin.log
master-host     =192.168.1.100
master-user     =backup
master-pass     =123456
master-port     =3306
master-connect-retry=60 #如果从服务器发现主服务器断掉，重新连接的时间差(秒)
replicate-do-db =test #只复制某个库
replicate-ignore-db=mysql #不复制某个库

4、同步数据库

有多种方法，我说最笨的一种，先mysqldump导出主机A的数据test为 test.sql

然后在，从机B上建立数据库test，mysql导入 test.sql到test库中

5、先重启主机A的mysql，再重启从机B的mysql

6、验证

在主机A中，mysql>show master status\G;

在从机B中，mysql>show slave status\G;

能看到大致这些内容

File: mysql-bin.000001
Position: 1374
Binlog_Do_DB: test
Binlog_Ignore_DB: mysql

可以在主机A中，做一些INSERT, UPDATE, DELETE 操作，看看主机B中，是否已经被修改
以下是一些其他朋友写的，我也做了参考

http://www.ningoo.net/html/2007/mysql_replication_configuration.html

http://leftleg.hzpub.com/post/645/

http://blog.zhangjianfeng.com/article/705

 由于项目设计里面，牵扯到了金钱的转移，于是就要用到MYSQL的事务处理，来保证一组处理结果的正确性

用了事务，就不可避免的要牺牲一部分速度，来保证数据的正确性。

只有InnoDB支持事务

事务 ACID Atomicity（原子性）、Consistency（稳定性）、Isolation（隔离性）、Durability（可靠性）

1、事务的原子性
一组事务，要么成功；要么撤回。

2、稳定性
有非法数据（外键约束之类），事务撤回。

3、隔离性
事务独立运行。
一个事务处理后的结果，影响了其他事务，那么其他事务会撤回。
事务的100%隔离，需要牺牲速度。

4、可靠性
软、硬件崩溃后，InnoDB数据表驱动会利用日志文件重构修改。
可靠性和高速度不可兼得， innodb_flush_log_at_trx_commit选项 决定什么时候吧事务保存到日志里。
开启事务
 START TRANSACTION 或 BEGIN

提交事务（关闭事务）
 COMMIT

放弃事务（关闭事务）
 ROLLBACK

折返点
 SAVEPOINT adqoo_1
 ROLLBACK TO SAVEPOINT adqoo_1
 发生在折返点 adqoo_1 之前的事务被提交，之后的被忽略

事务的终止

设置“自动提交”模式
 SET AUTOCOMMIT = 0
 每条SQL都是同一个事务的不同命令，之间由 COMMIT 或 ROLLBACK隔开
 掉线后，没有 COMMIT 的事务都被放弃

事务锁定模式

系统默认： 不需要等待某事务结束，可直接查询到结果，但不能再进行修改、删除。
缺点：查询到的结果，可能是已经过期的。
优点：不需要等待某事务结束，可直接查询到结果。

需要用以下模式来设定锁定模式

1、SELECT …… LOCK IN SHARE MODE（共享锁）
查询到的数据，就是数据库在这一时刻的数据（其他已commit事务的结果，已经反应到这里了）
SELECT 必须等待，某个事务结束后才能执行

2、SELECT …… FOR UPDATE（排它锁）
例如 SELECT * FROM tablename WHERE id<200
那么id<200的数据，被查询到的数据，都将不能再进行修改、删除、SELECT …… LOCK IN SHARE MODE操作
一直到此事务结束

共享锁 和 排它锁 的区别：在于是否阻断其他客户发出的 SELECT …… LOCK IN SHARE MODE命令

3、INSERT / UPDATE / DELETE
所有关联数据都会被锁定，加上排它锁

4、防插入锁
例如 SELECT * FROM tablename WHERE id>200
那么id>200的记录无法被插入

5、死锁
自动识别死锁
先进来的进程被执行，后来的进程收到出错消息，并按ROLLBACK方式回滚
innodb_lock_wait_timeout = n 来设置最长等待时间，默认是50秒

事务隔离模式

SET [SESSION|GLOBAL] TRANSACTION ISOLATION LEVEL
READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE
1、不带SESSION、GLOBAL的SET命令
 只对下一个事务有效
2、SET SESSION
 为当前会话设置隔离模式
3、SET GLOBAL
 为以后新建的所有MYSQL连接设置隔离模式（当前连接不包括在内）

隔离模式

   READ UNCOMMITTED
 不隔离SELECT
 其他事务未完成的修改（未COMMIT），其结果也考虑在内

   READ COMMITTED
 把其他事务的 COMMIT 修改考虑在内
 同一个事务中，同一 SELECT 可能返回不同结果

   REPEATABLE READ（默认）
 不把其他事务的修改考虑在内，无论其他事务是否用COMMIT命令提交过
 同一个事务中，同一 SELECT 返回同一结果（前提是本事务，不修改）

   SERIALIZABLE
 和REPEATABLE READ类似，给所有的SELECT都加上了 共享锁

出错处理
 根据出错信息，执行相应的处理

虽然自己不是DBA，但是作为一个程序员，多多少少，应该了解一些数据库方面的东西，并不能只关心程序，不考虑数据库，看到一篇文章，就先转过来，也许以后自己哪天会用到。

查看mysql的某个选项
show variables like ‘%VAR_NAME%’;
select @@VAR_NAME;

    在Linux下管理MySQL数据库的时候总有一些很紧急的情况，发现数据库突然变得压力很大了，那么作为一个DBA，也许需要一些常用的手段或者说命令去分析问题出现在哪里，然后解决：

数据库突然产生压力时查看正在查询的SQL:(如果这里内容太多表示并发执行的SQL过多，或许数据库堵塞了，会越来越慢，正常情况下这里应该很少有东西的，也就是连接都在Sleep状态）
/usr/local/mysql/bin/mysql -uroot -ppassword databaseName  -e “show full processlist” | grep -v Sleep

正在运行的SQL太多了，看不过来，那需要排序了，看持续执行时间最长的那些SQL：
/usr/local/mysql/bin/mysql -uroot -ppassword databaseName  -e “show full processlist” | grep -v Sleep | sort -k6rn >sort.tmp

如果发现IOWait很高，请查看临时表的生成情况，特别是disk tmp table:
/usr/local/mysql/bin/mysql -uroot -ppassword databaseName  -e “show global status like ‘%tmp%’”

通过这样一些办法可以查看数据库都在忙什么，那些忙的SQL又具体在哪一个步骤上卡住了，是在创建磁盘临时文件、Sending Data、statistics？依照不同的原因来解决问题

—————————————————————
关于Mysql Replication日常管理，重做，问题分析时常用的办法：

重做Slave，或者Master变化等等，需要将Slave与新的Master同步：
change master to master_host=IP,master_user=’replication userName’,master
_password=’replication Passwrod’,master_log_file=’log-bin.000001′,master_log_pos=0;

导出数据成SQL文本，慎用，根据你的DB大小会锁表，导致堵塞其他访问：
nohup /usr/local/mysql/bin/mysqldump –database DATABASEName -uUserName -pPassWord –lock-all-tables -F >DATA20070519.sql &
-F后会刷新Master Log这样配合上面的Change Master可以让Slave进行同步

只导出数据库的结构（没有任何内容）
/usr/local/mysql/bin/mysqldump -d DATABASEName -uUserName -pPassWord >DATA20070519.structure

只导出数据库的数据（没有创建表结构的语句等等）
/usr/local/mysql/bin/mysqldump -t DATABASEName -uUserName -pPassWord >DATA20070519.data

同步的时候出现问题（或者其他问题）了，根据同步出现问题的位置（偏移量），查看Binlog的具体内容
/usr/local/mysql/bin/mysqlbinlog binlogFileName –start-position=偏移量
呵呵，我们碰到过Master执行的SQL到了Slave会报语法错误，够诡异吧！不过就是这样查到了原因：如果通过存储过程将bit的内容改为1就会出现这样的问题，后来将bit改为tinyint(1)就好了

授权给某一台Slave拥有复制的权限：
grant replication slave on *.* to 用户名@IP identified by ‘密码’;

查看Slave状态：
Show slave status \G
查看Master状态：
Show master status;
重置Slave（慎用）
reset slave;
Slave出现问题了，先跳过这一条语句（请确认所要跳过的具体内容不会影响后面的同步，确认方法查看Binlog文件）：
set global sql_slave_skip_counter=1; (记得先暂停Slave：stop slave; 然后重启Slave：start slave;)

———————————————–
纯粹Linux相关的：
tcpdump -A “dst port 3306″ 查看3306端口的通信具体内容  

转自：http://mrtips.blog.hexun.com/5904126_d.html

导出整个数据库database
mysqldump –opt -uroot -ppassword database > dump.sql

导出单个数据表table
mysqldump –opt –add-drop-table -uroot -ppassword database table > dump.sql

遇到了一个非常变态的mysql错误，可能和他遇到的一样变态，点击查看。

无论怎么优化都一直出现这样的mysql错误：MySQL server has gone away
我程序中出现的错误原因可能是，mysql连接超时被关闭了，这可以通过修改my.ini，修改wait_timeout的值，来延长等待时间。（此方法未尝试）
我在程序中加入了如下判断，程序可以执行了。

详情查看 »

看到一篇很不错的js方面的文章，转了过来。

转自：http://www.aoao.org.cn/blog/2007/11/memory-cpu/ 

有的网页看起来并不大但打开会很卡，有的网页虽然很长但使用流畅，占用用户电脑的内存与CPU就影响这些。

浏览器问题，有各自的浏览器处理内存问题会影响到，但几乎没办法控制得了，Windows上的：

• IE系列，刷新回收的量不大，但最小化会释放内存，。
• Firefox2据说也会在最小化回收，可我从没见过最垃圾，用多少是多少，基本不回收。据说prototype的ajax还会引起内存一直增加。
• Opera最好。一直控制得很好。不存在什么问题。。

Linux的内存分配机制与Win的不一样，有多少用多少，如果浏览器占光时说不定会干掉系统。

页面问题，浏览器渲染页面会消耗内存和CPU，能减少一点就减少点。

详情查看 »