MySQL慢查询

是否启用慢查询日志，1为启用，0为禁用

指定慢查询日志文件的路径和名字，可使用绝对路径指定

默认值是'主机名_slow.log'，位于datadir目录

SQL语句运行时间阈值，执行时间大于参数值(单位秒)的语句才会被记录下来

SQL语句检测的记录数少于设定值的语句不会被记录到慢查询日志，即使这个语句执行时间超过了long_query_time的阈值

将没有使用索引的语句记录到慢查询日志，1为启用，0为禁用

5.6版本设定每分钟记录到日志的未使用索引的语句数目，超过这个数目后只记录语句数量和花费的总时间<br>mariadb没有这个参数

5.6版本记录执行缓慢的DDL语句，如alter table,analyze table, check table, create index, drop index, optimize table, repair table等。<br>mariadb没有这个参数<br>

5.7版本新增时间戳所属时区参数

5.6版本记录从库上执行的慢查询语句<br>mariadb没有这个参数<br>

默认值：记录UTC时区的时间戳到慢查询日志

推荐值：system，应修改为记录系统时区

mariadb没有这个参数

指定慢查询日志的输出方式，从5.5版本开始可以记录到日志文件(FILE，慢查询日志)和数据库表(TABLE，mysql.slow_log)中

推荐值：FILE,TABLE

mysqldumpslow [ OPTS... ] [ LOGS... ]

-s 表示按照何种方式排序<br><ul><li> c 访问次数</li><li> l 锁定时间</li><li> r 返回记录</li><li> t 查询时间</li><li> al 平均锁定时间</li><li> ar 平均返回记录数</li><li> at 平均查询时间</li></ul>-t 返回前面多少条数据<br>-g 后边搭配一个正则匹配模式，大小写不敏感

得到返回记录集最多的10条SQL：

得到访问次数最多的10条SQL：

得到按照时间排序的前10条里面含有左连接的SQL：

也支持管道符命令

pt-query-digest [OPTIONS] [FILES] [DSN]

--create-review-table 当使用--review参数把分析结果输出到表中时，如果没有表就自动创建。<br>--create-history-table 当使用--history参数把分析结果输出到表中时，如果没有表就自动创建。<br>--filter 对输入的慢查询按指定的字符串进行匹配过滤后再进行分析<br>--limit限制输出结果百分比或数量，默认值是20,即将最慢的20条语句输出，如果是50%则按总响应时间占比从大到小排序，输出到总和达到50%位置截止。<br>--host mysql服务器地址<br>--user mysql用户名<br>--password mysql用户密码<br>--history 将分析结果保存到表中，分析结果比较详细，下次再使用--history时，如果存在相同的语句，且查询所在的时间区间和历史表中的不同，则会记录到数据表中，可以通过查询同一CHECKSUM来比较某类型查询的历史变化。<br>--review 将分析结果保存到表中，这个分析只是对查询条件进行参数化，一个类型的查询一条记录，比较简单。当下次使用--review时，如果存在相同的语句分析，就不会记录到数据表中。<br>--output 分析结果输出类型，值可以是report(标准分析报告)、slowlog(Mysql slow log)、json、json-anon，一般使用report，以便于阅读。<br>--since 从什么时间开始分析，值为字符串，可以是指定的某个”yyyy-mm-dd [hh:mm:ss]”格式的时间点，也可以是简单的一个时间值：s(秒)、h(小时)、m(分钟)、d(天)，如12h就表示从12小时前开始统计。<br>--until 截止时间，配合—since可以分析一段时间内的慢查询。

索引缺失

索引重复

索引过多

索引优化

索引未使用

索引匹配度问题

由于更新删除比较多，数据库中的表的估计行数和实际行数已经不一致。<br>这个时候需要对数据库的统计信息进行重新计算，主要是重新排列表的数据存储，减小碎片率。<br>数据的存储空间会变少，查询性能也会有一定的提高。

mysql数据库的删除其实在数据底层，不是物理删除，是会先打一个删除标记。再通过其他进程来定时删除物理存储的。<br>所以大批量的删除，是不能实时的减小表的空间的。

举例：查询时把int类型和varchar类型的数字关联错误，导致字段隐式转换

select colID,name,smIconID,extend as singerID<br>from col<br>where colType = 2 and extend = 733570<br>limit 1

extend是varchar类型，不能用直接和int类型相等，会涉及到数据类型的隐式转换，导致无法使用索引，改写sql

大批量的更新时尽量使用主键进行查找

select count(*) from sys_msg_log<br> where cmd != 'CMD_USER' and cmd != 'CMD_SUB_GUIDE' and cmd != 'CMD_UPDATE_APP' and cmd != 'CMD_IMEI'<br> and cmd not in <br> ( <br> 'CMD_NOTIFY'<br> , <br> 'CMD_USER'<br> )

这里cmd是否可以改成等于或者in条件，然后加上cmd索引就可以用上了。

低版本的mysql中，对索引字段的倒序排序，会导致无法有效使用索引，从正常的内存排序降级为文件排序了<br>

select m.musicID,m.name,m.albumt,m.cover,m.addDate,s.name as singerNames<br> from music m LEFT JOIN singer s ON m.singerID = s.singerID<br> where m.status = 1 and m.cpID = 15531 <br> order by m.musicID desc<br> limit 0,5

对于唯一索引，需要判断是否需要，唯一索引对于插入的性能影响是最大的，每次单条插入都需要匹配全表查询唯一性。<br>考虑具体业务规划，唯一性约束通过业务逻辑实现，将数据库端的唯一索引降级为普通的单列索引或者复合索引。

当前表只有1行数据，总计有20,942,177次调用。<br>单行数据的超多次调用，考虑是否为静态资源，可以弄到缓存中<br>

SELECT taskID<br>FROM daily_tasks

当前状态：imei，varchar(100)，的唯一索引<br>注：imei,国际移动设备识别码，由15位数字组成，有些手机是17位，多出来的2个用于记录软件版本。<br>

SELECT id<br>FROM fcm_token0<br>WHERE imei = ?