一、数据库事务机制
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请求，由其他从服务器进行处理
