本文详细探讨了数据库管理的关键概念，包括数据库对象命名规范、备份与恢复策略（如全量、增量和差异备份，以及灾难恢复的RTO和RPO）、安全控制模型（如身份验证、访问控制和加密）、性能管理、表空间、索引和事务处理，以及数据一致性问题。
目录
数据库管理(Database Admin)
数据库对象
制定数据库对象的命名规范
良好的设计是良好的开端
数据库产品本身没有严格的限制。 随意的对象命名会导致系统的不可控，不可维护。
命名规范的几点建议
统一名称的大小写；
利用前缀标识对象类型，如表名前缀t_，视图前缀 v_，函数前缀f_等；
命名尽量采用富有意义、易于记忆、描述性强、简 短及具有唯一性的英文词汇，不建议使用汉语拼音；
以项目为单位，采用名称词典，制定一些公共的缩 略词，如amt代表amount（数量）
数据库的备份和恢复的基本概念（了解）
数据库备份
*备份数据库就是将数据库中的数据，以及保证数据库系统正常运行的有关信息保存起来，以备系统出现 故障后恢复数据库时使用。
备份对象，包括但不限于：
*数据本身；
*和数据相关的数据库对象；
*用户及权限；
* 数据库环境，如配置文件，定时任务等。
数据库恢复
* 将数据库系统从故障或者瘫痪状态恢复到可正常运行，并能够将数据恢复到可接受状态的活动
灾难恢复
企业级容灾
对于企业和单位来说，数据库系统和其他应用系统构成更大的信息系统平台，所以数据库备份恢复并不是孤立的功能点，要和其他应用系统考虑整个信息系统平台的容灭性能。
灾难备份
为了灾难恢复而对数据、数据处理系统、网络系统】基础设施、专业技术能力和运行管理能力进行备份的过程。
恢复时间目标(RTO）
灾难发生后，信息系统或业务功能从停顿到必须恢复的时间要求。
恢复点目标(RPO)
灾难发生后，系统和数据必须恢复到的时间点要求。
RTO（Recovery Time Objective）和RPO（Recovery Point Objective）是灾难恢复规划中的两个关键指标，它们分别从不同维度衡量企业在面临灾难或系统故障时数据恢复能力和业务连续性水平：
补充与理解
RTO（Recovery Time Objective）:
- 定义: RTO是指从灾难发生导致业务中断开始，到IT系统完全恢复到可支持正常业务运作状态所需的时间。换句话说，它是企业能接受的最大业务停机时间，即业务恢复服务功能所需的最短时间周期。
- 关注点: RTO主要关注业务的恢复速度和可用性，它直接影响了企业的业务中断成本和客户满意度。较低的RTO意味着企业希望在较短时间内恢复关键业务功能，以减少潜在的经济损失和信誉损害。
RPO（Recovery Point Objective）:
- 定义: RPO是指在灾难发生后，系统及生产数据能够恢复到的最近状态，即数据丢失的最长时间窗口。具体来说，它是企业能够容忍的从最近的有效数据备份点到灾难发生时刻之间，最大可接受的数据变化量（或时间间隔）。
- 关注点: RPO主要关注数据的完整性和一致性，它决定了在恢复过程中可能丢失的最新业务数据量。较小的RPO意味着企业希望尽可能减少数据丢失，以保证业务记录的准确性和法规遵从性，特别是对于那些对数据时效性要求极高的行业或应用来说尤为重要。
总结来说，RTO与RPO的区别在于：
- 时间 vs. 数据: RTO侧重于业务恢复的时间维度，衡量的是业务中断到恢复正常运作的时间跨度；而RPO侧重于数据恢复的质量维度，衡量的是允许丢失的最近数据更新的程度。
- 可用性 vs. 完整性: RTO关注的是确保业务系统的快速可用，以维持业务连续性；RPO关注的是最大限度地保护数据完整性，避免数据丢失对业务造成实质性影响。
- 影响因素: RTO的确定往往会考虑IT基础设施的冗余度、灾难恢复计划的执行效率、灾备系统的响应速度等因素；而RPO的设定则与备份策略（备份频率、备份方式）、数据同步技术（实时复制、近实时复制）以及数据的重要性密切相关。
在制定灾难恢复计划时，企业需要同时考虑并明确RTO和RPO目标，以确保在预算允许范围内，实现既能满足业务需求又符合风险承受能力的恢复能力。这两个指标共同构成了灾难恢复策略的基础，并指导企业在实际灾难发生时，有效地执行恢复操作，尽快恢复业务运行并最大程度地保留重要数据。
备份方式
根据备份的数据集合的范围
全量备份
差异备份
增量备份
根基是否停用数据库
热备
温备
冷备
根据备份内容
物理备份
逻辑备份
全量备份
也称为完全备份，对某个指定时间点的所以数据和对应的结构进行一个完全的备份。
特点
数据最完备
安全性最高
备份和恢复时间随着数据的体量而明显增加
非常重要，是差异备份和增量备份的基础
备份期间会对系统性能产生一定的影响
差异备份和增量备份
差异备份
差异备份是指上一次全量备份之后，对发生变化的数据进行的备份。
增量备份
增量备份是指上一次备份之后，对发生变化的数据进行的备份
热备，温备和冷备
热备
在数据库正常运行下进行备份。
备份期间，数据库读写均可正常进行。
温备
数据库可用性弱于热备，备份期间，数据库只能进行读操作，不能进行写操作。
冷备
在备份期间，应用的读写操作不可进行。 备份出的数据可靠性最高
物理备份和逻辑备份
数据库系统安全框架
广义范围，分为三个层次：
网络层次安全
操作系统层次安全
数据管理系统层次安全
安全控制模型
安全控制
在数据库应用系统的不同层次提供有意和无意损害行为的安全防范：
加密存取数据-> 有意非法活动
用户身份验证，限制操作权限-> 有意的非法操作
提高系统可靠性和数据备份-> 无意的损害行为
身份验证
数据库用户的身份验证是DBMS提供的最外层安全保护措施。
阻止未经授权的用户的访问。 对于数据库应用目前普遍采用用户名密码验证模式，所以有必要增强密码强度。
采用长度较长的字符串，如8-20个字符；
混合数字，字母和符号的密码
定期更换密码； 密码不能重复使用。 在开发的代码或者脚本中，禁止出现数据库用户的密码明文
访问控制
访问控制是数据库安全中最有效的办法也是最容易出问题的地方。
基本原则
对于不同用户根据敏感数据的分类要求，给予不同的权限
最小权限原则 检查关键权限 检查关键数据库对象的权限
基于角色的权限管理
对于大型数据库系统或者用户数量多的系统，权限管理主要使用基于角色的访问控制(Role Based Access Control，RBAC)
开启审计
审计可以帮助数据库管理员发现现存架构和使用中的漏洞。
数据库审计的层次
访问及身份验证审计，数据库用户登入(logon)，登出(logoff)的相关信息，如登入登出时间， 连接方式及参数信息，登入途径等。
用户与管理员审计：针对用户和管理员执行的活动进行分析和报告。
安全活动监控：记录数据库中任何未授权或者可疑的活动生成审计报告。
漏洞与威胁审计：发现数据库可能存在的漏洞，以及想要利用这些漏洞的“用户”。
数据库加密
数据库加密的不同层次:
DBMS内核层
数据在物理存取之前完成加/解密工作； 对于数据库用户来说是透明的，没有感觉的； 采用加密存储，加密运算在服务器端运行，在一定程度上会加重服务器的负载。
DBMS外层加密
开发专门的加解密工具，或者定义加解密方法； 可以控制加密对象粒度，到表或者字段级别进行加解密； 用户只需要关注敏感信息范围、
资源
供给类资源
这类资源也称为基础资源，是计算机硬件对 应的资源。
操作系统管理的资源。
处理能力：CPU>内存>>磁盘≈网络。
并发性控制资源
这类资源包括但不限于：锁，队列，缓存， 互斥信号等。
数据库系统管理的资源。
性能管理的基本原则
充分利用资源不浪费。
性能管理
意义
资源的高效使用
数据库实际上总是在有限的环境下运行。
对资源的有效管理确保数据库系统在高峰时期能够满足用户对系统的性能要求。
侦测系统问题
实时的系统性能监控（通过数据库提供的日志或者工具进行实时监控系统性能）。
系统历史性能数据跟踪（历史性能数据的分析）。
容量规划
性能管理所收集到的数据是进行系统容量规划及其他前瞻性规划的基础。 用事实而不是感觉说话。
目标
数据库系统的基本指标
吞吐量； 响应时间。
OLTP
在可接受的响应时间基础之上提供尽可能高的吞吐量。
降低单位资源消耗，快速通过并发共享区域，减少瓶颈制约。
OLAP
在有限的资源内尽可能地缩短响应时间。
一个事务应该充分利用资源来加速处理时间。
性能优化工作的一些场景
上线优化或未达到性能期望的性能优化；
响应速度逐渐变慢的系统优化；
系统运行过程中突然变慢的系统优化（应急处理）；
突然变慢，持续一段时间以后又恢复正常；
基于降低资源消耗的系统优化；
预防性的日常巡检工作。
性能管理需要采集的数据
能管理需要采集的数据范围
CPU使用数据；
空间使用率；
使用数据库系统的用户和角色；
心跳查询的响应时间；
提交到数据库的SQL为基本单元的性能数据；
数据库工具提交的作业相关的性能数据（如加载，卸载，备份，恢复等）。
关注的时间范围： 日常范围：一周高峰时段的时间；月度结束的时间；季节变化数据。 一天范围内：用户集中使用系统的时间段；系统压力比较高的时间段等。
建立性能报表
数据库系统内置很多监控报表
提取性能相关的数据建立定期性能报表（日报，周报，月报）。
建立常见指标的性能趋势分析报表，可以对当前系统性能有直观的展现。
特定趋势类型的报表，包括但不限于
基于异常事件的报表；
消耗大量资源的SQL或是作业；
特定用户、用户群的资源消耗报表；
特定应用的资源消耗报表。
数据库重要概念（省略了数据库和数据库实例）
Schema
表空间（Tablespace）（重点掌握作用）
表（Table）
临时表
表出存储方式
存储方式的选择
分区（Partition）
分区剪枝的原理
适用场景
数据分布
数据策略选择
复制（Replication）
适合记录集较小的表
表中数据在各节点上完全复制，各DN都拥有全量数据
Hash/List/Range
这三种方式适合数据量较大的表
分布列选择原则
字段设计建议
尽量使用高效数据类型
尽量使用执行效率比较高的数据类型
尽量使用短字段的数据类型
使用一致的数据类型
当多个表存在逻辑关系时，表示同一含义的字段应该使用相同的数据类型。
对于字符串数据，建议使用变长字符串数据类型，并指定最大长度。
视图（View）
视图的作用
索引（Index）
索引提供指向存储在表的指定列中的数据值的指针，如同图书的目录，能够加快表的查询速度， 但同时也增加了插入、更新和删除操作的处理时间。
在创建索引时，以下建议作为参考：
在经常需要搜索查询的列上创建索引，可以加快搜索的速度。
在作为主键的列上创建索引，强制该列的唯一性和组织表中数据的排列结构。
在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的。
在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时 间。
在经常使用WHERE子句的列上创建索引，加快条件的判断速度。
为经常出现在关键字ORDER BY、GROUP BY、DISTINCT后面的字段建立索引。
有效索引
创建索引≠索引一定被使用
索引创建成功后，系统会自动判断何时引用索引。当系统认为使用索引比顺序扫描更快时，就 会使用索引。
索引创建成功后，必须和表保持同步以保证能够准确地找到新数据，这样就增加了数据操作的 负荷。 需要定期删除无用的索引。
判断方法
通过执行explain语句查看执行计划来判断是否使用索引。
索引方式
约束
约束的设计
事务(Transaction)
事务处理模型
数据不一致情况——脏读
数据不一致情况——不可重复读
事务隔离级别
事务隔离级别遇问题对应表
习题：
ps ：视图，事务，表 还不是很清楚，后续看教学视频，搜索资料必须再做补充。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
