为什么Mysql explain extended中的filtered列值总是100

MySQL的统计信息非常少，只有表行数和索引列的唯一值数目，这使得MySQL的优化器经常不能对数据规模有一个正确的认识而给出性能不佳的执行计划。2. MySQL的join操作的效率非常依赖于索引(我之前两次帮人调优MySQL的SQL语句都是在加索引)。并不是说PG的join不需要索引，只是不像MySQL缺了索引的反应那么大。上面那个MySQL执行了1分多钟的例子，加上索引后，不管是MySQL还是PG的执行时间都立刻降到10毫秒以内。所以，开发人员在设计表的时候应该对可能的查询方式做个评估，把该建的索引都建上（不能少建也不宜多建）。

mysql explain 怎么看

如果是only

index，这意味着信息只用索引树中的信息检索出的，这比扫描整个表要快。

如果是where

used，就是使用上了where限制。

如果是impossible

where

表示用不着where，一般就是没查出来啥。

如果此信息显示using

filesort或者using

temporary的话会很吃力，where和order

by的索引经常无法兼顾，如果按照where来确定索引，那么在order

by时，就必然会引起using

filesort，这就要看是先过滤再排序划算，还是先排序再过滤划算。

explain 这个数表示mysql要遍历多少数据才能找到，在innodb上是不准确的

rows

这个数表示mysql要遍历多少数据才能找到，在innodb上是不准确的。

Extra

如果是Only index，这意味着信息只用索引树中的信息检索出的，这比扫描整个表要快。

如果是where used，就是使用上了where限制。

如果是impossible where 表示用不着where，一般就是没查出来啥。

如果此信息显示Using filesort或者Using temporary的话会很吃力，WHERE和ORDER BY的索引经常无法兼顾，如果按照WHERE来确定索引，那么在ORDER BY时，就必然会引起Using filesort，这就要看是先过滤再排序划算，还是先排序再过滤划算。

mysql explain扫描行数问题

这个执行计划里看到的行数应该跟你mysql库里的统计表中数据一样，统计表里的数据要满足一定条件才会更新，你也可以手动更新

mysql中explain执行结果中的rows究竟是怎么个统计原理

=1，指的是 你查询的结果，是需要从 表 t_dept 中查找出 deptno为1 的所有结果 ，where 后面就是跟的你所要查询的条件。建议楼主你去看看sql语句的语法调用

mysql explain type index和ref的区别

type=index，索引全扫描，MySQL遍历整个索引来查询匹配的行：select username from user;

type=ref，使用非唯一索引扫描或唯一索引的前缀扫描，返回匹配某个单独值的记录行，例如：select * from user where username = '张三';

个人理解：看你有没有加where条件吧，加了where就要匹配记录行。另外本人也测试了下，如果执行'select username from user where username = '张三';'，type依旧为ref，可见一斑。