第134期 勘误且自嘲一下(20240115)

数据库管理134期 2024-01-15

  • 第134期 勘误且自嘲一下(20240115)
    • 1 勘误
    • 2 自嘲
    • 总结

第134期 勘误且自嘲一下(20240115)

作者:胖头鱼的鱼缸(尹海文)
Oracle ACE Associate: Database(Oracle与MySQL)
网思科技 DBA总监
10年数据库行业经验,现主要从事数据库服务工作
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP、认证技术专家,ITPUB认证专家,OCM讲师
圈内拥有“总监”、“保安”、“国产数据库最大敌人”等称号,非著名社恐(社交恐怖分子)
公众号:胖头鱼的鱼缸;CSDN:胖头鱼的鱼缸(尹海文);墨天轮:胖头鱼的鱼缸;ITPUB:yhw1809。
除授权转载并标明出处外,均为“非法”抄袭。

1 勘误

上一篇文章,关于Exadata可以不建索引描述有不严谨的地方,这其实是对行业中遇到的一些事的调侃,可能会引发一些误解。有些场景不建索引性能也还行(甚至优于自建环境,毕竟Exadata的综合IO能力还是强不少),因为一体机特性确实Exadata上有些场景使用全表扫用于分析场景性能会更好,但不代表Exadata上不需要索引。(这一部分已经在墨天轮、CSDN、ITPUB的文章中进行的修改,公众号则无法修改,故此勘误)
在去年3月14日我也写了一篇《数据库管理-第六十一期 Exadata是否需要索引(20230314)》(https://blog.csdn.net/yhw1809/article/details/129517338),在实际的生产环境中,用实际的生产数据做测试,测试结果为一个主键可以带来至少15倍的性能提升。从实践来看,必要的索引设计及良好的执行计划管理,是所有平台(包括Exadata上)高效运行的基础。
那么为什么说在一些偏OLAP的分析场景上在Exadata上不建索引可能性能会更好呢,这其实得回到索引本身,一般分析场景往往需要调用对应表的大部分数据,BTREE索引一般当返回行数占总行数的一个比值后,认为全表扫描的代价比索引小(Oracle全表扫描在同等条件下也比其他数据库的全表扫描快一些),查询返回数据量越大索引回表效率越低,有时候优化器就会选择放弃使用索引,这时候Exadata的各种加速特性比如Smart scan offload、存储索引、EHCC、smart flash cache等就能发挥巨大作用,这里可以看看之前文章《数据库管理-第116期 Oracle Exadata 06-ESS-下(202301114)》(https://www.modb.pro/db/1724265332440375296)。

2 自嘲

也许你会发现,这篇文章开头会有点点不一样,从这一期文章开始我将在每篇文章的开头加上自我介绍,也是版权维护的手段,现在太多人对知识产权不重视了,甚至乐于直接抄袭、搬运,拿来作为赚钱、赚流量的工具,最重要的是还不思悔改,甚至反击原创作者和支持重视知识产权的人。这里有必要科普一下相关法律,算了,我也不是律师,免得等下又有人说我不务正业,链接一下百度百科就好《知识产权保护》(https://baike.baidu.com/item/%E7%9F%A5%E8%AF%86%E4%BA%A7%E6%9D%83%E4%BF%9D%E6%8A%A4/6064833),自己阅读,看看自己的行为是不是涉嫌违法了。
愤青时间结束,回到本节主题,开开心心快快乐乐的自嘲一下,主要涉及那几个“外号”。首先“总监”二字主要是源自于我公司给的title,和薛晓刚的“首席”、萧少聪的“主席”类似,既是朋友们的调侃,也算是自嘲,毕竟数据库圈曾几何时“总监”称号得是Oracle ACE Director,当然这个还是我目前的目标。“保安”二字则是参加《国产数据库共话未来趋势·第二期》时,被德哥指定在《是否需要专用时序数据库》专题PK时作为保安维护现场秩序,但是作为圈内人,保安最终还是没忍住下场协助PK,所谓“保安下场,寸草不生”(再次调侃+自嘲);“国产数据库最大敌人”则是《国产数据库共话未来趋势·第三期》担任了主持人,并且发表了题目为《国产数据库最大敌人》的主题分享(这题目交了就后悔想改,无奈宣传已发),主要说的是Oracle海量研发投入与创新发展,这也让我喜提了最新的“歪号”。关于“社交恐怖分子”这个呢,其实自从认识薛首席之后逐渐从“社交恐惧份子”逐渐向“社交牛X份子”最后向“社交恐怖分子”转化。

总结

本期无图,知道写了些啥!

你可能感兴趣的:(数据库,Oracle,数据库)