1. 对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
2. 应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num is null

可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：

select id from t where num=0

3. 应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。
4. 应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num=10 or num=20

　可以这样查询：

select id from t where num=10

union all

select id from t where num=20

5. in 和 not in 也要慎用，否则会导致全表扫描，如：

select id from t where num in(1,2,3)

对于连续的数值，能用 between 就不要用 in 了：

select id from t where num between 1 and 3

6. 下面的查询也将导致全表扫描：

select id from t where name like '%abc%'

若要提高效率，可以考虑全文检索。

• 简单哈希算法

哈希(Hash)就是把任意长度的输入通过散列算法,变换成固定长度的输出,该输出就是散列值。这种转换是一种压缩映射,使得散列值的空间通常远小于输入的空间,不同的输入可能会散列成相同的输出,而不可能从散列值来唯一的确定输入值。哈希算法是一种消息摘要算法,虽然哈希算法不是一种加密算法,但由于其单向运算,具有一定的不可逆性使其成为加密算法中的一个重要构成部分。

• 分布式缓存问题

哈希算法除了在数据加密中的运用外,也可以用在常见的数据分布式技术中。哈希计算是通过求模运算来计算哈希值的,然后根据哈希值将数据映射到存储空间中。设有由 N 个存储节点组成的存储空间,采用简单哈希计算将一个数据对象 object 映射到存储空间上的

公式为:Hash(object)% N。现在假设有一个网站,最近发现随着流量增加,服务器压力越来越大,之前直接读写数据库的方式已经不能满足用户的访问,于是想引入 Memcached 作为缓存机制。现在一共有三台机器可以作为 Memcached 服务器,如下图 1 所示。

既然Varnish需要在多台服务器上缓存数据，就需要Varnish映射所有的URL到一台单独的主机。

backend webserver {  
    .host = "127.0.0.1";  
    .port = "80";  
    .connect_timeout = 4s;  
    .first_byte_timeout = 5s;  
    .between_bytes_timeout = 20s;  
}  

该块配置用于定义一台Varnish默认访问的后端服务器，当Varnish需要从后端服务器获取数据时，就会访问自己的80端口。

当然Varnish也可以定义多台后端服务器实现负载均衡的目的。

.connect_timeout定义的是等待连接后端的时间

.first_byte_timeout定义的是等待从backend传输过来的第一个字节的时间

.between_bytes_timeout 定义的是两个字节的间隔时间

当然还可以增加一个backend，用于访问本机的8090端口，假设通过该端口提供图片服务。

backend img {  
    .host = "127.0.0.1";  
    .port = "8090";  
}  

当匹配img的URL时，需把请求发送到上面定义的backend img，其他的请求发送到backend webserver。

sub vcl_recv {  
    if (req.url ～ "^/img/") {  
        set req.backend = img;  
    } else {  
        set req.backend = webserver.  
    }  
}  

Varnish不仅仅可以定义多个backend，还可以把多个backend合成一个组，使用循环的方式把请求分配给组中的backends。并且Varnish会根据健康检查情况来判断后端服务器是否正常提供服务。

简介：

Varnish是一款高性能且开源的反向代理服务器和HTTP 加速器

特点：

（1）是基于内存缓存，重启后数据将消失。

（2）利用虚拟内存方式，io性能好。

（3）支持设置0~60秒内的精确缓存时间。

（4）VCL配置管理比较灵活。

（5）32位机器上缓存文件大小为最大2G。

（6）具有强大的管理功能，例如top，stat，admin，list等。

（7）状态机设计巧妙，结构清晰。

（8）利用二叉堆管理缓存文件，达到积极删除目的

环境设置：

测试环境：用VMWare安装的CentOS5.6,Windows2003,克隆的CentOS5.6命名为CentOS5.6.1

CentOS5.6 有两块网卡vmnet0(IP:192.168.2.10)用于与公网用户通信，vmnet1(IP:8.8.8.10)用于模拟内网

CentOS5.6.1 一块网卡vmnet0(IP:192.168.2.11)由于模拟内网提供服务web服务的服务器，我用的是Apache

Windows2003 一块网卡vmnet1(IP:8.8.8.11)用于模拟公网web用户。

配置CentOS5.6 

ifconfig eth0 192.168.2.10 netmask 255.255.255.0
ifconfig eth1 8.8.8.10 netmask 255.255.255.0

配置CentOS5.6.1

ifconfig eth0 192.168.2.11 netmask 255.255.255.0

配置window2003

IP地址：8.8.8.11 子网掩码255.255.255.0

语法规则： location [=|~|~*|^~] /uri/ { … }

= 开头表示精确匹配

^~ 开头表示uri以某个常规字符串开头，理解为匹配 url路径即可。nginx不对url做编码，因此请求为/static/20%/aa，可以被规则^~ /static/ /aa匹配到（注意是空格）。
~ 开头表示区分大小写的正则匹配
~*  开头表示不区分大小写的正则匹配
!~和!~*分别为区分大小写不匹配及不区分大小写不匹配 的正则
/ 通用匹配，任何请求都会匹配到。
多个location配置的情况下匹配顺序为（参考资料而来，还未实际验证，试试就知道了，不必拘泥，仅供参考）:
首先匹配 =，其次匹配^~, 其次是按文件中顺序的正则匹配，最后是交给 / 通用匹配。当有匹配成功时候，停止匹配，按当前匹配规则处理请求。
 

例子，有如下匹配规则：
 

location = / {
  #规则A
}
location = /login {
  #规则B
}
location ^~ /static/ {
  #规则C
}
location ~ \.(gif|jpg|png|js|css)$ {
  #规则D
}
location ~* \.png$ {
  #规则E
}
location !~ \.xhtml$ {
  #规则F
}
location !~* \.xhtml$ {
  #规则G
}
location / {
  #规则H
}

那么产生的效果如下：
访问根目录/， 比如http://localhost/ 将匹配规则A
访问 http://localhost/login 将匹配规则B，http://localhost/register 则匹配规则H
访问 http://localhost/static/a.html 将匹配规则C
访问 http://localhost/a.gif, http://localhost/b.jpg 将匹配规则D和规则E，但是规则D顺序优先，规则E不起作用，而http://localhost/static/c.png 则优先匹配到规则C
访问 http://localhost/a.PNG 则匹配规则E，而不会匹配规则D，因为规则E不区分大小写。
访问 http://localhost/a.xhtml 不会匹配规则F和规则G，http://localhost/a.XHTML不会匹配规则G，因为不区分大小写。规则F，规则G属于排除法，符合匹配规则但是不会匹配到，所以想想看实际应用中哪里会用到。
访问 http://localhost/category/id/1111 则最终匹配到规则H，因为以上规则都不匹配，这个时候应该是nginx转发请求给后端应用服务器，比如FastCGI（php），tomcat（jsp），nginx作为方向代理服务器存在。