云原生Java Web领域技术博客

在基于数据库进行业务功能的开发时，如何保证数据库访问的性能是区分普通程序员和高级程序员的分水岭。这里系统的梳理下如何在程序员视角下实现数据库访问性能优化。

在MySQL中，根据加锁的粒度，可以将数据库的锁细分为表锁、行锁、页锁。其中，表锁(Table Lock)是一种粗粒度的锁，它锁定整个表，阻止其他事务访问表中的任何行；行锁(Row Lock)是一种细粒度的锁，它锁定指定的行；页锁(Page Lock)是介于行锁和表锁之间的一种锁机制，它锁定表的一个页或多个页。此外，无论是表锁，还是行锁，都可以根据是否独占数据还是共享数据，进一步细分为共享锁和排他锁。

数据库锁是一种机制，用于管理并发访问数据库的方式。当多个用户或事务同时访问数据库时，可能会导致数据不一致或冲突的问题。数据库锁的作用是确保数据的一致性和完整性，同时允许多个用户并发地访问数据库。 需要注意的是，加锁是消耗资源的，锁的各种操作，包括获取锁、校验锁是否已解除、释放锁等，都会增加系统的开销。

多表查询是使用SQL必须掌握的技能。多表查询实现的本质是笛卡尔积，在数据库中对应的操作定义为连接。也就是说，在数据库中，使用连接实现多表查询——将多个表连接起来，使其看起来像一个表。

在MySQL中，引入NULL值表示一个未知值，以表示不可知、不确定。尽管提供了NULL值，但是在日常开发中，不建议使用NULL值，建议为其设置默认值，如空字符串或 0 等。如果必须使用NULL，需要明确其影响，避免引入业务异常。

分页查询数据，需要返回total，而这个值一般都是通过count函数实现。但是，针对count函数，有多种写法，如count(*)、count(1) 和 count(column)等。本文主要介绍以上几种写法的差异。 注意，这里仅针对MySQL数据库，其他类型的数据库仅供参考。

本文介绍了数据库CPU飙高问题定位及解决，重点介绍了如何判断慢SQL和QPS过高。需要说明的是，以上内容是笔者基于网上的知识整理的内容，笔者并没有太多这方面的实践经验。但是，上述定位问题的思路和解决方案是有参考价值的。比如使用缓存减少数据库读写次数、批量操作、机器资源配置升级等方案，笔者在实际的产品维护中，都有使用。

在使用数据库的时候，常常使用索引来加快数据的检索速度，提高数据的查找性能。但是，在使用索引的时候，要明确哪些场景下索引会生效，哪些场景下索引会失效。应尽可能避免索引失效，尽量保证索引生效。

索引是帮助数据库高效获取数据的数据结构。索引是加速查询的常用技术手段。在设计索引时，要遵循索引设计规范，避免不必要的踩坑。

好的设计会尽可能少的引入冗余数据，或做有损拆分，而是使用找到正确的分解。而范式则是关系数据库实现设计优化的通用手段。范式与关系数据库的关系可以参考。

现代软件架构的复杂性要求需要多人或多团队协同完成开发。在这种背景下，如何高效地协同完成软件的开发呢?对软件工程来说，数据库设计规范是在数据库设计层面对软件开发者的规范或标准。对软件来说，适当的规范和标准绝不是为了消除代码内容的创造性、优雅性，而是**限制过度个性化，并以一种普遍认可的统一方式一起做事，提升协作效率，降低沟通成本**。代码的字里行间流淌的是软件系统的血液，质量的提升是**尽可能少踩坑，杜绝踩重复的坑**，切实提升系统稳定性，码出质量。

目录锁的分类悲观锁和乐观锁共享锁和排他锁表锁和行锁更新锁(避免更新产生死锁)意向锁锁与数据库隔离级别死锁（Deadlock）产生死锁的四个必要条件死锁预防死锁检测与恢复参考确保事务隔离性的方法之一是要求对数据项以互斥的方式进行访问。也就是说，当一个事务访问某个数据项时，其他任何事务都不能修改该数据项。实现该需求最常用的方法是只允许事务访问当前该事务持有锁(lock)的数据项。锁的分类根据不同的分类标准，可以实现不同的锁划分。如根据使用的加锁策略是悲观策略还是乐观策略，可划分为悲观锁和乐观锁；根据加锁的

目录事务概念事务的基本性质一个简单的事务模型事务原子性和持久性事务隔离性事务隔离性级别隔离性级别的实现锁时间戳多版本和快照隔离构成单一逻辑工作单元的操作集合称作事务（transaction）。即使有故障，数据库系统也必须保证事务的正确执行——要么执行整个事务，要么属于该事务的操作一个也不执行。此外，数据库系统必须以一种能避免引入不一致性的方式来管理事务的并发执行。事务概念事务是访问并可能更新各种数据项的一个程序执行单元（unit）。事务通常由高级数据操纵语言(如SQL)或编程语言（如Java）通过JD

索引（Index）是帮助数据库高效获取数据的数据结构。 如果将数据库比作书，那么索引就相当于目录。

多表查询是使用SQL必须掌握的技能。多表查询实现的本质是笛卡尔积，在数据库中对应的操作定义为连接。也就是说，在数据库中，使用连接实现多表查询——将多个表连接起来，使其看起来像一个表。

学习数据库范式理论后，尽管已经知道范式能够帮助优化数据库设计，但是在使用中却发现，很难将这些理论方便的应用到实际中。本节主要梳理下如何在实际应用中使用范式。范式有很多种，参考关系数据库设计可知有第一范式、第二范式、第三方式、BC范式、第四范式、第五范式、域-码范式等。第一范式当关系模式满足第一范式时，该关系模式所有属性的域都是原子的。常见的非原子域实例如下：(1) 组合属性具有非原子域。如包含子属性street、city、state和zip的属性address。(2) 使用以集合为值的属性会导致

本文简要描述数据库系统设计基本概念，方便后续学习、使用。

构建一个数据库应用是一个复杂的任务，包括设计数据库模式，设计访问和更新数据的程序，以及设计控制数据访问的安全模式。这里的数据库设计是指数据库模式的设计。设计一个完整的数据库应用环境，并满足被建模企业的需求，需要关注广泛的问题。设计阶段设计数据库前，数据库设计者必须与应用的用户进行交互以理解应用的需求，把它们以用户能理解的高级别形式表示出来，然后再将需求转换为较低级别的设计。刻画数据库用户的数据需求。数据库设计的最初阶段需要完整地刻画未来数据库用户的数据需求。为完成这个任务，数据库设计者需要同应

实体-联系（Entity-Relationship， E-R）模型(以下简称E-R模型)的提出旨在方便数据库的设计，它是通过允许定义代表数据全局逻辑结构的企业模式实现的。E-R模型采用三个基本概念：实体集、联系集和属性。将E-R图的知识点打散到各个章节实体集实体（entity）是现实世界中可区别于所有其他对象的一个“事物”或“对象”。（可从面向对象的类含义类似）实体集是相同类型即具有相同性质（或属性）的一个实体集合。在建模汇中，我们通常抽象地使用术语“实体集”，而不是指某个个别实体的特别集合。实体

关系数据库设计的目标是生成一组关系模式，使我们存储信息时避免不必要的冗余，并且可以方便地获取信息。并通过满足适当范式（normal form）来实现设计的优化。好的关系设计的特点好的设计会尽可能少的引入冗余数据，或做有损拆分，而是使用规范的方法找到正确的分解。原子域和第一范式在关系模型中，将属性不具有任何子结构这种思想形式化。一个域是原子的（atomic），如果该域的元素被认为是不可分的单元。我们称一个关系模式R属于第一范式（First Normal Form，1NF），如果R的所有属性的域都是原子