在当今数字化时代，数据是企业的核心资产，数据库的安全与稳定直接关系到企业的正常运营。安全生产在数据库管理中至关重要，任何细微的失误都可能引发严重后果。
回顾过往，因数据库操作不当导致的数据丢失、服务中断等事件屡见不鲜，这些事件不仅给企业带来了巨大的经济损失，更损害了企业的声誉与形象。因此，如何确保数据库操作的安全生产，成为了每个数据库管理者必须深入思考的问题。近期，云和恩墨的服务总监 杨明翰带来了《MySQL高危操作(安全生产系列）》的主题分享，以下是对此次分享内容的详细整理。
我们也将持续分享【安全生产系列】的技术演讲，欢迎关注。
👉点击获取技术文档：https://www.modb.pro/doc/143180
MySQL 数据库操作四大守则
（一）备份重于一切
备份是数据库服务的生命线，类似于高空作业中的保险绳。我们无法保证存储、数据库本身或业务逻辑不会出现问题，而备份是恢复数据和服务的最后一道防线。在实际工作中，因未做日常备份或备份不可用而导致的故障屡见不鲜，恢复这些数据往往需要大量的人力、物力、财力和时间，且无法保证数据能够完全恢复。因此，无论是变更操作前的备份还是日常数据库的有效备份，都是同等重要的高投入产出比的工作。
（二）三思而后行
杨明翰指出，在执行任何操作之前，必须清楚该操作可能带来的影响，包括对数据库本身、数据、业务以及执行时间的影响。例如，某些命令可能会导致数据库覆盖，从而引发不可逆的后果。因此，在执行操作之前，务必确保你完全理解该操作的影响范围，并且该操作符合公司和客户的流程要求。
（三）删除操作需谨慎
删除操作通常是不可逆的，一旦执行，可能会带来巨大的影响。删除的数据很难找回，因此在执行删除操作之前，必须反复确认操作的必要性和准确性。如果不确定，宁可不做。
（四）制定规范
在数据库管理工作中，我们目前遵循的数据库操作规范是前人经验的总结，是他们踩过的“坑”换来的教训。随着架构的变化和技术的演进，这些规范可能无法适应所有场景。因此，我们需要在工作中不断积累经验，形成新的规范，以指导后续的工作。
MySQL 需谨慎执行的命令
接下来，我们将深入探讨在实际操作中需要谨慎执行的 MySQL 命令，这些命令的正确执行是确保数据库安全生产的关键。
（一）启动和关闭实例
启动和关闭 MySQL 实例都存在风险。在关闭实例时，如果没有检查是否存在未完成的事务，可能会导致大量事务回滚，甚至在重新启动时，实例可能会处于长时间的恢复状态，从而影响业务的正常开展。
（二）备份与恢复
备份是数据库管理中的关键环节。我们需要确保备份策略的完善性，避免出现未备份的库或备份类型不全的情况。同时，备份数据的可用性也至关重要，需要定期进行恢复验证操作。此外，备份操作可能会与业务产生相互影响，需要与业务方沟通，确定合适的备份窗口。对于 MySQL 来说，无论是逻辑备份还是物理备份，都可能涉及锁表操作，可能会影响业务的正常运行。如果在备份期间业务进行了表结构变更或存在长事务、慢查询，可能会导致备份失败或备库延迟。因此，备份操作需要谨慎规划，并配备相应的监控手段，以避免对业务产生不良影响。
（三）日志与复制相关操作
日志与复制相关操作也需要格外小心。例如，在备份过程中可能需要执行 flush logs 命令来生成新的二进制日志文件，但需要注意该命令会写入到二进制日志中并应用到从库，如果不想让从库执行相应操作，需要加上相应的关键字。
在清理二进制日志时，需要确保清理操作与备份不冲突，避免清理掉未备份的日志，导致后续无法恢复到指定时间点的数据。同时，需要注意主从复制中关键日志的传输延迟，避免清理掉尚未分发到从库的日志，否则可能导致备份失败，甚至需要重建备库。
（四）数据定义与结构变更
在 MySQL 中，DROP DATABASE和 DROP TABLE操作是文件系统层面的删除，没有后悔药！一旦执行，数据无法通过事务回滚恢复，且二进制日志只记录 DDL 操作，无法通过二进制日志恢复数据。因此，执行这些操作前，务必确保在正确的实例上，并且实例之前有有效的备份。
TRUNCATE TABLE 约等于 DROP TABLE + CREATE TABLE，在独立表空间配置下，会删除 .ibd 文件，二进制日志只记录 DDL SQL。在高并发场景下，TRUNCATE 会在 BP 中加锁，可能导致业务卡住。对于大表，建议先使用 RENAME TABLE，再择机清理，避免业务高峰期间执行。
ALTER TABLE操作如果涉及表重建，会导致长时间的锁表，影响业务。建议在执行 DDL 时指定 ALGORITHM=INPLACE/INSTANT，以减轻对业务的影响。对于大表，建议使用 pt-osc或 gh-ost工具，避免主备延迟。在 PXC 集群中，只能使用 pt-osc或 gh-ost。无论使用哪种方式，都要注意 MDL（元数据锁）。INSTANT 算法注意行版本 64 的限制（9.1 版本后为 255），非必要不删列。
OPTIMIZE TABLE 会重建表，阻塞 DML 操作，严禁使用。ANALYZE TABLE如果在长事务存在的情况下，会阻塞其他事务对该表的操作，严禁在业务高峰使用。
（五）数据变更
1.数据变更 - Update/Delete
- 严禁无条件或条件失效的 UPDATE 或 DELETE 操作。注意 WHERE 子句规范，避免条件失效，注意 UPDATE 子句，避免变更错误。建议在
binlog_format=ROW和binlog_row_image=FULL的情况下，使用工具进行“闪回”操作。执行UPDATE/DELETE前开启事务，发现异常后可回滚。 - 对于大表全表删除或更新，由于是大事务，会导致阻塞和主备延迟，建议分批处理，避开业务高峰，并监控数据库性能指标。
2.数据变更 - Load Data/Replace
- LOAD DATA INFILE 如果数据文件格式错误、编码问题、数据质量差，可能导致数据导入失败、数据损坏，甚至数据库崩溃。务必仔细检查数据文件格式、编码、分隔符等，在测试环境先进行小批量导入测试，并监控导入过程，及时发现和处理错误。
- REPLACE INTO 如果主键或唯一索引冲突，会先删除旧记录再插入新记录，可能导致数据丢失（如果新数据有问题）。生产环境谨慎使用，考虑使用 INSERT … ON DUPLICATE KEY UPDATE 或 INSERT IGNORE
（六）用户管理
在 MySQL 数据库管理中，用户管理是一个关键环节，它直接关系到数据库的安全性和稳定性。合理的用户管理可以有效防止未授权访问、数据泄露和恶意操作等风险。以下是从创建匿名用户、过度权限授予以及弱密码三个方面进行MySQL 用户管理。
（七）Kill 操作
KILL QUERY 和 KILL CONNECTION 用于强制终止 MySQL 中正在执行的查询或连接。使用这些命令可能会导致事务回滚失败、应用程序错误等问题，对数据库的稳定性产生影响。
在生产环境中应谨慎使用 KILL 操作。遇到查询执行缓慢等问题时，优先分析慢查询的原因，通过优化 SQL 语句或索引来解决问题。只有在必要时才考虑使用 KILL，并且可以适当增加 max_connections 参数，以避免因连接数限制导致的服务中断。
（八）Flush 操作
FLUSH PRIVILEGES 用于刷新 MySQL 的权限表，使修改后的用户权限立即生效。但其往往也有风险，在刷新权限表时，如果数据库中有过多的连接，可能会导致暂时的连接丢失或服务中断，影响数据库的可用性。
（九）配置修改
在修改 MySQL 配置时，如内存限制、连接数、缓存大小等，若参数配置不当，可能导致性能下降或系统崩溃。某些参数的修改，如 sql_mode，还可能导致业务执行 SQL 时出现报错。此外，修改某些只读参数后，可能导致实例启动失败，例如 lower_case_table_names（在 8.0 版本之后）和 innodb_data_file_path。因此，skip-grant-tables 的设置是严格禁止的，因为它会带来严重的安全风险。
写在最后
高危操作具有高风险和低可逆性特点，规范操作流程和制定详细的操作规范至关重要。在实际工作中，技术、流程和工具的结合使用可以有效降低操作风险，确保数据库的安全和稳定运行。
在分享的最后，杨明翰老师也为大家送上盖国强老师在《数据安全警示录》中的话，共勉：
“不论是作为数据库的守护者 DBA，还是其他的运维人员，都要遵循职业道德，不断加强自我修养：作数据的保护者，而不是窥探者、窃取者和破坏者；理智和情感分离，以成熟成职业，不以情绪行偏颇。“
