标签:rom 不用 tle 业务逻辑 pre 查询 sql执行时间 磁盘 font
相当于就是之前一个表数据量比较小,之后数据量大了查询就变慢,此时在经常用到的字段上加个索引,效率会翻倍很多的
例如: where a * 5 = 10 可以 转化为 where a = 10/5
这样既可以保证业务逻辑也可以继续使用原索引去操作,所以要避免对索引字段进行计算或类型转化
如果业务逻辑允许,且表里几乎无脏数据,那就可以使用JOIN去联表查询,而不建议使用LEFT JOIN或RIGHT JOIN去查询,因为本身它们联表都是有区别的,建议使用JOIN去联表,尽量的去提升速度
不建议 select * from table_name;
因为查询,返回结果集,都会花费io,还有带宽一些资源,所以结果集内容少速度也会提升的
表达式索引,如经常对一个字段进行 lower(字段xxx), 那就可以创建 表达式 lower(字段xxx) 的索引,只有操作可以使用到索引,速度必然会有所提升
如: where a = ‘f‘ and b = ‘2‘
就可以建立一个 a = ‘f’ and b = ‘2’ 的部分索引,因为业务经常会用到,自然会提升速度
如一下操作的数据量比较大,不管是DML、DDL语言都得考虑lock的粒度,不能影响线上业务操作,一般都是分布执行,不要为了省事,而导致业务挂掉,那就得不偿失了,操作前先查看操作数据量的级别
索引的维护,把一些不用的且占磁盘空间比较大,自然得删除,或者跟据业务逻辑对某字段的索引算法进行调整再或者使用新的索引去替代老的索引,注意处理同一个字段的两个索引的优化时,如果存在主从复制的机制在的话,维护索引注意不要影响生产业务
注意:以上优化都是基于不改变原有业务需求所做的优化,否则另换它法去优化
B-Tree、 Hash、Gist、SP-Gist、Gin、BRin
要用那种索引,跟据业务逻辑的特点或者字段的类型而定
标签:rom 不用 tle 业务逻辑 pre 查询 sql执行时间 磁盘 font
原文地址:https://www.cnblogs.com/williamjie/p/9478166.html