核心配置项（在购买/创建实例时选择）
这是配置的基石，决定了您数据库的“硬件”基础和“软件”版本。
（图片来源网络，侵删）
数据库引擎版本
- MySQL 8.0: 强烈推荐，性能、安全性、功能（如窗口函数、CTE、JSON增强等）都有显著提升,是当前的主流和未来方向。
- MySQL 5.7: 如果您的应用有严格的兼容性要求，无法升级到 5.7 以上，可以选择此版本,但建议尽快规划迁移。
实例规格
这是最重要的选择，直接决定了数据库的 CPU、内存 和最大连接数。
- 如何选择？
- 小型应用/开发测试: 1核2GB, 2核4GB 足够。
- 中型应用/Web网站: 2核4GB, 4核8GB 是常见选择,根据网站流量和复杂度调整。
- 大型应用/高并发交易: 8核16GB, 16核32GB 或更高，需要根据实际的 QPS（每秒查询率）和 TPS（每秒事务数）来评估。
- 核心与内存比例: 云厂商通常提供不同的系列，如通用型、独享型、突发型，通用型通常是
1:2或1:4的核内存比，适合大多数 OLTP（在线事务处理）场景。
存储配置
- 存储类型:
- 本地 SSD: 性能极高，但数据生命周期与实例绑定，迁移困难，适合对 I/O 要求极端苛刻的场景。
- 云盘 SSD: 强烈推荐，性能稳定，数据持久化，支持随实例生命周期自动备份和快照，且可以随时扩容，分为高性能 SSD 和通用 SSD，前者 IOPS 更高。
- 存储空间:
- 分配大小: 初始根据数据量预估，数据量预计 50GB，可分配 100GB,为增长留出空间。
- 最大大小: 设置一个上限，防止因日志或意外数据增长导致空间写满，云盘通常支持在线扩容,非常方便。
可用性与灾备
- 可用区: 选择与您的应用服务器在同一可用区,以获得最低的网络延迟。
- 跨可用区部署: 核心高可用方案，主库和备库部署在不同的可用区，当主库所在机房发生故障时，系统会自动切换到备库，实现 RPO（恢复点目标）=0，RTO（恢复时间目标）=分钟级。生产环境强烈推荐！
- 只读实例: 当有大量读请求时，可以创建只读实例，将读流量分流，减轻主库压力,提升整体性能。
参数组配置（精细调优）
创建实例后，需要通过“参数组”来精细调整 MySQL 的运行行为,以下是一些关键参数：
缓冲池
innodb_buffer_pool_size: 最最重要的参数之一。- 作用: InnoDB 存储引擎的缓存，用于缓存数据页和索引页，设置得当可以极大减少磁盘 I/O。
- 如何设置: 通常建议设置为可用物理内存的 70%-80%，如果服务器上只运行 MySQL，可以设置得更高（如 85%），但不要设置为 100%,要为操作系统和其他进程留出内存。
连接与线程
max_connections: 允许的最大并发连接数。- 如何设置: 不要盲目设置一个很大的值，过多的连接会导致内存耗尽和性能下降，建议根据应用预估的峰值连接数，并留有一定余量，可以通过
SHOW GLOBAL STATUS LIKE 'Max_used_connections';查看历史最大使用量来调整。
- 如何设置: 不要盲目设置一个很大的值，过多的连接会导致内存耗尽和性能下降，建议根据应用预估的峰值连接数，并留有一定余量，可以通过
back_log: 在 MySQL 短暂繁忙时，能够缓存的排队连接数。- 如何设置: 通常设置为
max_connections值的 1.5 倍左右。
- 如何设置: 通常设置为
日志配置
slow_query_log和long_query_time: 必须开启。slow_query_log = ON: 开启慢查询日志。long_query_time = 1: 执行时间超过 1 秒的查询将被记录，生产环境建议设置为 1 秒或 0.5 秒,便于定位性能瓶颈。
log_queries_not_using_indexes: 建议开启，记录未使用索引的查询，帮助优化 SQL。binlog_format: 二进制日志格式。ROW: 强烈推荐，记录每一行的变更，数据最完整，是主从复制、数据恢复和增量备份的基础，对性能有一定影响，但现代 MySQL 优化得很好。STATEMENT: 记录 SQL 语句，对某些函数支持不好,且可能产生主从数据不一致问题。MIXED: 混合模式，默认使用STATEMENT，对于不安全的语句自动切换为ROW。
InnoDB 引擎相关
innodb_flush_log_at_trx_commit: 控制事务提交时 redo log 的写入策略。1(默认): 最安全，每次事务提交时，将 redo log 从日志缓冲区写入磁盘并刷新，数据零丢失,但性能稍低。0: 每秒将 redo log 写入磁盘,但可能丢失最近一秒的事务数据。2: 每次事务提交时写入操作系统缓冲区，由操作系统决定何时刷到磁盘，性能介于 0 和 1 之间,但仍可能在系统崩溃时丢失数据。- 生产环境建议保持为 1，如果对性能有极致要求且能接受少量数据丢失，可以考虑 2,但需评估风险。
innodb_file_per_table: 必须设置为ON。- 每个表使用一个独立的
.ibd文件，这便于空间管理、数据恢复和优化,是现代数据库的最佳实践。
- 每个表使用一个独立的
安全配置
安全是云数据库的生命线。
网络访问控制
- 设置 IP 白名单: 在实例的“网络与安全”设置中，只允许您的应用服务器、堡垒机等可信 IP 地址访问数据库端口（3306）。不要设置为 0.0.0.0/0，这相当于公网开放,极其危险。
账号与权限
- 删除默认账号: 删除
root@%这样的远程管理账号，只保留root@localhost或特定 IP 的账号。 - 创建专用账号: 为应用程序创建单独的数据库账号，不要使用
root账号。 - 最小权限原则: 为应用账号授予其业务所需的最小权限（如
SELECT,INSERT,UPDATE,DELETE），绝不授予ALL PRIVILEGES或GRANT OPTION。 - 定期修改密码: 为所有账号设置强密码,并定期更换。
数据加密
- TDE (Transparent Data Encryption): 强烈推荐，对数据库文件（数据、日志文件）进行实时加密和解密，对应用透明,可以有效防止数据在存储介质上被窃取。
- SSL/TLS 加密连接: 启用 SSL/TLS 加密，确保客户端与数据库之间的网络传输数据是加密的,防止中间人攻击和数据窃听。
备份与恢复策略
自动备份
- 开启: 必须开启自动备份功能。
- 备份周期: 根据业务重要性设置,如每天全量备份。
- 保留时长: 设置一个合理的保留天数（如 7-15 天），以应对逻辑错误（如误删表、误删数据）需要回滚的场景。
手动备份
- 手动快照: 在进行重大操作（如版本升级、数据迁移）前，创建一次手动快照，作为“后悔药”。
恢复演练
- 定期演练: 定期测试从备份恢复数据的能力，确保备份是可用的,不要等到灾难发生时才发现备份无效。
监控与维护
监控指标
- 关注核心指标:
- QPS/TPS: 查询和事务吞吐量。
- 慢查询数量: 监控是否有新的慢查询产生。
- CPU 使用率: 是否持续高负载。
- 内存使用率:
innodb_buffer_pool_size是否被
（图片来源网络，侵删）
