ICP是当你有除了索引以外的筛选条件的时候，innodb层对非索引条件进行筛选。

1、mysqldump是单线程的。2、mysqlpump可以多线程并行，可以试试。

1、实例启动需要划分内存、启动进程，参数文件记录了内存sga、pga的分配情况、实例名等，这对于内存划分和进程启动至关重要。2、参数文件记录了控制文件的位置，后续数据库的挂载和打开需要控制文件信息。

导出的时候看看等待事件，有的时候存在bug啥的可能导致导出时间特别长

1、根据position和binlog，解析下binlog，看看这条数据2、拿着数据去备库表里找这条数据，如果没有，说明主从不一致了，可以选择跳过，或者补录3、如果有这条数据，那确认下这个表是否有主键，如果没有主键，可以看看这篇文章：https://www.modb.pro/db/646009

数据库一般都是大io的，内存使用率百分之90，大概率是有大量内存被用来作为io的cache了，可以重启下os。或者看看到底哪个进程占用的内存最多，11g一般没有bug进程占用大内存

600和7445一般就是上mos上搜索，这是oracle的内部错误，一般是bug，拿着报错码去网上找或者去mos上找

1、是不是sid、service、ip不对，2、监听没启动

mysql没办法绑定执行计划，不到1g的安装包，没那么多功能

adg吧，

analyze会删除表缓存中的表定义信息，需要做flush table操作，如果当前有查询或事务在表上，analyze有可能会被堵塞，继而堵塞后续的操作，ananlyze本身执行很快。

直接清空文件即可，不用删除   echo ' '> alert.log echo ' '> trc 

需要看看半同步怎么配置的，有的是配置的可以自动降级成异步，对主库没啥影响，有的配置是不自动降级，这种情况下主库就一直等备库的恢复，整个主库就会夯。

应该是开了类似ogg这种同步工具了

可以手动收集一下，把采样比设的低一些，大表设置增量收集。

阔以

mysql这种很少用压缩表的，读写占用增加cpu的负担不说，这里面会不会有未知的bug就难以预料了。

看看同义词

select for update 执行计划走的全表扫描，mysql就会锁全表update 走的是主键索引，在rc模式下，就锁单个记录。

技术上可以，管理上不行

楼上说的对，using index condition是索引下推，说明首先a=100用到了索引，b>200在innodb层进行了筛选，没有到server层筛选。

1）表大于_small_table_threshold的参数值设置2）表上的脏块小于表总block数的25%3）表中的块被cache的比例小于50%的时候

这个保留几天能有啥合理不合理的，有资源的就多保留几天，没资源想干掉就少保留两天。

你这报告跨度时间太久了，无用信息太多，最好是拿有问题的1h，跟正常时段的1h。

把卡顿时间段的awr和ash拿出来看看。

兄弟，你这个awr时间这么久，意义不大的哈，拿问题时段的一个小时的就ok

5.7都停服了，新的还是上8.0吧，别用最新，用次新。

//查看保护模式select database_role,protection_mode,protection_level from v$database;//查看是否实时应用set linesize 300col dest_name for a30col database_mode for a30select dest_id,dest_name,DATABASE_MODE,PROTECTION_

死锁是由于多个会话互相争抢对方持有的资源导致的，一般是应用逻辑问题或者持有锁的时间过长导致的。1、确保应用逻辑无问题2、优化事务持有锁的时间，大事务拆分成小事务。3、使用RC隔离级别，尽量不要使用RR隔离级别。

你可以试试加个组合索引：（area_code，isVideo，tagcode），

试试v$active_session_history，如果这个没有，那就是没采样到

1、备库设置下readonly看看是不是有人在备库删了数据2、表要设置主键，对于mysql8.0，如果表没有主键，在备库上可能会出现重放的时候找不到数据的情况。这还是备库重放算法决定的。

兄弟，你的配置非常牛逼啊，我看各类事件等待都很短，有一个点哈，你的buffer hit命中率比较低，另外pga也不大，可以试试把这两个值调大一些。另外如果是只有极短的时间卡顿的话，1小时的awr报告可能看不出来，可以拿ash或者v$ash看下。

光看TOP等待事件的时间就不正常：Top5平均都几十ms。排名第一的直接路径读，这种是直接绕过SGA，从磁盘读数据块到PGA，看看top sql里是不是有全表的或者大排序的。排名第三的log file sync，这个事件的子事件log file parallel write 平均等待事件都快20ms，这说明你磁盘io不行，看看是不是io有问题了。

你把awr和ash发上来，看下

应该是防火墙超时，对长连接进行断开了

兄弟，参考我这篇文章：https://www.modb.pro/db/515025

awr报告一般就看一个小时，半个小时的，你这十几个小时的，所有的指标都被平均了，没意义的。拿一个高负载时段的报告来看。

第一阶段参数文件  第二阶段控制文件

日志太粗了，把对应进程的日志发出来看看。

1、首先keepalive跨网段是不是支持切换，取决于网络配置2、基于mysql的自动切换比较简单的就是mha，还是开源的。3、单纯基于keepalive做的mysql自动切换是无法保证数据一致性的，keepalive是无状态的。4、业务量不大，又不想浪费资源，直接弄个主从复制得了，出问题了手动切换，

这是没正常启动吧

这是语法错误，