本文出自头条号老王谈运维,转载请说明出处. 前言 在DBA的日常工作中,调整个别性能较差的SQL语句是一项富有挑战性的工作.面对慢SQL,一些DBA会心烦,会沮丧,会束手无措,也会沉着冷静.斗智斗勇!当中的关键在于数据库管理员如何分析得出SQL语句的执行计划和如何从SQL语句的执行计划中发现问题. 下面老王就慢SQL的诊断和优化分享一些常用的套路~ 慢SQL诊断 系统层面: 检查系统服务器运行情况,磁盘 I/O 等: 数据库层面: 1.对于MySQL来说,通过慢日志定位慢SQL: 2.对于慢SQ…

温馨提示:本篇内容均来自网上,本人只做了稍微处理,未进行细致研究,仅当做以后不备之需,如若你喜欢可尽情转走. 一.问题的提出 在应用系统开发初期,由于开发数据库数据比较少,对于查询SQL语句,复杂视图的的编写等体会不出SQL语句各种写法的性能优劣,但是如果将应用系统提交实际应用后,随着数据库中数据的增加,系统的响应速度就成为目前系统需要解决的最主要的问题之一.系统优化中一个很重要的方面就是SQL语句的优化.对于海量数据,劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍,可见对于一个系统…

本篇主涉及MySQL SQL Statements层面的优化. 首先,推荐一个链接为万物之始:http://dev.mysql.com/doc/refman/5.0/en/optimization.html 其次,Explain作为分析SQL的优化利器,SHOW STATUS 和 PROCEDURE ANALYSE(16, 256)也蛮有用.推荐两篇MySQL Explain: http://www.khankennels.com/presentations/pdf/explain.pdf ht…

以前刚开始做项目的时候,开发经验尚浅,每次遇到查询比较慢时,项目经理就会问:是不是又用select * 了?查询条件有没有加索引?一语惊醒梦中人,赶紧检查..果然如此! 有时我们写sql语句时,没有考虑它的性能或者完全没有优化意识,虽然能暂时满足基本功能,等到数据量大时,后果可想而知. 下面我们就聊一聊sql优化的一些常见方法: 1. 尽量不要用select * from table,除非需要返回数据库表的全部字段,否则不要返回用不到的任何字段.因为select * 会导致全表扫描,效率比较低.…

explain查询和分析sql 开发中,为满足一业务功能,使用mysql书写sql时,一条sql往往有多种写法,那么我们就需要选择执行效率比较高的sql. 因此要比较分析sql的执行过程,且同一条sql我们要比较选择使用最优索引. 通过explain命令可以得到. 先整体了解下SQL查询的基本执行过程: )应用通过MySQL API把查询命令发送给MySQL服务器,然后被解析 )检查权限.MySQL optimizer进行优化,经过解析和优化后的查询命令被编译为CPU可运行的二进制形式的查询计划…

使用复合索引 如果经常执行如上查询,那么建立三个单独索引不如建立一个复合索引,因为三个单独索引通常数据库每次执行只能使用其中一个,虽然这样比不使用索引而进行全表扫描提高了很多效率,但使用复合索引因为索引本身就对应到三个字段上的,效率会有更大提升. 那么为什么数据库只支持一条查询语句只使用一个索引?简单的讲是因为N个独立索引同时在一条语句使用的效果比只使用一个索引还要慢,开销太大. 在使用索引字段作为条件时,如果该索引是复合索引,那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引,…

1.in与exists的效率比较 in是把外表和内表作hash 连接,而exists 是对外表作loop 循环,每次loop 循环再对内表进行查询.一直以来认为exists 比in 效率高的说法是不准确的.如果查询的两个表大小相当,那么用in 和exists 差别不大. 如果两个表中一个较小,一个是大表,则子查询表大的用exists,子查询表小的用in: 例如: 表A(小表),表B(大表)1: select * from A where cc in (select cc from B)效率低,用…

网上查找的总结: 1.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: select id from t where num is null 2.对查询进行优化,要尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 3.应尽量避免在 where 子句中使用 != 或 <> 操作符,否则将引擎放弃使用索引而进行全表扫描. 4.应尽量避免在 where 子句中使用 or 来连接条件,如果一个字段有索引,…

1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如:select id from t where num is null可以在num上设置默认值0,确保表中num列没有null值,然后这样查询:select id from t where num=0 3.应尽量避免在 where 子句中使用!=或<>操作符,否则引擎将放弃使用…

1.查询的模糊匹配  尽量避免在一个复杂查询里面使用 LIKE '%parm1%'—— 红色标识位置的百分号会导致相关列的索引无法使用,最好不要用. 解决办法: 其实只需要对该脚本略做改进,查询速度便会提高近百倍.改进方法如下: a.修改前台程序——把查询条件的供应商名称一栏由原来的文本输入改为下拉列表,用户模糊输入供应商名称时,直接在前台就帮忙定位到具体的供应商,这样在调用后台程序时,这列就可以直接用等于来关联了. b.直接修改后台——根据输入条件,先查出符合条件的供应商,并把相关记录保存在一…