最近做的一个应用，功能要求非常简单，就是 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 关闭这个功能吧
)
