[作者] 王栋:携程技术保障中心数据库专家,对数据库疑难问题的排查和数据库自动化智能化运维工具的开发有强烈的兴趣. [问题描述] 最近有一台MySQL5.6.21的服务器,在应用发布后,并发线程Threads_running迅速升高,达到2000左右,大量线程处于等待Opening tables.closing tables状态,应用端相关逻辑访问超时. [分析过程] 1.16:10应用发布结束后,Opened_tables不断增加,如下图所示: 查看当时故障期间抓取的pt-stalk日志文件,

mysqladmin showprocesslist可查看完整sql需要权限. SHOW PROCESSLIST显示哪些线程正在运行.您也可以使用mysqladmin processlist语句得到此信息.如果您有SUPER权限,您可以看到所有线程.否则,您只能看到您自己的线程(也就是,与您正在使用的MySQL账户相关的线程).请参见13.5.5.3节,“KILL语法”.如果您不使用FULL关键词,则只显示每个查询的前100个字符. 本语句报告TCP/IP连接的主机名称(采用host_name:

processlist命令的输出结果显示了有哪些线程在运行,可以帮助识别出有问题的查询语句,两种方式使用这个命令. 1. 进入MySQL/bin目录下输入mysqladmin processlist; 2. 启动mysql,输入show processlist; 如果有 SUPER 权限,则可以看到全部的线程,否则,只能看到自己发起的线程(这是指,当前对应的MySQL帐户运行的线程). 得到数据形式如下(只截取了三条): mysql> show processlist; +-----+-----

前一篇文章我们分析了Performance-Schema中每个表的用途,以及主要字段的含义,比较侧重于理论的介绍.这篇文章我主要从DBA的角度出发,详细介绍如何通过Performance-Schema得到DBA关心的数据,比如哪个SQL执行次数最多,哪个表访问最频繁,哪个锁最热等信息.通过充分利用Performance-Schema表的数据,让DBA更了解DB的运行状态,也更有助于排查定位问题.本文主要从两方面展开讨论,第一方面是统计信息维度,包括SQL维度,对象维度和等待事件维度三小点:第二方

转自http://blog.itpub.net/22664653/viewspace-1210844/  [MySQL]性能优化之 Index Condition Pushdown2014-07-06 21:25:57 分类: MySQL 一 概念介绍    Index Condition Pushdown (ICP)是MySQL 5.6 版本中的新特性,是一种在存储引擎层使用索引过滤数据的一种优化方式.a 当关闭ICP时,index 仅仅是data access 的一种访问方式,存储引擎通过索

网站运行很慢的时候,我就特别起知道为什么这么慢,所以我查啊查,数据库绝对是很重要的一部分,里面运行的sql是绝对不能放过的.平时做项目的时候,我也会注意sql语句的书写,写出一些高效的sql来,所以我会经常测试自己写的sql语句.我把我知道的二个方法,总结一下发出来. 一,show profiles 之类的语句来查看 ,查一下profile是不是打开了,默认是不打开的. mysql> show profiles; Empty set (0.02 sec) mysql> show variabl

SQL优化 1.查看各种SQL执行的频率 mysql> show status like 'Com_select';--Com_insert,Com_delete,connections(试图连接mysql服务的次数),uptime(mysql工作时间),slow_queries(慢查询次数)等等 2.定位执行效率较低的SQL语句 通过慢查询日志,定位查询效率低下的SQL语句,然后分析语句进行优化 3.通过explain或desc分析SQL语句的执行计划,如要查看所访问的分区使用explain

show processlist; 命令的输出结果显示了有哪些线程在运行,可以帮助识别出有问题的查询语句,两种方式使用这个命令. 方式1:进入mysql/bin目录下输入mysqladmin processlist; 方式2:启动mysql,输入show processlist; 如果有SUPER权限,则可以看到全部的线程,否则,只能看到自己发起的线程(这是指,当前对应的MySQL帐户运行的线程). 每列的作用: id:不用说了吧,一个标识,你要kill一个语句的时候很有用. user:显示单前

背景: MySQL 5.5开始新增一个数据库:PERFORMANCE_SCHEMA,主要用于收集数据库服务器性能参数.并且库里表的存储引擎均为PERFORMANCE_SCHEMA,而用户是不能创建存储引擎为PERFORMANCE_SCHEMA的表.MySQL5.5默认是关闭的,需要手动开启,在配置文件里添加: [mysqld] performance_schema=ON 查看是否开启: mysql>show variables like 'performance_schema'; +------

背景: 继上次介绍 初识 MySQL 5.6 新功能.参数完之后,刚好MySQL 5.7又GA了,在官方测试里看到,MySQL5.7在功能.性能.可用性.安全和监控上又提升了很高.现在看看和MySQL5.6对比,之前介绍了新增配置参数和安全相关特性.本文来说明MySQL5.7关于功能和性能提升的方面(持续更新). 1,功能性能上的提升 1.1:复制功能的提升. ①支持并行复制.slave-parallel-type 5.6开始支持基于库(database)的并行复制,对于只有一个库的,效果不好.

在某些数据访问层框架中,会使用show full tables from test like 'demo',来检查数据库的状态.当数据库中表的数量较少时,并没有出现严重的问题.但是当数据库中的表数量多余千个时,且并发数较高时,通过show processlist就会发现show full tables语句绝大部分处于checking permissions状态 | 2 | test | 192.168.15.128:57656 | NULL | Query | 0 | checking perm

一.MySQL数据库有几个配置选项可以帮助我们及时捕获低效SQL语句 1,slow_query_log这个参数设置为ON,可以捕获执行时间超过一定数值的SQL语句. 2,long_query_time当SQL语句执行时间超过此数值时,就会被记录到日志中,建议设置为1或者更短. 3,slow_query_log_file记录日志的文件名. 4,log_queries_not_using_indexes这个参数设置为ON,可以捕获到所有未使用索引的SQL语句,尽管这个SQL语句有可能执行得挺快. 二

1.查看profile的设置 SHOW VARIABLES LIKE '%profil%' 结果如下:profiling OFF 为关闭状态 2.开启profile 结果: 3.执行需要执行的sql explain   select*........ 4.查询执行的sql SHOW PROFILES 结果: 5.查看需要的sql执行详细信息 SHOW PROFILE 结果: SHOW profile cpu,MEMORY 结果: SHOW profile 结果: status: hecking

首先我们来说下in()这种方式的查询 在<高性能MySQL>里面提及用in这种方式可以有效的替代一定的range查询,提升查询效率,因为在一条索引里面,range字段后面的部分是不生效的.使用in这种方式其实MySQL优化器是转化成了n*m种组合方式来进行查询,最终将返回值合并,有点类似union但是更高效. 同时它存在这一些问题:老版本的MySQL在IN()组合条件过多的时候会发生很多问题.查询优化可能需要花很多时间,并消耗大量内存.新版本MySQL在组合数超过一定的数量就不进行计划评估了,

ACCOUNTS NOT PROPERLY CLOSING CONNECTIONS [ 1 ] Works since 5.6 SELECT ess.user, ess.host , (a.total_connections - a.current_connections) - ess.count_star as not_closed , ((a.total_connections - a.current_connections) - ess.count_star) * 100 / (a.tot

mysql的 profiling不是默认打开的 查看profiling是否找开 mysql> show variables like "%pro%"; +---------------------------+-------+ | Variable_name | Value | +---------------------------+-------+ | profiling | OFF | | | | slave_compressed_protocol | OFF | +---

上一篇<mysql metadata lock(一)>介绍了为什么引入MDL,MDL作用以及MDL锁导致阻塞的几种典型场景,文章的最后还留下了一个小小的疑问.本文将更详细的介绍MDL,主要侧重介绍MDL的原理和实现.一般而言,商业数据库系统实现锁,一般将锁划分为读锁(共享锁)和写锁(排它锁),为了进一步提高并发性,还会加入意向共享锁和意向排它锁.但是偏偏mysql的MDL搞地比较复杂,但目的也是为了提高并发度.MDL包含有9种类型,详细参考表1.主要其实也是两大类,只是对共享锁做了进一步细分.

想必玩过mysql的人对Waiting for table metadata lock肯定不会陌生,一般都是进行alter操作时被堵住了,导致了我们在show processlist 时,看到线程的状态是在等metadata lock.本文会对mysql 的metadata lock做一个小小的总结,希望对大家有所帮助. MDL是在5.5才引入到mysql,之前也有类似保护元数据的机制,只是没有明确提出MDL概念而已.但是5.5之前版本(比如5.1)与5.5之后版本在保护元数据这块有一个显著的不

转自:http://ctripmysqldba.iteye.com/blog/1938150 (有修改) MySQL在进行alter table等DDL操作时,有时会出现Waiting for table metadata lock的等待场景.而且,一旦alter table TableA的操作停滞在Waiting for table metadata lock的状态,后续对TableA的任何操作(包括读)都无法进行,因为他们也会在Opening tables的阶段进入到Waiting for