中小型数据库指适用于中小企业的轻量级、低成本、易部署数据库系统，如MySQL、PostgreSQL、SQLite等，具备GB级数据处理能力、数百用户并发支持、高灵活性及低运维门槛，广泛用于信息管理、电商、CMS等场景。
对中小型数据库（mysqldump 仍是全量备份最直接、跨版本兼容性最好的选择；但默认参数极易导致锁表、丢失存储过程、恢复失败或导入混乱——关键不在“能不能用”，而在“怎么配才不踩坑”。
mysqldump --single-transaction 为什么必须加（且只对 InnoDB 有效）
不加时，mysqldump 默认会对所有表执行 FLUSH TABLES WITH READ LOCK，InnoDB 表会被全局读锁阻塞写入，业务可能卡顿数秒到数分钟。加了 --single-transaction 后，它会在事务快照中读取数据，全程无锁，写操作完全不受影响。
- 仅对 InnoDB/XtraDB 表生效；MyISAM 表仍会触发锁表，此时应改用
--lock-all-tables或换物理备份 - 要求 MySQL 开启
autocommit=1，否则事务不会自动提交，快照可能过期 - 不能和
--lock-tables或--lock-all-tables共存，否则报错
哪些对象默认不备份？必须显式加的三个参数
mysqldump 默认只导出表结构和数据，存储过程、触发器、事件调度器全部被忽略——恢复后功能直接缺失，但错误不会立即暴露，容易漏检。
-
--routines：包含CREATE PROCEDURE和CREATE FUNCTION -
--triggers：导出每个表关联的触发器定义 -
--events：备份事件调度器（如定时清理任务） - 漏掉任意一个，恢复后对应逻辑就“消失”了，且无任何警告提示
--databases vs --all-databases：为什么推荐前者
--all-databases 看似省事，实则把 information_schema、performance_schema、sys 这些系统库也 dump 进来，不仅增大文件体积，还可能在恢复时报错（比如 CREATE DATABASE IF NOT EXISTS information_schema 不合法）。
- 用
--databases app_db user_db显式列出业务库，干净可控 - 避免恢复时因系统库权限或结构差异失败
- 配合
--set-gtid-purged=OFF可防止 GTID 环境下恢复时报GTID_PURGED cannot be changed
密码安全与脚本自动化中的硬伤点
在 shell 脚本里写 -p'password' 是高危操作：ps aux 可直接看到明文密码，历史命令、进程树、审计日志全暴露。
- 正确做法：创建
~/.my.cnf，权限设为600，内容为：
[client] user=root password=your_secure_password
mysqldump --defaults-extra-file=~/.my.cnf ...，避免密码入参~ 在非交互 shell 中可能不展开，建议写绝对路径如 /root/.my.cnf
真正容易被忽略的不是参数本身，而是备份后没验证——mysqldump 即使遇到部分表读取失败（比如临时表损坏、权限不足），也默认继续执行并返回 0 退出码，备份文件看似完整，实际缺数据。务必在备份后抽样检查 SQL 文件头尾、执行 head -20 backup.sql | grep "CREATE TABLE"，或导入到测试库跑一次 mysqlcheck -u root -p --all-databases。
