作为一名被赶鸭子上架的DD-WRT的小白用户，写点东西备忘一下本次处理的问题。仅供自己备忘，建议读者忽略。
问题：
业务上需要访问名为某book的SNS网站，需要通过穿wall路由来实现，也就是要说的这个DD-WRT。
问题很简单，访问不了。
现象：
直接连上去，访问失败。手工在路由的client上改DNS为四个8后，正常。
过程(看起来很小白)：
查看路由的resolv.conf，里面的nameserver是路由本机的ip，改成四个８，重启后被还原。
在启动脚本上强制去替换resolv.conf为四个８的。重启后正确，但依然无法出去。
通过WEB管理界面看到有DNSmasq的附加配置，发现里面指定的某book的解析，怀疑是ip失败或被wall。
清空后重启，依然无法访问。改为通过四个８解析出来的地址做泛解析，重启后正常。
关于覆盖索引，有几个比较常见的误区，简单总结一下。
1、使用覆盖索引的条件
[code]
当检索列、条件中使用的列全在某个索引中（索引中已隐含主键），就会使用覆盖索引。
用explain得到的Extra中包括using index时，就意味着本次查询使用覆盖索引。
[/code]
2、存储引擎中使用索引中字段个数的条件
[code]
容易记的方式：存储引擎只支持对索引连续筛选(in是特例，多个连续)。
标准的理解方式：必须按索引中各字段顺序使用，最多只能使用一个范围条件或左匹配的like。
[/code]
网上这种文章肯定是一大堆，我只列自己碰到的几种情况。
优点：
[code]
1、读写分离，承载能力提高。
2、某些索引，仅需从库上有，主库上可以没有。使主库写起来更快。
3、大报建索引时，可先在从库拿掉建，搞定后再挂上。可避免在主库上长时间锁表的问题。
[/code]
缺点：
[code]
1、主从同步需要时间，一般用户单次请求内先写再读同一条数据，几乎都出不来。需业务层面兼容或改用临时从主库读。
2、从库上有的索引，主库上没有。当需要改回单主结构时，性能有可能会成为严重问题。
3、如果需要双主，或主从角色互换，需要对含有自增字段的表做特殊处理，以防生成同一值冲突。
[/code]
在Android和iOS设备中，通过网页调用起App，比较简单的方式就是使用自定义协议，比如：
[code]
msblog://xxx/xxx
[/code]
Android和iOS的App分别指定msblog这个scheme，然后通过网页直接访问这个地址，就打开相应的应用了。
基础的讲完了，下面说问题。
如题，对InnoDB中的tinyint类型做了有符号和无符号转换的测试，几种情况：
[code]
1、有符号的-128转无符号时，预期是转成128，原因是0x80，实际上变成了0
2、无符号的设置为256时，预期为0，实为255
3、无符号的255转为有符号时，预期结果为-1，实为127。
4、无符号的255转为有符号时，为127，再转为无符号时，还是127不变。
[/code]
初步结论：超出值域时，会自动把值修正为离当前值近的边界值，原值丢弃。通过改回原类型无法找回原来的值。
ssh命令是一把军刀，能干很多事，举几个比较典型的例子。
1、做ssh穿墙的firewall，192.168.1.10是firewall的当前ip，xx.xx.xx.xx是远端用来当跳板的ip
[code]
ssh -fNg -D192.168.1.10:22022 xx.xx.xx.xx
[/code]
2、NAT：把当前server上的22022端口映射到xx.xx.xx.xx的22上。
[code]
ssh -fNg -L 22022:127.0.0.1:22 xx.xx.xx.xx
[/code]
3、Socket5代理：用当前Server上的8080端口当代理，通过xx.xx.xx.xx上网。
[code]
ssh xx.xx.xx.xx -D192.168.1.10:8080 -g -f sleep 30d
[/code]