在优化MySQL时,通常需要对数据库进行分析,常见的分析手段有慢查询日志,EXPLAIN 分析查询,profiling分析以及show命令查询系统状态及系统变量,通过定位分析性能的瓶颈,才能更好的优化数据库系统的性能。
1 慢查询日志
MySQL 的慢查询日志用来记录在 MySQL 中响应时间超过阈值的语句,具体指运行时间超过long_query_time值的 SQL,则会被记录到慢查询日志中
● long_query_time的默认值为10,意思是运行10秒以上的语句。
● 默认情况下,MySQL数据库没有开启慢查询日志,需要手动设置参数开启
------------------------------------------------
修改配置文件my.cnf或my.ini,在[mysqld]一行下面加入两个配置参数
[mysqld]
slow_query_log = ON
slow_query_log_file = /var/lib/mysql/hostname-slow.log
long_query_time = 3
在生产环境中,如果手工分析日志,查找、分析SQL,还是比较费劲的,所以MySQL提供了日志分析工具mysqldumpslow。
2 Explain(执行计划)
使用 Explain 关键字可以模拟优化器执行SQL查询语句,从而知道 MySQL 是如何处理你的 SQL 语句的。分析你的查询语句或是表结构的性能瓶颈
3 Show Profile 分析查询
Show Profile 是 MySQL 提供可以用来分析当前会话中语句执行的资源消耗情况。可以用于SQL的调优的测量。默认情况下,参数处于关闭状态,并保存最近15次的运行结果 .
1、先运行看看是否真的很慢,注意设置SQL_NO_CACHE
2、where条件单表查,锁定最小返回记录表。这句话的意思是把查询语句的where都应用到表中返回的记录数最小的表开始查起,单表每个字段分别查询,看哪个字段的区分度最高
3、explain查看执行计划,是否与1预期一致(从锁定记录较少的表开始查询)
4、order by limit 形式的sql语句让排序的表优先查
5、了解业务方使用场景
6、加索引时参照建索引的几大原则
7、观察结果,不符合预期继续从0分析
① 尽可能的使用复合索引而不是索引的组合;
②创建索引尽量让辅助索引进行索引覆盖 而不是回表;
③在可以使用主键id的表中,尽量使用自增主键id,这样可以避免页分裂;
④查询的时候尽量不要使用select * ,这样可以避免大量的回表;
⑤尽量少使用子查询,能使用外连接就使用外连接,这样可以避免产生笛卡尔集;
⑥能使用短索引就是用短索引,这样可以在非叶子节点存储更多的索引列降低树的层高,并且减少空间的开销;
(1)Where子句中:where表之间的连接必须写在其他Where条件之前,那些可以过滤掉最大数量记录的条件必须写在Where子句的末尾.HAVING最后。
(2)用EXISTS替代IN、用NOT EXISTS替代NOT IN。
(3)避免在索引列上使用计算
(4)避免在索引列上使用IS NULL和IS NOT NULL
(5)对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。
(6)应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描
(7)应尽量避免在 where 子句中对字段进行表达式操作,这将导致引擎放弃使用索引而进行全表扫描
首先对于索引的维护来说是需要成本的,我们对数据的增/删/修改,删除,都会产生额外的对索引文件的操作,这些操作需要消耗额外的IO,会降低增/改/删的执行效率。所以,在我们删除数据库百万级别数据的时候,删除数据的速度和创建的索引数量是成正比的,如果直接删除很可能会产生中断情况,所以我们想要删除百万数据的时候可以做如下操作:
1. 先删除索引(此时大概耗时三分多钟)
2. 然后删除其中无用数据(此过程需要不到两分钟)
3. 删除完成后重新创建索引(此时数据较少了创建索引也非常快,约十分钟左右)