web性能优化方向

1.服务器结构：

ip负载均衡->缓存服务器->Nginx反向代理->应用服务器->数据库

2.博客链接:http://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw%3D%3D&mid=2659598939&idx=1&sn=cb607189e62639f35eede86262ec7c3b&chksm=8be99749bc9e1e5f0a3eb54bfb7f74135fc7c8546b22a972725b25c7f8f6ad58b9da3203f999

3.就是减少数据库操作，比如for循环里面还有数据库查询

4.优化数据库查询

随着业务开发模式的变化，敏捷式开发被越来越多的团队采用，周期越来越短，很多数据库查询语句都是按照业务逻辑来写，时间久了常常就忽略了SQL查询的格式问题，造成数据库压力的增加，使数据库查询的响应变慢。这里简单介绍MySQL数据库中，几条被我们忽略的常见问题和优化方式：

1. 最左前缀匹配原则，非常重要的原则，MySQL会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。

2. 尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大我们扫描的记录数越少，唯一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0，那可能有人会问，这个比例有什么经验值吗？使用场景不同，这个值也很难确定，一般需要join的字段我们都要求是0.1以上，即平均1条扫描10条记录。

3. 尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会 逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。

4. 索引列不能参与计算，保持列“干净”，比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’);应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用。

5. 索引而进行全表扫描，如：
   select id from t where num is null可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
   select id from t where num=0

6. 应尽量避免在 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

7. 下面的查询也将导致全表扫描（不能前置百分号）：
   select id from t where name like ‘%abc%’若要提高效率，可以考虑全文检索。

8. 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