优化数据库查询

下文前8条摘自Web服务端性能提升实践。

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

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

　　　　　　先保留这么多，日后再追加

转载于:https://www.cnblogs.com/jenny-mapz/p/6405601.html