-
编辑 删除
通用SQL优化经典等价改写【四】——只取所需列
1. 引言在SQL优化中，"只取所需列"是一个简单却常被忽视的优化技巧。许多开发人员习惯性使用SELECT *从表或视图中获取所有列，然后在应用层面过滤出需要的列。这种做法看似方便，却可能导致数据库执行不必要的表连接和列读取，极大影响查询性能。本文将通过一个令人惊讶的案例，展示"只取所需列"如何彻底改变查询的执行计划，甚至减少访问的表数量，从而显著提升性能。
-
编辑 删除
通用SQL优化经典等价改写【三】——插入提速
大规模数据插入是数据库管理中的常见需求，选择合适的插入策略可以显著提升数据加载效率。本文将通过实际测试对比分析Oracle数据库中不同插入策略的性能差异，帮助数据库管理员选择最适合自己场景的数据插入方法...
-
编辑 删除
七座城堡⑨ 混元归一【下】（第一部大结局）
这里的前台其实就是数据库的优化器；厨房的各个区域就是数据库的存储引擎；往返于前台、厨房、餐厅中传达指令的服务员就是数据库的执行器；这里的连锁店就是数据库的分布式技术，由于各个区域的菜系差不多，所以对于数据库来说是似乎是一种复制分片，不过这对我来说也很受启发，复制分片是可以在很多场景发挥作用的。大家是否发现餐饮。这两个故事我稍做总结，请大家参考...
-
编辑 删除
七座城堡⑨ 混元归一【上】（第一部大结局）
老柯的故事暗示了超融合数据库中解决分布式通信与数据一致性的思路，为团队提供了全新的视角。会议还将继续，我们期待老柯分享的第二个故事，以及超融合数据库城堡的具体实现方案…
-
编辑 删除
七座城堡⑧ 困境与应对【下】
老柯一番话给老王带来信心，对未来充满了希望，就在准备告别之时，老王忽然想到有缘人给的那本满是蝌蚪文的书，于是让老柯随他一同看看此书，结果老柯也看的一头雾水，最终决定将书带回家中仔细研究。
-
编辑 删除
七座城堡⑧ 困境与应对【上】
老柯触碰控制台，一幅城市交通全息模型在空中展开。"情况有些复杂，"他声音略显疲惫，“交通拥堵确实缓解了，但效果远低于预期。恐怕庆功宴要暂时搁置了...
-
编辑 删除
通用SQL优化经典等价改写【二】——分页优化
ROWNUM基础与使用限制ROWNUM是Oracle的一个伪列，为查询返回的行顺序分配编号：第一行为1，第二行为2，依此类推。它常用于限制查询返回的总行数，且不能以任何表名作为前缀...
-
编辑 删除
通用SQL优化经典等价改写【一】——case when 改造
SQL优化的核心目标是减少访问路径。前面我们讨论了通过添加索引、分区表等物理设计改进性能的方法，这些属于无需修改SQL就能完成的优化手段。但在许多场景下，通过等价改写SQL也能显著提升性能。本文将重点探讨Case When改造这一强大的优化技巧...
-
编辑 删除
Oracle普通表自动改造分区表（可借鉴到其他数据库）
这是我编写的最经典的工具之一，很实用，技术含金量也比较高。本工具是基于Oracle的，但是这种结合数据字典的方式，是有通用性的，已经改造在PG数据库和部分国产数据库上了。这工具让AI来写，还真靠不住，不信你们可以尝试一下：）
-
编辑 删除
七座城堡⑦机器学习【下】
也就是说，之前的场景对数据的使用主要基于规则，而交通场景对数据的使用则更多依赖基于机器学习。老柯：是的，我们重点再说说数据的采集，交通数据来源繁多，a. 实时交通数据：车辆位置、速度、流量等，这些来源于传感器、监控摄像头、车辆GPS等设备；b. 历史交通数据：过去的交通状况、事故记录等，这些来源于政府数据源、交通管理部门等渠道；c. 天气数据：温度、湿度、降雨量、雪
-
编辑 删除
七座城堡⑦机器学习【上】
在老王的期盼中，GIS数据库城堡如期建成了，随着GIS数据采集录入工作的完成和导航应用程序的完善，商务大臣一行再次出发，前去邀请有缘人。这一次他们异常顺利，在导航的指引下成功抵达目的地，找到了有缘人。有缘人见到商务大臣，知道他们来意后很是开心，表示他已经在此等候多时了。随即有缘人就带上大礼，随着商务大臣一行前往图数据库城堡，参加王子的婚礼。老王得知有缘人已经在返回的途中也非常高兴
-
编辑 删除
七座城堡⑥ GIS【下】
是的，将GIS城堡数据结合进任何一个城堡中，由于要兼顾两种不同类型场景的需求，会增大产生新问题的可能，而眼下我们的这个GIS数据库需求如此急，怕难以有足够的时间打磨优化，所以单独建也可以规避这个风险点。另外我们可以参考时序数据库城堡类似的架构，用基于KV的模式来实现，将点、线、面的数据通过一定的转换存储成键值。有了以前的经验，咱们再建一个城堡的效率还是会很高的。老
-
编辑 删除
七座城堡⑥ GIS【上】
17. 迷失的寻找之路就在老王万分期待之时，却等来了一个坏消息，因为有缘人所住之地偏远且地形复杂，导致商务主管一行迷了路，无功而返。老柯：老王，商务主管一行靠地图确实容易迷路，照着地图是很难准确分辨自己当下的位置，只能靠人自身方位感来判断，即便不犯错，也很难形成最佳路径规划。如果遇到一些突发路况也无法及时获悉，往往地图显示可行，实际道路已经损坏，毕竟纸质地图不可能实时更新。”老王：头疼！你有什么好
-
编辑 删除
七座城堡⑤ 图【下】
在众人期待的目光下，指令发出了，第一个有缘人信息极短时间内即返回，人群欢呼雀跃。很快盒子的十层全部被打开了，真正有缘人的名字和地址水落石出....
-
编辑 删除
七座城堡⑤ 图【上】
有缘人是谁老柯没有让老王失望，时序城堡很快就建成了。接下来，根据剧情经验来看，老王肯定会出现在时序城堡的最高处，而且是在老柯的陪同下检阅脚下的新城堡和四处的城堡，然后各种询问和赞叹。没错，你全猜对了！只是这次和以往有所不同，有彩蛋，老王带着一个神秘的盒子来了。老柯：哎呀，来都来了，还带什么礼物…老王：想得美，这可不能送你！这是我多年前从高人那得到的神秘宝贝，被告之今天才能开启。据说破解其中
-
编辑 删除
七座城堡④ 时序【下】
老王：老柯，要应对如此大规模数据，你建时序城堡时有什么特别的应对策略吗？老柯：为应对当下这种量级的数据，并⽀撑未来可预期的增⻓，数据库架构需要⾮常好的线性扩展能⼒和弹性能⼒，也就是不但能⽀持线性扩展，⽽且扩容速度需要做到⾮常快。所以我的初步想法是，建一个基于NoSQL架构的KV数据库，来应对我们的时序场景。老王（有点懵）：啥，NoSQL，KV？老柯：NoSQL是指
-
编辑 删除
七座城堡④ 时序【上】
很快，HTAP城堡建好了，老王在老柯的陪同下登上了HTAP城堡的最高处，看着井然有序工作着的三个城堡，老王很是满意，心想现在不会再遇到什么困难了吧。于是转头问老柯：“ HTAP城堡建成后，效果如何？”老柯：效果很不错，现在实时分析的场景基本都在这个城堡内完成，让许多业务在决策性的速度和准确性上有了极大提升。有一件事跟您请示一下，目前三座数据库城堡给我们国家带来
-
编辑 删除
七座城堡③HTAP【下】
老柯：老王，咱们王国发展太快了，各种需求层出不穷，将数据的产生和使用不断推向高峰。您看我们这么努力才勉强支撑下来。不过更大的挑战已经来临了，需要我们好好想想对策了。老王：啊，还有挑战？你这波澜起伏的剧情描述，听的我头都晕了。老柯：您还记得之前我说，咱们迎来了快乐王国数据2.0时代吗？老王：记得，难道现在开始快乐王国数据3.0时代了？”老柯：没错...
-
编辑 删除
七座城堡③HTAP【上】
转眼间，OLAP城堡如期建成。当听闻这座城堡的卓越成果后，好学的老王兴奋不已，立即决定前往视察。在老柯的陪同下，老王登上了OLAP城堡的最高处，俯瞰着对面的OLTP城堡。这两座城堡相互呼应，景象壮观，老王心情愉悦。老王：老柯，上次你提到的问题，在这次OLAP城堡建好后应该都解决了吧，具体什么情况，你给我讲讲吧。老柯：老王，建完OLAP城堡之后，我们把OLTP城堡中需要分析
-
编辑 删除
七座城堡② OLAP【下】
老柯：能优化OLAP的方法有很多，我先举最关键最本质的来说，首先就是数据库的存储结构，这是决定OLTP和OLAP性能的重中之重。其中OLTP基于行存的存储效果最佳，什么是行存，也就是数据是一行一行的往数据库块里插，插满了一个数据块，就插下一个数据块。而OLAP则是基于列存的效果最优，什么是列存，那就是一列一列的往数据库块里插，比如一张表有10个列，那就同时往10个块里插
