CA一体机性能优化实操
先查询mysql常见问题
#查询连接线程数
SHOW GLOBAL STATUS LIKE 'Threads_connected';
#查询最大线程数
show variables like '%max_connections%'
#查询正在执行sq
SHOW FULL PROCESSLIST;l
发现问题
发现ca与km表在记录协议日志时候比较慢，还有执行+1时候比较慢。
-- 查询ca表sql平均执行时间
SELECT
SCHEMA_NAME,
DIGEST_TEXT,
AVG_TIMER_WAIT / 1e6 AS "Average Execution Time (ms)"
FROM
performance_schema.events_statements_summary_by_digest
WHERE SCHEMA_NAME = 'testcadb' and SUM_TIMER_WAIT > 1000000
ORDER BY
AVG_TIMER_WAIT DESC ;
-- 查询km表sql平均执行时间
SELECT
SCHEMA_NAME,
DIGEST_TEXT,
AVG_TIMER_WAIT / 1e6 AS "Average Execution Time (ms)"
FROM
performance_schema.events_statements_summary_by_digest
WHERE SCHEMA_NAME = 'testkmdb' and SUM_TIMER_WAIT > 1000000
ORDER BY
AVG_TIMER_WAIT DESC ;
确定问题点：
ca主要问题在记录协议日志：用时一个sql平均1秒执行完成。
km主要问题在记录密钥数量+1 等待时间较长，同时存储协议日志也较慢。
处理问题
1.开启配置：协议日志可根据配置是否记录（后期可发送统一记录，一次性记录1000条）。
2.km记录密钥：减少行锁时间。 方法一：一次性记录更多。 方法二：交由服务统一处理。
总结
如遇到数据实时性不需要那么强的时候，统一处理可以减少数据库压力，特别是垃圾服务器。
其他常用命令
1.最大连接数
show variables like ‘%max_connections%’
2.修改最大线程数
set GLOBAL max_connections = 200;
2.线程配置
SHOW STATUS LIKE ‘Threads%’
3.自增锁的值保存位置
InnoDB引擎的自增值，在MySQL5.7及之前的版本，自增值保存在内存里，并没有持久化。每次重启后，第一次打开表的时候，都会去找自增值的最大值max(id)，然后将max(id)+步长作为这个表当前的自增值
select max(id) from table_name for update;
4.自增id锁并不是一个事务锁，而是每次申请完就马上释放，以便允许别的事务再申请。
但在MySQL5.0版本的时候，自增锁的范围是语句级别。也就是说，如果一个语句申请了一个表自增锁，这个锁会等语句执行结束以后才释放
MySQL5.1.22版本引入了一个新策略，新增参数innodb_autoinc_lock_mode，默认值是1
1.这个参数设置为0，表示采用之前MySQL5.0版本的策略，即语句执行结束后才释放锁。
2.这个参数设置为1。
普通insert语句，自增锁在申请之后就马上释放 。
类似insert … select这样的批量插入数据的语句，自增锁还是要等语句结束后才被释放。
3.这个参数设置为2，所有的申请自增主键的动作都是申请后就释放锁。
所以当发生主键冲突和事务回滚都会导致自增主键id不连续的情况。
评论区