KunLunDB_Linda的博客

一、锁的概述在计算机中，锁是协调多个进程或线程并发访问某一资源的一种机制。在数据库中，除传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。二、锁的分类2.1 按数据操作的类型分类： 读锁（共享锁）：针对同一份数据，多个读操作可以同时进行.

前言之前文章介绍索引失效的场景（聊一聊MySQL索引失效的问题），用到了explain执行计划，执行计划返回执行过程中每一步的信息，而不是执行它。通过返回的一行或多行信息，显示出执行计划中的每一部分和执行的次序，从而可以从分析结果中，找到查询语句或是表结构的性能瓶颈。今天我们举一些实际的例子，来解释一下explain执行计划各字段的含义。首先建立 用户，角色，关系，分区表。CREATE TABLE table_user(id INT AUTO_INCREMENT,u

一、索引原理索引是提高数据库查询性能的一个重要方法。使用索引用可快速找出某个列中包含特定值的行。不使用索引，必须从第一条记录开始读，可能要读完整个表，才能找出相关的行。使用索引就像查字典一样，我们可以根据拼音、笔画、偏旁部首等排序的目录(索引)，快速查找到需要的字。之前介绍MySQL存储引擎的文章（聊一聊MySQL的存储引擎），测试对比了两种存储引擎(MyISAM或者InnoDB)，使用主键索引查询，效率快了几十倍。虽然索引大大提高了查询(select)速度，但同时也

一、前言存储引擎(storage engine)是MySQL的专用称呼，数据库行业老大哥Oracle，以及SQL Server，PostgreSQL等都没有存储引擎的说法。MySQL区别于其他数据库的重要特点就是，其插件式(pluggable)的表存储引擎。引擎(engine)是外来音译词，习惯上认为是发动机，好像和数据库搭不上关系。最早MySQL的存储引擎称为“数据表处理器”，可能是听起来太老土，后来才改成高大上的存储引擎。存储引擎的功能是接收上层传下来的指令，然后

一、字符集概述字符集（Character Set）是多个字符的集合，字符集种类较多，每个字符集包含的字符个数不同，常见字符集名称：ASCII、GB2312、BIG5、Unicode等。UTF(Unicode Tranformation Format)是Unicode的其中一个使用方式，即把Unicode转做某种格式的意思，包括UTF-8，UTF-16，UTF-32。UTF-8（8-bit Unicode Transformation Format）是一种针对Unicode的可变长度字

前言之前文章介绍了MySQL8.0主从复制，以及衍生出来的主主复制（可点如下链接查看）。 MySQL8.0轻松搞定GTID主从复制 MySQL8.0轻松搞定GTID主主复制 今天来聊一聊MySQL8.0的组复制。主从复制技术仅解决了数据同步的问题，如果主服务器宕机，意味着数据库管理员需要介入，应用系统可能需要修改数据库连接地址或者重启才能实现。组复制只要不是大多数节点坏掉就可以继续工作，有自动检测机制，当不同节点产生资源争用冲突时，不会出现错误，按照先到者优先

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

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

前言MySQL外键(FOREIGNKEY)是表的一个特殊字段，用来建立主表与从表的关联关系，为两个表的数据建立连接，约束两个表中数据的一致性和完整性。之前的第一篇文章相关文章（「技术讨论」为什么大家很少使用外键了？），总结了一些不使用外键的场景以及使用外键的优势之处。本篇文章会基于实例来说明外键约束虽会保证表间数据的关系“始终完整一致”，但在实际操作中，每次做DELETE 或者UPDATE都必须考虑外键约束，会导致开发的时候很痛苦。保持数据的一致性和完整性，主要体现在下面两个

背景目前很多公司都不考虑加入外键了，很多人工作中也不怎么使用外键了，毕竟每次做DELETE 或者UPDATE都必须考虑外键约束，会导致开发的时候很痛苦,测试数据极为不方便。在笔者看来，在相应的场景下，如果使用的一个功能弊大于利，可能就不会选择了。所以是否使用外键取决相应的场景，也不可去完全抛弃外键。为什么会很少使用外键呢？目前使用外键确实存在一些不便，这也是大多数人不使用的原因所在。我具体总结了会存在这么几个原因：1、增加数据库压力外键等于把数据的一致性事务实

背景 笔者最近在回顾多版本并发控制（MVCC），上篇章从加锁的角度理解了几个异常场景（有兴趣的朋友可以点击查看「技术讨论」事物系统的几种异常场景），由此可以发现一个递进关系：在解决了上一个问题时，又发现了下一个新问题。因此才引出了，根据这几个异常场景来定义的不同的有递进关系的隔离级别的概念。在对事物系统的隔离级别分析中，我们同样可以发现：每个隔离级别，是用来解决相对一个层次的问题。 事务系统的隔离级别 1、Read-Uncommited 读未提交该隔离级别解决第..

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

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