logo头像
Snippet 博客主题

MySQL索引优化总结

  1. 如果MySQL估计使用索引比全表扫描还慢,则不会使用索引;
  2. 前导模糊查询不能命中索引,在做模糊查询时,不要把通配符放在最前面,否则不会命中索引;
  3. 数据类型出现隐式转换的时候不会命中索引,特别是当列类型是字符串,一定要将字符常量值用引号引起来;
  4. 复合索引的情况下,查询条件不包含索引列最左边部分(不满足最左原则),不会命中符合索引;
  5. union、in、or都能够命中索引,建议使用in:or>in>union;
  6. 用or分割开的条件,如果or前的条件中列有索引,而后面的列中没有索引,那么涉及到的索引都不会被用到;
  7. 负向条件查询不能使用索引,可以优化为in查询,负向条件有:!=、<>、not in、not exists、not like等;
  8. 数据库执行计算不会命中索引,不要查询条件中使用表达式;
  9. 利用覆盖索引进行查询,避免回表;
  10. 建立索引的列,不允许为null;
  11. 更新十分频繁的字段上不宜建立索引:因为更新操作会变更B+树,重建索引。这个过程是十分消耗数据库性能的;
  12. 区分度不大的字段上不宜建立索引:类似于性别这种区分度不大的字段,建立索引的意义不大。因为不能有效过滤数据,性能和全表扫描相当。另外返回数据的比例在30%以外的情况下,优化器不会选择使用索引;
  13. 业务上具有唯一特性的字段,即使是多个字段的组合,也必须建成唯一索引。虽然唯一索引会影响insert速度,但是对于查询的速度提升是非常明显的。另外,即使在应用层做了非常完善的校验控制,只要没有唯一索引,在并发的情况下,依然有脏数据产生;
  14. 多表关联时,要保证关联字段上一定有索引;
  15. 创建索引时避免以下错误观念:索引越多越好,认为一个查询就需要建一个索引;宁缺勿滥,认为索引会消耗空间、严重拖慢更新和新增速度;抵制唯一索引,认为业务的唯一性一律需要在应用层通过“先查后插”方式解决;过早优化,在不了解系统的情况下就开始优化;
  16. 没有太大的必要使用DECIMAL数据类型。即使是在需要存储财务数据时,仍然可以使用BIGINT。比如需要精确到万分之一,那么可以将数据乘以一百万然后使用BIGINT存储。这样可以避免浮点数计算不准确和DECIMAL精确计算代价高的问题;
  17. 当只要一行数据时使用LIMIT 1。

后续总结再补充

支付宝打赏 微信打赏

赞赏是不耍流氓的鼓励