1. 如何构建数据库环境1.1. 托管MySQL1.2. VM上构建1.3. 天下没有免费的午餐，每一个选择都伴随着一系列的权衡2. 托管MySQL2.1. 服务商提供了一个可访问的数据库设置程序，而不需要用户深入了解MySQL的具体细节2.2. 使用托管MySQL将缺乏很多的可见性和控制能力2.3. Aurora MySQL2.4. 谷歌云平台（GCP）提供了CloudSQL3. Aurora MySQL3.1. Aurora MySQL是一个兼容MySQL的托管数据库3.2. 将计算和存储分开，这使二者可以更灵活地单独扩展3.3. Aurora中的所有托管解决方案都不兼容MySQL 8.0，而一些较旧的解决方案只兼容MySQL 5.63.4. 标准的Aurora产品是长期运行的计算实例，在其中选择一个实例类型3.5. Aurora集群内的复制完全是Amazon专有的，而不是我们在Oracle MySQL中所知道和使用的复制3.6. Aurora无服务器（Serverless）3.6.1. Aurora MySQL的无服务器服务移除了长期运行的计算程序，并利用亚马逊的无服务器平台为数据库的计算层提供服务3.7. Aurora全局数据库（Global Database）3.8. Aurora多主节点（Multi-Master）3.8.1. 多主节点是Aurora集群的一种特殊风格，可以同时在多个计算节点上接受写操作4. GCP Cloud SQL4.1. Cloud SQL是GCP的托管MySQL的产品4.2. 它运行的是社区版MySQL，但特别禁用了某些功能，以实现产品的多租户和可管理4.3. SUPER权限被禁用4.4. 插件加载功能被禁用4.5. 一些客户端也被禁用了，如mysqldump和mysqlimport4.6. 原生的高可用性支持4.7. 静止数据的原生加密4.8. 使用多种方法实现灵活管理的升级5. 虚拟机上的MySQL5.1. 在虚拟机上运行MySQL就像在裸金属服务器上运行一样，你可以完整和彻底地控制所有的操作面5.2. CPU5.2.1. 虚拟CPU，而不是物理CPU5.2.2. vCPU数量的计数公式5.2.2.1. （CPU核的数量×95%CPU总使用量）×25.2.2.2. 建议将50%作为常规的使用率目标，最高可达到65%～70%5.2.2.3. 如果维持在70%或更高的CPU使用率，将可能会看到延迟增加，此时应该考虑添加更多的CPU5.2.3. 运行的是一个高流量的Web应用程序，则可能需要确保使用更新一代的芯片5.3. 内存5.3.1. RAM可以极大地影响MySQL的性能5.3.2. 应为工作数据集选择最适合需求的机器规格，但错误的做法是RAM太多而不是不够5.4. 网络性能5.4.1. 如果有一个将读取大量数据的批处理进程，则你可能会发现在较小的机型上带宽已耗尽5.5. 选择正确的磁盘类型5.5.1. 高读密集型的工作负载将受益于更多的内存而不是磁盘性能，因为内存访问要快几个数量级5.5.2. 如果工作集大于InnoDB缓冲池，那么将总是需要到磁盘上读取一些数据5.5.3. 写密集型的工作负载总是会转移到磁盘上，这也是大多数人第一次看到磁盘瓶颈的地方5.6. 磁盘的连接类型5.6.1. 本地连接磁盘的好处是，其提供了令人难以置信的高性能和一致的吞吐量，但也很容易导致数据丢失5.6.1.1. 被视为仅用于短暂数据的磁盘5.6.2. 网络连接的磁盘可提供冗余和可靠性5.6.2.1. 网络连接的磁盘可能会遇到本地连接的磁盘不会出现的停顿5.6.3. 还可以使用磁盘快照技术让副本复制变得非常快，即使在许多TB级大小的磁盘上5.6.3.1. 可以让需要在副本可用之前赶上来的复制的延迟降到最低5.7. SSD与HDD5.7.1. SSD的启动速度比HDD快两到三倍5.7.2. 如果启动时间很重要，特别是在停机或重新启动的情况下，那么请始终使用SSD5.8. IOPS和吞吐量5.8.1. Percona Toolkit包中的pt-diskstats5.9. 只允许服务器恢复在线和复制，以让它自己自然地重新连接5.9.1. 使用SSD引导磁盘来允许尽可能快地重新启动。通常系统会在5分钟内恢复在线5.9.2. 禁止长达5分钟时间内的任何服务器宕机的告警通知，以使系统完全重启并恢复正常5.9.3. 如果源服务器重新启动，你可以编写一个选项来动态关闭read_only标志，从而让写入在没有人工干预的情况下继续进行5.9.4. 通过自动地向可能需要了解中断的团队或渠道发送邮件或消息，来让沟通最大化5.10. 建议将操作系统和MySQL数据分开5.10.1. 磁盘快照将仅限于MySQL数据，并且不包含任何操作系统信息5.10.2. 在使用网络连接的磁盘的情况下，可以轻松地断开磁盘的连接并重新连接到另一台机器5.10.3. 对于网络连接的磁盘，还可以升级或替换操作系统，而不必将数据重新复制到文件系统中5.11. 备份二进制日志5.11.1. 将二进制日志发送到一个存储桶中5.11.2. 在桶上设置生命周期控制，以便在一段确定的时间后自动清除旧文件5.11.3. 阻止在特定时间之前删除文件，或完全不允许删除5.11.4. 控制谁可以读取或删除这些数据对于维护安全的备份策略至关重要5.11.5. 建议允许所有数据库机器写入，但没有机器能够读取或删除。分别或同时控制受限账户、机器的读取和删除5.12. 自动扩展磁盘5.12.1. 对于网络连接的磁盘，需要为预分配的而不是已使用的空间付费5.12.2. 一种优化方法是将磁盘空间使用率目标提到更高的百分比6. 合规性6.1. DBA的工作并不局限于在业务运行时管理这些数据，还需要帮助企业保护数据，并使数据符合法律要求，或获得对企业至关重要的监管认证6.2. 合规是一个涉及政策和控制的广泛领域，对每种政策和控制的解释也很多6.3. GRC6.3.1. 治理（Governance）6.3.2. 风险管理（Risk management）6.3.3. 合规性（Compliance）6.4. 控制是公司内部定义的流程和规则，用于减少意外风险结果发生的概率6.5. 合规性的构建是一个持续的过程，在需要的时候不容易“添加”6.6. 法规法案6.6.1. 服务组织控制类型2（SOC 2）6.6.2. 2002年发布的萨班斯-奥克斯利法案（SOX）6.6.3. 支付卡行业数据安全标准（PCI-DSS）6.6.4. 1996年发布的《健康保险可携带性和责任法案》（HIPAA）6.6.5. 联邦风险和授权管理计划（FedRAMP）6.6.6. 通用数据保护条例（GDPR）是欧盟于2016年推出的6.6.7. 2020年，欧盟司法法院裁决了欧盟和Facebook爱尔兰分部之间的一桩案件。这项通常被称为Schrems II6.7. 不要共享用户6.7.1. 不要跨服务共享数据库凭据6.8. 不要在代码仓库中提交生产数据库凭据6.8.1. 一种常见的做法是在合并一个pull请求之前，扫描代码库寻找潜在的机密字符串（GitHub等代码仓库托管服务可以实现6.9. 确保密码始终以加密方式而不是以明文形式存储6.9.1. 机密信息的长度做了限制，如果想存储比数据库的用户和密码对更长的内容，可能会导致意外6.10. 区域的可用性6.11. 角色与数据分离6.11.1. 基于数据泄露将给企业或客户带来的风险等级对数据进行分离6.12. 出于合规性原因进行分片6.13. 独立的数据库用户6.14. 跟踪变更6.14.1. 很多合规性法规都附带了跟踪变更的控制措施6.15. 很多合规性法规都附带了跟踪变更的控制措施6.16. ⑩数据访问日志6.16.1. 要求维护特定数据集的变更日志或访问日志6.16.2. Percona审计日志插件是Percona发行的MySQL分支的一部分，但是默认情况下没有安装或启用6.17. ⑾schema变更的版本控制6.18. 建议设置这样一个策略：“删除六个月内未连接过数据库的用户”。这一做法将有助于防止使用不需要的、现在已成为负担的访问7. 不建议使用触发器7.1. 触发器会导致写性能下降，这会在最糟糕的时候对性能造成影响7.2. 触发器相当于在数据库中存储业务逻辑，这是不推荐的7.3. 在数据库中存储代码可能会绕过测试、转移和部署代码的任何过程。触发器可能意外地导致故障7.4. 触发器只能支持跟踪写入操作。无法扩展成可以跟踪读取访问的解决方案
