SQL(Structure Query Language)语言是数据库的核心语言。 SQL的发展是从1974年开始的，其发展过程如下： 1974年—--由Boyce和Chamberlin提出，当时称SEQUEL。 1976年—--IBM公司的Sanjase研究所在研制RDBMS SYSTEM R 时改为SQL。 1979年—--ORACLE公司发表第一个基于SQL的商业化RDBMS产品。 1982年—--IBM公司出版第一个RDBMS语言SQL/DS。 1985年—--IBM公司出版第一个RDBMS语言DB2。 1986年—--美国国家标准化组织ANSI宣布SQL作为数据库工业标准。 SQL是一个标准的数据库语言，是面向集合的描述性非过程化语言。 它功能强，效率高，简单易学易维护（迄今为止，我还没见过比它还好 学的语言）。然而SQL语言由于以上优点，同时也出现了这样一个问题： 它是非过程性语言，即大多数语句都是独立执行的，与上下文无关，而 绝大部分应用都是一个完整的过程，显然用SQL完全实现这些功能是很困 难的。所以大多数数据库公司为了解决此问题，作了如下两方面的工作： (1)扩充SQL，在SQL中引入过程性结构；(2)把SQL嵌入到高级语言中， 以便一起完成一个完整的应用。 二. SQL语言的分类 SQL语言共分为四大类：数据查询语言DQL，数据操纵语言DML，数据定义语言DDL，数据控制语言DCL。 1. 数据查询语言DQL 数据查询语言DQL基本结构是由SELECT子句，FROM子句，WHERE 子句组成的查询块： SELECT <字段名表> FROM <表或视图名> WHERE <查询条件> 2 .数据操纵语言DML 数据操纵语言DML主要有三种形式： 1) 插入：INSERT 2) 更新：UPDATE 3) 删除：DELETE 3. 数据定义语言DDL 数据定义语言DDL用来创建数据库中的各种对象—--表、视图、 索引、同义词、聚簇等如： CREATE TABLE/VIEW/INDEX/SYN/CLUSTER | | | | | 表 视图 索引 同义词 簇 DDL操作是隐性提交的！不能rollback 4. 数据控制语言DCL 数据控制语言DCL用来授予或回收访问数据库的某种特权，并控制 数据库操纵事务发生的时间及效果，对数据库实行监视等。如： 1) GRANT：授权。 2) ROLLBACK [WORK] TO [SAVEPOINT]：回退到某一点。 回滚—ROLLBACK 回滚命令使数据库状态回到上次最后提交的状态。其格式为： SQL>ROLLBACK; 3) COMMIT [WORK]：提交。 在数据库的插入、删除和修改操作时，只有当事务在提交到数据 库时才算完成。在事务提交前，只有操作数据库的这个人才能有权看 […]
View Details锁是计算机协调多个进程或线程并发访问某一资源的机制。锁保证数据并发访问的一致性、有效性；锁冲突也是影响数据库并发访问性能的一个重要因素。锁是Mysql在服务器层和存储引擎层的的并发控制。 加锁是消耗资源的，锁的各种操作，包括获得锁、检测锁是否是否已解除、释放锁等。 锁机制 共享锁与排他锁 共享锁（读锁）：其他事务可以读，但不能写。 排他锁（写锁） ：其他事务不能读取，也不能写。 粒度锁 MySQL 不同的存储引擎支持不同的锁机制，所有的存储引擎都以自己的方式显现了锁机制，服务器层完全不了解存储引擎中的锁实现： MyISAM 和 MEMORY 存储引擎采用的是表级锁（table-level locking） BDB 存储引擎采用的是页面锁（page-level locking），但也支持表级锁 InnoDB 存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。 默认情况下，表锁和行锁都是自动获得的， 不需要额外的命令。 但是在有的情况下， 用户需要明确地进行锁表或者进行事务的控制， 以便确保整个事务的完整性，这样就需要使用事务控制和锁定语句来完成。 不同粒度锁的比较： 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。 这些存储引擎通过总是一次性同时获取所有需要的锁以及总是按相同的顺序获取表锁来避免死锁。 表级锁更适合于以查询为主，并发用户少，只有少量按索引条件更新数据的应用，如Web 应用 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。 最大程度的支持并发，同时也带来了最大的锁开销。 在 InnoDB 中，除单个 SQL 组成的事务外， 锁是逐步获得的，这就决定了在 InnoDB 中发生死锁是可能的。 行级锁只在存储引擎层实现，而Mysql服务器层没有实现。 行级锁更适合于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用，如一些在线事务处理（OLTP）系统 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。 MyISAM 表锁 MyISAM表级锁模式： 表共享读锁 （Table Read Lock）：不会阻塞其他用户对同一表的读请求，但会阻塞对同一表的写请求； 表独占写锁 （Table Write Lock）：会阻塞其他用户对同一表的读和写操作； MyISAM 表的读操作与写操作之间，以及写操作之间是串行的。当一个线程获得对一个表的写锁后， 只有持有锁的线程可以对表进行更新操作。 其他线程的读、 写操作都会等待，直到锁被释放为止。 默认情况下，写锁比读锁具有更高的优先级：当一个锁释放时，这个锁会优先给写锁队列中等候的获取锁请求，然后再给读锁队列中等候的获取锁请求。 （This ensures that updates to a table are not “starved” even when there is heavy SELECT activity for the table. However, if there are many updates for […]
View Details概述 为了防止分布式系统中的多个进程之间相互干扰，我们需要一种分布式协调技术来对这些进程进行调度。而这个分布式协调技术的核心就是来实现这个分布式锁。 为什么要使用分布式锁 成员变量 A 存在 JVM1、JVM2、JVM3 三个 JVM 内存中 成员变量 A 同时都会在 JVM 分配一块内存，三个请求发过来同时对这个变量操作，显然结果是不对的 不是同时发过来，三个请求分别操作三个不同 JVM 内存区域的数据，变量 A 之间不存在共享，也不具有可见性，处理的结果也是不对的 注：该成员变量 A 是一个有状态的对象 如果我们业务中确实存在这个场景的话，我们就需要一种方法解决这个问题，这就是分布式锁要解决的问题 分布式锁应该具备哪些条件 在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行 高可用的获取锁与释放锁 高性能的获取锁与释放锁 具备可重入特性（可理解为重新进入，由多于一个任务并发使用，而不必担心数据错误） 具备锁失效机制，防止死锁 具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败 分布式锁的实现有哪些 Memcached：利用 Memcached 的 add 命令。此命令是原子性操作，只有在 key 不存在的情况下，才能 add 成功，也就意味着线程得到了锁。 Redis：和 Memcached 的方式类似，利用 Redis 的 setnx 命令。此命令同样是原子性操作，只有在 key 不存在的情况下，才能 set 成功。 Zookeeper：利用 Zookeeper 的顺序临时节点，来实现分布式锁和等待队列。Zookeeper 设计的初衷，就是为了实现分布式锁服务的。 Chubby：Google 公司实现的粗粒度分布式锁服务，底层利用了 Paxos 一致性算法。 通过 Redis 分布式锁的实现理解基本概念 分布式锁实现的三个核心要素： 加锁 最简单的方法是使用 setnx 命令。key 是锁的唯一标识，按业务来决定命名。比如想要给一种商品的秒杀活动加锁，可以给 key 命名为 “lock_sale_商品ID” 。而 value 设置成什么呢？我们可以姑且设置成 1。加锁的伪代码如下：
|
1 2 |
setnx（lock_sale_商品ID，1） |
当一个线程执行 setnx 返回 1，说明 key 原本不存在，该线程成功得到了锁；当一个线程执行 setnx 返回 0，说明 key […]
View Details8 月初，当 Linux 5.8 RC 版本开放测试时，大多数的新闻都聚焦于它的大小，称其为“史上最大的内核版本”。正如 Linus Torvalds 本人指出的那样，“尽管没有任何一件事情能脱颖而出……但 5.8 似乎是我们有史以来最大的发行版之一。” 确实，刚刚发布的 Linux 内核 5.8 RC 具有超过 14,000 个 commit，约 80 万行新代码以及大约 100 名新贡献者。要知道，距离 5.7 正式版发布才仅仅过去了约 2 个月的时间。Linux 内核维护者 Steven Rostedt 认为，5.8 之所以变得如此之大，很有可能是因为 COVID-19 疫情让很多人难以出门旅行，所有人都因此能够在这期间完成比平时更多的工作。 Rostedt 表示，从一个经验丰富的 Linux 内核贡献者和维护者的角度来看，5.8 RC 发行版特别令人震惊的并不是它的大小，而是它的空前规模对于那些正在维护它的人来说却没有造成困扰，“我认为这是因为 Linux 具有比世界上任何软件项目都好的工作流程。” 拥有最佳的工作流程意味着什么？对 Rostedt 而言，这归结为 Linux 内核开发人员随着时间的推移建立的一系列基本规则，以使他们能够持续不断地大规模、可靠地发展 Linux 内核项目。Rostedt 站在一个 Linux 内核资深维护者的角度，为我们分享了庞大的 Linux 内核项目 30 年来是如何有条不紊地运转的。 第一个关键因素是 Git 首先让我们从 Linux 项目的历史来看。在该项目的早期（1991-2002年），人们只能直接将补丁发送给 Linus Torvalds。准确地说，Linus 从项目的子维护者那里获取补丁，而这些子维护者从其他代码贡献者那里获取补丁。随着 Linux 内核变得越来越大，代码越来越复杂，很快他们就发现，一切都变得很难扩展和跟踪，并且项目将始终面临合并不兼容代码的风险。 这导致 Linus 开始探索包括 BitKeeper 在内的各种版本管理工具。BitKeeper 是一种最早的分布式版本管理的方法，其他的版本管理系统通常使用签出/修改/签入协议，而 BitKeeper 则向所有人提供整个仓库的副本，并允许开发人员将其变更发送出去以进行合并。Linux 在 2002 年开始短暂地采用了 BitKeeper，但是由于其本身是一个专有软件，被认为不符合社区对开源工作的信念，于是该工具在 2005 年停止使用。为了寻找替代品，Linus 消失了一段时间，并带着 git 回来了，后者成为了更强大的分布式版本管理系统，并且是管理流程的第一个重要实例化。Git 的出现使 Linux 开发在今天依然运转良好。 Rostedt 为我们列出了 Linux […]
View Details打个比方 我们有个文件夹project project里面有一堆文件夹 aaa,bbb,ccc,我们需要找到aaa文件夹的其中某个文件file.txt的修改记录 我们可以再project上开启git操作 然后 输入 git blame -L 11,12 aaa/file.txt -L 11,12 含义是该文件的第11行和12行的修改记录 from:https://www.cnblogs.com/1179929172-zh/p/12938344.html
View Detailsgit bisect是一个很有用的命令，用来查找哪一次代码提交引入了错误。 它的原理很简单，就是将代码提交的历史，按照两分法不断缩小定位。所谓"两分法"，就是将代码历史一分为二，确定问题出在前半部分，还是后半部分，不断执行这个过程，直到范围缩小到某一次代码提交。 本文通过一个实例，解释如何使用这个命令。下面是一个代码库，请将它克隆到本地。
|
1 2 3 4 |
$ git clone <a class="token email-link" href="mailto:git@github">git@github</a><span class="token punctuation">.</span>com<span class="token punctuation">:</span>bradleyboy<span class="token operator">/</span>bisectercise<span class="token punctuation">.</span>git $ cd bisectercise |
这个库是一个网页index.html，在浏览器打开这个网页。
|
1 2 3 |
$ open index<span class="token punctuation">.</span>html |
网页上是一个计数器，有两个按钮。点击+号按钮，可以看到计数器没有递增，反而递减，这说明代码有问题。 现在，就要来查找，到底哪一次代码提交，引入了错误。首先，检查一下代码提交历史。
|
1 2 3 |
$ git log <span class="token operator">--</span>pretty<span class="token operator">=</span>oneline |
可以看到，这个库一共有101次提交。最早的第一次提交的哈希是4d83cf。 git bisect start命令启动查错，它的格式如下。
|
1 2 3 |
$ git bisect start <span class="token punctuation">[</span>终点<span class="token punctuation">]</span> <span class="token punctuation">[</span>起点<span class="token punctuation">]</span> |
上面代码中，"终点"是最近的提交，"起点"是更久以前的提交。它们之间的这段历史，就是差错的范围。 这个例子中，我们选择全部的代码历史。起点是第一次提交4d83cf，终点是最近一次的HEAD。当然，指定其他范围也可以。
|
1 2 3 |
$ git bisect start HEAD 4d83cf |
执行上面的命令以后，代码库就会切换到这段范围正当中的那一次提交，本例是第51次提交。 现在刷新浏览器，点击+按钮，发现可以正常递增。使用git bisect good命令，标识本次提交（第51次）没有问题。
|
1 2 3 |
$ git bisect good |
既然第51次提交没有问题，就意味着错误是在代码历史的后半段引入的。执行上面的命令，Git 就自动切换到后半段的中点（第76次提交）。 现在刷新浏览器，点击+按钮，发现不能正常递增。使用git bisect bad命令，标识本次提交（第76）有问题。
|
1 2 3 |
$ git bisect bad |
执行上面的命令以后，Git 就自动切换到第51次到第76次的中点（第63次提交）。 接下来，不断重复这个过程，直到成功找到出问题的那一次提交为止。这时，Git 会给出如下的提示。
|
1 2 3 |
b47892 is the first bad commit |
既然找到那个有问题的提交，就可以检查代码，确定具体是什么错误。 然后，使用git bisect reset命令，退出查错，回到最近一次的代码提交。
|
1 2 3 |
$ git bisect reset |
现在就可以开始修复错误了。 （完） from:http://www.ruanyifeng.com/blog/2018/12/git-bisect.html
View Details