html5 网站后台,网站建设做网站好做吗,西安哪里有做网站的,wordpress建设的网站10.6. 数据库开发常识
作为一名专业数据库开发人员#xff0c;不但需要掌握数据库开发相关的语法和功能实现#xff0c;还要掌握专业数据库开发的常识。这样#xff0c;才能在保量完成工作任务的同时#xff0c;也保质的完成工作任务#xff0c;避免了为应用的日后维护埋…10.6. 数据库开发常识
作为一名专业数据库开发人员不但需要掌握数据库开发相关的语法和功能实现还要掌握专业数据库开发的常识。这样才能在保量完成工作任务的同时也保质的完成工作任务避免了为应用的日后维护埋下性能和稳定性方面的隐患。可遗憾的是现实中很大一部分的专业开发人员只能做到保量的完成工作任务而做不到既保量也保质。这也就不难解释现实中为什么很多应用系统上线后性能和稳定性等方面还频繁的出现问题。
这里所谓的数据库开发常识指经过长期不断的基础理论和实践经验的积累与沉淀专业人员获得的数据库开发方面的规律和结论用以帮助提高数据库开发工作的效率更重要的是保证开发成果的质量。
下面仅就实际工作中最常遇到的也是最常用到的数据库开发常识进行介绍和说明以期对各位有所启发和帮助。
10.6.1. 判断SQL性能的标准
目前几乎所有高版本关系库RDBRelational Database的优化器都是CBO见本专栏6.1节的那么判断一条SQL语句性能好坏的标准只有一个那就是执行计划Explain Plan及其成本。拿到一条SQL语句的执行计划前我们没办法准确判断其性能的好坏及问题所在。因此我们不但要掌握获取执行计划的方法也要学会查看和分析执行计划起码要会查看和分析简单的执行计划。
10.6.2. 索引相关误区
1走索引一定是最优的。
查看和分析执行计划时有一个大家似乎公认的调优原则那就是走FTS就一定是错的存在性能问题的走index就一定是对的是最优的。针对这种观点我只能说不一定要看具体的实际情况。大家先考虑下为什么这么说为了便于理解我们考虑两个比较极端的场景。
第一个场景假设表里的数据比较少一个数据块就能容纳并且表的相应列上有B*Tree索引假设索引也只有一个数据块。我们哪怕只访问表里的一条数据时当不走索引时我们只需读取一个数据块就可以那就是表的所有数据块如果走索引那么就得读取两个数据块先读索引块然后读表的数据块大家比较下哪个成本高哪个成本低呢另一个场景假设一个表有100个数据块索引有20个数据块。当我们读取表里90%的数据时如果不走索引那么只需要读取表的100个数据块而如果走索引就得读取至少1890108个数据块。这么看走索引似乎有点得不偿失大家比较下该场景下哪个成本高哪个成本低呢当然以上只是通过这两个极端、理想的场景说明一个道理走index未必最优走FTS也未必就有问题。现实中场景和成本计算都要比这里复杂得多也还会涉及到其他概念和因素例如FTS的并行多块读index的顺序读索引的聚簇因子Cluster Factor等这些都会影响SQL语句的最终执行计划。
--注 1大家思考下当读取相同的数据块数时并行多块读和顺序读的区别和结果分别是什么 2这里大家需要思考一个问题那就是在现实工作中有时查询一张表所读取的数据块数比整张表的数据块数还要多有时是整张表数据块数的几倍甚至几十倍为什么
2索引可随便创建
现实工作中很多公司或机构的开发库、测试库甚至生产库的管理和权限控制既很不严格也非常不规范。所有或部分员工都可以随便访问数据库且都拥有修改数据、建立、删除索引及其他对象甚至数据库的最高权限。现实中由于员工随便删除索引导致事故的案例并不稀奇因员工随便乱建索引而引发数据库负载居高不下、性能陡降甚至引起严重事故的现象也是屡见不鲜。
因此规范数据库管理和严控数据库权限尤其是机构生产库的管理和权限会很大程度上避免事故的发生和减少由此带来的损失。由此也杜绝了无序的乱建索引而引发的一系列问题和后果。现实工作中除非确定索引能极大的改善某个应用模块或操作的性能且不会对其他应用模块或操作带来负面影响否则还是三思而后行最好通过规范的流程和渠道去分析、确定和实施索引策略。
--注 1大家思考下删除索引为什么会导致事故随便建索引又为什么会导致负载居高不下、性能陡降甚至引起事故
