mysqlexplain

mysql explain index和ref的区别

提示：

mysql explain index和ref的区别

onst联接类型的一个特例。表仅有一行满足条件.如下(t3表上的id是 primary key)

mysql> explain select * from (select * from t3 where id=3952602) a ;
+----+-------------+------------+--------+-------------------+---------+---------+------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+--------+-------------------+---------+---------+------+------+-------+
| 1 | PRIMARY | | system | NULL | NULL | NULL | NULL | 1 | |
| 2 | DERIVED | t3 | const | PRIMARY,idx_t3_id | PRIMARY | 4 | | 1 | |
+----+-------------+------------+--------+-------------------+---------+---------+------+------+-------+

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

提示：

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

1. MySQL的统计信息非常少，只有表行数和索引列的唯一值数目，这使得MySQL的优化器经常不能对数据规模有一个正确的认识而给出性能不佳的执行计划。
2. MySQL的join操作的效率非常依赖于索引(我之前两次帮人调优MySQL的SQL语句都是在加索引)。并不是说PG的join不需要索引，只是不像MySQL缺了索引的反应那么大。上面那个MySQL执行了1分多钟的例子，加上索引后，不管是MySQL还是PG的执行时间都立刻降到10毫秒以内。所以，开发人员在设计表的时候应该对可能的查询方式做个评估，把该建的索引都建上（不能少建也不宜多建）。
3. 相比之下，PG不仅统计所有列的值分布，而且除了唯一值还有直方图，频繁值等等信息，支撑了PG的优化器做出正确的决策。猜测也是由于这个原因，PG社区认为PG的优化器已经足够智能，不需要把和Oracle类似的hint功能加到PG的内核里（因为hint可能会被人滥用，导致系统很难维护；不过，实在想用的话可以自己装pg_hint_plan插件）。