当使用索引列查询的时候,尽量不要使用表达式,应该把计算放到业务层而不是数据库层。
例如下面这两个sql语句,显然应该避免的是第二种 where字句后面 写计算的
通过执行计划可以看出这个sql的type是const
而这个写表达式的是 index,const比index执行效率高
尽量使用主键查询,而不是其他索引,因为主键查询不会触发回表。
使用索引扫描来做排序:
mysql有两种方式可以生成有序的结果:通过排序操作或者按索引顺序扫描,如果explain出来的type列的值为index,则说明mysql使用了索引扫描来做排序
扫描索引本身是很快的,因为只需要从一条索引记录移动到紧接着的下一条记录。但如果索引不能覆盖查询所需的全部列,那么就不得不每扫描一条索引记录就得回表查询一次对应的行,这基本都是随机IO,因此按索引顺序读取数据的速度通常要比顺序地全表扫描慢
mysql可以使用同一个索引即满足排序,又用于查找行,如果可能的话,设计索引时应该尽可能地同时满足这两种任务。
只有当索引的列顺序和order by子句的顺序完全一致,并且所有列的排序方式都一样时(都是desc或都是asc),mysql才能够使用索引来对结果进行排序,如果查询需要关联多张表,则只有当orderby子句引用的字段全部为第一张表时,才能使用索引做排序。order by子句和查找型查询的限制是一样的,需要满足索引的最左前缀的要求,否则,mysql都需要执行顺序操作,而无法利用索引排序。
union all , in , or 都能使用索引的情况下,推荐使用 in
更新十分频繁,数据区分度不高的字段不宜建立索引:
更新会变更B+树,更新频繁的字段建立索引会大大降低数据库性能,更新的话会造成页分裂和页合并。
类似于性别这类区分度不大的属性,建立索引是没有意义的,不能有效过滤数据,想一下,性别就男和女,本身就能区分数据了,建立索引没什么意义,索引在id这种字段上建立的话,sql上where id = ? 这种的话,是直接可以检索的,而在性别上,就一个分支,男和女,没有太多的树。一般区分度在80%以上的时候就可以建立索引,区分度可以使用count(distinct(列名))/count(*)来计算。
创建索引的列,不允许为null。如果为null则会出现不符合预期的结果。
如果明确知道只有一条结果返回,limit 1 能够提高效率。因为用了limit 1之后 索引指针不会往下进行判断,如果下面还有数据,如果没有用limit 1 的话,还是会继续往下判断的。
网站声明:如果转载,请联系本站管理员。否则一切后果自行承担。
添加我为好友,拉您入交流群!
请使用微信扫一扫!