转自贝贝的blog，略有补充，贝贝的原贴地址：http://www.thinkingquest.net/articles/449.html

有两个补充之处：
1、GATEWAY配置
Centos的GATEWAY配置不仅在ifcfg-eth0中，也可能在/etc/sysconfig/network中。ifcfg-eth0中对单个网卡有效，network配置的是全局，作用范围不同。
原理都是改GATEWAY。

2、转发配置：
修改/proc/sys/net/ipv4/ip_forward是临时性的，是内核的当前运行状态，永久的改动位于：
/etc/sysctl.conf的
[code]
net.ipv4.ip_forward = 1
[/code]
改完后执行以下命令生效
[code]
#sysctl -p
[/code]
生效后，/proc/sys/net/ipv4/ip_forward会自动变为/etc/sysctl.conf中net.ipv4.ip_forward的值。

下面附上贝贝的原文（我这访问只能绑host访问贝贝的blog，原文转过来更方便）。
－－－－－－－－我是分隔线，以下是引用的全文－－－－－－－－－－

几个vps（虚拟主机），只有一个拥有公网ip地址，所有的vps都拥有内网ip地址。其它的vps需要通过拥有公网ip的这个vps进行公网访问，以方便yum安装软件等需求。

在没有公网ip的vps上需要进行的设置：

/etc/sysconfig/network-scripts/ifcfg-eth0 文件中： GATEWAY=10.x.x.x

service network restart

到此完成。

接下来是拥有公网ip的那台vps上进行设置：

echo "1" > /proc/sys/net/ipv4/ip_forward

注意，这条命令是临时开启系统的转发功能，系统重启后会恢复为默认设置。 可以通过在/etc/rc.d/rc.local中加入上述命令，使之在系统启动时被执行。

打开iptables的nat功能：

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

到此设置完成。

其它vps应该可以访问公网了。

缘起：线上发现一条慢查询日志，耗时32秒，对用户来说此次访问直接失败。

原因：用户长期未上线，拉群离线消息时扫描了几千万行数据。

现状：主键为消息唯一编号msgId，用户拉消息时，使用msgId > xxxx来拉，正常用户间隔较近，基本上耗时为毫秒。间隔越大，时间越长。

修改：当前msgId差值小于200w时，用主键索引。超出时，强制使用群编号groupId索引。msgId差值200w时用主键索引耗时为5秒左右。差值4000w时强制使用groupId索引，耗时600毫秒左右。

结论：用默认方案hold绝大多数的case，当特例出现时，强制使用另一个索引，确保用户可用。

tcpdump是抓包工具，strings是输出可见字符工具，组合应用会有比较漂亮的用法。

1、用来监控当前服务器上对MySQL的访问。
[code]
tcpdump -i eth0 -s 0 -l -w - dst port 3306 | strings
[/code]

2、用户监控当前服务器上对Redis的访问。
[code]
tcpdump -i eth0 -s 0 -l -w - dst port 6379 | strings
[/code]

只要是有明文传输的地方，都可以这么用。

查看当前MySQL的查访缓存方面的参数：
[code]
show variables like '%query_cache%';
[/code]
得到结果如下，说明查询缓存是开启的：
[code]
mysql> show variables like '%query_cache%';
+------------------------------+-----------+
| Variable_name | Value |
+------------------------------+-----------+
| have_query_cache | YES |
| query_cache_limit | 1048576 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 134217728 |
| query_cache_type | ON |
| query_cache_wlock_invalidate | OFF |
+------------------------------+-----------+
6 rows in set (0.00 sec)
[/code]

再查看查询缓存相关的统计状态
[code]
mysql> show status like '%Qcache%';
+-------------------------+-----------+
| Variable_name | Value |
+-------------------------+-----------+
| Qcache_free_blocks | 11 |
| Qcache_free_memory | 133522200 |
| Qcache_hits | 17197 |
| Qcache_inserts | 3954 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 34251 |
| Qcache_queries_in_cache | 271 |
| Qcache_total_blocks | 575 |
+-------------------------+-----------+
8 rows in set (0.00 sec)
[/code]
一般认为Qcache_hits至少是Qcache_inserts的三倍才可能有效果，最好能达到10倍。这个是四倍多，不太好确定查询缓存是否有效果。

从业务形态上，相同查询出现的几率比较低，更多的是写入和更新操作。还是决定禁用之。
[code]
SET GLOBAL query_cache_size = 0;
[/code]
这个最彻底，可以实时生效。因为query_cache_type只对新开的连接有效，已有连接无效。

后续效果待观察。