1、単一テーブルのクエリの最適化
SQLテーブルを構築
NOTは`article`が存在する場合のCREATE TABLE（
` id`のINT（10）UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT、
`author_id`のINT（10）UNSIGNED NOT NULL、
` category_id`のINT（10）UNSIGNED NOT NULL、
`views`のINT（ 10）UNSIGNED NOT NULL、
`comments`のINT（10）UNSIGNED NOT NULL、
` VARBINARY（255）、NOT NULL、title`
`content` TEXT NOT NULL
）。
article` `。INSERT INTO（` author_id`、 `category_id`、` views`、 `comments`、` title`、 `content`）VALUES
（1、1、1、1、 '1'、 '1'）、
（2、2、2、2、 '2'、 '2'）、
（1、1、3、3、3 ''、3 ''）。
記事SELECT * FROM。
ケース
ケース＃クエリは1とコメント、意見ほとんどのarticle_idに1より大きいCATEGORY_ID。
SQLを実行します。
SELECT ID、物品からAUTHOR_IDをEXPLAIN WHEREビューによってCATEGORY_ID = 1とコメント> 1 ORDER DESCのLIMIT 1。
＃結論：明らかに、型は、ALLであるが、最悪のケースです。エクストラレーンもfilesortレコードを使用して登場し、それは状況の最悪でした。最適化をする必要があります。
クエリランキング：記事からのショーのインデックス。
：＃は、最適化を開始
＃1.1 の新指数は+インデックスの削除
; #ALTERのTABLE `article`のADD INDEX idx_article_ccv（` category_id`、 `comments`、` views`）のインデックスを作成 idx_article_ccvをON Articleこの記事は（CATEGORY_ID、コメント、意見）であった。
DROP INDEX idx_article_ccv ON Articleこの記事でした
＃1.2第2次を説明
ビューDESCのLIMIT 1 BY `article` CATEGORY_ID = 1とコメント> 1 ORDER FROM SELECT ID、AUTHOR_IDをEXPLAIN。
#结论：
#type 变成了 range,这是可以忍受的。但是 extra 里使用 Using filesort 仍是无法接受的。
#但是我们已经建立了索引,为啥没用呢?
#这是因为按照 BTree 索引的工作原理,
# 先排序 category_id,
# 如果遇到相同的 category_id 则再排序 comments,如果遇到相同的 comments 则再排序 views。
#当 comments 字段在联合索引里处于中间位置时,
#因comments > 1 条件是一个范围值(所谓 range),
#MySQL 无法利用索引再对后面的 views 部分进行检索,即 range 类型查询字段后面的索引无效。
# 1.3 删除第一次建立的索引
DROP INDEX idx_article_ccv ON article;
# 1.4 第2次新建索引
#ALTER TABLE `article` ADD INDEX idx_article_cv ( `category_id` , `views` ) ;
create index idx_article_cv on article(category_id,views);
# 1.5 第3次EXPLAIN
EXPLAIN SELECT id,author_id FROM article WHERE category_id = 1 AND comments > 1 ORDER BY views DESC LIMIT 1;
#结论：可以看到,type 变为了 ref,Extra 中的 Using filesort 也消失了,结果非常理想。