mysql优化之SQL语句优化

Mysql优化是一个老生常谈的问题,

优化的方向也优化很多:从架构层;从设计层;从存储层;从SQL语句层;

今天讲解一下从SQL语句层:

这个部分是程序员最容易把控的地方,也是最容易忽视的地方.

一个好的SQL语句可以让mysql的压力降低不少,也能够看清楚一个程序员的能力水准.

可以从日常的工作中积累.

对于怎么查看explain执行计划,比较索引就不多说了.

如下总结的一些优化建议:

a).可通过开启慢查询日志来找出较慢的SQL

b).不做列运算:SELECT id WHERE age + 1 = 10,任何对列的操作都将导致表扫描,它包括数据库教程函数、计算表达式等等,查询时要尽可能将操作移至等号右边

c).sql语句尽可能简单:一条sql只能在一个cpu运算;大语句拆小语句,减少锁时间;一条大sql可以堵死整个库.

d).不用SELECT *

e).OR改写成IN:OR的效率是n级别,IN的效率是log(n)级别,in的个数建议控制在200以内

f).不用函数和触发器,在应用程序实现

g).避免%xxx式左侧查询

h).少用JOIN

i).使用同类型进行比较,比如用‘123‘和‘123‘比,123和123比

j).尽量避免在WHERE子句中使用 != 或 <> 操作符,否则将引擎放弃使用索引而进行全表扫

k).对于连续数值,使用BETWEEN不用IN:SELECT id FROM t WHERE num BETWEEN 1 AND 5

l).列表数据不要拿全表,要使用LIMIT来分页,每页数量也不要太大;

后续会更新其余方面针对Mysql优化的建议.

原文地址:https://www.cnblogs.com/qiucw-cn/p/10776770.html

时间: 2024-10-11 10:20:47

mysql优化之SQL语句优化的相关文章

mysql索引优化和sql语句优化

一.mysql索引分为btree索引和hash索引. btree索引是二叉树结构 先到索引树上找,再去根据索引到数据里边找数据. hash索引是memory引擎,精准查询非常快,如果查范围内(where>8),会比较慢.因为是无序的,无法使用前缀索引. 2.btree索引 建立索引,通常是经常用到做查询条件,做分组,做排序. 独立索引,单个建索引只能用一个索引,通常用联合索引. 如建了一个(a,b,c)的复合索引,那么实际等于建了(a),(a,b),(a,b,c)三个索引,因为每多一个索引,都会

ORACLE性能优化之SQL语句优化

版权声明:本文为博主原创文章,未经博主允许不得转载. 目录(?)[+] 操作环境:AIX +11g+PLSQL 包含以下内容: 1.  SQL语句执行过程 2.  优化器及执行计划 3.  合理应用Hints 4.  索引及应用实例 5.   其他优化技术及应用 1.SQL语句执行过程 1.1 SQL语句的执行步骤 1)语法分析,分析语句的语法是否符合规范,衡量语句中各表达式的意义. 2)语义分析,检查语句中涉及的所有数据库对象是否存在,且用户有相应的权限. 3)视图转换,将涉及视图的查询语句转

MYSQL学习笔记——sql语句优化工具

前面讲解了很多mysql的基础知识,这一章讲解mysql的语句优化. 一.定位慢查询                                                                                 我们要对sql语句进行优化,第一步肯定是找到执行速度较慢的语句,那么怎么在一个项目里面定位这些执行速度较慢的sql语句呢?下面就介绍一种定位慢查询的方法. 1.1.数据库准备 首先创建一个数据库表: CREATE TABLE emp (empno MED

(3)mysql优化之sql语句优化

概述 该篇主要介绍一些常用的sql优化技巧 sql优化 1.select * from table_name where; 建议将*改为需要的列.这对速度不会有明显的影响,主要考虑节省内存. 2.like语句 一般情况下不鼓励使用like操作,如果非使用不可,如何使用也是一个问题.like "%aaa%" 不会使用索引而like "aaa%"可以使用索引. 3.不要在列上进行运算,无法运用索引 select * from users where YEAR(addda

SQL Server优化之SQL语句优化

一切都是为了性能,一切都是为了业务 一.查询的逻辑执行顺序 (1) FROM left_table (3) join_type JOIN right_table (2) ON join_condition (4) WHERE where_condition (5) GROUP BY group_by_list (6) WITH {cube | rollup} (7) HAVING having_condition (8) SELECT (9) DISTINCT (11) top_specific

数据库性能优化之SQL语句优化

一.问题的提出 在应用系统开发初期,由于开发数据库数据比较少,对于查询SQL语句,复杂视图的的编写等体会不出SQL语句各种写法的性能优劣,但是如果将应用系统提交实际应用后,随着数据库中数据的增加,系统的响应速度就成为目前系统需要解决的最主要的问题之一.系统优化中一个很重要的方面就是SQL语句的优化.对于海量数据,劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍,可见对于一个系统不是简单地能实现其功能就可,而是要写出高质量的SQL语句,提高系统的可用性. 在多数情况下,Oracle使用索

数据库性能优化之SQL语句优化1

一.问题的提出 在 应用系统开发初期,由于开发数据库数据比较少,对于查询SQL语句,复杂视图的的编写等体会不出SQL语句各种写法的性能优劣,但是如果将应用系统提交实 际应用后,随着数据库中数据的增加,系统的响应速度就成为目前系统需要解决的最主要的问题之一.系统优化中一个很重要的方面就是SQL语句的优化.对于海 量数据,劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍,可见对于一个系统不是简单地能实现其功能就可,而是要写出高质量的SQL语句,提 高系统的可用性. 在多数情况下,Oracl

[转]数据库性能优化之SQL语句优化1

一.问题的提出 在应用系统开发初期,由于开发数据库数据比较少,对于查询SQL语句,复杂视图的的编写等体会不出SQL语句各种写法的性能优劣,但是如果将应用系统提交实际应用后,随着数据库中数据的增加,系统的响应速度就成为目前系统需要解决的最主要的问题之一.系统优化中一个很重要的方面就是SQL语句的优化.对于海量数据,劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍,可见对于一个系统不是简单地能实现其功能就可,而是要写出高质量的SQL语句,提高系统的可用性. 在多数情况下,Oracle使用索

数据库优化之SQL语句优化-记录

1. 操作符优化 (a) IN 操作符 从Oracle执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别: ORACLE试图将其转换成多个表的连接,如果转换不成功则先执行IN里面的子查询,再查询外层的表记录,如果转换成功则直接采用多个表的连接方式查询.由此可见用IN的SQL至少多了一个转换的过程.一般的SQL都可以转换成功,但对于含有分组统计等方面的SQL就不能转换了. 推荐方案:在业务密集的SQL当中尽量不采用IN操作符,用EXISTS 方案代替. (b) NOT IN操作符 不能应用