节省了很多.
再来看实际执行:
| mysql> SELECT SQL_NO_CACHE channel, COUNT(channel) AS visitors FROM xxx_sources WHERE client_id = '1301' GROUP BY client_id, channel; +---------+----------+ | channel | visitors | +---------+----------+ | NULL | 0 | +---------+----------+ 1 row in set (0.25 sec) |
哇,从11.69秒变成了0.25秒,这是什么概念,优化了多少倍,算一下吧.
看到这里在想什么呢,记住这个案例,嗯,不错,以后还可以加引号优化一下.那为什么不问一下,能不能在优化了,为什么会这样呢?
我们先来看一下第一个问题：
能不能在优化了?
答案是当然可以了.从索引的长度上来看258还是一个非常大的数据,对于client_id这个字段从名字上来看,也只会存数据型的值,那为什么不用的一个int unsigned去存呢,
索引的长度马上会从258降到4。这样不是又节省了很多吗？
接下来看一下第二个问题，为什么会这样呢？
原因有两点，同时基于一个原则，基于成本的优化器。对于client_id在表的定义时定义成了字符型的值，在查询时传入了数值型的值，需要经过一个数值转换，悲剧的开始，最终
导致MySQL选择了一个完成的索引去扫描。
从这个案例上，我们需要注意什么呢？
合理的选择数据类型，基本工太重要了，就这叫赢在起跑线，一切都不能随便了，别把一个表定义成了降了主建外其它全是Varchar(255)。对数据库的double/float这种字段做索引时一定要小心。
