常见的sql优化

一些常见的SQL优化

• 负向条件查询不能使用索引

    select * from order where status!=0 and stauts!=1
    not in/not exists都不是好习惯
    可以优化为in查询：
        select * from order where status in(2,3)
  

• 前导模糊查询不能使用索引

    select * from order where desc like '%XX'
    而非前导模糊查询则可以：
        select * from order where desc like 'XX%'
  

• 数据区分度不大的字段不宜使用索引

    select * from user where sex=1
  
    原因：性别只有男，女，每次过滤掉的数据很少，不宜使用索引。
  
    经验上，能过滤80%数据时就可以使用索引。对于订单状态，如果状态值很少，
    不宜使用索引，如果状态值很多，能够过滤大量数据，则应该建立索引。
  

• 在属性上进行计算不能命中索引

    select * from order where YEAR(date) < = '2017'
  
    即使date上建立了索引，也会全表扫描，可优化为值计算：
  
    select * from order where date < = CURDATE()
  
    或者：
        select * from order where date < = '2017-01-01' 
  

• 允许为null的列，查询有潜在大坑

        单列索引不存null值，复合索引不存全为null的值，如果列允许为null，
                          可能会得到“不符合预期”的结果集
  
        select * from user where name != 'shenjian'
  
        如果name允许为null，索引不存储null值，结果集中不会包含这些记录。
  
  
  
         所以，请使用not null约束以及默认值。
  

• 复合索引最左前缀，并不是值SQL语句的where顺序要和复合索引一致

    用户中心建立了(login_name, passwd)的复合索引
  
    select * from user where login_name=? and passwd=?
    
    select * from user where passwd=? and login_name=?
    
    都能够命中索引 
    
    select * from user where login_name=?
    
    也能命中索引，满足复合索引最左前缀        
    
    select * from user where passwd=?
    
    不能命中索引，不满足复合索引最左前缀
  

• 使用ENUM而不是字符串

    ENUM保存的是TINYINT，别在枚举中搞一些“中国”“北京”“技术部”这样的字符串，字符串空间又大，效率又低。
  

• 如果明确知道只有一条结果返回，limit 1能够提高效率

    select * from user where login_name=?
  
    可以优化为：
  
    select * from user where login_name=? limit 1
  
    原因：
  
    你知道只有一条结果，但数据库并不知道，明确告诉它，让它主动停止游标移动
  

转载至https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651960280&idx=1&sn=da519cff7081ab347eb1aaa4f0f4f408&chksm=bd2d06048a5a8f123730ed91b60ac2f55ec5eb92774f24ec45c3fc0d004aea514e6fc3990e0e&scene=21#wechat_redirect