‘壹’ mysql查看sql执行效率
Explain命令在解决数据库性能上是第一推荐使用命令，大部分的性能问题可以通过此命令来简单的解决，Explain可以用来查看 SQL 语句的执行效 果，可以帮助选择更好的索引和优化查询语句，写出更好的优化语句。
Explain语法：explain select … from … [where ...]
例如：explain select * from 表名;
‘贰’ 一般mysql超过多长时间，会被认为是慢查询
肯定影响的。
常见查询慢的原因常见的话会有如下几种：
1、没有索引或没有用到索引。
PS：索引用来快速地寻找那些具有特定值的记录，所有MySQL索引都以B-树的形式保存。如果没有索引，执行查询时MySQL必须从第一个记录开始扫描整个表 的所有记录，直至找到符合要求的记录。表里面的记录数量越多，这个操作的代价就越高。如果作为搜索条件的列上已经创建了索引，MySQL无需扫描任何记录 即可迅速得到目标记录所在的位置。如果表有1000个记录，通过索引查找记录至少要比顺序扫描记录快100倍。
索引类型：
普通索引：这是最基本的索引类型，没唯一性之类的限制。
唯一性索引：和普通索引基本相同，但所有的索引列只能出现一次，保持唯一性。
主键：主键是一种唯一索引，但必须指定为"PRIMARY KEY"。
全文索引：MYSQL从3.23.23开始支持全文索引和全文检索。在MYSQL中，全文索引的索引类型为FULLTEXT。全文索引可以在VARCHAR或者TEXT类型的列上创建。
2、IO吞吐量小形成了瓶颈。
PS：这是从系统层来分析MYSQL是比较耗IO的。一般数据库监控也是比较关注IO。
监控命令：$iostat -d -k 1 10
参数 -d 表示，显示设备（磁盘）使用状态；-k某些使用block为单位的列强制使用Kilobytes为单位；1 10表示，数据显示每隔1秒刷新一次，共显示10次。
‘叁’ MySQL怎么查询比较耗时的sql语句
开启慢查询日志即可
文件方式配置
MySQL
慢查询的方法：
在
mysql
配置文件
my.cnf
中增加：
log-slow-queries=/opt/data/slowquery.log
long_query_time=2
log-queries-not-using-indexes
命令方式配置
MySQL
慢查询的方法：
set
global
slow_query_log=on;
set
global
long_query_time=1;
set
global
slow_query_log_file=‘/opt/data/slow_query.log’;
查询
MySQL
慢查询状态的方法：
SHOW
VARIABLES
LIKE
'%query%';
解析
MySQL
慢查询日志的方法：
按照
sql
执行时间最长的前
20
条
sql：
mysqlmpslow
-s
t
-t
20
-g
'select'
/opt/data/slowquery.log
‘肆’ 在MySQL 中，哪些原因导致一条简单的 SQL 插入耗时很长
Count: 6 Time=25.33s (152s) Lock=0.00s (0s) Rows=0.0 (0), xxx[xxx]@xxx
INSERT INTO tablename(f_uid,uid,create_time) VALUES (N,N,N)
分析原因如下：
1.不可能是锁等待，因为记录的Lock时间为0；
2.若是InnoDB引擎，则跟主键为啥存在一定关系，但是应该不是特别大，从你的SQL语句看；
3.数据库主机的负载过高，导致处理不过，是最可能的原因；
‘伍’ mysql如何优化以下语句，查询耗时太久了
一般进行性能分析，分如下三步：
首先需要使用慢查询日志功能，去获取所有查询时间比较长的SQL语句
其次查看执行计划查看有问题的SQL的执行计划 explain
最后可以使用show profile查看有问题的SQL的性能使用情况
慢查询日志分析
首先我们要使用慢查询日志，因为它收集了查询时间比较长的SQL语句，但使用之前必须开启慢查询日志，在配置文件my.cnf（一般为/etc/my.cnf）中的[mysqld] 增加如下参数：
slow_query_log=ONlong_query_time=3slow_query_log_file=/var/lib/mysql/slow-log.log复制代码
增加这些参数之后，重启MySQL，可以进行查询慢查询日志是否开启。
1. 任何地方都不要使用 select * from t，用具体的字段列表代替“*“，不要返回用不到的任何字段。
2. 索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。
3. 并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。
4. 尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
5. 尽可能的使用 varchar 代替 char ，因为首先变长字段存储空间小，可以节省存储空间， 其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
6. 如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。
7. 对查询进行优化，应尽量避免全表扫描，首先应考虑在 where和order by相关的列上建立索引。
8. 应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描。
例如： select * from t where num is null
我们可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：select * from t where num=0。
‘陆’ mysql中sql语句执行时间怎么看
右下角的时间是从点击查询到输出查询结果的总时间，而profile中的是收集在执行语句的时候所使用的资源，包括执行sql时完整的数据查询逻辑明细及耗时时间，其中包含查询语句执行时间、索引排序时间、查询结果展示时间等
‘柒’ mysql数据库性能下降,想找到哪些sql耗时较长,应该如何操作
1、show processlist;
2、select * from information_schema.processlist ;
3、可以在[mysqld]中添加如下：
log =/var/log/mysql.log
如果需要监控慢查询可以添加如下内容：
log-slow-queries = /var/log/slowquery.log
long_query_time = 1
‘捌’ 请教：mysql 运行一段时间后速度变慢问题
我们先来看第一个阶段，MySQL慢的诊断思路，一般我们会从三个方向来做：
第一个方向是MySQL内部的观测
第二个方向是外部资源的观测
第三个方向是外部需求的改造
1.1 MySQL 内部观测
我们来看MySQL内部的观测，常用的观测手段是这样的，从上往下看，第一部分是Processlist，看一下哪个SQL压力不太正常，第二步是explain，解释一下它的执行计划，第三步我们要做Profilling，如果这个SQL能再执行一次的话, 就做一个Profilling，然后高级的DBA会直接动用performance_schema ，MySQL 5.7 以后直接动用sys_schema，sys_schema是一个视图，里面有便捷的各类信息，帮助大家来诊断性能。再高级一点，我们会动用innodb_metrics进行一个对引擎的诊断。
除了这些手段以外，大家还提出了一些乱七八糟的手段，我就不列在这了，这些是常规的一个MySQL的内部的状态观测的思路。除了这些以外，MySQL还陆陆续续提供了一些暴露自己状态的方案，但是这些方案并没有在实践中形成套路，原因是学习成本比较高。
1.2 外部资源观测
外部资源观测这部分，我引用了一篇文章，这篇文章的二维码我贴在上面了。这篇文章是国外的一个神写的，标题是：60秒的快速巡检，我们来看一下它在60秒之内对服务器到底做了一个什么样的巡检。一共十条命令，这是前五条，我们一条一条来看。
1.uptime，uptime告诉我们这个机器活了多久，以及它的平均的负载是多少。
2.dmesg -T | tail，告诉我们系统日志里边有没有什么报错。
3.vmstat 1，告诉我们虚拟内存的状态，页的换进换出有没有问题，swap有没有使用。
4. mpstat -P ALL，告诉我们CPU压力在各个核上是不是均匀的。
5.pidstat 1，告诉我们各个进程的对资源的占用大概是什么样子。
我们来看一下后五条：
首先是iostat-xz 1，查看IO的问题，然后是free-m内存使用率，之后两个sar，按设备网卡设备的维度，看一下网络的消耗状态，以及总体看TCP的使用率和错误率是多少。最后一条命令top，看一下大概的进程和线程的问题。
这个就是对于外部资源的诊断，这十条命令揭示了应该去诊断哪些外部资源。
1.3 外部需求改造
第三个诊断思路是外部的需求改造，我在这里引用了一篇文档，这篇文档是MySQL的官方文档中的一章，这一章叫Examples of Common Queries，文档中介绍了常规的SQL怎么写, 给出了一些例子。文章的链接二维码在slide上。
我们来看一下它其中提到的一个例子。
它做的事情是从一个表里边去选取，这张表有三列，article、dealer、price，选取每个作者的最贵的商品列在结果集中，这是它的最原始的SQL，非常符合业务的写法，但是它是个关联子查询。
关联子查询成本是很贵的，所以上面的文档会教你快速地把它转成一个非关联子查询，大家可以看到中间的子查询和外边的查询之间是没有关联性的。
第三步，会教大家直接把子查询拿掉，然后转成这样一个SQL，这个就叫业务改造，前后三个SQL的成本都不一样，把关联子查询拆掉的成本，拆掉以后SQL会跑得非常好，但这个SQL已经不能良好表义了，只有在诊断到SQL成本比较高的情况下才建议大家使用这种方式。
为什么它能够把一个关联子查询拆掉呢？
这背后的原理是关系代数，所有的SQL都可以被表达成等价的关系代数式，关系代数式之间有等价关系，这个等价关系通过变换可以把关联子查询拆掉。
上面的这篇文档是一个大学的教材，它从头教了关于代数和SQL之间的关系。然后一步步推导怎么去简化这句SQL。
第一，MySQL本身提供了很多命令来观察MySQL自身的各类状态，大家从上往下检一般能检到SQL的问题或者服务器的问题。
第二，从服务器的角度，我们从巡检的脚本角度入手，服务器的资源就这几种，观测手法也就那么几种，我们把服务器的资源全部都观察一圈就可以了。
第三，如果实在搞不定，需求方一定要按照数据库容易接受的方式去写SQL，这个成本会下降的非常快，这个是常规的MySQL慢的诊断思路。
‘玖’ MySQL等数据库读取插入的耗时比较，哪种操作耗时较久
对于正常情况的表（主要是建立了合适的索引），写入要比读取快许多倍。如果索引建立得不合适，例如缺少必要的索引，那么查询速度会变慢，例如过度建立了多余的索引，插入数据会变慢。