- 博客(268)
- 收藏
- 关注
RSS订阅
原创 SQL改写的书终于出版了
众所周知，SQL 优化很多 SQL 都是写法上有问题，目前市面上没有这种书籍，为了造福广大Oracle使用者教主和我特意编写 SQL 改写 优化的书籍 ，大家可以到这里购买http://product.china-pub.com/4455744#mlSQL水平比较菜的兄弟们也可以购买运维同志们也可以购买
2020-05-11 09:54:51
9795
1
原创 SQL优化新书《SQL优化核心思想》终于出版了
耗时三年，SQL优化大作终于出版了，有想提升SQL优化水平的同学，可以买本看看本书共10章内容：第一章介绍SQL优化的基础知识；第二章讲解统计信息相关内容；第三章讲解执行计划，快速找出SQL性能瓶颈；第四章讲解常见的访问路径；第五章讲解表的各种连接方式；第六章介绍单表访问以及索引扫描的成本计算，引出优化思想。第七章讲解查询变换；第八章讲解优化技巧；第九章分享经典案例；第十章介绍全自动SQL审核...
2020-05-11 09:54:16
12752
17
原创 恭喜崖山分布式数据库斩获”安全可靠测评“最高等级
崖山数据库作为国内首个在统一内核上同时融合共享存储集群与分布式集群的数据库产品，其融合集群架构基于统一内核（共享集群和分布式集群共用同一套存储引擎、事务引擎和SQL引擎），涵盖单机主备、共享存储集群、分布式集群三大部署形态，可灵活切换，实现“一次选型，持续演进”。6.研发实力层面：崖山DB不是在PG，MySQL上做二次研发，MySQL上限已被锁死，PG性能很强，但是有烦人的表膨胀，崖山内核完全纯自研，带来的是从根本上的自主可控，技术自由和架构领先。
2026-05-27 10:08:25
77
原创 测试Oracle-崖山常规路径INSERT性能
结论：常规路径INSERT，表上面没有索引时，Oracle和崖山INSERT速度差不多，表上面有索引时崖山INSERT速度比Oracle快。Oracle和崖山设置logfile 2GB，检查点超时设置为1800秒，日志量到达2GB触发检查点。2.崖山支持并行INSERT(enable parallel dml)，我这边是虚拟机，暂不做测试。前面测试了Oracle-崖山UPDATE性能，崖山UPDATE比Oracle快一倍。1.崖山不支持/*+ append */，所以不测试直接路径加载。
2026-04-13 15:34:58
78
原创 Oracle-崖山UPDATE和CR块一致读性能测试
总结：崖山UPDATE性能比Oracle快1倍，CR块一致读比Oracle块1倍1，原因在于崖山UNDO量产生比Oracle少接近1倍，单机版崖山性能确实牛逼(国产DB最强)，希望崖山早日修复YAC存在的性能问题。测试发现崖山YAC跨节点全表扫描第一次查询巨慢，相比Oracle慢了20倍，崖山一直在等gc cr request，Oracle无此问题，我把测试结果反馈给崖山内部人士，回复说问题确实存在，已经安排排期紧急优化中。Oracle耗费了2002MB UNDO。崖山把Oracle暴捶了一顿。
2026-04-07 22:02:00
130
原创 崖山数据库-锁可观测性相关视图功能性缺失
我之前看到崖山有个AWR DB CPU占比99.97%， DB CPU 99.97% ORACLE DBA会认为这个数据库系统非常健康，因为绝大部分时间都花费在CPU上，意思就是没有任何等待，但是它还没跑赢MySQL，后面发现排名第二的是死锁相关等待，大概率就是锁相关等待被算入CPU_TIME了，没被算入application_wait_time，最终导致DB CPU算错了。blocking_session和final_blocking_session不光用于TX锁，还用于各种阻塞链路查询。
2026-03-30 16:12:13
202
原创 崖山数据库-谓词没提前过滤优化器BUG
结论：看上去原始SQL没有提前过滤t2.owner = ‘SCOTT’，优化器有BUG。SQL耗时14秒，正常来说应该秒杀才对。
2026-03-30 14:41:00
79
原创 测试ORACLE-崖山NESTED LOOPS性能
全表扫描性能后面我又单独进行了测试，没有WHERE条件(扫描4500W行数据)，崖山全表扫描(4.5s)比Oracle全表扫描(4s)慢0.5s，有WHERE条件(过滤后5023744行数据)崖山全表(3.258s)扫描比Oracle全表扫描(1.75s)慢1.5s。Oracle索引扫描+回表耗时6.49秒，崖山索引扫描+回表耗时4.05秒，确实是崖山索引扫描+回表性能比Oracle快。3.A-Time模式下Oracle索引扫描+回表耗时7.66秒，Oracle索引扫描了500W次共耗时1.82秒。
2026-03-30 13:35:12
301
原创 sqlplus rowprefetch 严重影响order by + rownum性能
既然11.2.0.4没问题，19c有问题，问题又出现在SQLPLUS上，那就对比SQLPLUS中的参数设置，在11.2.0.4的SQLPLUS中show all，在19c的SQLPLUS中show all，19c多了几个参数，rowprefetch引起了我的注意，默认=1，把它设置大点看看能否提升速度。发现这个问题之后，我又到Oracle26ai上进行测试，发现问题依然存在，于是到Oracle11.2.0.4上进行测试，11.2.0.4没有问题，Oracle12c我没测试，不知道有没有问题。
2026-03-25 16:36:31
276
原创 测试Oracle-崖山HASH JOIN性能
HASH JOIN场景太多了，有内连接，外连接，全外连接，半连接，反连接，1个列关联，多个列关联，JOIN+非等值关联过滤，小表JOIN大表，大表JOIN大表，1:1关联，1:N关联，N:N关联，以及各种不同数据类型列关联等等，这么多场景根本测不完，我这里选择大表JOIN大表1:1关联，关联列使用ROWID类型，也算是具有代表性了。测试SQL共4条，测试Oracle19c物理机，Oracle19c虚拟机，崖山23.5.1虚拟机单行模式，崖山23.5.1虚拟机批量模式4条SQL4种场景性能表现。
2026-03-18 13:29:50
295
原创 测试Oracle-崖山排序性能
设置VM_BUFFER_SIZE=8192M后，崖山测试结果比第一次好很多，但是还是比Oracle差，Oracle可是有ON DISK排序，崖山这次没有ON DISK排序，反而比Oracle慢，应该更快才对，崖山的排序算法需要内核再深度优化一下。在崖山数据库中没找到pga，workarea，sort类似参数，查找崖山官方文档，学习Oracle一般是从阅读concepts开始，还好崖山也有concepts，也就是概念手册，我在崖山概念手册—>实例架构—>这个测试结果让人大跌眼镜，难道是遇到BUG了？
2026-03-15 19:17:25
263
原创 测试崖山半连接反连接HASH JOIN是否有刹车功能
Oracle HASH JOIN 上面的表是驱动表，也就是说TEST02是驱动表，崖山TEST02在下面，说明崖山HASH JOIN驱动表行为和PG一样，跟Oracle是反正来的，有点坑啊能不能改成和Oracle一样的。崖山没有半连接HASH JOIN没有刹车功能，TEST01所有数据都被扫描了，逻辑读651026，耗时8秒，反连接HASH JOIN刹车功能就不测了，应该也是没有的。注意：必须是TEST01连接列数据要完全包含TEST02连接列数据才有半连接/反连接 HASH JOIN刹车功能。
2026-02-26 19:10:16
119
原创 测试Oracle-崖山-DM-GaussDB树形查询性能
Oracle深度优先循环了9216次，Oracle广度优先循环了4456K次，ORACLE START WITH CONNECT BY默认用的是深度优先算法，普通的WITH递归用的是广度优先算法，现在破案了，Oracle之所以跑得快是因为默认采用深度优先算法，把需要处理的数据量给缩小了。注意：生产环境不会有这样的大量重复数据，object_id和data_object_id也不是层级关系，严格来说我这个测试不严谨(虽然不严谨，但是能反映问题)，主要是数据不好构造，见谅。4.树形查询能够开启并行查询。
2026-02-10 23:23:41
349
原创 把屁股数据库(PG)优化到底
通过执行计划知道数据库是PG(具体版本没问)，SQL慢在两个子查询上，子查询1被扫描了358613次，子查询2被扫描了41195次，ticket_tab过滤后返回35W行，不然子查询1不可能被扫描35W次，ticket_tab的关联列是id，大概率是主键(没去验证)，ticket_activity_tab的关联列是ticket_id，大概率是外键(没去验证)，想要优化上面SQL，只能想办法减少子查询被扫描次数。下面SQL跑2.1秒(一个PG兄弟请求优化SQL)注意，不要把SQL改写成下面写法。
2026-02-04 23:38:17
142
原创 崖山批量模式(BATCH_MODE=2)真牛逼
强制TEST02当驱动表，TEST02到上面去了，但是TEST01又自动GROUP BY了，HASH JOIN驱动表问题先不纠结了，后面问一下崖山研发。Oracle并行4耗时00:00:01.36，崖山批量模式并行4耗时00:00:00.698，快了接近1倍，牛逼PLUS。崖山批量模式HASH JOIN耗时00:00:02.852，Oracle HASH JOIN耗时00:00:04.67。Oracle耗时00:00:03.62，开启批量模式后崖山耗时00:00:02.204，比Oracle快1.2秒。
2026-02-02 23:29:27
111
原创 测试Oracle-PG-DM-崖山-openGauss游标LOOP性能
虽然我们嘴上说要尽量避免使用游标，但是有时候很多PLSQL代码都已经写了10-20年了，里面大量使用了游标，木已成舟，不可能推翻重来了。如果国产库游标LOOP性能和Oracle差距不大，就加测游标LOOP+INSERT，批量游标，如果性能差距太大就不测了，免得丢人。数据量少(10w行内)，如果没有游标套游标，如果游标中没有复杂慢SQL，如果游标中没有胡乱调用复杂自定义函数，可以适当使用游标。Oracle游标LOOP循环性能最好，游标LOOP带计算性能损失1.29秒。数据量很少，爱咋咋用。
2026-01-26 22:13:24
551
原创 测试崖山是否支持优化器各种消除技术
SQL只取复杂view一个列(来自主表)，但是复杂view后面有一大堆left join group by，因为Oracle没有left join group by消除功能，所以SQL跑得慢。从内核研发角度来说，上面提到的各种消除技术实现并不难，可能是崖山之前没遇到类似场景，也可能是遇到了类似场景，研发主要精力不在这，相信崖山后面很快能实现上述功能。结论：PG(其他国产数据库没测)支持LEFT JOIN GROUP BY消除，Oracle，崖山不支持LEFT JOIN GROUP BY消除。
2026-01-24 21:14:07
713
原创 测试崖山OR EXISTS(子查询)优化器行为
Oracle之所以跑50(设置了statistics_level=all，不设置跑38秒)秒是因为FILTER CACHE失效了，索引IDX_TEST02_OBJECT_ID被扫描了4000多W次。崖山没走FILTER，走的是标量+AGGR PUSHED，耗时6.3秒，这里崖山标量子查询CACHE应该是生效的，不然不可能6.3秒能跑完。在Oracle中会走FILTER，耗时50秒(设置了statistics_level=all，不设置跑38秒)，执行计划如下。
2026-01-18 19:14:43
1113
1
原创 测试崖山是否支持JOIN列谓词推入
下面4条SQL在Oracle19c中均能秒杀，Oracle优化器能够自动的通过JOIN列将谓词推入到视图(子查询)中，限于篇幅，就不贴执行计划了，有兴趣的同学可以自行实验。为了节省篇幅，就不贴剩余3条SQL实验过程了，直接说结论：崖山不能自动谓词推入，需要使用HINT /*+ use_nl(t1,t2) */ 提醒优化器谓词推入。设置参数的谓词推入没有使用HINT谓词推入好，比如FROM后面有2个子查询，一个子查询想谓词推入，一个子查询不想谓词推入。有的读者可能会问，如果数据库没有谓词推入功能怎么办？
2026-01-14 15:11:36
285
原创 测试崖山-DM8-GaussDB-OpenTeleDB数据库在长事务下表和索引是否膨胀
3.openGauss系数据库某发行版，遇到个bug，autovacuum进程一直对某个表空转，其余表长时间没来得及做autovacuum，最终全库表膨胀，CPU一直100%搞个了crontab，每隔一段时间检查n_dead_tup，当n_dead_tup大于某个阈值，检查表上有没有锁，没有锁就人工回收空间，自此之后，每次月结跑批就很稳定了。2.为什么不测试原生PG?后面定位到是索引膨胀，索引上死元组有3到4000W行，索引是十几个字段组成的联合主键，由于死元组有几千万行，批量INSERT到该表，
2026-01-08 22:12:30
713
原创 验证崖山数据库标量子查询是否带有CACHE功能
ID=3 Loops=36757506，这是啥情况(如果有CACHE功能，ID=3的Loops应该显示为2，如果没有CACHE功能Loops应该显示为6)，希望改进和Oracle一模一样。2.崖山SELECT调用自定义函数，如果自定义函数是纯SQL会被优化器自动改写为标量子查询，如果自定义函数不是纯SQL，还是和Oracle一样要人工改写为标量子查询写法。a过滤完之后返回31793行数据，a通过join列谓词推入到d，d被扫描了31793次，a nl d之后累计耗时3.5秒，注意SQL总耗时3.7秒。
2025-12-29 22:30:27
667
1
原创 Oracle-PG-崖山全表扫描基础算子性能对比
如果Oracle是跑在INTEL志强2代,3代,4代下(2，3，4代性能差距不大，挤牙膏，志强5代后提升明显)，使用海光最新CPU替换，同样跑Oracle，性能大概会下降20-30%如果Oracle是跑在INTEL志强2代,3代,4代下(2，3，4代性能差距不大，挤牙膏，志强5代后提升明显)，使用海光最新CPU替换，跑原生PG，性能大概只有Oracle的40%如果Oracle是跑在INTEL志强6代，AMD EYPC ZEN5下，使用海光最新CPU替换，跑原生PG，性能大概只有Oracle的20-25%
2025-12-26 00:31:19
1008
2
原创 OpenTeleDB xstore vs GaussDB ustore表膨胀测试
那么我们就拿OpenTeleDB和GaussDB做个PK吧，看看OpenTeleDB的XSTORE和GaussDB的USTORE谁更强。XStore号称通过原位更新技术，把旧数据写入回滚段，垃圾集中进行清理回收，数据存储空间不再膨胀。电信天翼云最近开源了OpenTeleDB，发布了XProxy、XStore、XRaft三大技术。还可消除对 Vacuum 的依赖，无需再为空间回收与事务冻结而进行频繁维护。
2025-11-05 23:07:51
405
原创 Oracle19c HINT不生效？
在Oracle中，加了HINT，但是不走，要么HINT写错了，要么是Oracle优化器某些特性把HINT忽略了。1.试一试优化器降级，比如降级到11.2.0.4，11.2.0.1看HINT能否生效，如果能生效，大概率遇到了优化器某个特性阻止HINT生效。加了HINT/*+ index(h idx_ef_ap_fee_header_pc) */，但是h走的是IDX_EAFH_SC_SC_BB。如果你遇到了HINT不生效，先检查HINT写对了没，位置放对了没，如果确定HINT没问题。
2025-07-23 22:42:40
625
原创 使用Oracle HINT BITMAP_TREE优化where (col1=xxx or col2=xxx)
想要SFCS_COLLECT_TEST_VALUE表走索引，加HINT INDEX(TV)是不对的，加这个HINT只能走INDEX FULL SCAN。Oracle会抽风，有时候会走BITMAP OR，有时候不走，不走的时候需要把SQL改写为UNION。SQL慢在ID=28，SFCS_COLLECT_TEST_VALUE表被反复多次全表扫描。SFCS_COLLECT_TEST_VALUE表非常大，这条SQL跑了大半天没出结果。熟悉我的读者都知道本人喜欢改写SQL，之前遇到过类似案例，也是做的SQL改写。
2025-07-02 19:36:32
546
原创 PostGreSQL/openGauss表膨胀处理
最后搞个了crontab，每隔一段时间检查n_dead_tup，当n_dead_tup大于某个阈值，检查表上有没有锁，没有锁就人工回收空间，自此之后，每次月结跑批就很稳定了。在PG/OG数据库中，命令vacuum full，插件pg_repack用于处理表膨胀，但是别高兴得太早，如果有长事务，vacuum full执行完之后空间还是无法回收。为什么要先锁住原表呢？我做实验的表比较小，如果表特别大，几十GB，上百GB就不好处理了，所以大表最好分区，分区之后可以按照分区单独处理表膨胀。
2025-04-08 11:28:00
1047
原创 openGauss关联列数据类型不一致引起谓词传递失败
视图dba_tab_columns的定义非常复杂，这里就不贴了，视图dba_tab_columns的table_name没有做类型转换，table_name同样来自pg_class.relname。这是因为dba_tab_columns过滤条件有where table_name = 'psph_t'，并且两个表关联条件是dct.table_name = dtcs.table_name。...........................省略.............................
2025-03-24 21:07:06
1216
原创 openGauss谓词推入失败案例二
Oracle一般都是安装在INTEL志强2代，志强3代CPU上，国产库一般采购的是ARM或者海光的X86处理器，ARM，海光CPU本身的性能就比INTEL志强二代，三代单核慢接近1倍，6.针对案例一以及本案例，其实笔者改写的SQL有点问题，应该将标量子查询放最外面，而笔者放在了最里面，如果前端某个用户选了中间第几千页，标量执行的次数就多了，3.如果没有复杂的包，存储过程，将Oracle迁移至国产库优化工作量是可控的，因为问题都是共性的，一旦有非常复杂的包，存储过程要迁移，这个工作量就很大了。
2025-03-15 16:20:21
1006
原创 openGauss谓词推入失败案例一
A的名字是VW_RME_EQP，以VM开头或者结尾大概率是视图，E的名字是VW_OPTROAD_PIONTRES，E也大概率是视图。这条SQL是典型的分页语句，SQL里面没有聚合函数，没有分析函数，最多返回20行，正常情况下应该秒杀。
2025-03-11 10:34:56
823
1
原创 MogDB&openGauss查询重写规则uniquecheck
在MogDB&openGauss中，参数rewrite_rule用于控制查询重写，本文介绍查询重写规则uniquecheck。子查询test02 t2没有被提升(Oracle的说法是没有被展开)，走了filter，被扫描了4000多万次。设置rewrite_rule=uniquecheck之后，子查询被提升了，t1和t2走了hash join。如果子查询JOIN列(t2.object_id)不唯一，SQL会报错。如果子查询有agg函数，无需设置查询重写参数，可以自动提升。整个SQL耗时10秒，性能较好。
2024-06-02 23:57:19
464
原创 MogDB&openGauss查询重写规则magicset
从执行计划上可以看到test01 t3是大表，有4400W行数据，它走了全表扫描，t2是小表，并且t2还有过滤条件，过滤完之后只有36行数据。disable_pullup_expr_sublink表示禁止子查询提升，效果与添加hint /*+ no_expand */ 一样。如果不想设置rewrite_rule=magicset，也可以对子查询添加/*+ no_expand */达到优化目的。为什么t2会被访问2次呢？从执行计划上可以看到，t2被访问了2次，但是整个SQL语句中，t2只出现了一次。
2024-05-19 21:22:11
583
原创 MogDB&openGauss查询重写规则lazyagg
从执行计划中看到，子查询先进行了GROUP BY，再与test02进行关联，整个SQL GROUP BY了2次。当子查询中有GROUP BY，子查询中的表很大，子查询与外面的表(比较小/过滤完之后数据量少)进行关联之后还有GROUP BY，这个时候就可以开启lazyagg特性，加快SQL性能。从执行计划中看到，子查询中的聚合运算被消除了，子查询中的表test01与test02先做了关联，关联之后再进行GROUP BY，整个SQL只做了1次GROUP BY。2.子查询与外面的表关联之后还有GROUP BY。
2024-05-12 21:06:56
436
原创 MogDB&openGauss中的Bitmap Index Scan
从上面的例子看到，当where条件有limit，不要走Bitmap Index Scan，limit无法刹车。没有force_bitmapor参数，当where条件中有or，想要强制走BitmapOr，禁止全表扫描就行。4. BitmapOr 要注意观察最终返回的数据量，返回数据量少性能较高，返回数据量大，走全表扫描。禁止indexscan，禁止走全表扫描，这个时候只能走Bitmap Index Scan。只有在返回少量数据的情况下BitmapOr性能才高，返回的数据量大，全表扫描性能更高。
2024-05-04 13:45:04
723
原创 MogDB&openGauss导出TYPE对象的DDL
可以先使用gs_dump导出所有对象DDL，再使用shell过滤CREATE TYPTE。在MogDB/openGauss中，可以使用gs_dump导出数据库中所有对象。目前 dbms_metadata.get_ddl 还不支持导出TYPE对象。虽然 dbms_metadata.get_ddl不支持，但是还是有其他方法。
2024-04-30 17:47:40
454
原创 CPU对数据库的性能影响
设置了参数alter system set "_serial_direct_read"=never;intel e5-2667 v4 1.58秒，这颗CPU和E5-2697 v3都是垃圾佬比较关注的CPU。为了避免物理IO的影响，多次反复运行，确保test01全部缓存在buffer cache中。我拿消费级CPU对比服务器CPU是有问题的，毕竟消费级CPU主频比服务器CPU高接近1倍了。从上面的测试结果可以看到，CPU对数据库的影响非常巨大，特别是有跑批业务的情况。最近做了个CPU性能测试，测试语句如下。
2024-02-05 23:39:14
1012
2
原创 利用ORDERED_PREDICATES优化多个自定函数作为WHERE过滤条件
利用ORDERED_PREDICATES优化多个自定函数作为WHERE过滤条件
2022-11-18 16:06:23
988
1
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人