mysql查询速率过慢是件很使人头疼的事，所以呢，作者专程花了一些时刻为人人整理了关于mysql查询速率的优化计划，本篇文章满是作者的个人观点，若有疑问或毛病迎接交换并斧正，人人一同进修进步。

MySQL 大表的count()优化

相干mysql视频教程引荐：《mysql教程》

写本篇文章也是为了能协助人人消除疑问，回归正题，以下是基于我连系B+树的数据构造和对试验效果的推想作出的推断

本日试验了一下MySQL的count()操纵优化, 以下议论基于mysql5.7 InnoDB存储引擎. x86 windows操纵系统。

竖立的表的构造以下（数据量为100万）：

首先是关于mysql的count(*)，count(PK), count(1)哪一个快的题目。
完成效果以下：

并没有什么区别！加上了WHERE子句以后3个查询的时刻也是雷同的，我就不贴图片了。

之前在公司的时刻就写过一个select count(*) from table的SQL语句，在数据多的时刻异常慢。所以要怎样优化呢？

这要从InnoDB的索引提及, InnoDB的索引是B+Tree。

对主键索引来讲：它只要在叶子节点上存储数据，它的key是主键，而且value为整条数据。
对辅佐索引来讲：key为建索引的列，value为主键。

这给我们两个信息：
1. 依据主键会查到整条数据
2. 依据辅佐索引只能查到主键，然后必需经由过程主键再查到盈余信息。

所以假如要优化count(*)操纵的话，我们须要找一个短小的列，为它竖立辅佐索引。
在我的例子中就是status，虽然它的”severelity”险些为0.

先竖立索引：ALTER TABLE test1 ADD INDEX (status);
然后查询，以下图：

能够看到，查询时刻从3.35s下落到了0.26s，查询速率提拔近13倍。

假如索引是str这一列，效果又会是怎样呢？
先竖立索引: alter table test1 add index (str)
效果以下：

能够看到，时刻为0.422s，也很快，然则比起status这列照样有着1.5倍摆布的差异。

再斗胆勇敢一点做个试验，我把status这列的索引删掉，竖立一个status和left(omdb,200)(这一列均匀1000个字符)的团结索引，然后看查询时刻。
竖立索引： alter table test1 add index (status,omdb(200))
效果以下：

时刻为1.172s
alter table test1 add index (status,imdbid);