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

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]

- 阅读剩余部分 -

项目中经常会用到数字的唯一标识生成,比较常见的做法是用PostgreSQL的SEQUENCE来生成。
简单说一下步骤:
基础:
PostgreSQL自带的命令行工具是psql,用法是psql -Uuserxxx -Wpasswordxxx dbname
如果未配置到PATH环境变更中,默认可执行文件位置/usr/local/pgsql/bin/psql
退出命令行使用\q

1、创建一个从123456开始名为xxx_id_seq序列
[code]
CREATE SEQUENCE xxx_id_seq START 123456;
[/code]

2、使用方法
[code]
SELECT nextval('xxx_id_seq');
[/code]

3、改当前序列号为从10000001开始
[code]
SELECT setval('xxx_id_seq',10000001);
[/code]

- 阅读剩余部分 -