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

你可能感兴趣的:(mysql 案例 ~ 常见案例汇总~2)