MySQL MyISAM / PHP 高并发优化经验

最近做的一个应用，功能要求非常简单，就是 key/value 形式的存储，简单的 INSERT/SELECT，没有任何复杂查询，唯一的问题是量非常大，如果目前投入使用，初期的单表 insert 频率约 20Hz（次/秒，我喜欢这个单位，让我想起国内交流电是 50Hz），但我估计以后会有 500Hz+ 的峰值。目前的工作成果，额定功率 200Hz（CPU 占用 10 - 20，load avg = 2），最大功率 500Hz（这时 load avg > 20，很明显，只能暂时挺挺，应该在出现这种负载前提前拆表了）

INSERT DELAYED INTO

从数据的插入开始说起。如果可以容忍结果几秒以后再生效的，可以用 INSERT DELAYED INTO，因为在我的这个结构中不需要对同一个 key 频繁的 INSERT/SELECT，因为 SELECT 我是用 Memcached 挡住了，除非 Memcached 挂了，或者数据实在老到过期了，才会去 SELECT。而且要注意，如果 PHP 不需要关心 MySQL 操作的返回结果，应该使用 unbuffered query，简单的说，在你提交 query 后，不用等待 MySQL 有返回信息就继续执行之后的 PHP 指令，具体用法是用 mysql_unbuffered_query 代替 mysql_query，如果用的 MySQLi 类，应该使用 mysqli->query($sQuery, MYSQLI_USE_RESULT);

如果 SHOW PROCESSLIST，可以看到用户名为 DELAYED 的进程，进程数量等于 INSERT DELAYED 的表的数量，因为表级锁的存在，每个表一条以上的 DELAYED 进程是没有意义的

关于这个功能的 my.cnf 配置有三条，我定为如下值

delayed_insert_limit = 1000
delayed_insert_timeout = 300
delayed_queue_size = 5000

连接

有人说，如果报错连接数过大，你把 max_connections 调大就 OK，如果只这么说而不讲原因，完全是句废话，你调成 1M 肯定不会再报 Too many connections（但应该会报内存溢出之类的），但如果是这样 MySQL 又何必给这个参数？

我看到的一个很有用的公式

key_buffer_size + (read_buffer_size + sort_buffer_size) * max_connections

以 前只有很模糊的概念，应该设的很大，但又不能太大，具体多大合适，知道这个就明确了。innoDB 的公式比这个复杂点，一并给 出

innodb_buffer_pool_size
+ key_buffer_size
+ max_connections * ( sort_buffer_size + read_buffer_size + binlog_cache_size )
+ max_connections * 2MB

还有一个看起 来很有用的参数 back_log ， 给我一种连接池的感觉，而且它确实在起作用，我不知道如果设大了会占用多少内存，但估计不会很多。

key_buffer_size

很多文章都告诉你越大越好，要为此 分配一半左右的物理内存，这么干通常不会出问题，但肯定不是最优的，甚至可以说很无理头——分多少内存应该是根据需求决定，而不是不管什么机器，都砍掉一 半内存用作 key_buffer_size ——有的时候可能是不够，还有的时候可能是浪费。

其实最关键的指标，还是看 SHOW GLOBAL STATUS 时的 Key_blocks_unused，只要还有剩余，就说明 key_buffer_size 没用满。有人说看 Key_reads 跟 Key_read_requests 的比值，至少要达到 1:100。这可以作为一个结果来衡量，但不够准确，因为在服务器刚启动的时候，大多数请求都要新建缓存，缓存命中比高不起来，需要运行稳定（几小时后） 再观察。我个人建议还是看 Key_blocks_unused

如果不花很长时间在运行中调试，给出一个简单的计算方法，把数据库填满，达 到设计时的最大值，看看这时候索引占了多大空间，然后把所有表的索引大小加起来，就是 key_buffer_size 可能达到的最大值，当然，还要留些余地，乘个 2 或 3 之类的。

这是我做测试的时候的 phpMyAdmin 截图，可以看到 key_buffer_size 被浪费了太多

OPTIMIZE TABLE

优化一下有好处，但会锁住表，是否值 得做要权衡一下。拿我现在这个表做例子，有 text 字段，700万条记录，1.5G 大小，优化时间约两分钟，优化后性能提升了 50%，同时表的大小变为 1.4G，但随着表的频繁改写，约一天后又恢复到以前的速度，因此在我看来并不值得。

Query Cache

因为每有写操作 Query Cache 都会被清空，除了极特殊的情况（大量读，少量写，但即使这样也应该是多用 memcached 才对）完全没有必要使用这个，把 query_cache_size 设为 0 关闭这个功能吧