数据库疑点

目录

 

IN和EXIST

redo log和undo log

undo log

delete/update操作的内部机制

---

IN和EXIST

SOL中的IN可以分为三类

第一种：

　1、形如select * from t1 where f1 in ('a','b')，应该和以下两种比较效率

　　select * from t1 where f1='a' or f1='b'

　　或者 select * from t1 where f1 ='a' union all select * from t1 f1='b'

in后面是一个列表，这样的形式和转换成or类似，但是存储引擎对这个in查询进行了优化，对in中的数据进行了优化，在前面的数据进行匹配的时候，会对in中的数据进行排序，然后进行二分查找，效率为O(logn），而or的效率为O（n)

第二种：

　2、形如select * from t1 where f1 in (select f1 from t2 where t2.fx='x')，

　　其中子查询的where里的条件不受外层查询的影响，这类查询一般情况下，自动优化会转成exist语句，也就是效率和exist一样。

第三种：

3、形如select * from t1 where f1 in (select f1 from t2 where t2.fx=t1.fx)，

　　其中子查询的where里的条件受外层查询的影响，这类查询的效率要看相关条件涉及的字段的索引情况和数据量多少，一般认为效率不如exists。
　　除了第一类in语句都是可以转化成exists 语句的SQL，一般编程习惯应该是用exists而不用in，而很少去考虑in和exists的执行效率.
in在查询的时候，首先查询子查询的表，然后将内表和外表做一个笛卡尔积，然后按照条件进行筛选。所以相对内表比较小的时候，in的速度较快。

exist指定一个子查询，检测行的存在。遍历循环外表，然后看外表中的记录有没有和内表的数据一样的。匹配上就将结果放入结果集中。

in 和 exists的区别: 如果子查询得出的结果集记录较少，主查询中的表较大且又有索引时应该用in, 反之如果外层的主查询记录较少，子查询中的表大，又有索引时使用exists。其实我们区分in和exists主要是造成了驱动顺序的改变(这是性能变化的关键)，如果是exists，那么以外层表为驱动表，先被访问，如果是IN，那么先执行子查询，所以我们会以驱动表的快速返回为目标，那么就会考虑到索引及结果集的关系了 ，另外IN时不对NULL进行处理。

in 是把外表和内表作hash 连接，而exists是对外表作loop循环，每次loop循环再对内表进行查询。一直以来认为exists比in效率高的说法是不准确的。

如果查询语句使用了not in 那么内外表都进行全表扫描，没有用到索引；而not extsts 的子查询依然能用到表上的索引。所以无论那个表大，用not exists都比not in要快。

总结下来：子查询表小的用in，子查询表大的用exist

redo log和undo log

undo log

undo log有两个作用：提供回滚和多版本并发控制

undo log是逻辑日志。可以认为当delete一条记录时，undo log中会记录一条相应的insert记录，反之依然，当update一条记录的时候，它会记录一条相反的update记录

当执行回滚的时候，就可以从undo log中的逻辑记录中读取到相应的内容并进行回滚。有时候应用到行版本控制的时候，也是通过undo log来实现的：当读取的某一行被其他事务锁定时，它可以从undo log中分析出该行记录以前的数据是什么，从而提供该行版本信息，让用户实现非锁定一致性读取。

undo log是采用段(segment)的方式来记录的，每个undo操作在记录的时候占用一个undo log segment。

undo log也会产生redo log，因为undo log也要实现持久性保护。

delete/update操作的内部机制

当事务提交的时候，innodb不会立即删除undo log，因为后续还可能会用到undo log，如隔离级别为repeatable read时，事务读取的都是开启事务时的最新提交行版本，只要该事务不结束，该行版本就不能删除，即undo log不能删除。

但是在事务提交的时候，会将该事务对应的undo log放入到删除列表中，未来通过purge来删除。并且提交事务时，还会判断undo log分配的页是否可以重用，如果可以重用，则会分配给后面来的事务，避免为每个独立的事务分配独立的undo log页而浪费存储空间和性能。

通过undo log记录delete和update操作的结果发现：(insert操作无需分析，就是插入行而已)

• delete操作实际上不会直接删除，而是将delete对象打上delete flag，标记为删除，最终的删除操作是purge线程完成的。
• update分为两种情况：update的列是否是主键列。
  • 如果不是主键列，在undo log中直接反向记录是如何update的。即update是直接进行的。
  • 如果是主键列，update分两部执行：先删除该行，再插入一行目标行。