MySQL:联合索引与Where子句的优化
本网站系统上线至今,数据量已经不知不觉上到500M,近8W记录了。涉及数据库操作的基本都是变得很慢了,用的人都会觉得躁火~~然后把这个情况在群里一贴,包括机器配置什么的一说,马上就有群友发话了,而且帮我确定了不是机器配置的问题,“深圳-枪手”热心人他的机器512内存过百W的数据里也跑得飞快,甚至跟那些几W块的机器一样牛(吹过头了),呵呵~~~
在群友的分析指点下,尝试把排序、条件等一个一个去除来做测试,结果发现问题就出在排序部分,去除排序的时候,执行时间由原来的48秒变成0.3x秒,这是个什么档次的变化呀~~看着这个结果我激动ing.....
于是我把涉及排序的字段组成一个联合索引alter table xx add index indexname(x1,x2,x3),经过2分钟创建新索引之后再执行同一个SQL语句,哇塞0.28S。。。。爽
于是按照同样的思路把其它几个常用的SQL作了过些优化,效果马上见效
过了30分钟再查slow sql记录文件,不好了,发现原来一个好好的SQL变得灰常慢了,神马情况?
几经分析和测试原来就是因为添加了联合索引的原因,而且这个SQL语句当中有个or,当把这个or改用union之后问题排除。
这回又得出一个心得:写SQL的时候千万别一时就手,随便写个就OK,那会为以为带来很严重的后果。
再附上一段关于Where子句的执行顺序:
在用MySQL查询数据库的时候,连接了很多个用,发现非常慢。例如:
- SELECT ... WHERE p.languages_id = 1 AND m.languages_id = 1 AND c.languages_id = 1 AND t.languages_id = 1 AND p.products_id IN (472,474)
这样查询需要20多秒,虽然在各个字段上都建立了索引。用分析Explain SQL一分析,发现在***次分析过程中就返回了几万条数据:
WHERE p.languages_id = 1 ,然后再依次根据条件,缩小范围。
而我改变一下WHERE 字段的位置之后,速度就有了明显地提高:
- WHERE p.products_id IN (472,474) AND
- p.languages_id = 1 AND m.languages_id = 1 AND c.languages_id = 1 AND t.languages_id = 1
这样,***次的条件是p.products_id IN (472,474),它返回的结果只有不到10条,接下来还要根据其它的条件来过滤,自然在速度上有了较大的提升。
经过实践发现,不要以为WHERE中的字段顺序无所谓,可以随便放在哪,应该尽可能地***次就过滤掉大部分无用的数据,只返回最小范围的数据。
希望能帮到有同样遭遇的朋友。
【编辑推荐】
相关文章
- 从本体论开始说起——运营商关系图谱的构建及应用
- 如何成为一名数据科学家?
- 从未见过的堂兄杀了人,你的DNA是关键证据
- 20个安全可靠的免费数据源,各领域数据任你挑
- 20个安全可靠的免费数据源,各领域数据任你挑
- 阿里云李飞飞:All in Cloud时代,云原生数据库优势明显
- 基于Hadoop生态系统的一高性能数据存储格式CarbonData(性能篇)
- 大数据告诉你:10年漫威,到底有多少角色
- TigerGraph:实时图数据库助力金融风控升级
- Splunk利用Splunk Connected Experiences和Splunk Business Flow 扩大数据访问
- 大数据开发常见的9种数据分析手段
- 以免在景区看人,我爬了5W条全国景点门票数据...
- 【实战解析】基于HBase的大数据存储在京东的应用场景
- 数据科学家告诉你哪些计算机科学书籍是你应该看的
- Kafka作为大数据的核心技术,你了解多少?
- Spring Boot 整合 Redis 实现缓存操作
- 大数据学习必须掌握的五大核心技术有哪些?
- 基于Antlr在Apache Flink中实现监控规则DSL化的探索实践
- 甲骨文再次被Gartner评为分析型数据管理解决方案魔力象限领导者
- 爬取吴亦凡微博102118条转发数据,扒一扒流量的真假