知数堂·叶问

知数堂·叶问

叶问(20190108)RDS上，MySQL实例中某张表数据小于tmp_table_size，但有查询时会报错临时空间满 The table '/data/mysql/zst/tmp/#sql_13975_23' is full。原因可能是什么？

可能有下面几种情况：

1、在SQL中执行group by、order by、distinct、union、多表update、子查询、多表JOIN等情况下，可能需要生成内部临时表，当内部临时表超过tmp-table-size时，就会产生磁盘临时表。
2、接上，若查询包含BLOB、TEXT类型字段时，MySQL会直接使用磁盘临时表。
3、云数据库购买的磁盘空间，是包括数据库文件、日志文件（binlog、relay log、error log等）、临时文件&临时表（关注 Created_tmp_disk_tables、Created_tmp_tables、Binlog_cache_disk_use、Binlog_stmt_cache_disk_use等指标）所消耗占用的磁盘空间。
4、发生table...is full报错，说明可能生成磁盘临时表太多，超过云数据库购买的空间限制。

解决办法可以有：

1、关注slow query log，或者查看processlist，及时发现需要用到临时文件、临时表的SQL，尽快优化。
2、调高 tmp_table_size 参数值来调高内存临时表的上限。
3、调高参数loose_rds_max_tmp_disk_space值，可设置为当前空闲空间的80%（阿里云RDS专属参数）。
4、优化表DDL设计，尽量避免使用BLOB、TEXT类型字段，并且在SQL中减少对这些大字段的访问。
5、优化查询逻辑，避免使用UNION或者需要中间数据集的子查询等SQL。

叶问(20190115)云环境上自建MySQL，有哪些高可用实现方案？

1、基于VPC环境，支持独立分配IP相关IP段的，还是可以考虑VIP方案，云环境把协议阉割，使用TCP方式，如：×××开源的Xenon， MHA 。在VPC中，是可以自主绑定私有IP，还是比较方便。
2、基于MGR、PXC构建MySQL高可用。因为MGR、PXC无法告知应用端切换后的IP地址，所以建议配合使用类似consul来使用。如果使用多主模式的MGR/PXC，可以使用LVS/haproxy或者SLB等。
3、基于中间件层MySQL高可用。使用consul配合MGR/PXC，或者consul配合MHA使用。
4、基于ProxySQL+Replication-manager+Consul进行构建，用Replication-manager提供主从切换，动态通知proxysql,利用consul感知ProxySQL可用性。

叶问(20190220)MySQL安全相关的参数有哪些？该如何配置？

1、MySQL数据安全

innodb_flush_log_at_trx_commit =1 #innodb每次提交事务redo buffer 刷新到redo log
innodb_doublewrite =on #开启innodb特性“二次写”
secure_file_priv #禁用导入导出目录，避免被人利用

2、复制安装

sync_binlog = 1 #事务每次提交binlog cache刷新到binlog file
binlog_format =row #binlog格式为row格式
relay_log_info_repository =table #relay log信息记录到innodb存储引擎的table中
master_info_repository=table #master 信息记录到innodb存储引擎的table中
slave_skip_errors=off #禁止跳跃错误信息
binlog_row_image=full #全量记录binlog日志内容

3、使用建议

master-slave：建议开启gtid，采用半同步复制或者mgr高可用
密码相关：设置密码复杂度，定期修改密码，针对应用app授权，减少权限分配
存储引擎：建设使用innodb，避免使用myisam
网络环境：内外隔离，不要把数据库直接暴漏到公网
相关连接：
"MySQL数据安全策略"：
http://t.cn/EfvKeFD
"我猜你一定达不到要求的《MySQL安全策略":
http://t.cn/Efv9yjI

叶问(20190226): MySQL DBA运维中那些动作属于危险性操作?

1、MySQL无备份、备份无校对。
2、执行rm -rf / tmp 等类似操作，执行rm 前要三思。
3、执行kill -9等操作
4、binlog 非row格式，执行dml操作(update、delete)
5、在生产环境执行测试命令。或在生产环境直接调索引。
6、避免使用一些骚操作："slave_skip_errors" ,或故意导致主从不一致操作。
7、drop database
8、DML操作条件写错，线上DDL导致业务报错
9、恢复数据，实例不对（基于IP连接管理环境）
10、线上高并发环境运行 flush table ; flush table with read lock; lock table;
11、数据库重启空间不够文件损坏，初始化数据库把机器IO资源占满
12、从库延迟并对外提供服务
13、开多窗口操作重要数据库
14、敏感字段不加密，备份不加密存放，线上数据同步到线下
15、犯困时操作线上环境

叶问(20190326)：MySQL误删除frm文件该怎么办？

情况一：误删后还未重启MySQL

1、从proc中恢复.frm文件
cp /proc/pidof mysqld/fd/误删除的.frm /datadir/db/对应库的目录/

情况二：误删后也重启MySQL了

2、从备份中获取表结构
2.1 物理备份
从物理备份中直接把.frm文件拷贝回来。
2.2 逻辑备份
找到该表的DDL，在备用实例创建该表，再把.frm文件拷贝回来。

注意事项：

1、无论是情况一还是情况二，都需要重新设置属主和属组。
2、若恢复期间对该表执行了新的DDL，则上述方法可能都无效。
3、本案例在MySQL 5.7.18版本（开启表独立空间模式）下亲测通过。

叶问(20190409):在一个2c4g的服务器上如何用python操作8GB的超大文件

1、使用with open的方式，for line in f文件对象f视为一个迭代器，会自动的采用缓冲IO和内存管理，并且能够自动关闭文件，推荐该方式
举例：
with open('filename') as f:
for line in f:
do_things(line)

2、open file的方式，可以通过read(size)指定每次读取的大小，将大文件切割成小文件来读取，每次处理完小块即释放内存
举例：
f = open(filePath)
while True:
content = f.read(chunk_size)
do_things(content)

3、linecache模块，可以指定读取文件某一行
举例：
content = linecache.getline('filename', linenum)
do_things(content)

叶问(20190411)：MySQL反应慢的排查思路

一、导致MySQL慢可能的因素有

1、计算资源不足
2、系统层面未进行基本的优化，或不同进程间资源抢占
3、MySQL配置不科学(附神器：http://imysql.com/my-cnf-wizard.html)
4、垃圾SQL满天飞

二、查看系统层面负载手段

1、top查看整体负载情况，快速确认哪个进程系负载高
2、free查看内存情况，是否有内存泄露和用了swap等风险
3、vmstat/sar查看当前系统瓶颈到底在哪，如CPU、IO、网络等
4、终极神器perf top查看cpu消耗在哪些系统调用函数

三、查看MySQL的整体情况

1、观察show processlist输出中是否有临时表、排序、大量逻辑读、锁等待等状态
2、观察show engine innodb status输出中是否有大事务、长事务、锁等待等状态

四、干掉垃圾SQL，常用手段

1、用explain、desc观察执行计划
2、用profiling定位sql执行的瓶颈
3、用pt-query-digest分析慢sql

五、几个窍门

1、mysqld进程消耗CPU长时间超过90%的话，99.9%是因为没用好索引
2、cpu的%sys高的话，大概率是swap或中断不均衡导致，也可能是有多个索引且超高并发写入(更新)，或者有很严重的锁等待事件
3、最⼤的瓶颈通常是在磁盘I/O上，因此尽量用高速磁盘设备
4、如果物理磁盘无法再升级，则通过增加内存提升性能容量
5、遇到无法诊断的问题时，试试⽤perf top来观测跟踪
6、SQL执行慢，有时未必是效率低，也可能是因为锁等待，甚⾄是磁盘满了

详情戳：https://ke.qq.com/course/392646

叶问(20190416):生产环境MySQL死锁如何监控及如何减少死锁发生的概率？

首先，死锁并不是"锁死"，死锁是由于两个或两个以上会话锁等待产生回路造成

一、死锁监控及处理方法

对于死锁的监控，各个版本都提供了innodb_print_all_deadlocks选项，打开该选项即会将死锁的日志输出到MySQL的错误日志当中,
因此可以通过监控错误日志来达到监控死锁的目的。而对于MariaDB就更加简单了，MariaDB提供了Innodb_deadlocks的计数器，可以
通过监控该计数器的增长来监控是否存在发生死锁。
假如线上出现死锁并且频率较高的话，务必要引起重视。由于死锁日志仅记录了最后引起死锁的两条SQL，因此并不能通过死锁日志立即定位
出死锁的原因，应当及时协同开发模拟出死锁过程，分析死锁产生原因，修改程序逻辑。

二、如何降低死锁发生的概率

1、尽量使用短小事务，避免大事务
2、加FOR UPDATE/LOCK IN SHARE MODE锁时，最好降低事务隔离级别，例如用RC级别，降低死锁发生概率，也可以降低锁定粒度
3、事务中涉及多个表，或者涉及多行记录时，每个事务的操作顺序都要保持一致
4、通过索引优化SQL效率，降低死锁概率，避免全表扫描导致锁定所有数据
5、程序中应有事务失败检测及自动重复提交机制
6、高并发（秒杀）场景中，关闭innodb_deadlock_detect选项，降低死锁检测开销，提高并发效率