-
编辑 删除
Oracle数据库设计规范篇{六}——索引规范【下】（联合、无、失效索引及数量）
即可以建立 col1,col2 的联合索引，又可以建col2,col1的联合索引，此时如果存在col1 列单独查询较多的情况下，一般倾向于建col1,col2的联合索引...
-
编辑 删除
Oracle数据库设计规范篇{五} ——索引规范【上】（分区、函数、位图及外键的索引）
# 3.索引规范## 3.1 用不上分区条件的局部索引不宜建分区表建立分区索引后，如果在查询应用中无法用到这个分区索引列的条件，索引读将可能遍历所有的分区，如果有100个分区，相当于遍历了100个小索引，将会严重影响性能，此时需要慎重考虑，判断是否需要修改为全局索引。```sql-- 创建分区表CREATE TABLE SALES_HISTORY ( SALE_ID NU
-
编辑 删除
Oracle数据库设计规范篇{四}——物理设计规范【下】（列的设计、命名的规范）
采用有意义的字段名尽量采用有意义的字段名，使描述尽可能清楚，如采用缩写，尽量使用通用的缩写语言...
-
编辑 删除
Oracle数据库设计规范篇{三}——物理设计规范【中】（分区设计规范）
2.3分区设计规范分区表设计总体原则：每个表必须包含以下属性参数: TABLESPACE，PCTUSED，STORAGE。根据表的不同属性进行表类型设计分区表：对于数据量比较大的表，根据表数据的属性进行分区，以得到较好的性能：如果表按某些字段进行增长，则采用按字段值范围进行范围分区。如果表按某个字段的几个关键值进行分布，则采用列表分区。对于静态表，则采用hash分区或列表分区。在范围分区中，如果数
-
编辑 删除
Oracle数据库设计规范篇{二}——物理设计规范【上】（基本规范、表设计规范）
长度规范凡是需要命名的对象其标识符均不能超过30个字符，也即：Oracle中的表名、字段名，函数名，过程名，触发器名，序列名，视图名的长度均不能超过30个字符...
-
编辑 删除
Oracle数据库设计规范篇{一}——表规范
1.表规范 1.1逻辑设计方法及规范一个优秀的数据库设计，应该是满足需求的前提下，实现性能最优的综合考虑，因此，数据库表的设计都应经过2个阶段：逻辑设计阶段（将需求转化为数据库表达的方式），物理设计阶段（对逻辑设计的结果物理调优设计）。1.1.1采用ER模型进行逻辑设计实体关系模型（ER模型，以下简称ER模型）是人们认识客观世界的一种方法、工具。ER模型的设计过程，基本上是两
-
编辑 删除
通用SQL优化经典等价改写【七】——避免使用触发器
数据库设计与开发中，触发器是一种常用的数据库对象，可以在表发生特定事件时自动执行预定义的操作。然而，过度依赖触发器会带来一系列问题，尤其是性能方面的挑战。本文将通过实际案例，详细分析触发器的性能影响...
-
编辑 删除
通用SQL优化经典等价改写【六】——减少函数调用
虽然我们应尽量避免在SQL中使用函数调用，但在实际开发中，有些复杂逻辑已被封装为函数，成为开发规范，开发人员难以避免使用。面对这种情况，即使无法完全避免函数调用，我们仍可通过减少调用次数来显著提升性能...
-
编辑 删除
通用SQL优化经典等价改写【五】——避免函数调用
编写 SQL 时，我们通常要尽量避免在 SQL 中使用函数。可考虑将函数的写法转化为表连接的写法。这是因为在 SQL 里使用函数，会产生大量的递归调用。一般而言，表中有多少条记录，函数就会被调用多少次，这会导致性能急剧下降...
-
编辑 删除
通用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数据采集录入工作的完成和导航应用程序的完善，商务大臣一行再次出发，前去邀请有缘人。这一次他们异常顺利，在导航的指引下成功抵达目的地，找到了有缘人。有缘人见到商务大臣，知道他们来意后很是开心，表示他已经在此等候多时了。随即有缘人就带上大礼，随着商务大臣一行前往图数据库城堡，参加王子的婚礼。老王得知有缘人已经在返回的途中也非常高兴
