其实有时候数据库的问题，仅仅从SQL文本分析就可以获得不少有价值的信息，甚至直接定位问题。有一次，一个客户的SQL解析出现了问题，共享池和CURSOR相关的闩锁等待延迟都比较高，不过从AWR报告上看,IO性能似乎不太好，SQL执行次数，解析、硬解析的负载似乎问题也不是很大。我瞟了一眼SQL COMPLETE LIST的数据，看到不少带有“OPT_DYN_SAMP”提示的SQL，而相关SQL访问的动态采样的表所处的数据文件和表空间的IO延时都是比较差的，平均接近10毫秒。于是我建议他们先试试对这几张表做个采样。采样结束后，共享池和解析方面的问题都消失了。

　　动态采样的这个问题对于某些国产数据库也是类似的，以前我在国产的金仓、高斯数据库上也遇到过类似的问题。除了动态采样容易引发SQL解析问题外，如果一条SQL中使用了大量的in list、where条件中的谓词数量巨大（比如超过50个），也会引发SQL解析性能下降的问题。去年在一个金仓数据库上我就发现了PLAN TIME在TIME MODEL中占比过高，其中BIND的时间特别长，数据库执行效率不佳，后来经过检查发现是因为有几条前端动态拼凑的SQL的in语句的括号里居然有一百多个绑定变量。

　　另外SQL_TEXT分析还应该关注表连接的数量或者子查询的层次，国产数据库的优化器能力相对Oracle还是有很大的差距，如果表连接数量过多或者子查询层次草果4层，优化器出现错误执行计划的概率会大大上升。

　　递归逻辑也是十分需要关注的，如果数据库的执行算子中存在不优化的地方，递归层次过多会导致CPU开销过大，SQL执行时的内存消耗也会大幅增加。因此当分析数据库的CPU开销过大，或者内存消耗过多的时候，千万不要忽略带有递归的SQL，如果数据发生了变化，递归的层次增加，还是很容易带来问题的。分析时关注CPU或内存使用过多的SQL中是否带有递归逻辑。

　　其实数据库运维的知识和经验永远都不会是十分深奥的，也不会是某些专家的独门秘籍，都包含在这些大家容易忽视的小常识里。在传统运维时代，有经验的专家经历过大量的案例洗礼，所以他们比较容易关注到这些细枝末节，而普通的DBA无法在生产中熟练使用这些技巧。不过在AI时代，一切都发生了变化，如果把这些小技巧都写成skills，让AI智能体帮你去做分析，那么哪怕是刚入行的小白，在这些skills的帮助下都可以做得不错。

　　其实DBA去拥抱AI并不是一句空话，或者是一句引发焦虑的话，自己从点点滴滴的小技巧的收集开始，并且用一个小的AI助手来管理这些知识，并逐步用到你的运维实践中，那么你就会变成一个AI时代的DBA了。