mysql 案例 ~ 常见案例汇总~2

一 简介: 我们会在此篇文章继续记录日常故障问题

二 案例汇总

     1 sql慢日志出现 administrator command: Prepare; ,时间很长

     分析 : 此场景常见于 PHP相关应用 

     补充基础知识    

     php-pdo 两种prepare模式

　  1. 本地prepare 不会发送给MySQL Server

　  2. 服务器端prepare 会发送给MySQL Server

   2 解决办法  

      PHP将链接模式修改为本地  然后通过mysql查看 show global status like 'Com_stmt_prepare'; ,如果值不再变化,证明修改成功

   总结  

       1. 在服务器端的prepare毕竟有消耗，当并发量大，频繁prepare的时候，就会有性能问题

　　2. 服务端的prepare模式还会带来的另外一个问题就是，排错和slow 优化有困难，因为大部分情况下是看不到真实query的

　　3. 尽量设置php-pdo为 $pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES,true) ，在本地prepare，不要给服务器造成额外压力

  2  mysql 从库错误日志

      日志描述

      Error reading relay log event: slave SQL thread was killed

     Slave SQL thread initialized, starting replication in log

     分析  发生的时段是处于备份时期,经过分析得知与xtrabackup的一个参数 safe-backup有关,不算错误

3  select * from table提示表不存在,但是show tables可以看到

    分析 可能情况有几种
           1 大小写敏感(mysql默认),查询书写的表名和实际表名存在大小写区别
           2 相关查询表存在手动维护,比如直接重命名表,更改文件权限和数组 
           3 ibdata本身可能存在损坏问 题
           4 通过`db.table`方式创建表 
     解决方式

         1 查询的表名和创建的表名一模一样
         2 不要通过`db.table`方式创建表
         3 查询数据库表相关文件,保证和其他数据文件一样
         4 针对ibdata的损坏问题,以下可能是尝试方法
                1 尝试导出导入表空间
                2 尝试通过调整恢复级别导出表
                3 主从复制下进行高可用切换重做主库

          5  可以删除整个库解决问题,如果库本身不重要的话

 4  show processlist出现大量 wait for meta lock

      分析 

       这种情况大概率是由于DDL执行等待引起的,等待MDL锁

       解决方式   通过sql语句查看MDL锁 

      1 查看  metdata_locks的MDL锁持有者

     2 查看   innodb_trx的 MDL锁持有者(极有可能存在未提交的事务,需要注意事务开始的时间)

        启用MDL锁监控 (需要是5.7版本 metadata_locks在5.7版本才会有)

      1 update setup_consumers  set enabled='yes' where name='global_instrumentation'

      2 update setup_instruments  set enabled='yes' where name='wait/lock/metadata/sql/mdl'

      3 通过 select * from metadata_locks查看

转载于:https://www.cnblogs.com/danhuangpai/p/10873766.html