MySQL调优

SQL调优:基于MySQL-索引

    • 1. 善用 EXPLAIN:
    • 2. SQL 语句中 IN 包含的值不应过多:
    • 3. SELECT 语句务必指明字段名称:
    • 4. 当只需要一条数据的时候,使用 limit 1:
    • 5. 如果排序字段没有用到索引,就尽量少排序:
    • 6. 如果限制条件中其他字段没有索引,尽量少用 or:
    • 7. 尽量用 union all 代替 union:
    • 8. 不使用 ORDER BY RAND():
    • 9. 区分 in 和 exists,not in 和 not exists:
    • 10. 使用合理的分页方式以提高分页效率:
    • 11. 分段查询:
    • 12. 避免在 where 子句中对字段进行 null 值判断:
    • 13. 不建议使用%前缀模糊查询:
    • 14. 避免在 where 字句中对字段进行表达式操作:
    • 15. 避免隐式类型转换:
    • 16. 关于 join 优化:

1. 善用 EXPLAIN:

做 MySQL 优化,我们要善用 EXPLAIN 查看 SQL 执行计划。

2. SQL 语句中 IN 包含的值不应过多:

MySQL 对于 IN 做了相应的优化,即将 IN 中的常量全部存储在
一个数组里面,而且这个组是排好序的。但是如果数值较多,产
生的消耗也是比较大的。对于连续的数值,能用 between 就不
用 in ;再或者使用连接来替换。

3. SELECT 语句务必指明字段名称:

SELECT * 增加很多不必要的消耗(cpu、io、内存、网络带宽);
当表结构发生改变时,前断也需要更新。所以要求直接在 select
后面接上字名。

4. 当只需要一条数据的时候,使用 limit 1:

在 Mysql 中进行数据分页等操作时适用 limit,而 Oracle 中适用
rownum

5. 如果排序字段没有用到索引,就尽量少排序:

6. 如果限制条件中其他字段没有索引,尽量少用 or:

or 两边的字段中,如果有一个不是索引字段,而其他条件也不是
索引字段,会造成该询不走索引的情况。很多时候使用 union all
或者是 union(必要的时候)的方式来替“or”会得到更好的效果

7. 尽量用 union all 代替 union:

union 和 union all 的差异主要是前者需要将结果集合并后再进
行唯一性过滤操作,这就涉及到排序,增加大量的 CPU 运算,加
大资源消耗及延迟。(union all 的前提条是两个结果集没有重复
数据)

8. 不使用 ORDER BY RAND():

9. 区分 in 和 exists,not in 和 not exists:

区分 in 和 exists 主要是造成了驱动顺序的改变(这是性能变化
的关键),如果是 exists,那么以外层表为驱动表,先被访问,如
果是IN,那么先执行子查询。 (IN适合于外表大而内表小的情况;
EXISTS适合于外表小而内表大的情况)关于not in和not exists,
推荐使用 not exists,不仅仅是效率问题,not in 可能存在逻辑
问题。

10. 使用合理的分页方式以提高分页效率:

11. 分段查询:

12. 避免在 where 子句中对字段进行 null 值判断:

对于 null 的判断会导致引擎放弃使用索引而进行全表扫描。

13. 不建议使用%前缀模糊查询:

例如 LIKE “%name”或者 LIKE “%name%”,这种查询会导致索引
失效而进行全表扫描。但是可以使用 LIKE “name%”。那如何查
询%name%?使用全文索引

14. 避免在 where 字句中对字段进行表达式操作:

15. 避免隐式类型转换:

where 子句中出现 column 字段的类型和传入的参数类型不一
致的时候发生的类型转换,建议先确定 where 中的参数类型

16. 关于 join 优化:

1)LEFT JOIN:左表为驱动表
2)INNER JOIN:MySQL 会自动找出数据量小的表作驱动表
3)RIGHT JOIN:右表为驱动表
注意:Mysql 中没有 full join(全外连接:Oracle 拥有);
合理使用索引:被驱动表的索引字段作为 on 的限制字段;
尽量利用小表驱动大表。

你可能感兴趣的:(optimize,MySQL)