MySQL innodb count(*) count(1) 性能比较

      有写文章说尽量不要用count(*),这样性能不好。那今天来实测一下,从执行计划,转换后的SQL和Last_query_cost三个方面说事。注:这个值说明需要多少个数据页的随机查找才能完成上面的查询。这是根据一系列的统计信息计算得来的:每个表或者索引的页面个数,索引的基数(索引中不同值的数量),索引和数据行的长度、索引分布情况。优化器在评估成本的时候并不考虑任何层面的缓存,它假设读取任何数据都需要一次磁盘IO。

      结论就是在innodb中是一样的。

version()        
-----------------
10.1.22-MariaDB  

EXPLAIN SELECT COUNT(*) FROM gg_bm_o_order;
    id  select_type  TABLE          TYPE     KEY                         key_len  ref       ROWS  Extra        
------  -----------  -------------  ------   --------------------------  -------  ------  ------  -------------
     1  SIMPLE       gg_bm_o_order  INDEX    IDX_ORDER_ORDER_START_TIME  8        (NULL)      42  USING INDEX  
EXPLAIN EXTENDED SELECT COUNT(*) FROM gg_bm_o_order;
SHOW WARNINGS;
LEVEL     CODE  Message                                                    
------  ------  -----------------------------------------------------------
Note      1003  SELECT COUNT(0) AS `count(*)` FROM `gg_bm_o_order` 
SELECT COUNT(*) FROM gg_bm_o_order;
SHOW STATUS LIKE 'Last_query_cost';
Variable_name    VALUE     
---------------  ----------
Last_query_cost  9.399000  


EXPLAIN SELECT COUNT(1) FROM gg_bm_o_order;
    id  select_type  TABLE          TYPE     KEY                         key_len  ref       ROWS  Extra        
------  -----------  -------------  ------   --------------------------  -------  ------  ------  -------------
     1  SIMPLE       gg_bm_o_order  INDEX    IDX_ORDER_ORDER_START_TIME  8        (NULL)      42  USING INDEX  
EXPLAIN EXTENDED SELECT COUNT(1) FROM gg_bm_o_order;
SHOW WARNINGS;
LEVEL     CODE  Message                                                    
------  ------  -----------------------------------------------------------
Note      1003  SELECT COUNT(1) AS `COUNT(1)` FROM `gg_bm_o_order`  
SELECT COUNT(1) FROM gg_bm_o_order;
SHOW STATUS LIKE 'Last_query_cost';
Variable_name    VALUE     
---------------  ----------
Last_query_cost  9.399000  

猜你喜欢

转载自blog.csdn.net/guogang83/article/details/79198213