Mysql安装、用户管理、初始化、多实例 2021-04-28 下载 https://downloads.mysql.com/archives/community/ mysql-5.7.26-linux-glibc2.12-x86_64.tar.gz 安装方式 安装方式优点缺点 rpm安装卸载简单可定制性差 glibc可定制性相比rpm包灵活些安装相比rpm包复杂些，需要手动初始化数据库 源码安装可定制性最强，根据需求和功能定制安装麻烦，需要手动初始化数据库 RPM: mysql-community-server-5.7.28-1.el7.x86_64.rpm ，需要在特定linux版本下安装。 glibc: mysql-5.7.28-linux-glibc2.12-x86_64.tar.gz，依赖glibc库，可以安装在通用的Linux系统下 源代码编译安装: mysql-5.7.31.tar.gz，通用的Linux下都可以编译安装 glibc方式安装 # 解压软件 [root@localhost software]# ls mysql-5.7.26-linux-glibc2.12-x86_64.tar.gz [root@loc....
普通索引、唯一索引 2020-05-05 查询性能对比 假设维护一个市民系统，每个人都有一个唯一的身份证号，而且业务代码已经保证了不会写入两个重复的身份证号。如果市民系统需要按照身份证号查姓名，就会执行类似这样的 SQL 语句： select name from CUser where id_card = 'xxxxxxxyyyyyyzzzzz'; 定会考虑在 id_card 字段上建索引。由于身份证号字段比较大，不建议把身份证号当做主键，那么现在你有两个选择，要么给 id_card 字段创建唯一索引，要么创建一个普通索引。如果业务代码已经保证了不会写入重复的身份证号，那么这两个选择逻辑上都是正确的。 如果从性能的角度考虑，应该选择唯一索引还是普通索引呢？选择的依据是什么呢？ 假设字段 k 上的值都不重复。如下图所示： 分别对两种索引查询和更新语句的性能进行分析。 查询过程 假设，执行查询的语句是 select id from T where k=5。这个查询语句在索引树上查找的过程，先是通过 B+ 树从树根开始，按层搜索到叶子节点，也就是图中右下角的这个数据页，然后可以认为数据页内部通过二分法来定位记录。 *....
MVCC、事务隔离 2020-05-01 事务到底是隔离的还是不隔离的？ 可重复读隔离级别，事务 T 启动的时候会创建一个视图 read-view，之后事务 T 执行期间，即使有其他事务修改了数据，事务 T 看到的仍然跟在启动时看到的一样。也就是说，一个在可重复读隔离级别下执行的事务，好像与世无争，不受外界影响。 在发生行锁冲突的时候，一个事务要更新一行，如果刚好有另外一个事务拥有这一行的行锁，则该事务会被锁住，进入等待状态。问题是，既然进入了等待状态，那么等到这个事务自己获取到行锁要更新数据的时候，它读到的值又是什么呢？ 下面是一个只有两行的表的初始化语句。 mysql> CREATE TABLE `t` ( `id` int(11) NOT NULL, `k` int(11) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB; insert into t(id, k) values(1,1),(2,2); 需要注意的是事务的启动时机。begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个操作 InnoDB 表的语句....
行锁：减少锁冲突提升业务并发度 2020-04-29 行锁 行锁就是针对数据表中行记录的锁。这很好理解，比如事务 A 更新了一行，而这时候事务 B 也要更新同一行，则必须等事务 A 的操作完成后才能进行更新。 MySQL 的行锁是在引擎层由各个引擎自己实现的。但并不是所有的引擎都支持行锁，比如 MyISAM 引擎就不支持行锁。 支持行锁意味着并发控制只能使用表锁，对于这种引擎的表，同一张表上任何时刻只能有一个更新在执行，这就会影响到业务并发度。 两阶段锁 在下面的操作序列中，事务 B 的 update 语句执行时会是什么现象呢？假设字段 id 是表 t 的主键。 这个问题的结论取决于事务 A 在执行完两条 update 语句后，持有哪些锁，以及在什么时候释放。你可以验证一下：实际上事务 B 的 update 语句会被阻塞，直到事务 A 执行 commit 之后，事务 B 才能继续执行。 也就是说，在 InnoDB 事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议。 在事务中合理优化两段式提交 如果你的事务中需要锁多个行，要把最可能造成锁冲突、最可能影响并发度的....
全局锁、表级锁 2020-04-24 数据库中的锁 数据库锁设计的初衷是处理并发问题。作为多用户共享的资源，当出现并发访问的时候，数据库需要合理地控制资源的访问规则。而锁就是用来实现这些访问规则的重要数据结构。 MySQL 里面的锁大致可以分成全局锁、表级锁和行锁三类 为什么需要锁 假设你现在要维护一个课程购买系统，关注的是用户账户余额表和用户课程表。 现在发起一个逻辑备份。假设备份期间，有一个用户，他购买了一门课程，业务逻辑里就要扣掉他的余额，然后往已购课程里面加上一门课。 如果时间顺序上是先备份账户余额表 (u_account) => 用户购买 => 备份用户课程表 (u_course)，会怎么样呢？如下图所示： 如果用以上备份来恢复数据的话，用户 A 就发现，自己赚了。用户 A 的数据状态是：账户余额没扣，但是用户课程表里面已经多了一门课。 （用户也开心） 如果反过来：备份用户课程表 (u_course) => 用户购买 => 先备份账户余额表 (u_account) ，基于此备份进行恢复数据，会发现用户在没有发生任何购买行为的情况下，原本的余额减少了。（用户无法接受） 也就....
索引 2020-04-23 索引简介 索引的出现其实就是为了提高数据查询的效率，就像书的目录一样。 在 MySQL 中，索引是在存储引擎层实现的，所以并没有统一的索引标准，即不同存储引擎的索引的工作方式并不一样。而即使多个存储引擎支持同一种类型的索引，其底层的实现也可能不同。 索引的常见模型 索引的出现是为了提高查询效率，但是实现索引的方式却有很多种，所以这里也就引入了索引模型的概念。可以用于提高读写效率的数据结构很多，例如:哈希表、有序数组、搜索树。 数据库底层存储的核心就是基于这些数据模型的。每碰到一个新数据库，我们需要先关注它的数据模型，这样才能从理论上分析出这个数据库的适用场景。 哈希索引 # 适用场景 * 哈希表这种结构适用于只有等值查询的场景，比如 Memcached 及其他一些 NoSQL 引擎。 # 优点 * 图中四个 ID_card_n 的值并不是递增的(并不是有序的，123456)，这样做的好处是增加新的 User 时速度会很快，只需要往后追加。 # 缺点 * 因为不是有序的，所以哈希索引做区间查询的速度是很慢.(如果你现在要找身份证号在[ID_card_X, ID_card_Y]这....
Isolation 2020-04-30 Transaction 简单来说，事务就是要保证一组数据库操作，要么全部成功，要么全部失败。在 MySQL 中，事务支持是在引擎层实现的。 MySQL是一个支持多引擎的系统，但并不是所有的引擎都支持事务。 隔离性与隔离级别 隔离性(Isolation) 当数据库上有多个事务同时执行的时候，就可能出现脏读（dirty read）、不可重复读（non-repeatable read）、幻读（phantom read）的问题，为了解决这些问题，就有了“隔离级别”的概念。 隔离性与执行效率的平衡点 隔离得越严实，效率就会越低。因此很多时候，我们都要在二者之间寻找一个平衡点。 SQL 标准的事务隔离级别 * 读未提交（read uncommitted） 读未提交是指，一个事务还没提交时，它做的变更就能被别的事务看到。 * 读提交（read committed） 读提交是指，一个事务提交之后，它做的变更才会被其他事务看到。 * 可重复读（repeatable read） 可重复读是指，一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。当然在可重复读隔离级别下，未提交....
