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只对新开的连接有效，已有连接无效。

后续效果待观察。

业务中存在一些跟每个用户相关的数据，高频读写却对精确度要求不高，但也要确保在一定的范围内。数据一般为两种：时间戳或某个自增产生的序号
最初：直接读写DB，业务稍增长后db负载过高。
现状：改为读写redis，value中增加序列号，满千次写一次DB，redis中未命中时读DB。

具体实现方式：
先get，得到xxx.n，当n大于等于1000时，入库set成yyy.1，否则set成yyy.n+1。一个流程中，两次缓存操作，千分之一次DB操作。

今天改为另一种方式：
直接getset yyy, 得到xxx，取yyy和xxx的差值，找一个合理的阈值，超过阈值时触发存储。

优点：
用户数据高频操作时，完全不会写DB，热度降到某个限制以下时，有限的写几次，即：更扛压。原方案用户数据高频操作时写DB必须是同比增加的。

缺点：
确定阈值时麻烦，需要考量高峰和低谷时的情形，去评估主要用户的冷热程度。

需要注意的地方：校验是否需写DB时用的缓存值是上次存入redis，而不是上次存入DB的。如果是时间数据，阈值设置成8小时，不能认为一天就会写三次，实际上中间有阈值内使用时，就会低于三次，甚至如果用户数据操作闲置时间不会低于8小时，就一直不会触发入DB。

问题描述：
在WEB应用的日志中，发现把HTTP的HEAD信息全当成KV参数处理了。而且这个KV的尾部还真带着个有效的参数，只是分隔符=已经被URLEncode了。

问题后果：
我们的应用中会对所有参数做hash校验，参数不对会认为报文无效，被丢弃。直接影响业务功能。
如果是对参数没校验的应用，结果是丢失HEAD信息后跟的第一个参数，有可能会影响业务功能，除非第一个参数放无用的参数。

解决办法：
识别出现，删除错误的，解析成正确的加进去。让后续逻辑正常。

问题原因：
出现的机率相对较小，大概是十万分之一吧。怀疑是用户提交的报文本身就是错的，也可能是nginx转发的时候错了，再或者是Tomcat解析的时候出错了。
目前看到的KV是以HEAD中charset=utf-8的这个=号作为分隔符的。
机率太小，就没抓报文去确认是谁的问题。有知道答案的，可以回复我~

一个问题的备忘。

测试MySQL版本：5.5.8
测试MySQL存储引擎：InnoDB

初衷：
大表SQL查询按主键正序order by后再limit，速度比较慢，需要优化。

优化过程：
后发现把order by去掉后速度会快非常多，且结果依然正确。

反例被发现：
测试中发现某些特定查询，用到的索引不是主键，默认的顺序是所用到的索引的正序，跟主键的正序不一样。

反例的两个优化推广：
1、如果用到的索引序和主键序完全一样，可以省略order by操作。
2、如果通过主键索引的查询性能优于另一个索引的先排序再limit，可以考虑强制索引：FORCE INDEX (PRIMARY)

欢迎提出推广的反例或其它意见~

一童鞋用java -jar执行时，发现指定的classpath环境变量无效，用-cp也无效。

后经确认，java -jar执行时，classpath会被jar中MANIFEST.MF的classpath取代，同样的原因-cp也无效。
只能用Bootstrap Classloader来调用
[code]
java -Xbootclasspath/a: 1.jar:2.jar: -jar xxx.jar
[/code]

如果想让-cp参数生效，只能用最原始的方式：把jar包classpath下，加Main函数所在的类全称来执行。