PostgreSQL SQL优化用兵法，优化后提高 140倍速度
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2720人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6群均已爆满，7群430+，开8群170+ 9群)
今天的领悟，人生没有白走的，对错都算数，做完一些事情，经常会后悔，如果我当时选择了A，就好了，可我当时选择的是B，然后不断地悔恨。人的眼睛都是长在前面的，选择就选择了，错了就错了，错了吸收教训，不要再犯就好，当时我也站在迷雾中，也很迷茫，哪怕在给我一次机会，还是会选择B，与其后悔，不如持续修炼--- 一个现实世界的“申公豹”留言。
SQL 的优化是DBA工作的主题，这里我想以这篇文章，将SQL优化的方式方法，以及程序员的撰写SQL的问题说清楚，如果有不周之处还请各位老师指点一二。
SQL 本身是什么，完成什么功能这点做DBA的同学要清晰。
1 SQL是程序完成数据输入，输出的必经之路
2 SQL是程序搜取数据不多方案中的最有效的数据提取方案
3 SQL除了必备的数据提取功能，还有数据处理和计算的功能
4 SQL可能完成了程序功能的一部分，甚至是程序核心的一部分
5 SQL是大部分程序中的热点，是一个程序运行好坏的至关重要的一部分
明白了这些SQL的运行的好坏与程序之间的关系就明确了。
为什么SQL就不能一次性写好
1 程序生成的SQL，通过程序将代码转换为SQL，这样的SQL明显不能进行优化的写法实现，在系统初步运行的过程可以接受这样的写法，但在系统高负载的情况下，则这样的SQL就是问题的爆发点。
2 乱建索引，这点很常见，索引的好坏影响SQL的运行。一个好的索引可以助力SQL快速的运行，一个差劲的索引是SQL运行的阻碍，乱建的方式
1 每个字段建立一个索引
2 将很多的字段建立索引
3 不按照语句的规律和查询的字段顺序和方式建立索引
4 索引重复建设 （ORACLE没有这个问题，其他都有）
5 语句作废后的无用索引的滞留
3 业务持续变化，SQL语句从简单到复杂，程序员把SQL当程序写，希望一个SQL解决所有需求（这是产生问题的关键）
下面我们用一个SQL和执行计划来说明如何快速的分析一个PG的SQL的优化点。咱们先看语句
这个语句有几个问题
1 语句中使用了数据源嵌套方式，也就是select * from (select * from )我们俗称的子查询，子查询实际上也没有什么问题，关键是子查询中的SQL复杂度和SQL所过滤后的数据量。在子查询中的过滤后的数据量较大的情况下就会产生临时表，SQL过于复杂会增加产生执行计划准确度的难度。所以我们在撰写SQL都希望通过 join的方式来表达表和表之间的关系，并获得关系后的并集，交集等数据结果。
SELECT
ata.planId,
ata.detail_di,
ata.item_di,
ata.item_code,
ata.item_name,
ata.item_pinyin,
ata.unit_di,
ata.unit_name,
ata.enable_muti_size,
ata.small_class_di,
ata.small_class_code,
ata.small_class_name,
ata.lane_di,
ata.lane_name,
ata.standardTime,
ata.warnTime,
SUM(ata.maxQty) AS maxQty
FROM
(
SELECT
kifd.itemfilter_di AS planId,
kifd.detail_di,
ai.di AS item_di,
ai.code AS item_code,
ai.NAME AS item_name,
ai.pinyin AS item_pinyin,
ai.unit_di,
f_get_unit_name (ai.unit_di) AS unit_name,
ai.enable_muti_size,
aic2."di" AS small_class_di,
aic2.code AS small_class_code,
aic2.NAME AS small_class_name,
kifd.lane_di,
kifl.lane_name AS lane_name,
ki.standard_time AS standardTime,
ki.warn_time AS warnTime,
bmcd.maxqty AS maxQty
FROM
kc_itemfilter AS kif
INNER JOIN kc_itemfilter_detail AS kifd ON kif.di = kifd.itemfilter_di
AND kifd.setting_mode = 0
LEFT OUTER JOIN kc_itemfilter_lane AS kifl ON kifd.lane_di = kifl.di
INNER JOIN _item AS ai ON ai.di = kifd.detail_di
AND ai.delflg = 0
AND ai.is_enable = TRUE
AND ai.is_package = FALSE
AND ai.create__di = '160539'
INNER JOIN _item_class AS aic2 ON ai.small_class_di = aic2.di
AND aic2.delflg = 0
AND aic2.LEVEL = 1
AND aic2.create__di = '160539'
LEFT JOIN kc_item AS ki ON ai.di = ki.item_di
AND ki.item_size_di = -1
AND ki.delflg = 0
AND ki.belong__di = '160540'
LEFT JOIN bm_machine_combine_dishes AS bmcd ON ai.di = bmcd.item_di
AND bmcd.size_di = -1
AND bmcd.delflg = 0
AND bmcd.create__di = ai.create__di
WHERE
kifd.itemfilter_di IN ('16053900000000001')
UNION
SELECT
kifd.itemfilter_di AS planId,
kifd.detail_di,
ai.di AS item_di,
ai.code AS item_code,
ai.NAME AS item_name,
ai.pinyin AS item_pinyin,
ai.unit_di,
f_get_unit_name (ai.unit_di) AS unit_name,
ai.enable_muti_size,
aic2."di" AS small_class_di,
aic2.code AS small_class_code,
aic2.NAME AS small_class_name,
kifd.lane_di,
kifl.lane_name AS lane_name,
ki.standard_time AS standardTime,
ki.warn_time AS warnTime,
bmcd.maxqty AS maxQty
FROM
kc_itemfilter AS kif
INNER JOIN kc_itemlter_detail AS kifd ON kif.di = kifd.itemfilter_di
AND kifd.setting_mode <> 0
LEFT OUTER JOIN kc_iteilter_lane AS kifl ON kifd.lane_di = kifl.di
INNER JOIN _item AS ai ON ai.small_class_di = kifd.detail_di
AND ai.delflg = 0
AND ai.is_enable = TRUE
AND ai.is_package = FALSE
AND ai.create__di = '160539'
INNER JOIN _item_lass AS aic2 ON ai.small_class_di = aic2.di
AND aic2.delflg = 0
AND aic2.LEVEL = 1
AND aic2.create__di = '160539'
LEFT JOIN kc_item AS ki ON ai.di = ki.item_di
AND ki.item_size_di = -1
AND ki.delflg = 0
AND ki.belong__di = '160540'
LEFT JOIN mach_cobine_dishes AS bmcd ON ai.di = bmcd.item_di
AND bmcd.size_di = -1
AND bmcd.delflg = 0
AND bmcd.create__di = ai.create__di
WHERE
kifd.itemfilter_di IN ('16053900000001')
) AS ata
GROUP BY
ata.planId,
ata.detail_di,
ata.item_di,
ata.item_code,
ata.item_name,
ata.item_pinyin,
ata.unit_di,
ata.unit_name,
ata.enable_muti_size,
ata.small_class_di,
ata.small_class_code,
ata.small_class_name,
ata.lane_di,
ata.lane_name,
ata.standardTime,
ata.warnTime
ORDER BY
small_class_codeQUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
GroupAggregate (cost=4296.87..4296.98 rows=2 wdith=861) (actual time=2067.727..2068.947 rows=1068 loops=1)
Group Key: aic2.code, kifd.itemfilter_di, kifd.detail_di, ai.di, ai.code, ai.name, ai.pinyin, ai.unit_di, (f_get_unit_name(ai.unit_di, false)), ai.enable_muti_size, aic2.di, aic2.name, kifd.lane_di, kifl.lane_name, ki.standard_time, ki.warn_time
-> Sort (cost=4296.87..4296.87 rows=2 wdith=857) (actual time=2067.714..2067.804 rows=1068 loops=1)
Sort Key: aic2.code, kifd.itemfilter_di, kifd.detail_di, ai.di, ai.code, ai.name, ai.pinyin, ai.unit_di, (f_get_unit_name(ai.unit_di, false)), ai.enable_muti_size, aic2.di, aic2.name, kifd.lane_di, kifl.lane_name, ki.standard_time, ki.warn_time
Sort Method: quicksort Memory: 200kB
-> Unique (cost=4296.75..4296.84 rows=2 wdith=857) (actual time=2065.780..2066.441 rows=1068 loops=1)
-> Sort (cost=4296.75..4296.75 rows=2 wdith=857) (actual time=2065.778..2065.865 rows=1068 loops=1)
Sort Key: kifd.itemfilter_di, kifd.detail_di, ai.di, ai.code, ai.name, ai.pinyin, ai.unit_di, (f_get_unit_name(ai.unit_di, false)), ai.enable_muti_size, aic2.di, aic2.code, aic2.name, kifd.lane_di, kifl.lane_name, ki.standard_time, ki.warn_time, bmcd.maxqty
Sort Method: quicksort Memory: 200kB
-> Append (cost=736.35..4296.74 rows=2 wdith=857) (actual time=3.874..2063.680 rows=1068 loops=1)
-> Nested Loop Left Join (cost=736.35..2148.02 rows=1 wdith=145) (actual time=3.873..2060.342 rows=1068 loops=1)
Join Filter: ((bmcd.create__di = ai.create__di) AND (ai.di = bmcd.item_di))
-> Nested Loop Left Join (cost=736.35..2051.28 rows=1 wdith=113) (actual time=2.937..1589.088 rows=1068 loops=1)
Join Filter: (ai.di = ki.item_di)
Rows Removed by Join Filter: 1167324
-> Nested Loop Left Join (cost=18.37..697.16 rows=1 wdith=109) (actual time=0.621..15.154 rows=1068 loops=1)
-> Nested Loop (cost=18.23..697.00 rows=1 wdith=101) (actual time=0.615..13.895 rows=1068 loops=1)
-> Nested Loop (cost=18.09..695.73 rows=1 wdith=101) (actual time=0.593..10.341 rows=1068 loops=1)
-> Hash Join (cost=17.80..692.98 rows=2 wdith=77) (actual time=0.075..3.503 rows=1088 loops=1)
Hash Cond: (ai.small_class_di = aic2.di)
-> Index Scan using dix__item on _item ai (cost=0.29..674.36 rows=425 wdith=57) (actual time=0.020..2.010 rows=1088 loops=1)
Index Cond: (create__di = 160539)
Filter: (is_enable AND (NOT is_package) AND (delflg = 0))
Rows Removed by Filter: 7
-> Hash (cost=17.35..17.35 rows=13 wdith=28) (actual time=0.039..0.040 rows=18 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> Index Scan using dix__item_class on _item_class aic2 (cost=0.28..17.35 rows=13 wdith=28) (actual time=0.012..0.032 rows=18 loops=1)
Index Cond: (create__di = 160539)
Filter: ((delflg = 0) AND (level = 1))
Rows Removed by Filter: 14
-> Index Scan using pk_kc_itemfilter_detail on kc_itemfilter_detail kifd (cost=0.29..1.37 rows=1 wdith=24) (actual time=0.005..0.005 rows=1 loops=1088)
Index Cond: ((itemfilter_di = '16053900000000001'::bigint) AND (detail_di = ai.di))
Filter: (setting_mode = 0)
-> Index Only Scan using pk_kc_itemfilter on kc_itemfilter kif (cost=0.14..1.26 rows=1 wdith=8) (actual time=0.002..0.003 rows=1 loops=1068)
Index Cond: (di = '16053900000000001'::bigint)
Heap Fetches: 1068
-> Index Scan using pk_kc_itemfilter_lane on kc_itemfilter_lane kifl (cost=0.14..0.16 rows=1 wdith=16) (actual time=0.000..0.000 rows=0 loops=1068)
Index Cond: (di = kifd.lane_di)
-> Bitmap Heap Scan on kc_item ki (cost=717.98..1347.36 rows=541 wdith=12) (actual time=1.095..1.380 rows=1094 loops=1068)
Recheck Cond: (belong__di = 160540)
Filter: ((item_size_di = '-1'::integer) AND (delflg = 0))
Rows Removed by Filter: 18
Heap Blocks: exact=52332
-> Bitmap Index Scan on pk_kc_item (cost=0.00..717.84 rows=1102 wdith=0) (actual time=1.086..1.086 rows=1150 loops=1068)
Index Cond: (belong__di = 160540)
-> Seq Scan on bm_machine_combine_dishes bmcd (cost=0.00..96.48 rows=1 wdith=16) (actual time=0.410..0.410 rows=0 loops=1068)
Filter: ((size_di = '-1'::integer) AND (delflg = 0) AND (create__di = 160539))
Rows Removed by Filter: 3012
-> Nested Loop Left Join (cost=736.35..2148.69 rows=1 wdith=145) (actual time=2.957..2.961 rows=0 loops=1)
Join Filter: ((bmcd_1.create__di = ai_1.create__di) AND (ai_1.di = bmcd_1.item_di))
-> Nested Loop Left Join (cost=736.35..2051.94 rows=1 wdith=113) (actual time=2.956..2.960 rows=0 loops=1)
Join Filter: (ai_1.di = ki_1.item_di)
-> Nested Loop Left Join (cost=18.37..697.82 rows=1 wdith=109) (actual time=2.955..2.959 rows=0 loops=1)
-> Nested Loop (cost=18.23..697.23 rows=1 wdith=101) (actual time=2.955..2.958 rows=0 loops=1)
-> Nested Loop (cost=18.09..695.96 rows=1 wdith=101) (actual time=2.955..2.957 rows=0 loops=1)
-> Hash Join (cost=17.80..692.98 rows=2 wdith=85) (actual time=0.077..1.179 rows=1088 loops=1)
Hash Cond: (ai_1.small_class_di = aic2_1.di)
-> Index Scan using dix__item on _item ai_1 (cost=0.29..674.36 rows=425 wdith=57) (actual time=0.020..0.788 rows=1088 loops=1)
Index Cond: (create__di = 160539)
Filter: (is_enable AND (NOT is_package) AND (delflg = 0))
Rows Removed by Filter: 7
-> Hash (cost=17.35..17.35 rows=13 wdith=28) (actual time=0.042..0.043 rows=18 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> Index Scan using dix__item_class on _item_class aic2_1 (cost=0.28..17.35 rows=13 wdith=28) (actual time=0.012..0.030 rows=18 loops=1)
Index Cond: (create__di = 160539)
Filter: ((delflg = 0) AND (level = 1))
Rows Removed by Filter: 14
-> Index Scan using pk_kc_itemfilter_detail on kc_itemfilter_detail kifd_1 (cost=0.29..1.37 rows=1 wdith=24) (actual time=0.001..0.001 rows=0 loops=1088)
Index Cond: ((itemfilter_di = '16053900000000001'::bigint) AND (detail_di = ai_1.small_class_di))
Filter: (setting_mode <> 0)
-> Index Only Scan using pk_kc_itemfilter on kc_itemfilter kif_1 (cost=0.14..1.26 rows=1 wdith=8) (never executed)
Index Cond: (di = '16053900000000001'::bigint)
Heap Fetches: 0
-> Index Scan using pk_kc_itemfilter_lane on kc_itemfilter_lane kifl_1 (cost=0.14..0.57 rows=1 wdith=16) (never executed)
Index Cond: (di = kifd_1.lane_di)
-> Bitmap Heap Scan on kc_item ki_1 (cost=717.98..1347.36 rows=541 wdith=12) (never executed)
Recheck Cond: (belong__di = 160540)
Filter: ((item_size_di = '-1'::integer) AND (delflg = 0))
-> Bitmap Index Scan on pk_kc_item (cost=0.00..717.84 rows=1102 wdith=0) (never executed)
Index Cond: (belong__di = 160540)
-> Seq Scan on bm_machine_combine_dishes bmcd_1 (cost=0.00..96.48 rows=1 wdith=16) (never executed)
Filter: ((size_di = '-1'::integer) AND (delflg = 0) AND (create__di = 160539))
Planning Time: 7.995 ms首先看到这么一大坨语句和执行计划，都犯怵，但是我们要快速优化SQL需要有方法，有了方法就可以快速的将60%-80%的问题解决。
1 识别关键词 GroupAggregate : 这个词在PG中时进行聚合操作，这标明这里有GROUP BY 或者分组聚合类的操作。
sort： 排序，看到这个词说明查询结果需要进行排序
unique: 看这个说明有去重操作
append: 看到这个词说明查询结果需要合并
Nested Loop Joins: 说明两个结果及进行了笛卡尔积操作
Bitmap Heap Scan : 将数据转换为位图后进行扫描
index scans: 在索引上进行全扫
seq scan : 全表扫描
另外我在分析PostgreSQL SQL的会注意一个部分，rows removed by filter
1 如果有大量的行被移除，说明在这个操作过程中有大量不符合条件的数据被移除，不符合条件就有可能是索引缺少或索引错误导致的，并且会产生大量的IO
2 通过了解那些行被移除，可以查看是否缺少对应的索引，连接方式是否合理等
那么这里我优化的方法论或框架
1 寻找 seq scan 从这里入手
2 查看 rows removed by filter 行数多的
3 发现cost 突然增大的部分
现在就用我上面的方法论来对这个SQL来看看找出他的一些问题
1 先看Seq Scan ,在语句的执行计划中，有两个地方发生了 Seq Scan
根据这个方法论，首先第一个表就没有索引，来我们对这个表进行分析 ，看是否需要添加索引,在判断需要添加索引后我们看执行计划的变化
仅仅针对这个部分进行添加索引后，就从原来的2秒多，变更到0.8秒，优化达成率 60% 。 在此扫描新的执行计划，里面已经没有 Seq Scan，下一步，找到 rows removed by filter 数据较大的部分来查看。
然后我们照着第二个部分下手，rows removed by filter,很快我就定位了这部分过滤的大户，然后顺藤摸瓜，直接找到
然后针对这块来发现索引的问题，一看的确是缺索引。经过我第二次添加索引，整体比以前快了59倍。
写到这里，还可以继续优化，不过SQL优化和过生活一样，不要太急功近利，太多的索引未必对其他的操作有帮助，现在SQL已经来到了14ms，还想怎么样，收工。
通过以上的方法我们DBA 可以快速的对一些难搞的POSTGRESQL 进行快速的优化，达到解决80%SQL以上的问题，兵法总结：抓住要点，顺藤摸瓜，直击要害，解决关键问题，
1查全表扫描，
2查过滤行数，
3关注Cost突发变大的位置。
当然SQL得优化并没有这么简单，但简单的方法能解决80%的问题，我们终究是要解决问题,如SQL改写，逻辑变更，条件置换，条件前置，添加插件进行POSTGRESQL SQL hint 等在大部分情况下并不是优化的常用手段，部分情况下你要了解业务，深入到业务当中的，才可以使用更绝的手段。
截止今天共发布1298篇文章
置顶
ORACLE 最终会把 MySQL 弄死对吗？原因是什么！ （译）
2025数据库“新闻”，第四条坐实了开源PG属于谁？ 开源MySQL低迷原因在哪？
公众号给我两个数字 34.6万，65.5万--告别2024
云不云的，我不晕，从今天起云专栏的喇叭开始广播了。
没有谁是垮掉的一代--记 第四届 OceanBase 数据库大赛
ETL 行业也够卷，云化ETL，ETL 软件不过了
PostgreSQL 相关文章
PostgreSQL 运维的难与“难” --上海PG大会主题记录
PostgreSQL 什么都能存，什么都能塞 --- 你能成熟一点吗？
PostgreSQL 迁移用户很简单 --- 我看你的好戏
PostgreSQL 用户胡作非为只能受着 --- 警告他
全世界都在“搞” PostgreSQL ，从Oracle 得到一个“馊主意”开始PostgreSQL 加索引系统OOM 怨我了--- 不怨你怨谁
PostgreSQL “我怎么就连个数据库都不会建？” --- 你还真不会！
病毒攻击PostgreSQL暴力破解系统，防范加固系统方案（内附分析日志脚本）
PostgreSQL 远程管理越来越简单，6个自动化脚本开胃菜
PostgreSQL 稳定性平台 PG中文社区大会--杭州来去匆匆
PostgreSQL 如何通过工具来分析PG 内存泄露
PostgreSQL 分组查询可以不进行全表扫描吗？速度提高上千倍？
POSTGRESQL --Austindatabaes 历年文章整理
PostgreSQL 查询语句开发写不好是必然，不是PG的锅
PostgreSQL 字符集乌龙导致数据查询排序的问题，与 MySQL 稳定 "PG不稳定"
PostgreSQL Patroni 3.0 新功能规划 2023年 纽约PG 大会 （音译）
PostgreSQL 玩PG我们是认真的，vacuum 稳定性平台我们有了
PostgreSQL DBA硬扛 垃圾 “开发”，“架构师”，滥用PG 你们滚出 ！（附送定期清理连接脚本）
DBA 失职导致 PostgreSQL 日志疯涨
MySQL相关文章
ORACLE 最终会把 MySQL 弄死对吗？原因是什么！ （译）
MySQL 内存那点事你咋就不会--问来问去 --分析+自动分析脚本（1）
MySQL 怎么让自己更高级---从内存表说到了开发方式
MySQL timeout 参数可以让事务不完全回滚
"DBA 是个der" 吵出MySQL主键问题多种解决方案
MySQL 让你还用5.7 出事了吧，用着用着5.7崩了
MySQL 的SQL引擎很差吗？由一个同学提出问题引出的实验
用MySql不是MySQL, 不用MySQL都是MySQL 横批 哼哼哈哈啊啊
MYSQL --Austindatabases 历年文章合集
MongoDB 相关文章
MongoDB 大俗大雅，上来问分片真三俗 -- 4 分什么分
MongoDB 大俗大雅，高端知识讲“庸俗” --3 奇葩数据更新方法
MongoDB 学习建模与设计思路--统计数据更新案例
MongoDB 大俗大雅，高端的知识讲“通俗” -- 2 嵌套和引用
MongoDB 大俗大雅，高端的知识讲“低俗” -- 1 什么叫多模
MongoDB 合作考试报销活动 贴附属，MongoDB基础知识速通
MongoDB 年底活动，免费考试名额 7个公众号获得
MongoDB 使用网上妙招，直接DOWN机---清理表碎片导致的灾祸 (送书活动结束)
数据库 《三体》“二向箔” 思维限制 ！8个公众号联合抽奖送书 建立数据库设计新思维
MongoDB 是外星人，水瓶座，怎么和不按套路出牌的他沟通？
17000多张MongoDB表的锅 自动分析删除表数据难题--从头到尾的处理过程（文尾有MongoDB开发规范）
MongoDB 插入更新数据慢，开发问哪的问题？附带解决方案和脚本
MongoDB 不是软柿子，想替换就替换
MongoDB 挑战传统数据库聚合查询，干不死他们的MongoDB 2023纽约 MongoDB 大会 -- 我们怎么做的新一代引擎 SBE Mongodb 7.0双擎力量（译）
MongoDB 2023年度纽约 MongoDB 年度大会话题 -- MongoDB 数据模式与建模
MongoDB 双机热备那篇文章是 “毒”
MongoDB 会丢数据吗？在次补刀MongoDB 双机热备
MONGODB ---- Austindatabases 历年文章合集
PolarDB 相关文章
在被厂商围剿的DBA 求生之路 --我是老油条
POLARDB 添加字段 “卡” 住---这锅Polar不背
PolarDB 版本差异分析--外人不知道的秘密（谁是绵羊，谁是怪兽）
在被厂商围剿的DBA 求生之路 --我是老油条
PolarDB 答题拿-- 飞刀总的书、同款卫衣、T恤，来自杭州的Package（活动结束了）
PolarDB for MySQL 三大核心之一POLARFS 今天扒开它--- 嘛是火星人
PolarDB-MySQL 并行技巧与内幕--（怎么薅羊毛）
PolarDB 并行黑科技--从百套MySQL撤下说起 （感谢8018个粉丝的支持）
PolarDB 杀疯了，Everywhere Everytime Everydatabase on Serverless
POLARDB 从一个使用者的角度来说说，POALRDB 怎么打败 MYSQL RDS
PolarDB 最近遇到加字段加不上的问题 与 使用PolarDB 三年感受与恳谈
PolarDB 从节点Down机后，引起的主从节点强一致的争论
PolarDB serverless 真敢搞，你出圈了你知道吗!!!!
PolarDB VS PostgreSQL "云上"性能与成本评测 -- PolarDB 比PostgreSQL 好？
临时工访谈：PolarDB Serverless 发现“大”问题了 之 灭妖记 续集
临时工访谈：庙小妖风大-PolarDB 组团镇妖 之 他们是第一
PolarDB for PostgreSQL 有意思吗？有意思呀
PolarDB Serverless POC测试中有没有坑与发现的疑问
临时工说：从人性的角度来分析为什么公司内MySQL 成为少数派，PolarDB 占领高处
POLARDB 到底打倒了谁 PPT 分享 （文字版）
POLARDB -- Ausitndatabases 历年的文章集合
PolarDB for PostgreSQL 有意思吗？有意思呀
PolarDB 搞那么多复杂磁盘计费的东西，抽筋了吗？
临时工访谈系列
Oracle 文化走后，你我只值9.9元
知人者智，自知者明，琼瑶一路走好
本地存储还有活路吗？ 从上周一个供应商问我的问题开始
一年又一年，成了老梆子，别回头，往前看！
临时工说: 实际实例揭穿AI, 上云就不用DBA的谎言
临时工说：DBA 7*24H 给2万的工作，到底去不去？
国内最大IT服务公司-招聘DBA “招聘广告”的变化--分析与探讨
临时工说: 网友问35岁就淘汰，我刚入行DBA 怎么办？
OceanBase 相关文章
没有谁是垮掉的一代--记 第四届 OceanBase 数据库大赛
OceanBase 送祝福活动，礼物和幸运带给您
跟我学OceanBase4.0 --阅读白皮书 (OB分布式优化哪里了提高了速度)
跟我学OceanBase4.0 --阅读白皮书 （4.0优化的核心点是什么）
跟我学OceanBase4.0 --阅读白皮书 （0.5-4.0的架构与之前架构特点）
跟我学OceanBase4.0 --阅读白皮书 （旧的概念害死人呀，更新知识和理念）
聚焦SaaS类企业数据库选型（技术、成本、合规、地缘政治）
OceanBase 学习记录-- 建立MySQL租户,像用MySQL一样使用OB
OceanBase 学习记录 -- 安装简易环境
OceanBase 学习记录 -- 开始入门
数据库最近第一比较多，OceanBase 定语加多了？
临时工访谈：OceanBase上海开大会，我们四个开小会 OB 国产数据库破局者
临时工说：OceanBase 到访，果然数据库的世界很卷，没边
数据库信息速递 阿里巴巴的分布式数据库OceanBase旨在进军中国以外的市场 （翻译）
SQL SERVER 系列
SQL SERVER维保AI化，从一段小故事开始
SQL SERVER 如何实现UNDO REDO 和PostgreSQL 有近亲关系吗
SQL SERVER 危险中，标题不让发，进入看详情（译）
SQL SERVER 我没有消失，SQL SERVER下一个版本是2025 (功能领先大多数数据库）
SQL SERVER 2022 针对缓存扫描和Query Store 的进步，可以考虑进行版本升级
阿里云系列
阿里云数据库产品权限设计缺陷 ，六个场景诠释问题，你可以做的更好？
阿里云数据库--市场营销聊胜于无--3年的使用感受与反馈系列
阿里云数据库产品 对内对外一样的卷 --3年阿里云数据库的使用感受与反馈系列
阿里云数据库使用感受--客户服务问题深入剖析与什么是廉价客户 --3年的使用感受与反馈系列
阿里云数据库使用感受--操作界面有点眼花缭乱 --3年的使用感受与反馈系列
