1. 2.2 PostgreSQL MVCChistorical

    1. 总体规则 - 在PostgreSQL中,每一个事务都会得到一个被称作为 XID 的事务ID - 可以通过 select cast(txid current() as text) 查询 - 这里说的事务不仅仅是被 BEGIN - COMMIT 包裹的一组语句,还包括单条的 insert 、 up

  2. 2.3 PostgreSQL explainhistorical

    1. 不加where 1.1. 普通的explain - 结果 1.1.1. 解析 - 读取的方式 - 顺序扫描,一块块读取 - 统计信息 - cost - 获取第一行的时间 - 获取所有行的时间 - 单位是规划器cost unit,不是毫秒 - rows - 扫描的行数 - width - 所有行的平均

  3. SQL Join查询historical

    1. 连接查询是什么 把各个连接表中的记录都取出来依次匹配的组合加入结果集并返回给用户 2. Join种类有哪些 2.1. 内连接 驱动表中的记录在被驱动表中找不到匹配的记录, 不会 加入到最后的结果集 on和where后的条件等价 驱动表和被驱动表是可以互换的,不加条件等价于笛卡尔积 举例 2.2. 外连接 驱动表中的记录即使在被驱动表中没有匹配的记录, 会 加入到结果集 必须使用 ON 子句来指出连接条件 on和where不等价 左外连接:选取左侧的表为驱动表;右外连接:选取右侧的表为驱动表 举例 2.3. 例子 tb item:3096 tb item cat:1182 No1 A表的所

  4. SQL执行顺序historical

    1. 是什么 1. 执行from join on,创建临时表 2. 执行where,过滤掉数据。这里不能使用select中的别名,只能使用from和join表中的字段,因为select还没有执行 3. 执行group by,执行后这个值唯一的分成一组,并且select后面可以使用聚合函数 4. 执行having,分组之后每个组内的值进行过滤。同where不能使用select中的别名 5. 执行select,选择显示的字段 6. 执行distinct,行去重 7. 执行order by,排序,这里可以使用select中的别名 8. 执行limit,offset,限制条数 2. 参考 SQL查询之

  5. 关系型数据库historical

    1. 什么是关系型数据库 采用了关系模型来组织数据的数据库 关系 一对一 一对多 多对多:可以通过中间表拆解成两个一对多 2. 为什么需要关系型数据库 3. 关系型数据库特点 3.1. 表结构存储 数据的存储采用二维表格模型,即行和列的形式 3.2. 规范化设计 数据库范式.md 3.3. 使用SQL查询数据 SQL Join查询.md 3.4. 支持事务 数据库事务.md 4. 数据库优化 数据库优化.md 5. 数据库原理 5.1. SQL执行顺序 SQL执行顺序.md 5.2. 锁 数据库锁.md 5.3. B+Tree B Tree.md 6. 常用关系型数据库 6.1. MySQL

  6. 数据库乐观锁与悲观锁historical

    1. 悲观锁 2. 乐观锁 乐观锁假设认为数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测 版本号 增加一个version字段。先查一次,更新时原来的语句基础上 update xxx set version=version+1 where version=version ,失败则循环 3. 参考 数据库第一类第二类丢失更新 云+社区 腾讯云

  7. 数据库事务historical

    1. 什么是事务 将多个读写操作合并成一个逻辑单元,视作一个操作执行 这个操作满足ACID特性 2. 为什么需要事务 主要是为了让应用层简化对一系列问题的处理 事务是一个抽象层,应用程序 事务 数据库。 通过事务的抽象应用程序可以假装数据库不会崩溃(原子性),没有其他人同时访问数据库(隔离),存储设备是完全可靠的(持久性) 所有这些错误都被简化为 事务中止 ,而应用需要的仅仅是重试 3. 事务的特性 3.1. A (原子性) 3.1.1. 原子性是什么 无论有多少条sql语句,要么整体执行失败,要么整体执行成功。 原子性 这个的原子性不是指并发的,即不是描述多个线程同时访问相同的数据会发生什么

  8. 数据库优化historical

    1. 什么是数据库优化 2. 数据库优化思路 2.1. 应用层 2.1.1. 缓存 如何设计缓存系统.md 2.2. 数据库层 2.2.1. SQL语句 MySQL SQL调优.md 2.2.2. 表结构 冗余字段到主表中 2.2.3. 复制 MySQL主从复制.md 2.2.4. 分区分库分表 数据库分库分表.md 2.3. 系统层 2.3.1. 调优服务器参数 MySQL配置 Linux配置 2.4. 硬件层 更强劲的机器 3. 参考 阿里P8架构师谈:MySQL慢查询优化、索引优化、以及表等优化总结 优知学院 MySQL 对于千万级的大表要怎么优化? 知乎

  9. 数据库分库分表historical

    1. 为什么需要分库分表 分布式系统分区.md 2. 分库分表是什么 分库是把原来的一个库分成多个库,分表是把原来的一张表分成多张表 分库和分表都有水平拆分和垂直拆分的方式 2.1. 垂直拆分 2.1.1. 垂直分表 每个表的结构都不一样,每个表的数据也不一样 把一张表的字段按照使用频率、是否大字段分成多张表(一对一关系)。比如把商品信息表分成商品基本信息表和商品描述表 这个操作一般在设计之初完成 2.1.2. 垂直分库 每个库的结构都不一样,每个库的数据也不一样 按照业务逻辑耦合程度把一个库分成多个库,部署在不同机器上。本质上和微服务按照业务拆分一个逻辑,每个服务对应一个数据库,比如商品信息

  10. 数据库死锁historical

    1. 什么是死锁 死锁是指两个(或多个)事务相互持有对方想要的锁 如果事务 1 在表 A 上获得一个排他锁,同时试图获取一个在表 B 上的排他锁, 而事务 2 已经持有表 B 的排他锁,同时却正在请求表 A 上的一个排他锁,那么两个事务就都不能进行下去。 1.1. 例子 两个并发事务在修改一个表。 第一个事务执行: 这样就在acctnum = 11111的行上获得了一个行级锁 然后,第二个事务执行: 第一个UPDATE语句成功地在指定行上获得了一个行级锁acctnum = 22222,因此它成功更新了该行 但是第二个UPDATE语句发现它试图更新的行已经被锁住了,因此它等待持有该锁的事务结束