数据库索引设计及优化

1.表的索引数量不应有上限,只要所有的SQL都能够流畅的运行。

一个页从磁盘读取到数据缓冲池中,一个页包含多条记录,我们可能需要该页上的所有行或一部分行或一行,但花费的成本都相同,约10ms. 在计算领域中, 10ms是一个很长的时间。
10ms怎么计算出来的:排队时间 + 寻道时间 + 半圈旋转时间 + 传输时间
Q:平均排队时间
U: 平均驱动器繁忙度
S:平均服务时间
Q = (u/(1-u))/S

2.SQL处理过程

select * from user where sex = ‘m’ and (weight > 90 or height > 190)
如果一个索引能满足select查询语句所有谓词表达式,那么优化器就可能建立一个高效的访问路径。

过滤因子描述了谓词的选择性,即表中满足谓词条件的记录行数所占的比例,它主要依赖于列值的分布情况。
组合谓词的过滤因子可能比两个谓词过滤因子的乘积要低的多。
对结果集排序要意味着,即使只需要提取一条记录,也必须物化整个结果集。

磁盘及cpu时间的基础假设:
随机读 10ms
顺序读 40Mb/s

顺序扫描的cpu时间
检查一行记录 5us
fetch 100us

select cno, fname from cust where lname = ‘jack’ and city = ‘beijing’ order by fname

如果结果集有1000行,组合谓词lname 和 city做索引,查询花费的时间 1 * 10ms + 1000 * 0.1 ms = 0.1s 。表没有访问,所需的列值都已经复制到索引中了。

星级给定:
一星 : 减少了扫描的范围;
二星:索引的顺序和查询条件的需求一致, 不需要排序操作
三星:索引行包含查询语句的所有列,避免访问表操作

5.索引设计
发现不合适的索引:
1)基本问题法;是否有一个已存在的或者计划中的索引包含where字句所引用的所有列,如果是否,可以考虑将缺少的谓词列加到索引中(Basic Question, BQ)
2)快速上限估算法;(Quick Upper-Bound Estimate, QUBE)
本地响应时间(LRT)
随机访问的数量:TR
顺序访问的数量:TS
有效FETCH的数量:F
F的成本比TS大一个数量级
比较值:
LRT = TR * 10ms + TS ** 0.01ms
绝对值:
LRT = TR * 10ms + TS * 0.01ms + F * 0.1ms

扫描索引或表的一个片段,那么第一行的读取即为一次随机访问。后续行的读取,每行都是一次顺序访问。顺序访问的成本比随机访问低得多。一次索引访问的成本与一次表访问的成本基本是相同的。
一次顺序读所消耗的时间是0.01ms。顺序访问的时间是指数据库在判断是否接受一行时所做的必要的处理的时间,不管是在索引中还是表中,所有的行都必须进行这一步检测,被拒绝的行将不需要进一步处理。

通过主键索引读取一个表行需要随机访问一次表和随机访问一次索引。
LRT = 2 * 10ms + 0.01ms = 20ms

扫描索引片的过程:需要进行一次随机访问来找到索引片上的第一条符合条件的索引行,直到找到不匹配的行为止,包括访问的最后一个不匹配的行。
1 * 10ms + 1000 * 0.01ms = 20ms

select cno, lname, fname from cust where zip = :zip and lname =: lname order by fname
存在索引(zip,lname, fname)
LRT = 2 * 10ms + 2000 * 0.01ms + 1000 * 0.1ms = 140ms

表记录不是通过聚簇索引访问的,表的1000次访问就会变成随机访问
LRT = 1001 * 10ms + 1000 * 0.01ms + 1000 * 0.1ms = 10s
这种情况下,将列cno加到索引中让索引成为三星索引。可以使本地响应时间从10s降低到0.1s。

BQ方法所提出的问题:是否有一个现有的或者计划中的索引包含了where字句中所涉及的所有列。

设计索引是为了设法让所有 程序都运行得足够快,同时还能够做到不使用过量的磁盘存储、内存和读缓存,且不使磁盘超载。

半宽索引:最大化索引过滤(所有的谓词都在索引列中)
宽索引:只需访问索引

6.影响索引设计的因素
or操作符和布尔谓词
谓词和其他谓词之间为or操作,那么对于优化器而言,他们也可能是困难的。可行的替代方案有全索引扫描,全表扫描,以及多索引扫描。
好的谓词(BT谓词),只要任何一个简单谓词被判定为不满足条件,那么这一行就可以被排除。
不好的谓词(非BT谓词):仅仅不满足谓词A或仅仅不满足谓词B无法排除一行记录

8、为表连接设置索引
连接查询中有两类谓词:本地谓词和连接谓词。
只用于访问一张表的谓词称为本地谓词,定义了表和表之间的连接关系的谓词称为连接谓词。
当谓词具有很高的过滤因子时,全表扫描会很快,当过滤因子较低时,索引扫描会更快。

select cname, ctype, ino, ieur from idate =: idate and cust.cno = invoice.cno
只取前20张发票数据
索引 idate TR = 1 TS = 19
表 invoice TR = 20

索引CNO TR = 20
表 CUST TR = 20
提取 20 * 0.1ms
LRT TR = 61 TS = 19
61 * 10ms + 19 * 0.01ms + 2 ms = 612ms

9、星型连接
星型连接与普通连接的差别:
1)位于星型结构中心位置的表称为事实表,它的数据量远大于它周围的表------维度表
2)最佳的访问路径通常是包含维度表的笛卡儿积。

索引统统比表占用的空间大,原因:
1)表进行了压缩处理,索引没有
2)新增一条记录,表不需要空闲空间,索引需要留足够的空闲时间

  • 0
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
第 1 页 共 19 页 1 引言 1.1 编写目的 一个系统的性能的提高,不单单是试运行或者维护阶段的性能调优的任务,也不单单是开发阶段的事情,而是在整个 软件生命周期都需要注意, 进行有效工作才能达到的。 所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关 的注意事项。 1.2 分析阶段 一 般来说,在系统分析阶段往往有太多需要关注的地方,系统各种功能性、可用性、可靠性、安全性需求往往吸引 了我们大部分的注意力,但是,我们必须注意,性能 是很重要的非功能性需求,必须根据系统的特点确定其实时性需求、 响应时间的需求、硬件的配置等。最好能有各种需求的量化的指标。 另一方面,在分析阶段应该根据各种需求区分出系统的类型,大的方面,区分是 OLTP(联机事务处理系统)和 OLAP (联机分析处理系统) 。 1.3 设计阶段 设计阶段可以说是以后系统性能的关键阶段, 在这个阶段, 有一个关系到以后几乎所有性能调优的过程—数据库设计。 在数据库设计完成后,可以进行初步的索引设计,好的索引设计可以指导编码阶段写出高效率的代码,为整个系统的 性能打下良好的基础。 以下是性能要求设计阶段需要注意的: 1.3.1 数据库逻辑设计的规范化 数据库逻辑设计的规范化就是我们一般所说的范式,我们可以这样来简单理解范式: 第 1 规范:没有重复的组或多值的列,这是数据库设计的最低要求。 第 2 规范 每个非关键字段必须依赖于主关键字,不能依赖于一个组合式主关键字的某些组成部分。消除部分依赖,大 部分情况下,数据库设计都应该达到第二范式。 第 3 规范 一个非关键字段不能依赖于另一个非关键字段。 消除传递依赖, 达到第三范式应该是系统中大部分表的要求, 除非一些特殊作用的表。 更高的范式要求这里就不再作介绍了,个人认为,如果全部达到第二范式,大部分达到第三范式,系统会产生较少的 列和较多的表,因而减少了数据冗余,也利于性能的提高。 1.3.2 合理的冗余 完全按照规范化设计的系统几乎是不可能的,除非系统特别的小,在规范化设计后,有计划地加入冗余是必要的。 冗余可以是冗余数据库、冗余表或者冗余字段,不同粒度的冗余可以起到不同的作用。 冗余可以是为了编程方便而增加,也可以是为了性能的提高而增加。从性能角度来说,冗余数据库可以分散数据库压 力,冗余表可以分散数据量大的表的并发压力,也可以加快特殊查询的速度,冗余字段可以有效减少数据库表的连接, 提高效率。 1.3.3 主键的设计 主键是必要的,SQL SERVER 的主键同时是一个唯一索引,而且在实际应用中,我们往往选择最小的键组合作为主键, 第 2 页 共 19 页 所以主键往往适合作为表的聚集索引。聚集索引对查询的影响是比较大的,这个在下面索引的叙述。 在有多个键的表,主键的选择也比较重要,一般选择总的长度小的键,小的键的比较速度快,同时小的键可以使主键 的 B 树结构的层次更少。 主键的选择还要注意组合主键的字段次序,对于组合主键来说,不同的字段次序的主键的性能差别可能会很大,一般 应该选择重复率低、单独或者组合查询可能性大的字段放在前面。 1.3.4 外键的设计 外键作为数据库对象,很多人认为麻烦而不用,实际上,外键在大部分情况下是很有用的,理由是: 外键是最高效的一致性维护方法,数据库的一致性要求,依次可以用外键、CHECK 约束、规则约束、触发器、客 户端程序,一般认为,离数据越近的方法效率越高。 谨慎使用级联删除和级联更新,级联删除和级联更新作为 SQL SERVER 2000 当年的新功能,在 2005 作 了保留, 应该有其可用之处。我这里说的谨慎,是因为级联删除和级联更新有些突破了传统的关于外键的定义,功能有点 太过强大,使用前必须确定自己已经把握好 其功能范围,否则,级联删除和级联更新可能让你的数据莫名其妙 的被修改或者丢失。从性能看级联删除和级联更新是比其他方法更高效的方法。 1.3.5 字段的设计 字段是数据库最基本的单位,其设计对性能的影响是很大的。需要注意如下: 数据类型尽量用数字型,数字型的比较比字符型的快很多。 数据类型尽量小,这里的尽量小是指在满足可以预见的未来需求的前提下的。 尽量不要允许 NULL,除非必要,可以用 NOT NULL+DEFAULT 代替。 少用 TEXT 和 IMAGE,二进制字段的读写是比较慢的,而且,读取的方法也不多,大部分情况下最好不用。 自增字段要慎用,不利于数据迁移。 1.3.6 数据库物理存储和环境的设计设计阶段,可以对数据库的物理存储、操作系统环境、网络环境进行必要的设计,使得我们的系统在将来能适应比 较多的用户并发和比较大的数据量。 这里需要注意文件组的作用,适用文件组可以有效把 IO 操作分散到不同的物理硬盘,提高并发能力。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值