一、数据库事务机制

ACID描述

1、原子性Atomicity：事务通常由多个语句组成。原子性保证将每个事务视为一个“单元”，该事务要么完全成功，要么完全失败

2、一致性Consistency：“一致”是指数据库中的数据是正确的，不存在矛盾。事务的一致性是指事务执行前后，数据都是正确的，不存在矛盾。如果执行后数据是矛盾的，事务就会回滚到执行前的状态（执行前是一致的）

3、隔离性Isolation：通常数据库会有多个事务同时执行，隔离可确保事务的并发执行不会相互干扰。

4、持久性Durability：持久性保证一旦事务被提交，即使在系统故障（例如，停电或崩溃）的情况下，事务也将保持提交状态

一致性详解：数据库事务一致性的理解_事务的一致性-CSDN博客

二、数据库锁机制

锁机制保证了数据库事务的ACID特性

表锁

行锁

查看锁情况：mysql8查看锁信息_Mysql_脚本之家

1、性能测试，涉及更新数据库的接口，比如修改用户头像，可能会因为锁，导致接口慢

2、性能测试，某个接口，比如注册，如果需要操作三个表，但是批量执行后，三个表更新的数据条数不一致，说明事务控制出了问题。——所以性能测试后要验证数据库中数据的一致性

三、数据库调优思路汇总

1、数据库出现瓶颈的现象：

1.1、资源使用率过高

CPU、网络资源、硬盘资源、内存

1.2、有慢查询日志

超过慢查询阈值long_query_time的增删改查语句

查询是否开启慢查询

show variables like '%slow_query_log%';

开启慢查询

set global slow_query_log='ON';

修改慢查询阈值（查过这个值的查询、更新会被记录到满查询log中）

set global long_query_time=1;

满查询日志

slow_query_log_file

注意：命令行可以，navicat会报错误

mysql> show variables like '%slow_query_log%';
+---------------------+-----------------------------------------+
| Variable_name       | Value                                   |
+---------------------+-----------------------------------------+
| slow_query_log      | OFF                                     |
| slow_query_log_file | /var/lib/mysql/VM-100-3-centos-slow.log |
+---------------------+-----------------------------------------+
2 rows in set (0.00 sec)
mysql> set global slow_query_log='ON';
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like '%slow_query_log%';
+---------------------+-----------------------------------------+
| Variable_name       | Value                                   |
+---------------------+-----------------------------------------+
| slow_query_log      | ON                                      |
| slow_query_log_file | /var/lib/mysql/VM-100-3-centos-slow.log |
+---------------------+-----------------------------------------+
2 rows in set (0.00 sec)
mysql> set global long_query_time=1;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like '%long_query_time%';
+-----------------+-----------+
| Variable_name   | Value     |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
1 row in set (0.00 sec)

2、调优——连接池

连接池过多——数据库压力大，处理变慢——资源使用率高——降低连接池数量

连接池过少——应用等待连接池释放消耗时间，导致程序响应慢——资源使用率低——增加连接池数量

3、调优——内存大小

内存大小变量：innodb_buffer_pool_size

可以修改该变量，调整大小，数据库一般独立部署运行，服务器的内存80%给到数据库

mysql> show variables like '%innodb_buffer_pool_size%';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+
1 row in set (0.00 sec)

mysql> 

4、调优——SQL

4.1 查询调优

（1）尽量用到索引

未用到索引的情况
- 对应筛选条件 没建立索引，那就不会用到索引
-【数据量比较小】创建了索引不一定会用到索引，数据库本身有优化机制

如何查看表创建的索引：show index from 表;

如何检测SQL语言用到索引
查看执行计划：EXPLAIN  sql 语句
执行计划内容：

主要看Type字段，从上往下 --- 逐步变慢

 索引最好的状态就是以下三种
1）consts 单表中最多只有一个匹配行（主键或者唯一索引），在优化阶段即可读取到数据

2）ref 指的是使用普通的索引（normal index）

3）range 对索引进行范围检索

下面三种都比较慢type=index，索引物理文件全扫描，速度非常慢，这个 index 级别比较 range 还低，与全表扫描是小巫见大巫

（2）尽量避免查询不需要的数据查询需要的信息

避免：select *
实际业务场景，可能只需要记录的 部分字段
原因：查询不需要的数据 -- 占内存、网络带宽最终 影响 响应时间、吞吐量

（3）避免大量的表关联 join

一条SQL查询 涉及的表越多， SQL越慢
 阿里巴巴 内部： 禁止出现 3张表以上的关联查询

（4）搜索场景严禁左模糊或者全模糊

like 模糊查询可能导致索引失效

右模糊走索引，左模糊、全模糊不走索引
 
右模糊 'aa%'

全模糊：'%aa%'

左模糊： '%aa'

（5）功能设计： 不论表大小，都要加上分页的参数

防止 后续数据库表数据增加，而产生性能问题
性能测试-- 针对未来的某个场景模拟 未来表数据增加之后，系统是否能够支撑

4.2 更新调优

非必要，不要主动锁数据
    数据库 提供SQL语句，主动 锁表/锁记录
    如果因为数据被锁，而导致 请求变慢 【监控 数据库 锁等待信息】
及时关闭事务
    事务 会导致 数据库 锁表/锁数据 情况
    操作完数据库之后，没有及时 关闭事务，可能导致其他操作数据的变慢
大量更新可以用批处理
    业务场景
        数据导入功能
        数据批量删除/修改
    1. 数据库 -- 批量执行多条SQL语句
    2. 插入 -- values sql

5、调优——表结构

设计表的时候。就要考虑索引
    数据量非常大的时候，创建索引是很慢的
    创建索引也可能导致数据库变卡

表结构可以适当的做一些冗余
字段允许适当冗余，以提高查询性能，但必须考虑数据一致。冗余字段应遵循：

      1）不是频繁修改的字段。

      2）不是 varchar 超长字段，更不能是 text 字段。正例：商品类目名称使用频率高，字段长度短，名称基本一成不变，可在相关联的表中冗余存储类目名称，避免关联查询。

缺点： 字段修改的时候会涉及多个表很麻烦，而且占用更多空间 这就是性能优化的取舍

触发器、主外键，高并发下避免使用
触发器：当我们执行数据操作的时候， 触发数据库里面设定好的 存储过程的时候/用户自定义功能的执行
主外键：当进行数据变更的时候， 数据库会去额外进行主外键检测
主外键的目的：是为了确保数据的正确性 ，例如：员工表里面的 部门ID字段，和 部门表的ID字段 一一对应，数据的正确 应该交给 应用程序去维护（业务逻辑），而不是交给数据库，因为数据库的性能不高，删除部门之前，程序先查询部门下是否有员工。尽量少让数据库干活

表字段类型尽量和使用时需要的类型相匹配，避免无谓的类型转换

6、调优——集群架构

单台数据库服务器，在面临海量的数据，海量的请求情况下， 肯定是有上限
集群架构
    用多台服务器
    部署多个数据库服务
    从开发调用的角度，依然是像一台服务器去使用‘
 

数据库服务器
     分库分表：每个数据库服务器上，有一张结构一样的表：
 

shardingsphere（数据库中间件）：

官网：https://shardingsphere.apache.org/index_zh.html

虚拟数据库：本质上是数据库代理，需要依赖java环境
server.yaml：配置 虚拟数据库 用户名 和密码
config-sharding.yaml：真实操作的数据库信息、操作的规则
start.bat：启动，默认端口 3307
使用时，连接数据库代理，而不是 真实的数据库
注意事项： 这个软件也是需要单独部署，这个服务器也需要监控起来这个服务器的配置也需要比较高，所有的sql 都需要经过 
它不做数据真实存储，只是 做SQL的分发，和 结果的合并

分库分表
    一个表拆分为多个表，甚至放在不同的服务器
读写分离
    一个数据库 主服务器 负责 写入数据
    读取数据的所有sql请求，由其他从服务器进行处理