爲什麼這個結果不能僅使用索引解決？

架構：爲什麼這個結果不能僅使用索引解決？

CREATE TABLE IF NOT EXISTS `tx_hep_homes_attributes_mm` (
    `uid_local` int(11) NOT NULL DEFAULT '0', 
    `uid_foreign` int(11) NOT NULL DEFAULT '0', 
    `tablenames` varchar(30) COLLATE utf8_unicode_ci NOT NULL DEFAULT '', 
    `sorting` int(11) NOT NULL DEFAULT '0', 
    KEY `uid_local` (`uid_local`), 
    KEY `uid_foreign` (`uid_foreign`), 
    KEY `uid_local_foreign` (`uid_local`,`uid_foreign`) 
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

樣品輸入：

INSERT INTO `tx_hep_homes_attributes_mm` (`uid_local`, `uid_foreign`, `tablenames`, `sorting`) VALUES 
(2, 4, '', 3), 
(2, 1, '', 2), 
(2, 2, '', 1), 
(1, 2, '', 5), 
(1, 3, '', 4), 
(1, 4, '', 3), 
(1, 7, '', 2), 
(1, 8, '', 1);

查詢：

SELECT amm.uid_local, 
     amm.uid_foreign 
FROM tx_hep_homes_attributes_mm amm 
     JOIN (SELECT 1 AS att_id 
      UNION 
      SELECT 4 AS att_id 
      UNION 
      SELECT 13 AS att_id 
      UNION 
      SELECT 22 AS att_id 
      UNION 
      SELECT 12 AS att_id)d1 
     ON d1.att_id = amm.uid_foreign 
     JOIN (SELECT 1 AS home_id 
      UNION 
      SELECT 2 AS home_id)d2 
     ON d2.home_id = amm.uid_local 
ORDER BY uid_local

生產：

+------+---------------+-------------------+-------+------------------------------------------+--------------------+----------+-------------+-------+---------------------------------+ 
| id | select_type |  table  | type |    possible_keys    |  key   | key_len | ref  | rows |    Extra    | 
+------+---------------+-------------------+-------+------------------------------------------+--------------------+----------+-------------+-------+---------------------------------+ 
| 1 | PRIMARY  | <derived7>  | ALL | NULL          | NULL    | NULL  | NULL  | 2  | Using temporary; Using filesort | 
| 1 | PRIMARY  | amm    | ref | uid_local,uid_foreign,uid_local_foreign | uid_local_foreign | 4  | d2.home_id | 1  | Using where; Using index  | 
| 1 | PRIMARY  | <derived2>  | ALL | NULL          | NULL    | NULL  | NULL  | 5  | Using where; Using join buffer | 
| 7 | DERIVED  | NULL    | NULL | NULL          | NULL    | NULL  | NULL  | NULL | No tables used     | 
| 8 | UNION   | NULL    | NULL | NULL          | NULL    | NULL  | NULL  | NULL | No tables used     | 
| NULL | UNION RESULT | <union7,8>  | ALL | NULL          | NULL    | NULL  | NULL  | NULL |         | 
| 2 | DERIVED  | NULL    | NULL | NULL          | NULL    | NULL  | NULL  | NULL | No tables used     | 
| 3 | UNION   | NULL    | NULL | NULL          | NULL    | NULL  | NULL  | NULL | No tables used     | 
| 4 | UNION   | NULL    | NULL | NULL          | NULL    | NULL  | NULL  | NULL | No tables used     | 
| 5 | UNION   | NULL    | NULL | NULL          | NULL    | NULL  | NULL  | NULL | No tables used     | 
| 6 | UNION   | NULL    | NULL | NULL          | NULL    | NULL  | NULL  | NULL | No tables used     | 
| NULL | UNION RESULT | <union2,3,4,5,6> | ALL | NULL          | NULL    | NULL  | NULL  | NULL |         | 
+------+---------------+-------------------+-------+------------------------------------------+--------------------+----------+-------------+-------+---------------------------------+

正如你所看到的那樣，使用文件排序，儘管它應該從複合索引中解析出來。

來源

2012-01-03 Pentium10

如果tx_hep_homes_attributes_mm只是這裏顯示的9行，那麼我會期望索引被忽略，因爲所有的數據都將在緩存中，並且使用索引會花費更多。

當索引選擇的數據量遠小於表中的行數時，主要使用Indicies。這裏有75％的行在結果中。

來源

2012-01-03 13:57:02 Mark

此表爲示例數據，這就是爲什麼它只有9行。但解釋仍然需要展示最佳匹配。 – Pentium10 2012-01-03 13:58:57

這取決於數據的大小和結果中需要的行數，因此您必須查看實際數據。 – Mark 2012-01-03 14:01:21

如果索引基數較低或者行數爲小。 9很小。 – 2012-01-03 14:09:16

如果行數不是很大，查詢優化器使用表掃描而不是索引。

來源

2012-01-03 13:57:51

爲什麼這個結果不能僅使用索引解決？

回答

相關問題