ITPub博客

主要是在semi join/anti join里使用，不管是nested loops,还是hash join,sort merge join,只要走semi join/anti join都有 first match思想，这是一种“短路”算法，快速裁剪，类似加个rownum=1(但是得注意，如果你手动加rownum=1, oracle数据库则子查询不能unnest,pg,mysql可以，所以，CBO自己能处理，就不要“画蛇添足”),

MySQL的in很长，超过200条不走index dive,要用cardinality,可能不准，大表的甚至可能走全表，然后逐条判断Filter,造成性能慢， 可以改为values row行构造为临时表，转为semi join,转为的是semi join,按理说剔重后转为join更好

按照SQL性能=cpu time+wait time，考虑执行计划突变，有多种原因，统计信息收集错，谓词条件out of range统计信息，灌入大量数据未收集，分区表灌数据收集时机不对，条件倾斜，数据量变化，绑定变量peeking问题，DML影响一致性块重构导致逻辑读增加，数据从buffer cache刷出，表和索引碎片增加，索引失效以及优化器BUG，ACS，cardinality feedback，dynamic sampling等影响执行计划。

oracle latch，mutex，enqueue内部结构区别详解

oracle sql tuning如何从获取TOP 语句到开始优化，需要的优化工具，优化方法等全流程，做详细讲解

MySQL的MVCC实现决定了它对长事务极度敏感，而Oracle的块级重构架构使其更具韧性。

hash join最好以树形计划为准,对于pg和mysql,树形会将probe table写在hash table前面，hash table有Hash标志，而oracle会将hash table写在前面

在 MySQL 中，optimizer_switch 是一个用于控制查询优化器是否启用某些特定优化特性的系统变量。它是一个由多个 flag=on/off 对组成的字符串，每个开关对应一种优化策略或算法。通过调整这些开关，DBA 或开发者可以针对特定查询或负载调整优化器的行为，例如启用新的优化特性、规避某些因优化器决策导致的性能问题，或者进行调试分析。

log file sync等待事件是衡量Oracle数据库事务响应延迟的关键指标。 它指的是当一个用户会话（前台进程）发起COMMIT或ROLLBACK操作后，必须等待LGWR（日志写入器）后台进程将该会话产生的重做日志从日志缓冲区（Log Buffer） 成功写入在线重做日志文件（Online Redo Log），并且（在特定架构下）完成必要的全局同步后，才会收到操作成功的确认。这个从发起请求到收到确认的整个等待时间，就是log file syn

Oracle Latch Free 等待是数据库内部内存结构保护机制的核心体现，理解其原理对诊断高并发场景的性能瓶颈至关重要。

DBMS_SYSTEM.KSDWRT 是 Oracle 内部包中的过程，用于向 告警日志（alert log）或跟踪文件 写入自定义消息。

Oracle 11g 的 Adaptive Log File Sync 特性在 11.2.0.3 版本中默认开启后，确实带来了一系列严重的性能问题，这也是业界普遍建议关闭该参数的根本原因

在Oracle执行计划中，E-Rows 和 A-Rows 是评估SQL性能的两个核心指标，它们分别代表了优化器的“预估值”和SQL运行时的“实际值”。

buffer busy waits通常是由于多个进程同时访问同一个buffer block导致的争用，尤其是在高并发的情况下。而read by other session则是在等待另一个会话正在从磁盘读取相同的数据块到buffer cache中。在RAC环境中，gc buffer busy acquire和release则涉及到跨实例的块访问争用，可能由热点块、网络延迟或Oracle Bug引起。

什么情况下，oracle表和索引产生大量碎片？特别一些中间表频繁insert，delete，删除后空间不是重用吗，为什么会产生大量碎片，如何解决这些问题

数据库ACID机制的ANSI标准并未完全实现C和I，可能存在不可重复读和幻读问题，也会发生第二类丢失更新，三大数据库oracle，pg，MySQL的隔离级别和实现也不一样

Oracle AWR里的TPS,IOPS,QPS指标

数据库里中间表频繁insert和delete可能导致大量碎片，比如t_mid里面插入大量数据，有status自动，然后处理按照status=0查找数据并处理后delete掉. ...这种频繁insert然后delete可能中间表只有几条数据，但是实际空间可能几个G，以oracle为例，如何避免这种中间表碎片问题，可以从业务流程设计和数据库侧考虑减少碎片，并且保证查找和处理的性能，比如这种中间表开发侧可能没有建索引，如何在有碎片情况下也能保障性能？

网上到处都是什么nologging放在insert 语句里减少redo size的说法，但是很少看到有数据来说明，或者测试的环境有所差别，其他的不说了，nologging那个eygle网站上有,append神马情况下减少redo,nologging用在神马情况...

看到有些人经常问，把自己的一些体会简单举个例子，详细的东西还是需要自己慢慢体会的，比如from a,b where a.id=b.id(+) and b.name='a'这个b.name没有+号则相当于普通的连接（准确地说是先外连接后过滤），还有些...