Optimizing the index shows an example single MYSQL

1. Create a table 

CREATE TABLE IF NOT EXISTS `article` (
`id` BIGINT(10) NOT NULL AUTO_INCREMENT,
`author_id` INT(10) NOT NULL,
`category_id` INT(10) NOT NULL,
`views` INT(10) NOT NULL,
`comments` INT(10) NOT NULL,
`title` VARCHAR(10) COLLATE utf8_unicode_ci NOT NULL,
`content` TEXT COLLATE utf8_unicode_ci NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=INNODB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

 

2. Add data

INSERT INTO article(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');

 

 

 

3. Query

SELECT * FROM article;

 

 

 

4. Demand

  Query category_id case 1 is greater than 1 and comments, views the most article_id.

  

5. SQL

  SELECT id, author_id FROM article WHERE category_id =1 AND comments>1 ORDER BY views DESC LIMIT 1;

 

6. index optimization analysis

  

 

 

   type = ALL: full table scan 

   key = NULL: do not use the index,

  Extra also appeared Using filesort, had a secondary sorting

  Conclusion: garbage, it needs to be optimized.

  (1) for the first time to create an index

     First View original article index 

     

 

 

     It is a primary key primary index. And where, order by using the column did not have any relationship, so do not take the index to normal.

     The following create a multi-column index based on where, order by field 

     create index idx_c_c_v on article(category_id,comments, views);

    

 

     View index again    

              

 

      Note that the index inx_c_c_v, Seq_in_index indicates the index column for the order, more than, for example, said in use inx_c_c_v, first find category_id, find comments, and finally find views.

 

 

    After creating the index, we then analyze SELECT id, author_id FROM article WHERE category_id = 1 AND comments> 1 ORDER BY views DESC LIMIT 1 of the implementation plan.

     

 

 

    type = range: scan range, than the previous full table scan type = ALL higher efficiency.

    key = inx_c_c_v: Use the index was created. OK,

    Extra: Using filesort,. . . . . . The pit cargo is still there. . . .

 

    Then we look at the following execution plan

    

 

     type = ref: non-unique index scan, the efficiency is higher than the above range of the scanning range it

    key = inx_c_v_v: use of the index 

    ref = const,const : 两个常量,优秀!

    Extra ,干掉了Using filesorting 

    

    通过对比,我们不难发现,inx_c_c_v不变的情况下,仅是由于查询语句的不同,直接造成执行计划的巨大差异。 其根本原因是comment> 1是个type=range范围查询,它会导致该索引列之后索引列失效,即是(category --√--- comments -----×--views)

    

    所以,index_c_v_v这个索引不行呀,都是因为comments造成的, 所以我们建索引时,不要它,试试!

    drop index idx_c_c_v on article;

    

 

 

 

   (2) 第二次创建索引 

    create index idx_c_v on  article(category_id,views);

    

 

     查看表索引。。。

    

  

    最后来看一下explain SELECT id, author_id FROM article WHERE category_id =1 AND comments>1 ORDER BY views DESC LIMIT 1\G

    

 

 

      type = ref : 完美

    ref = const : 完美  

    Extra ,没有Using filesort, 也算完美!

    总之,还可以吧!

 

7. 总结

   相同的索引 ,select 语句的差别也会造成不同的执行计划,性能差别距大

   创建索引时,范围查询需要 特别注意。

 

Guess you like

Origin www.cnblogs.com/z-qinfeng/p/11704669.html