今天项目遇到一个问题:就是在公司test环境中执行sql查询语句很快,也就几百毫秒,但是放到sit环境中测试就要延迟至少1分钟左右。
网上找了很多原因,大多数都是说索引问题,我看了索引没问题,又重新建立索引散列值保证其有效,但是还是不行;
原因:test环境中数据量很少,也就100多条,索引的散列有效值也是100多,但是sit环境中有近4000条数据,自己本身的sql语句中又有子查询+join外连接。我在想是不是sql语句写的有些复杂导致执行变慢。
解决:sql语句优化,尽量不用子查询,我将子查询换成了join外连接查询,完美解决,但是网上的资料对我也有一定帮助,对mysql有进一步的了解。
优化方案1
最近客户提出某些业务查询数据的速度特别慢,而且这种情况来的比较突然。
情况:
1.系统最近没有更新
2.数据库结构没有更改
3.没有大量增加过数据
分析:
1.应用服务器问题:尝试把慢的业务的SQL语句取出到mysql命令行执行,速度依然很慢
2.VPN问题:把业务系统数据导出,再导入到本地数据库运行,速度很快,没有出现上述问题
陷入困境,求教于DBA,DBA也很茫然,查看进程,每次执行那些SQL语句进程占用CPU都非常高;没有错误的日志;MYSQL也运行了2个多月没重启过;硬盘也检查过OK的,也怀疑是raid有问题。
查了这么多也没有找到原因,包括mysql和应用服务器都重启过了。
最后DBA说用Analyze Table的方法看看。
语句是:
ANALYZE TABLE MYTABLE;
运行后,问题解决,速度恢复正常。
MySQL 的在优化SQL语句时,首先需要收集一些相关信息,其中就包括表的cardinality(可以翻译为“散列程度”),它表示某个索引对应的列包含多少个不同的值——如果cardinality大大少于数据的实际散列程度,那么索引就基本失效了。
我们可以使用SHOW INDEX语句来查看索引的散列程度。
TABLE KEY_NAME COLUMN_NAME CARDINALITY
------- -------- ----------- -----------
MYTABLE PRIMARY ORG_ID_FK 10
此时可以看到,MYTABLE 数据有几百,但是CARDINALITY只有10,可见CARDINALITY大大少于数据量,因此这个索引基本起不到作用,例如当查询语句对这个字段用到join连接时,由于索引的失效,查询就会变得很慢。
在使用了ANALYZE TABLE后cardinality被增大到了500,因此查询的性能得到了提高。
优化方案2
- 避免使用select *
- 其他数据库中使用count(1)或count(列) 代替 count(*),而mysql数据库中count(*)经过优化后,效率与前两种基本一样.
- 创建表时尽量时 char 代替 varchar:char表示定长最多可以放255字符,varchar表示变长最多可以存放65532个字符
- 表的字段顺序固定长度的字段优先
- 组合索引代替多个单列索引(经常使用多个条件查询时)
- 使用连接(JOIN)来代替子查询(Sub-Queries)
- 不要有超过4个以上的表连接(JOIN)
- 优先执行那些能够大量减少结果的连接。
- 连表时注意条件类型需一致
- 索引散列值不适合建索引,例:性别不适合
例子:
- like '%xx' select * from tb1 where name like '%cn'; - 使用函数 select * from tb1 where reverse(name) = 'wupeiqi'; - or select * from tb1 where nid = 1 or email = 'seven@live.com'; 特别的:当or条件中有未建立索引的列才失效,以下会走索引 select * from tb1 where nid = 1 or name = 'seven'; select * from tb1 where nid = 1 or email = 'seven@live.com' and name = 'alex' - 类型不一致 如果列是字符串类型,传入条件是必须用引号引起来,不然... select * from tb1 where name = 999; - != select * from tb1 where name != 'alex' 特别的:如果是主键,则还是会走索引 select * from tb1 where nid != 123 - > select * from tb1 where name > 'alex' 特别的:如果是主键或索引是整数类型,则还是会走索引 select * from tb1 where nid > 123 select * from tb1 where num > 123 - order by select email from tb1 order by name desc; 当根据索引排序时候,选择的映射如果不是索引,则不走索引 特别的:如果对主键排序,则还是走索引: select * from tb1 order by nid desc; - 组合索引最左前缀 如果组合索引为:(name,email) name and email -- 使用索引 name -- 使用索引 email -- 不使用索引
优化方案3
查询计划
1,语法格式
explain + 查询SQL - 用于显示SQL执行信息参数,根据参考信息可以进行SQL优化
2,执行计划让mysql预估执行操作一般正确
mysql> explain select * from tb2; +----+-------------+-------+------+---------------+------+---------+------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+------+---------------+------+---------+------+------+-------+ | 1 | SIMPLE | tb2 | ALL | NULL | NULL | NULL | NULL | 2 | NULL | +----+-------------+-------+------+---------------+------+---------+------+------+-------+ 1 row in set (0.00 sec)
type : 查询计划的连接类型, 有多个参数,先从最佳类型到最差类型介绍 性能: null > system/const > eq_ref > ref > ref_or_null > index_merge > range > index > all 慢: explain select * from userinfo where email='alex'; type: ALL(全表扫描) 特别的: select * from userinfo limit 1; 快: explain select * from userinfo where name='alex'; type: ref(走索引) ③EXPLAIN 参数详解:http://www.cnblogs.com/wangfengming/articles/8275448.html
id 查询顺序标识 如:mysql> explain select * from (select nid,name from tb1 where nid < 10) as B; +----+-------------+------------+-------+---------------+---------+---------+------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+------------+-------+---------------+---------+---------+------+------+-------------+ | 1 | PRIMARY | <derived2> | ALL | NULL | NULL | NULL | NULL | 9 | NULL | | 2 | DERIVED | tb1 | range | PRIMARY | PRIMARY | 8 | NULL | 9 | Using where | +----+-------------+------------+-------+---------------+---------+---------+------+------+-------------+ 特别的:如果使用union连接气值可能为null select_type 查询类型 SIMPLE 简单查询 PRIMARY 最外层查询 SUBQUERY 映射为子查询 DERIVED 子查询 UNION 联合 UNION RESULT 使用联合的结果 ... table 正在访问的表名 type 查询时的访问方式,性能:all < index < range < index_merge < ref_or_null < ref < eq_ref < system/const ALL 全表扫描,对于数据表从头到尾找一遍 select * from tb1; 特别的:如果有limit限制,则找到之后就不在继续向下扫描 select * from tb1 where email = 'seven@live.com' select * from tb1 where email = 'seven@live.com' limit 1; 虽然上述两个语句都会进行全表扫描,第二句使用了limit,则找到一个后就不再继续扫描。 INDEX 全索引扫描,对索引从头到尾找一遍 select nid from tb1; RANGE 对索引列进行范围查找 select * from tb1 where name < 'alex'; PS: between and in > >= < <= 操作 注意:!= 和 > 符号 INDEX_MERGE 合并索引,使用多个单列索引搜索 select * from tb1 where name = 'alex' or nid in (11,22,33); REF 根据索引查找一个或多个值 select * from tb1 where name = 'seven'; EQ_REF 连接时使用primary key 或 unique类型 select tb2.nid,tb1.name from tb2 left join tb1 on tb2.nid = tb1.nid; CONST 常量 表最多有一个匹配行,因为仅有一行,在这行的列值可被优化器剩余部分认为是常数,const表很快,因为它们只读取一次。 select nid from tb1 where nid = 2 ; SYSTEM 系统 表仅有一行(=系统表)。这是const联接类型的一个特例。 select * from (select nid from tb1 where nid = 1) as A; possible_keys 可能使用的索引 key 真实使用的 key_len MySQL中使用索引字节长度 rows mysql估计为了找到所需的行而要读取的行数 ------ 只是预估值 extra 该列包含MySQL解决查询的详细信息 “Using index” 此值表示mysql将使用覆盖索引,以避免访问表。不要把覆盖索引和index访问类型弄混了。 “Using where” 这意味着mysql服务器将在存储引擎检索行后再进行过滤,许多where条件里涉及索引中的列,当(并且如果)它读取索引时,就能被存储引擎检验,因此不是所有带where子句的查询都会显示“Using where”。有时“Using where”的出现就是一个暗示:查询可受益于不同的索引。 “Using temporary” 这意味着mysql在对查询结果排序时会使用一个临时表。 “Using filesort” 这意味着mysql会对结果使用一个外部索引排序,而不是按索引次序从表里读取行。mysql有两种文件排序算法,这两种排序方式都可以在内存或者磁盘上完成,explain不会告诉你mysql将使用哪一种文件排序,也不会告诉你排序会在内存里还是磁盘上完成。 “Range checked for each record(index map: N)” 这个意味着没有好用的索引,新的索引将在联接的每一行上重新估算,N是显示在possible_keys列中索引的位图,并且是冗余的。
优化方案4
大数据量分页优化
1,简单粗暴,不允许查询靠后的数据【优先选择】
2,在查询下一页时把上一页的行id作为参数传递给客户端程序,即
select * from tb1 where id>3000000 limit 10;
还有一种方式,比如100页的10条数据
select * from tb1 where id>100*10 limit 10;
3,延迟关联
我们在来分析一下这条语句为什么慢,玄机就处在这个 * 里面,这个表除了id主键肯定还有其他字段, 因为select * 所以mysql在沿着id主键走的时候要回行拿数据,走一下拿一下数据,如果把语句改成
select id from tb1 limit 3000000,10;
你会发现时间缩短了一半;然后我们再拿id分别去取10条数据就行了;
select table.* from tb1 inner join ( select id from tb1 limit 3000000,10 ) as tmp on tmp.id=table.id;
慢查询日志
1、概念
将mysql服务器中影响数据库性能的相关SQL语句记录到日志文件,通过对这些特殊的SQL语句分析,改进以达到提高数据库性能的目的。
2、慢查询日志参数
long_query_time : 设定慢查询的阀值,超出设定值的SQL即被记录到慢查询日志,缺省值为10s slow_query_log : 指定是否开启慢查询日志 log_slow_queries : 指定是否开启慢查询日志(该参数已经被slow_query_log取代,做兼容性保留) slow_query_log_file : 指定慢日志文件存放位置,可以为空,系统会给一个缺省的文件host_name-slow.log log_queries_not_using_indexes: 如果值设置为ON,则会记录所有没有利用索引的查询.
3、查看MySQL慢日志信息
#.查询慢日志配置信息 : show variables like '%query%'; #.修改配置信息 set global slow_query_log = on;
4、查看不使用索引参数状态
# 显示参数
show variables like
'%log_queries_not_using_indexes'
;
# 开启状态
set
global
log_queries_not_using_indexes
=
on;
5、查看慢日志显示的方式
#查看慢日志记录的方式 show variables like '%log_output%'; #设置慢日志在文件和表中同时记录 set global log_output='FILE,TABLE';
6、测试慢查询日志
#查询时间超过10秒就会记录到慢查询日志中 select sleep(3) FROM user ; #查看表中的日志 select * from mysql.slow_log;
char与varchar的区别:https://www.cnblogs.com/webph/p/6679815.html
参考文章:https://www.cnblogs.com/hanbowen/p/9569149.html