MySQL生产环境的高危操作
实际工作中，经常遇到一些临时应急需求，DBA没有充分准备之前，直接到线上执行一些命令，除此之外一些没有考虑清楚厉害关系的命令，最后导致事故的情况。
MySQL DBA运维中那些动作属于危险性操作?
MySQL数据库操作：
1. shutdown/restart命令（8.0版本）: 关闭 mysql服务,重新启动，
平时在运行习惯，在测试环境随意执行，到生产无意识执行这些命令。
大事务运行还没结束，执行命令导致事务大量回滚 或 无法数据库及时关闭问题。如load 等操作中
2. kill pid进程
不是马上kill掉进程，底层要进行回滚动作，要是大事务 回滚需要很长时间 30分钟，3个小时或更长。
碰到大事务下，kill操作
服务器负载过高，无法提供足够的CPU，IO等资源
3. FLUSH BINARY LOGS:
截断旧binlog日志，产生新的binlog日志，同时也会触发expire_logs_days参数清除过期binlog，在高可用架构下禁止执行。
从库因为其他问题，日志还有没分发到从库relay log中
正好进行大事务，截断操作，可能导致，数据库穷住。
binlog记录的是数据操作记录，被清除，在出现故障无法进行恢复
4. set sql_log_bin=0
SESSION操作不记录binlog，当然一些特殊情况，不想分发到从库，比如从库要额外创建一些索引之类的。
相关操作无法分发到从库上
5. RESET MASTER / RESET SLAVE :
重置主节点，从节点信息
gtid重置，
binlog 信息清除 或
重置复制信息
6. TRUNCATE TABLE
清除数据，
不会记录binlog 恢复找到操作详细数据
处置之外truncate 有一定的概率触发bug ，穷住库
7. DROP DATABASE
删除数据和文件
binlog 不会记录详细数据操作
底层数据和结构文件，全部物理删除
8. FLUSH TABLES。。。(FLUSH TABLES WITH READ LOCK):
关闭所有打开的表
强制关闭所有正在使用的表
并刷新查询缓存和预准备语句缓存
不会刷新脏块
上全局COMMIT锁
9. LOCK TABLES READ/WRITE ;
锁表动作
10. ALTER DATABASE dbname READ ONLY（8.0版本）
对于数据库只读，不允许写
11. slave_skip_errors ：
跳过复制错误代码，导致主从数据不一致
12. purge binary logs
清除binglog物理文件，复制状态下，需要确保无用的binlog进行清除。
13. DML操作条件写错 或 不使用索引
where 不使用索引，导致全表扫描
insert into t1 select * from t2方式：t1 或 t2 表结构变化导致语句失败。
14. 在线DDL
不管online ddl 还是 pt-osc ，gh-ost都会有一定的问题存在，所以谨慎执行，特别是高负载下。
online ddl 导致meta data lock
pt-osc 因为表数量大导致中间意外停止，触发器无法删除
gh-ost binlog接受，延迟导致一直无法进行下去。
15. ANALYZE ，OPTIMIZE table
锁表，缓存移除，对表数据无法进行修改，严重的话会影响业务。
15. MySQL无备份、无高可用节点，binlog没有开启（ROW）模式
故障触发，一些操作 都无法回逆。这种环境更应该谨慎
16. 执行rm -rf / data tmp 等类似操作，执行rm 前要三思
物理删除，进程在虽然可以通过lsof delete方式召回，但未必能全部恢复。
17. 不用mysqld_safe守护进程启动, 执行kill mysqld pid 等操作
没有守护进程，mysql服务器会异常关闭，无法启动。更严重情况下数据文件损坏，无法启动
18. 在生产环境执行测试命令。
19. 逻辑恢复数据，实例不对（基于IP连接管理环境）
特备是开发工具Navicat，SQLyog，这部分权限需要控制好。
执行数据操作命令需要核对实例信息
20. 空间不够下的操作
导致导致事务丢失，文件损坏，比如备份，迁移数据文件等操作。
21. 从库延迟并对外提供服务
数据延迟，导致业务段收到的信息不对。因为mysql是逻辑回放。
22. 开多窗口操作重要数据库
容易把命令 分发到所有节点。
23. 敏感字段不加密，线上数据同步到线下
敏感数据无法做到透明，但可以通过一些函数算法，替换一些字段。
24. 系统表操作
对mysql库 ，information_schema库下的表进行删除，更改，创建，truncate 动作，都有可能导致数据库无法启动。
25.参数更改
lower_case_table_names大小写敏感，只能初始化设置，之后不建议改。需要改动就逻辑导出导入方式
innodb_buffer_pool_size 在线调整，当负载高的时候容易出现持续穷住现象。
26.犯困时操作线上环境
复杂操作需要制定好操作步骤
需要第二人协助确认和检查
总结
虽然目前很多数据库管理已经逐步进入半自动化，脚本化。但很多时候还需要人为操作，需谨慎。虽做到万无一失很难，但做好备份，准备工作，环境允许甚至测试验证都是必不可少的。
