MySQL优化班13期课后作业,20180717

1、你为什么(不)升级到MySQL 5.7,理由呢

2、使用MySQL 5.7时,启用P_S了吗

3、show processlist时,总能看到unauthenticated user,你都有什么解决思路

4、本节课程总结
已邀请:

aaron8219 - Oracle DBA

赞同来自:

1. 升级到MySQL 5.7可以利用到很多新特性包括:
1)增强半同步(after_sync),保证收到从库的ACK后存储引擎再进行提交,保证数据强一致性。
2)组提交(Group Commit),取消了prepare_commit_mutex,多个事务合并提交,减少binlog的sync次数。
3)并行复制(MTS),支持从库多线程回放,并支持以logic_clock方式进行复制,而不是5.6的database方式,可以极大地减少从库延迟的问题。
4)为将来过渡到MySQL 8.0做准备,8.0支持writeset方式基于行级别的复制,占用更少的锁资源,效率更高。
 
2. MySQL 5.7建议开启P_S库,已经对P_S做了一定的优化。
 
3. 在my.cnf的[mysqld]中加入skip-name-resolve=off(default),当客户端连接进来时采用IP地址进行解析,而非以主机名方式解析。
 
4. 本课内容为MySQL体系结构2,包含以下内容:
1)InnoDB存储层内存结构及对应参数说明
2)使用profiling进行性能诊断的方法
3)各种存储引擎对比(主要是InnoDB,Tuokudb,MyRocks,columnstore几种)
4)plugin的管理(install plugin xxx soname 'xxx',uninstall plugin xxx)及其他plugin介绍
5)TuokuDB存储引擎介绍
6)MariaDB columnstore存储引擎介绍
7)Jason和虚拟列介绍
8)一些指标的统计方法介绍
9)常用的percona toolkit工具介绍
10)select SQL执行过程说明

zhwei228

赞同来自:

1、你为什么(不)升级到MySQL 5.7,理由呢
一、不升级
稳定:
我们现在使用的版本是5.6.19,相当还很稳定,目前遇到的bug只有唯一键失效,5.6.21已解决
备份工具:
xtrabackup版本要替换
sql:
各别字段类似存在隐式转换的问题
功能:
查看聚集索引很方便
维护:
习惯了grant 授权用户
二、升级的好处
新功能,p_s,sys的使用
2、使用MySQL 5.7时,启用P_S了吗
p_s从5.6开始就默认是打开的,5.6如果不关闭好像会触发oom,具体什么场景忘记了,5.7可以使用,不是开启就能有结果,切记要查什么开起什么
3、show processlist时,总能看到unauthenticated user,你都有什么解决思路
这种场景没遇见过
4、课后总结
最近事有点多。。。

DBA_Xin - A820-辛佳宇-重庆

赞同来自:

1、现在暂时没升级的原因:初入公司,还不完全熟悉生产库,老大懒得折腾只有我熟悉后慢慢折腾了,计划先把公司内部使用的库升起来。
     升级原因:5.7的性能提升以及可以使用group commit和并行复制,有一套交易库为了提高数据一致性还可以使用5.7的增强半同步。5.7也可以在线修改buffer_pool不用停库,在线启动关闭GTID。
2、虽然没有在生产库上使用5.7,但测试库上的5.7里P_S库是用起的。
3、出现show processlist中user列出现unauthenticated user,就需要在my.cnf中【mysqld】下添加skip-name-resolve(静态全局,默认为OFF)参数。不过5.7.5已经移除了这个参数。
4、主介绍体系结构辅介绍参数和索引:
    1)mysql8.0的部分参数及对应概念
    2)innodb的体系结构
    3)做了不同引擎的对比(InnoDB,TokuDB,MyISAM,inforbright/infinidb,Memory等)
    4)plugin管理(查看、安装、删除),隔天吴总的课上搭建MGR就用上了。
    5)一些常用的监控语句(统计无用索引、统计全表扫描、统计指定表buffer消耗,统计MDL锁)
5、percona toolkit中实际常用的几种工具(pt-taable-checksum、pt-table-sync等)
6、select sql执行过程
ps:肯定还有我漏掉的内容,剩下的只有周末复习回顾时补全笔记了。

liyh

赞同来自:

问题1:
为什么升级到5.7呢,因为5.7当中有很多优秀的新特性,比如说并行复制,json,虚拟列,onlineDDL,更成熟的GTID模式,半同步复制等等。以前想要用到并行复制,会想到MariaDB,但是现在官方并行复制也很靠谱了,且5.7以后MariaDB已经很官方版本渐行渐远了,差异越来越大。5.7版本也融合其他分支版本的好的特性,值得期待和信任。
 
问题2:
我一直以为MySQL5.7 P_S是自动开启的。
 
问题3:
说实话没没见过这个,unauthenticated user。百度了一下,说是可以在配置文件中加上skip-name-resolve,我的配置文件模板里一直有这选项。
配置参数还是值得研究的,不知道的知识太多,不断学习积累。
 
问题4:
MySQL三层体系结构:连接层-->SQL层(server层)-->存储引擎层
连接层:处理客户端连接请求,分配连接线程,验证连接权限,安全检查等。
server层:处理权限判断,正常登陆后,相应客户端SQL需求,根据不同请求类别分配不同的处理器,并对SQL进行优化改写,并执行,以及最后返回结果给客户端
引擎层:存储引擎基于磁盘:innodb,tokuDB等api接口,基于内存的memery,heap引擎。处理各种日志。作为数据存储,和处理的平台,并把数据持久化到磁盘。

UnixFBI - 保险经纪人

赞同来自:

问题1:
现在线上使用的是5.6版本。计划升级到5.7版本。5.7对复制进行了很大的改进,例如增强半同步,并行复制,多源复制,binlog group commit等特性。我

主要是从以下方面考虑:
(1)开启ROW+GTID的模式,使用GTID可以方便增加slave实例,以及主从结构的切换再也不用去日志找位置点了。
(2)主从复制使用并行复制+binlog group commit,提高主从复制的一致性。
(3)备份服务器开启增强半同步功能,保证数据的安全性。
 
问题2:
启用了P_S,主要是收集数据库性能参数,为优化做支持。
例如:可以查看SQL语句执行的时长,统计无用的索引,统计全表扫描,统计MDL锁,统计SQL使用临时表,哪个SQL返回的结果集最多等等。
 
问题3:
出现这种问题,不一定是数据库本身的问题,这是访问的用户未认证,有可能是应用程序那边问题。
1.先查看show processlist 确认是哪个主机连接过来的。
2.确认数据库服务器负载,CPU ,内存使用率;
3.确认是否是应用安全问题,出现线程异常终端导致出现大量异常数据库连接;
4.看看MySQL客户端连接版本是否兼容;
 
问题4:
 
1)讲解了,存储层和InnoDB引擎内存结构;

(2)不同引擎的对比;

(3)什么是TokuDB

(4)介绍虚拟列;

(5)怎么查看InnoDB buffer pool信息:

mysql> pager cat - | less


mysql> show engine innodb status\G 

如果innodb buffer pool不够用了,Free buffers 会变成0 ,或者一个比较小个位的数值。
Innodb_buffer_pool_pages_free 这个值会变成0或者个位数的数值。表示innodb buffer pool 不够用了。
Innodb_buffer_pool_wait_free   这个值>0 的话,也是表示innodb buffer pool 不足了。
这两种情任何一种情况出现,都表示innodb buffer pool是不够用的。

(6)table cache参数介绍:
Opend_tables 表示MySQL这个生命周期内打开的表的次数。
Open_tables 表示正在打开表的次数。

如果table cache 足够用的话,打开关闭打开关闭,Opend_tables、Open_tables 这两个值肯定不会相差太大,也就是历史上打开的次数和当前打开次数不会相差太大。
如果table cache 不够用的话,历史上打开表的次数肯定要远远大于当前正在打开表的次数。因为table cache不够用,所以打开一个新表的话,需要把旧表关闭掉。
(7)thread cache介绍:
Threads_cached 表示当前正在缓存的数量
Threads_connected 表示已经创建连接的数量
Threads_created  表示历史上创建的数量
Threads_running 表示正在运行的数量

如果历史上创建的数量(Threads_created)远远大于已经创建连接的数量(Threads_connected)的话,例如相差5-10倍,表示thread cache 是不够用的。
对这几个值的监控 是看 一段时间的增量值,例如 1分钟内的增量。
(8)关于临时表介绍:
Created_tmp_tables  创建临时表的数量,我们查看一下最近10s中创建临时表的数量有没有增加。如果监控发现平均每10s 都有一次临时表的增加,可能在每10s内,就有一个比较大的SQL需要产生临时表。
Created_tmp_disk_tables  创建磁盘的临时表。如果这个值比较大,表示问题就更严重了。 这个值也是看一个时间段的值。
(9)查看一个SQL语句执行时长:
使用 profiling ,以及information_schema信息进行统计;
(10)统计无用索引:
root@localhost:mysql3306.sock [(none)]> use sys;
Database changed
root@localhost:mysql3306.sock [sys]> select * from schema_unused_indexes;
(11)统计全表扫描:
root@localhost:mysql3306.sock [sys]> select * from schema_tables_with_full_table_scans limit 4;

(12)统计指定表buffer消耗:
(13)统计MDL锁:
root@localhost:mysql3306.sock [sys]> select * from schema_table_lock_waits limit 4\G
如果show processlist 出现了  Waiting for table metadata lock ,表示出现了MDL锁等待。
(14)介绍SELECT SQL执行过程以及SELECT SQL WHERE提取过程;
 
 

要回复问题请先登录注册