数据库知识学习,数据库设计优化攻略(七)
3.1.3 分布式数据库设计
分布式数据库系统是在集中式数据库系统的基础上发展起来的,理解起来也很简单,就是将整体的数据库分开,分布到
各个地方,就其本质而言,分布式数据库系统分为两种:1.数据在逻辑上是统一的,而在物理上却是分散的,一个分布式数
据库在逻辑上是一个统一的整体,在物理上则是分别存储在不同的物理节点上,我们通常说的分布式数据库都是这种 2.逻
辑是分布的,物理上也是分布的,这种也成联邦式分布数据库,由于组成联邦的各个子数据库系统是相对“自治”的,这种
系统可以容纳多种不同用途的、差异较大的数据库,比较适宜于大范围内数据库的集成。
分布式数据库较为复杂,在此不作详细的使用和说明,只是举例说明一下,现在分布式数据库多用于用户分区性较强的
系统中,如果一个全国连锁店,一般设计为每个分店都有自己的销售和库存等信息,总部则需要有员工,供应商,分店信息
等数据库,这类型的分店数据库可以完全一致,很多系统也可能导致不一致,这样,各个连锁店数据存储在本地,从而提高
了影响速度,降低了通信费用,而且数据分布在不同场地,且存有多个副本,即使个别场地发生故障,不致引起整个系统的
瘫痪。但是他也带来很多问题,如:数据一致性问题、数据远程传递的实现、通信开销的降低等,这使得分布式数据库系
统的开发变得较为复杂,只是让大家明白其原理,具体的使用方式就不做详细的介绍了。
3.1.4 整理数据库碎片
➢ 如果你的表已经创建好了索引,但性能却仍然不好,那很可能是产生了索引碎片,你需要进行索引碎片整理。
什么是索引碎片?
由于表上有过度地插入、修改和删除操作,索引页被分成多块就形成了索引碎片,如果索引碎片严重,那扫描索引的时
间就会变长,甚至导致索引不可用,因此数据检索操作就慢下来了。
如何知道是否发生了索引碎片?
在 SQLServer 数据库,通过 DBCC ShowContig 或 DBCC ShowContig(表名)检查索引碎片情况,指导我们对其进行定时
重建整理。
通过对扫描密度(过低),扫描碎片(过高)的结果分析,判定是否需要索引重建,主要看如下两个:
Scan Density [Best Count:Actual Count]-扫描密度[最佳值:实际值]:DBCC SHOWCONTIG 返回最有用的一个百分比。这
是扩展盘区的最佳值和实际值的比率。该百分比应该尽可能靠近 100%。低了则说明有外部碎片。
Logical Scan Fragmentation-逻辑扫描碎片:无序页的百分比。该百分比应该在 0%到 10%之间,高了则说明有外
部碎片。
解决方式:
一是利用 DBCC INDEXDEFRAG 整理索引碎片
二是利用 DBCC DBREINDEX 重建索引。
两者区别调用微软的原话如下:
DBCC INDEXDEFRAG 命令是联机操作,所以索引只有在该命令正在运行时才可用,而且可以在不丢失已完成工作
的情况下中断该操作。这种方法的缺点是在重新组织数据方面没有聚集索引的除去/重新创建操作有效。
重新创建聚集索引将对数据进行重新组织,其结果是使数据页填满。填满程度可以使用 FILLFACTOR 选项进行配置。这种方
法的缺点是索引在除去/重新创建周期内为脱机状态,并且操作属原子级。如果中断索引创建,则不会重新创建该索引。也
就是说,要想获得好的效果,还是得用重建索引,所以决定重建索引。
相关文章
- 直接在代码里面对list集合进行分页
- .NET Framework 4.5新特性详解
- 大数据的简要介绍
- 大数据的由来
- 高斯混合模型的自然梯度变量推理
- timing-wheel 仿Kafka实现的时间轮算法
- 使用Navicat软件连接自建数据库(Linux系统)
- 那一天,我被Redis主从架构支配的恐惧
- Redis 深入了解键的过期时间
- C#使用委托调用实现用户端等待闪屏
- 基于流计算 Oceanus 和 Elasticsearch Service 构建百亿级实时监控系统
- GRAND | 转录调控网络预测数据库
- JFreeChart API中文文档
- 临床相关突变查询数据库
- TIGER | 人类胰岛基因变化查询数据库
- 视频边缘计算网关EasyNVR在视频整体监控解决方案中的应用分析
- Apache Arrow - 大数据在数据湖后的下一个风向标
- 常见的电商数据指标体系
- AKShare-艺人数据-艺人流量价值
- MySQL中多表联合查询与子查询的这些区别,你可能不知道!