Mysql之EXPLAIN显示using filesort
EXPLAIN 是mysql解释select查询的一个关键字,可以很方便的用于调试
语法格式如下
EXPLAIN tbl_name
或者:
EXPLAIN SELECT select_options
EXPLAIN 语句可以被当作 DESCRIBE 的同义词来用，也可以用来获取一个MySQL要执行的 SELECT 语句的相关信息。
EXPLAIN tbl_name 语法和 DESCRIBE tbl_name 或 SHOW COLUMNS from tbl_name 一样。
当在一个 SELECT 语句前使用关键字 EXPLAIN 时，MYSQL会解释了即将如何运行该 SELECT 语句，它显示了表如何连接、连接的顺序等信息。
以下信息为引用:
在explain我们所使用的sql的时候，经常会遇到using filesort这种情况，原以为是由于有相同列值的原因引起，结果昨天看到公司的一个sql，跟同事讨论了下加上自己又做了一些测试，突然发现自己原来的想法是错误的。
首先，只有在order by 数据列的时候才可能会出现using filesort，而且如果你不对进行order by的这一列设置索引的话，无论列值是否有相同的都会出现using filesort。因此，只要用到order by 的这一列都应该为其建立一个索引。
其次，在这次测试中，使用了一个稍微有点复杂的例子来说明这个问题，下面详细用这个例子说一下：
SELECT * from DB.TB WHERE ID=2222 AND FID IN (9,8,3,13,38,40) ORDER BY INVERSE_DATE LIMIT 0, 5
里面建立的索引为一个三列的多列索引：IDX（ID,FID ,INVERSE_DATE） 。INVERSE_DATE这个是时间的反向索引。
对于这个sql我当时最开始认为应该是个优化好的状态，应该没有什么纰漏了，结果一explain才发现竟然出现了：Using where; Using filesort。
为什么呢，后来经过分析才得知，原来在多列索引在建立的时候是以B-树结构建立的，因此建立索引的时候是先建立ID的按顺序排的索引，在相同ID的情况下建立FID按 顺序排的索引，最后在FID 相同的情况下建立按INVERSE_DATE顺序排的索引，如果列数更多以此类推。有了这个理论依据我们可以看出在这个sql使用这个IDX索引的时候只是用在了order by之前，order by INVERSE_DATE 实际上是using filesort出来的。。汗死了。。因此如果我们要在优化一下这个sql就应该为它建立另一个索引IDX（ID,INVERSE_DATE），这样就消除了using filesort速度也会快很多。问题终于解决了。
相关文档：
遇到一个问题是在MySQL命令行插入中文数据或者查询中文数据时出现乱码，或者显示不对。
在命令行输入:show variables like ‘character_set_%’;
查看当前配置的编码；
在命令行输入 :set names utf8;
则等同于
set character_set_client=utf8;
set character_set_results ......
今天我们看看关于MySQL慢日志的阅读。
我们知道，如果我们的语句不够优化，那么首先MySQL的慢日志是进一步优化的离线证据，虽然里面有好
多“伪慢语句”！
先不说怎么优化，如果你的日志有一条语句赌住了，那么会有不计其数的慢语句填充到MySQL的满日志里面。那么首先提炼出这些语
句就非常头疼。
今天主要� ......
这两天正在测MYSQL的性能，按照MYSQL文档中推荐的设置，修改了几个系统变量
innodb_buffer_pool_size=1G
innodb_log_file_size=250M
innodb_log_buffer_size=8M
结果MYSQL崩了。mysql客户端能登录，但只要执行任何命令，mysqld立刻崩掉。
开始还以为是innodb_buffer_pool_size等几个参数设得太大了，可是调整了几次� ......
查询是数据库技术中最常用的操作。查询操作的过程比较简单，首先从客户端发出查询的SQL语句，数据库服务端在接收到由客户端发来的SQL语句后， 执行这条SQL语句，然后将查询到的结果返回给客户端。虽然过程很简单，但不同的查询方式和数据库设置，对查询的性能将会有很在的影响。
因此，本文就在MySQL中常用的查询优化技术� ......
