最近做的一个应用，功能要求非常简单，就是key/value形式的存储，简单的

    INSERT/SELECT，没有任何复杂查询，唯一的问题是量非常大，如果目前投入使用，初期的单表insert频率约

    20Hz(次/秒，我喜欢这个单位，让我想起国内交流电是50Hz)，但我估计以后会有500Hz+的峰值。目前的工作成果，额定功率200Hz(CPU占用

    10-20，loadavg=2)，最大功率500Hz(这时loadavg>

    20，很明显，只能暂时挺挺，应该在出现这种负载前提前拆表了);w5O.T.S9T7~-A'^

    7L6X/h7h$_%h+e{

    从数据的插入开始说起。如果可以容忍结果几秒以后再生效的，可以用INSERTDELAYEDINTO，因为在我的这个结构中不需要对同一个key

    频繁的INSERT/SELECT，因为SELECT我是用Memcached挡住了，除非Memcached挂了，或者数据实在老到过期了，才会去

    SELECT。而且要注意，如果PHP不需要关心MySQL操作的返回结果，应该使用unbufferedquery，简单的说，在你提交query

    后，不用等待MySQL有返回信息就继续执行之后的PHP指令，具体用法是用mysql_unbuffered_query代替

    mysql_query，如果用的MySQLi类，应该使用mysqli->query($sQuery,MYSQLI_USE_RESULT);#R,

    A"}.A:i

    如果SHOWPROCESSLIST，可以看到用户名为DELAYED的进程，进程数量等于INSERTDELAYED

    的表的数量，因为表级锁的存在，每个表一条以上的DELAYED进程是没有意义的

    关于这个功能的my.cnf配置有三条，我定为如下值2w'c#L+n:i:j/_

    delayed_insert_limit=1000

    delayed_insert_timeout=300

    delayed_queue_size=5000(?3y8|&l8h/b

    5P;u(d4Y6k!T'k

    连接有人说，如果报错连接数过大，你把max_connections调大就OK，如果只这么说而不讲原因，完全是句废话，你调成1M肯定不会再报

    Toomanyconnections(但应该会报内存溢出之类的)，但如果是这样MySQL又何必给这个参数?

    我看到的一个很有用的公式&P%K0s9x/_#[

    key_buffer_size+(read_buffer_size+sort_buffer_size)*

    max_connections

    /v#f7B;e:X9w0Y

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

    ,N2A3c1u1P|3f8i

    innodb_buffer_pool_size:N'y&M;@:R#X0[-Z

    +key_buffer_size(u*K8G$O-b$P6V0]5t

    +max_connections*(sort_buffer_size+read_buffer_size+

    binlog_cache_size)

    +max_connections*2MB

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

    3o/k0_#c9p/u)R"K5Z#K

    key_buffer_size,K-o6A!d,g*d7i

    F%^'L:V,x1M

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

    key_buffer_size——有的时候可能是不够，还有的时候可能是浪费。9S4H({*A#Ce/}+I,`

    's"F:y:j$o+J%d1G

    其实最关键的指标，还是看SHOWGLOBALSTATUS时的Key_blocks_unused，只要还有剩余，就说明

    key_buffer_size没用满。有人说看Key_reads跟Key_read_requests的比值，至少要达到

    1:100。这可以作为一个结果来衡量，但不够准确，因为在服务器刚启动的时候，大多数请求都要新建缓存，缓存命中比高不起来，需要运行稳定(几小时后)再观察。我个人建议还是看

    Key_blocks_unused(j+k*R&M*_4R'M6V2\

    如果不花很长时间在运行中调试，给出一个简单的计算方法，把数据库填满，达到设计时的最大值，看看这时候索引占了多大空间，然后把所有表的索引大小加起来，就是

    key_buffer_size可能达到的最大值，当然，还要留些余地，乘个2或3之类的。

    )d/n'V-d2~2j+H"i

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

    2N$c+x(\5G!{

    7H1F!w,F.B,^

    OPTIMIZETABLE

    3g)M$Z!C0k-y.}

    优化一下有好处，但会锁住表，是否值得做要权衡一下。拿我现在这个表做例子，有text字段，700万条记录，1.5G

    大小，优化时间约两分钟，优化后性能提升了50%，同时表的大小变为1.4G，但随着表的频繁改写，约一天后又恢复到以前的速度，因此在我看来并不值得。

    !z:F,k#i+|*{)J/N

    QueryCache;g:[]8c8}1f&Y

    3j!t1p/d.v%C2R(u.T!c;?

    因为每有写操作QueryCache都会被清空，除了极特殊的情况(大量读，少量写，但即使这样也应该是多用memcached

    才对)完全没有必要使用这个，把query_cache_size设为0关闭这个功能吧

注：成都晨宇网络科技公司自由网络，专业提供网站推广服务，有需要咨询欢迎联系我们在线客服。