作为一名被赶鸭子上架的DD-WRT的小白用户,写点东西备忘一下本次处理的问题。仅供自己备忘,建议读者忽略。

问题:
业务上需要访问名为某book的SNS网站,需要通过穿wall路由来实现,也就是要说的这个DD-WRT。
问题很简单,访问不了。

现象:
直接连上去,访问失败。手工在路由的client上改DNS为四个8后,正常。

过程(看起来很小白):
查看路由的resolv.conf,里面的nameserver是路由本机的ip,改成四个8,重启后被还原。
在启动脚本上强制去替换resolv.conf为四个8的。重启后正确,但依然无法出去。
通过WEB管理界面看到有DNSmasq的附加配置,发现里面指定的某book的解析,怀疑是ip失败或被wall。
清空后重启,依然无法访问。改为通过四个8解析出来的地址做泛解析,重启后正常。

- 阅读剩余部分 -

关于覆盖索引,有几个比较常见的误区,简单总结一下。

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]

- 阅读剩余部分 -