在记录中成长

redo log

InnoDB 存储引擎是以页为单位来管理存储空间的, 我们的增删改查操作本质上都是在访问页面, 如读取一条数据, 会把这个数据所在的页加载到内存中, 而不仅仅是这条数据本身, 这个页的默认大小是 16KB.

在事务中, 我们有一个特性: 持久性, 指对于一个已提交的事务, 在事务提交后, 即使系统崩溃, 也要保证这个事务对数据库做的更改不会丢失, 那么我们如何保证这一点呢, 有一个简单粗暴的做法就是: 在事务提交之前, 将事务所修改的所有页面都刷新到磁盘, 但这种做法有几个问题:

• 刷新一个数据页太浪费了, 可能我们只修改了这个数据页中的一个字节, 但 InnoDB 所有操作都是基于页面的, 我们只修改一个字节就要刷新一个 16KB 的页到磁盘上台浪费了.
• 随机 IO 刷起来比较慢, 一个事务可能包含了很多语句, 即使一条语句, 也可能修改了许多页面, 有可能修改的这些页面并不相邻, 那么这就需要进行很多次随机 IO, 这相对顺序 IO 来说很慢, 尤其对机械硬盘来说.

那么如何解决这个问题呢, InnoDB 采用了 redo log 机制来解决:

MySQL 拿到一个查询请求后，会先看看之前有没有执行过这条语句，如果执行过，则直接从查询缓存中取之前查询的结果即可，但大多情况不建议使用 MySQL 的查询缓存，因为弊大于利。

因为查询缓存的失效非常频繁，只要对一个表进行更新，那么这个表的所有查询缓存将会全部被清除，所以命中率并不会很好，除非你有一张静态的表，不会改变他的数据，或者很久才会更新一次。比如系统配置表，才适合使用这个查询缓存。

还有一个原因是因为，现在有 Redis, MemoryCache 等专门用来做缓存的应用，他们对缓存的处理会更优，而且 MySQL 服务器的资源通常都比较宝贵，所以不推荐使用 MySQL 的查询缓存。

查看查询缓存状态:

1

show variables like '%query_cache_type%';

显式指定使用查询缓存:

1

select SQL_CACHE * FROM user where ID = 10;

进行连接

使用数据库的第一步是连接，连接命令为:

1

mysql -u$username -h$host -P$port -p

然后输入密码就行了，不推荐在 -p 的后面输入密码，会有安全问题。

在项目中我们经常会碰到这种格式的数据, 需要将其转化为树形结构:

一般的做法是查询出所有, 然后递归构建树形结构, 但其实可以巧用 MyBatis 在查询时就进行转换, 这用到了 MyBatis 的 resultMap 功能.

首先由以下表结构定义:

题意

给予一颗非负二叉搜索树, 返回任意两个节点之间的最小相差值.

注: 树至少有两个节点.

例 :

1
2
3
4
5
6
7
8
9
10
11

给予树:


   1
    \
     4
    / \
   2   7


返回: 1 (1 和 2 之间相差 1).

题意

给予一颗二叉搜索树, 返回任意两个节点之间的最小相差值.

注: 树至少有两个节点.

例 :

1
2
3
4
5
6
7
8
9
10
11

给予树:


   1
    \
     4
    / \
   2   7


返回: 1 (1 和 2 之间相差 1).