|
随着业务开发模式的变化,敏捷式开发被越来越多的团队采用,周期越来越短,很多数据库查询语句都是按照业务逻辑来写,时间久了常常就忽略了SQL查询的格式问题,造成数据库压力的增加,使数据库查询的响应变慢.这里简单介绍MySQL数据库中,几条被我们忽略的常见问题和优化方式：
- 最左前缀匹配原则,非常重要的原则,MySQL会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配,比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引,d是用不到索引的,如果建立(a,d,c)的索引则都可以用到,a,d的顺序可以任意调整.
- 尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*),表示字段不重复的比例,比例越大我们扫描的记录数越少,唯一键的区分度是1,而一些状态、性别字段可能在大数据面前区分度就是0,那可能有人会问,这个比例有什么经验值吗?使用场景不同,这个值也很难确定,一般需要join的字段我们都要求是0.1以上,即平均1条扫描10条记录.
- 尽量使用数字型字段,若只含数值信息的字段尽量不要设计为字符型,这会降低查询和连接的性能,并会增加存储开销.这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符,而对于数字型而言只需要比较一次就够了.
- 索引列不能参与计算,保持列“干净”,比如
from_unixtime(create_time) = ’2014-05-29’就不能使用到索引,原因很简单,b+树中存的都是数据表中的字段值,但进行检索时,需要把所有元素都应用函数才能比较,显然成本太大.所以语句应该写成create_time = unix_timestamp(’2014-05-29’);应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用.
- 索引而进行全表扫描,如：
select id from t where num is null
可以在num上设置默认值0,确保表中num列没有null值,然后这样查询：
select id from t where num=0
- 应尽量避免在 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?
- 下面的查询也将导致全表扫描(不能前置百分号)：
select id from t where name like ‘%abc%’
若要提高效率,可以考虑全文检索.
- 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
文章来自微信公众号：互联网架构师 （编辑：网站开发网_盐城站长网 ）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
