MySQL运维的一款利器sys schema
MySQL运维中有很多的工具,就好比你进了一个杂货铺,各种运维中的小技巧几乎都有一些小工具, 走一圈发现真是琳琅满目,可见MySQL充分享受了开源社区的红利。
而比较特别的一点是MySQL社区中,官方提供的工具在以前不会成为市面上的拳头产品,有些甚至维护一段之后就没有深入维护了。所以走一圈发现,MySQL很多实用成熟的工具都来自于社区,而官方推出的一些工具不是因为企业版的限制就是功能的不成熟而被有限使用。
当然不一而论,在早些年我可以说这些话,但是在5.7开始,你会明显发现官方的投入已经很大了,官方推出的社区版迭代很快,已经早早超越了两个流行的分支Percona和MariaDB,尤其是MGR的推出,算是让MySQL在这方面有了不少的亮点和话语权。
我们继续回到工具,还是工具,工具是DBA的一把瑞士军刀,其实对我们来说,我们也不希望有一大把的小工具,如果有太多的工具,太多的瑞士军刀,我们的行李箱就会很沉重,哪些都需要,哪些都要单独安装,所以我们有时候希望做减法。如果官方有而且做得不错,那毫无疑问是我们首选的方案了。
所以在此我要推荐MySQL 的sys schema。这是在5.7推出的一个特性。算是对以前的performance_schema和information_schema的一个抽象层。
有的同学可能会问,这都是MySQL 5.7的特性了,我们的很多环境使用的依旧是5.5,5.6,这个特性对我们来说有什么意义,如果只是这样想,只能说明你只是意识到了这个问题而已,但是对于解决问题没有实质性建议。
我们来简单说下sys schema里面的一些小细节。
之前发表在DBAplus社群的一篇文章可供参考:在Oracle专家眼中,MySQL sys Schema是怎样一种存在?
我对sys下的视图做了一些分类,通过视图的命名可以看出来。
- host_summary,这个是服务器层面的,比如里面的视图host_summary_by_file_io
- user_summary,这个是用户层级的,比如里面的视图user_summary_by_file_io
- InnoDB,这个是InnoDB层面的,比如innodb_buffer_stats_by_schema
- IO,这个是I/O层的统计,比如视图 io_global_by_file_by_bytes
- memory,关于内存的使用情况,比如视图memory_by_host_by_current_bytes
- schema,关于schema级别的统计信息,比如schema_table_lock_waits
- session,关于会话级别的,这个视图少一些,就两个,session和session_ssl_status
- statement,关于语句级别的,比如statements_with_errors_or_warnings
- wait,关于等待的,这个还是处于起步阶段,等待模型有待完善,目前只有基于io/file, lock/table, io/table这三个方面,提升空间还很大。
所以这确实是一个宝贝,让我们对原本难以入手的性能问题有了一些很清晰的定位方式。
比如我很看好的一个功能是自增列的溢出问题检测,如果能够提前发现,那么对于运维工作会从被动变为主动。
在MySQL 5.7中我会这样来用:
select *from schema_auto_increment_columns;
如果自增列值快要溢出(我们可以设置一个阈值,比如90%之类的),我们可以通过视图的方式来很容易定位到。
如果要查看这个视图的具体实现就会发现逻辑远比我们想象的复杂,视图的定义如下:
select `information_schema`.`COLUMNS`.`TABLE_SCHEMA` AS `table_schema`,`information_schema`.`COLUMNS`.`TABLE_NAME` AS `table_name`,`information_schema`.`COLUMNS`.`COLUMN_NAME` AS `column_name`,`information_schema`.`COLUMNS`.`DATA_TYPE` AS `data_type`,`information_schema`.`COLUMNS`.`COLUMN_TYPE` AS `column_type`,(locate('unsigned',`information_schema`.`COLUMNS`.`COLUMN_TYPE`) = 0) AS `is_signed`,(locate('unsigned',`information_schema`.`COLUMNS`.`COLUMN_TYPE`) > 0) AS `is_unsigned`,((case `information_schema`.`COLUMNS`.`DATA_TYPE` when 'tinyint' then 255 when 'smallint' then 65535 when 'mediumint' then 16777215 when 'int' then 4294967295 when 'bigint' then 18446744073709551615 end) >> if((locate('unsigned',`information_schema`.`COLUMNS`.`COLUMN_TYPE`) > 0),0,1)) AS `max_value`,`information_schema`.`TABLES`.`AUTO_INCREMENT` AS `auto_increment`,(`information_schema`.`TABLES`.`AUTO_INCREMENT` / ((case `information_schema`.`COLUMNS`.`DATA_TYPE` when 'tinyint' then 255 when 'smallint' then 65535 when 'mediumint' then 16777215 when 'int' then 4294967295 when 'bigint' then 18446744073709551615 end) >> if((locate('unsigned',`information_schema`.`COLUMNS`.`COLUMN_TYPE`) > 0),0,1))) AS `auto_increment_ratio`
from (`INFORMATION_SCHEMA`.`COLUMNS`
join `INFORMATION_SCHEMA`.`TABLES`
on(((`information_schema`.`COLUMNS`.`TABLE_SCHEMA` = `information_schema`.`TABLES`.`TABLE_SCHEMA`)
and (`information_schema`.`COLUMNS`.`TABLE_NAME` = `information_schema`.`TABLES`.`TABLE_NAME`))))
where ((`information_schema`.`COLUMNS`.`TABLE_SCHEMA` not in ('mysql','sys','INFORMATION_SCHEMA','performance_schema')) and (`information_schema`.`TABLES`.`TABLE_TYPE` = 'BASE TABLE') and (`information_schema`.`COLUMNS`.`EXTRA` = 'auto_increment'))
order by (`information_schema`.`TABLES`.`AUTO_INCREMENT` / ((case `information_schema`.`COLUMNS`.`DATA_TYPE` when 'tinyint' then 255 when 'smallint' then 65535 when 'mediumint' then 16777215 when 'int' then 4294967295 when 'bigint' then 18446744073709551615 end) >> if((locate('unsigned',`information_schema`.`COLUMNS`.`COLUMN_TYPE`) > 0),0,1))) desc,((case `information_schema`.`COLUMNS`.`DATA_TYPE` when 'tinyint' then 255 when 'smallint' then 65535 when 'mediumint' then 16777215 when 'int' then 4294967295 when 'bigint' then 18446744073709551615 end) >> if((locate('unsigned',`information_schema`.`COLUMNS`.`COLUMN_TYPE`) > 0),0,1))
里面引用了performance_schema和information_schema的数据字典。
所以有一个很重要的问题,5.7的视图内容是否可以照搬到5.5来用呢。
显然不是一个完全肯定的答案,因为5.7中的information_schema中的表有72个,而5.5中只有37个,大部分的差异是在InnoDB的数据字典上。
但是巧的是对于视图schema_auto_increment_columns的实现来说,5.5的逻辑已经足够了。
所以尽管我们使用的5.5的版本,我们依旧可以享用这个5.7的特性带来的福利,当然不是简单的拿来主义,对于这列操作,我更希望是放在从库来执行,提前测试避免不必要的麻烦。所以很多问题都能够有定位的方法,对于解决问题就会如虎添翼。
所以顺着这个思路走下去,你会发现有很多工作待发掘。
- PhalGo-介绍
- 实测Nginx服务器开启pagespeed加速效果
- MySQL频繁停库的问题分析(r12笔记第33天)
- 解决Nginx Helper插件一键清理缓存功能导致网站打不开问题
- Oracle 12c DBCA浅析(r12笔记第48天)
- MySQL中的derived table(r12笔记第47天)
- Oracle数据库端口突然无法访问的分析(r12笔记第46天)
- MySQL中的反连接(r12笔记第45天)
- Nginx配置多站点下的Proxy_cache或Fastcgi_cache缓存加速
- MySQL主从不一致的细小问题分析(r12笔记第62天)
- Linux在批量服务器管理中实用的PS1命令提示符格式
- Golang语言社区-并发模型和应用场景
- 翻过那座山,就能看见海|kubernetes让DBA更优雅地管理数据库
- 基于TextCNN的谩骂评论识别模型
- MySQL 教程
- MySQL 安装
- MySQL 管理与配置
- MySQL PHP 语法
- MySQL 连接
- MySQL 创建数据库
- MySQL 删除数据库
- MySQL 选择数据库
- MySQL 数据类型
- MySQL 创建数据表
- MySQL 删除数据表
- MySQL 插入数据
- MySQL 查询数据
- MySQL where 子句
- MySQL UPDATE 查询
- MySQL DELETE 语句
- MySQL LIKE 子句
- mysql order by
- Mysql Join的使用
- MySQL NULL 值处理
- MySQL 正则表达式
- MySQL 事务
- MySQL ALTER命令
- MySQL 索引
- MySQL 临时表
- MySQL 复制表
- 查看MySQL 元数据
- MySQL 序列 AUTO_INCREMENT
- MySQL 处理重复数据
- MySQL 及 SQL 注入
- MySQL 导出数据
- MySQL 导入数据
- MYSQL 函数大全
- MySQL Group By 实例讲解
- MySQL Max()函数实例讲解
- mysql count函数实例
- MYSQL UNION和UNION ALL实例
- MySQL IN 用法
- MySQL between and 实例讲解
- linux 压力测试工具之ab
- 什么是Python Wheels?为什么要关心它?
- Nginx fastcgi_cache权威指南
- 玩转dockerfile
- redis实战第六篇 手动创建redis cluster
- docker容器入门最佳教程
- redis实战第五篇 jedis 连接 redis sentinel详解
- redis实战第四篇 手动容灾故障转移记录
- 10条很棒的Python一行代码
- 如何在一个Docker中同时运行多个程序进程?
- 如何在CentOS / RHEL 7上启用IPv6
- Golang中的RegExp正则表达式用法指南
- Golang glog使用详解
- kubernetes使用securityContext和sysctl
- 浅谈分词算法基于字的分词方法(HMM)