DBA发来一个线上慢查询问题. SQL例如以下(为突出重点省略部分内容): select distinct article0_.id, 等字段 from article_table article0_, hits_table articlehit1_ where article0_.id=articlehit1_.id order by hits; EXPLAIN结果:耗时4.03S 出乎意料. 居然会有Using temporary, order by仅仅用到了一张表. 正常情况下不会出现
原文地址:http://huoding.com/2013/06/04/261 问题 通过「SHOW FULL PROCESSLIST」语句很容易就能查到问题SQL,如下: SELECT post.* FROM post INNER JOIN post_tag ON post.id = post_tag.post_id ORDER BY post.created DESC LIMIT 说明:因为post和tag是多对多的关系,所以存在一个关联表post_tag. 试着用EXPLAIN查询一下SQL
最近慢慢接触MySQL,了解如何优化它也迫在眉睫了,话说工欲善其事,必先利其器.最近我就打算了解下几个优化MySQL中经常用到的工具.今天就简单介绍下EXPLAIN. 内容导航 id select_type table type possible_keys key key_len ref rows Extra 环境准备 MySQL版本: 创建测试表 CREATE TABLE people( id bigint auto_increment primary key, zipcode ) not n
原理MySQL查询缓存保存查询返回的完整结果.当查询命中该缓存,会立刻返回结果,跳过了解析,优化和执行阶段. 查询缓存会跟踪查询中涉及的每个表,如果这写表发生变化,那么和这个表相关的所有缓存都将失效. 但是随着服务器功能的强大,查询缓存也可能成为整个服务器的资源竞争单点. 初步设置默认这个开关是关闭的,就是禁止使用query_cache,查询是否使用语句如下: mysql> SHOW VARIABLES LIKE 'have_query_cache'; Variable_name | Va
MySQL优化 一.单表.双表.三表优化 1.单表 首先结论就是,range类型查询字段后面的索引全都无效 (1)建表 create table if not exists article( id int primary key auto_increment, author_id int not null, category_id int not null, views int not null, comments int not null, title ) not null, conte
