ITPub博客

前言MySQL外键(FOREIGNKEY)是表的一个特殊字段，用来建立主表与从表的关联关系，为两个表的数据建立连接，约束两个表中数据的一致性和完整性。之前的第一篇文章相关文章（「技术讨论」为什么大家很少使用外键了？），总结了一些不使用外键的场景以及使用外键的优势之处。本篇文章会基于实例来说明外键约束

前言之前文章介绍了MySQL8.0主从复制，以及衍生出来的主主复制（可点如下链接查看）。MySQL8.0轻松搞定GTID主从复制MySQL8.0轻松搞定GTID主主复制今天来聊一聊MySQL8.0的组复制。主从复制技术仅解决了数据同步的问题，如果主服务器宕机，意味着数据库管理员需要介入，应用系统可能

前言之前文章介绍了GTID主从复制，实现了一主多从的MySQL架构，今天我们来介绍一下主主复制的架构。原理：主主复制就是根据主从复制的原理，将两个主库设置互为主从即可。变化：在这两个主库的基础上，还可以搭建双主多从架构。下面介绍在安装好MySQL8的centos8虚拟机上，实现GTID主主复制，以及

为什么需要主从复制？通俗来讲，如果对数据库的读和写都在同一个数据库服务器中操作，业务系统性能会降低。为了提升业务系统性能，优化用户体验，可以通过做主从复制来减轻主数据库的负载。而且如果主数据库宕机，可快速将业务系统切换到从数据库上，可避免数据丢失。主从复制原理主库将更新记录保存于Binlog文件中，

背景目前很多公司都不考虑加入外键了，很多人工作中也不怎么使用外键了，毕竟每次做DELETE或者UPDATE都必须考虑外键约束，会导致开发的时候很痛苦,测试数据极为不方便。在笔者看来，在相应的场景下，如果使用的一个功能弊大于利，可能就不会选择了。所以是否使用外键取决相应的场景，也不可去完全抛弃外键。为

背景笔者最近在回顾多版本并发控制（MVCC），上篇章从加锁的角度理解了几个异常场景（有兴趣的朋友可以点击查看「技术讨论」事物系统的几种异常场景），由此可以发现一个递进关系：在解决了上一个问题时，又发现了下一个新问题。因此才引出了，根据这几个异常场景来定义的不同的有递进关系的隔离级别的概念。在对事物系

背景笔者最近在回顾多版本并发控制（MVCC），这里对相关内容做个小总结，首先就从隔离级别说起。为什么要讨论隔离，场景是什么？首先，作为事务系统，如果单位时间内，只有一个事务在运行，则谈不上隔离。可是实际上，真正用于实际生产的事务系统，单位时间内都是有多个事务同时的在对资源进行着读写。那么就必定会存在

在做数据库设计时，我们经常需要给很多表增加一个‘类型’字段，比如人的性别有‘男’，‘女’，学校的类型有‘幼儿园’，‘小学’，‘中学’，‘大学’，汽车的类型有‘轿车’，‘suv’，‘mpv’等，这种字段的本质特点是它们包含“有限个离散值”。对于这种字段，使用enum数据类型是最合适的，mysql和Po

KunlunBase查询优化（三）排序下推

KunlunBase查询优化（二）Project和Filter下推

前面介绍了KunlunBase的架构以及技术，应该会有朋友好奇其查询优化的过程吧，本篇章带来的是查询优化这一块的具体流程介绍，后续也会出一篇实例来举例演示。 当然后续也会对KunlunBase的其它技术方面（比如数据分片这些）做实例演示，以方便大家去了解KunlunBase。

Hadoop HDFS 3.3.1分布式存储搭建

昆仑分布式数据库独特的变量读写功能介绍~

在一条DML语句中插入/更新/删除/获取几百万行数据，你会特别注意什么？

昆仑分布式数据库（下文简称昆仑或者昆仑数据库）的计算节点源自PostgreSQL，因此继承了PostgreSQL的Sequence功能，本文介绍昆仑分布式数据库的Sequence的功能用法、用例和实现。

本文详述分布式事务对于两阶段提交算法的错误处理原理和机制及延时损耗~

为避免经典的两阶段提交算法缺陷的发生，昆仑分布式数据库的分布式事务处理机制基于经典的两阶段提交算法，并在此基础上增强了其容灾能力和错误处理能力。 故此可以做到任意时刻昆仑数据库集群的任意节点宕机或者网络故障、超时等都不会导致集群管理的数据发生不一致或者丢失等错误。

过去经典的两阶段提交算法过程中，发现会遇上部分节点在执行事务提交期间发生故障，导致出现错误，这些错误都会导致用户数据丢失或者出错。本次浅谈如何避免两阶段缺陷以及昆仑分布式数据库如何优化避免其缺陷。

昆仑分布式数据库技术优势介绍~

昆仑分布式数据库的技术特点介绍~