0%

语法手册:cmake语法手册及教程_可克的博客-CSDN博客_cmake语法

哔哩哔哩视频

视频下方有笔记

图片

add_definitions()添加编译选项

include_directories()将指定目录添加到编译器的头文件搜索路径下

参考

add_library()生成静态库(STATIC)或者动态库(SHARED)

add_executable()生成可执行文件

aux_source_directory(dir VAR) 发现一个目录(dir)下所有的源代码文件并将列表存储在一个变量(VAR)中

target_link_libraries( # 目标库 demo # 目标库需要链接的库 ${log-lib} )

如果一个文件被设置了SUID或SGID位,会分别表现在所有者或同组用户的权限的可执行位上。例如:

1、-rwsr-xr-x 表示SUID和所有者权限中可执行位被设置

2、-rwSr–r– 表示SUID被设置,但所有者权限中可执行位没有被设置

3、-rwxr-sr-x 表示SGID和同组用户权限中可执行位被设置

4、-rw-r-Sr– 表示SGID被设置,但同组用户权限中可执行位没有被设置

给文件加SUID和SUID的命令如下:

chmod u+s filename 设置SUID位

chmod u-s filename 去掉SUID设置

chmod g+s filename 设置SGID位

chmod g-s filename 去掉SGID设置

SUID属性
例如/usr/bin/passwd 带有SUID属性 属于root用户 root用户主
其它用户只有/usr/bin/passwd的可执行权限,在执行这个命令时会暂时获取root权限

SGID属性
和SUID属性十分相似
不同的是其它用户在执行有SGID属性的命令时,会暂时获取该程序群组的支持

正规方程

正规方程是通过求解下面的方程来找出使得代价最小的函数
只适用于线性模型,不适合逻辑回归模型等其它模型

过拟合、欠拟合、权重衰退

训练误差和泛化误差

训练误差:模型在训练数据集上计算得到的误差
泛化误差:模型应用在同样从原始样本的分布中抽取的无限多数据样本时,模型误差的期望

我们永远不能准确地计算出泛化误差。这是因为无限多地数据样本是一个虚构的对象。在实际中,我们只能通过将模型应用于一个独立的测试集来估计泛化误差,该测试集由随机选取的、未曾在训练集中出现的数据样本构成

模型复杂度

几个倾向于影响模型泛化的因素
1.可调整参数的数量。当可调整参数的数量(自由度)很大时,模型往往更容易过拟合
2.参数采用的值。当权重的取值范围较大时,模型可能更容易过拟合
3.训练样本的数量。即使模型很简单,也很容易过拟合只包含一两个样本的数据集。而过拟合一个有数百万个样本的数据集则需要一个极其灵活的模型

正则化是处理过拟合的常用方法:在训练集的损失函数中加入惩罚项,以降低学习到的模型的复杂度

Unet网络

Unet

事务并发执行遇到的问题
1.脏写:
一个事务修改了另一个未提交事务修改过的数据
2.脏读
一个事务读到了另一个未提交事务修改过的数据
3.不可重复读
一个事务只能读到另一个已经提交的事务修改过的数据,并且其它事务每对该数据进行一次修改,并提交后都能查询得到最新值
4.幻读
一个事务先根据某些条件查询出一些记录,之后另一个事务又向表中插入了符合这些条件的记录,原先的事务再次按照该条件查询时,能把另一个事务插入的记录也读出来

MySQL四种隔离级别
微信截图_20230219113504.png

MVCC原理(多版本并发控制)
版本链
READ COMMITTED和REPEATABLE READ生成ReadView的时机不同

事务id

  • 对于只读事务来说,只有在它第一次对某个用户创建的临时表执行增、删、改操作时才会为这个事务分配一个事务id
  • 对于读写事务来说,只有在它第一次对某个表(包括用户创建的临时表)执行增、删、改操作时才会为这个事务分配一个事务id

聚簇索引的记录还会自动添加名为trx_id、roll_pointer的隐藏列
其中trx_id就是对这个聚簇索引记录做改动的语句所在的事务对应的事务id
roll_pointer就是一个指向记录对应的undo日志的一个指针

与在事务提交时将所有修改过的内存中的页面刷新到磁盘中相比,只将该事务执行过程中产生的redo日志刷新到磁盘的好处如下
1.redo日志占用的空间非常小
2.redo日志是顺序写入磁盘的

每条语句包含多个mtr,每个mtr包含一组redo log
一个mtr运行结束后,会将产生的一组redolog复制到log buffer中,在一些情况下它们会被刷新到磁盘里
1.log buffer空间不足时
2.事务提交时
3.后台线程不停地刷
4.正常关闭服务器
5.做checkpoint 时
6.其它情况

redo日志文件前4个block

  • log file header:描述该日志文件地一些整体属性
  • checkpoint1
  • 无用
  • checkpoint2

Log Sequence Number(日志序列号)lsn
每一组由mtr生成地redo日志都有一个唯一的lsn值与其对应,lsn值越小,说明redo日志产生的越早

在mtr结束时,还会将执行过程中可能修改过的页面加入到buffer pool 的flush链表

checkpoint:
redo日志只是为了系统崩溃后恢复脏页用的,如果对应的脏页已经刷新到磁盘,就不需要对应的redo日志了,所以判断某些redo日志占用的磁盘空间是否可以覆盖的依据就是它对应的脏页是否已经刷新到磁盘里。

做一次checkpoint其实可以分为两个步骤
1.计算一下当前系统中可以被覆盖的redo日志对应的lsn值最大是多少(有必要的话更新checkpoint_lsn)
2.将checkpoint_lsn和对应的redo日志文件组偏移量以及此次checkpoint的编号写到日志文件的管理信息(目前系统做了多少次checkpoint的变量checkpoint_no,每做一次checkpoint,该变量就加1)

1.原子性:要么全做,要么全不做
2.隔离性:保证其它的状态转换不会影响到本次的状态转换
3.一致性(符合所有现实世界的约束):

  • 数据库本身能为我们保证一部分一致性需求,比如MySQL数据库可以为表建立主键、唯一索引、外键、声明某个列为NOT NULL来拒绝NULL值的插入。又比如对某个列建立了唯一索引时,如果插入某条记录时该列的值重复了,那么MySQL就会报错并且拒绝插入,MySQL还支持CHECK语法来自定义约束,但是实际上MySQL并不会去检查CHECK子句中的约束是否成立,但是我们还是可以通过定义触发器的方式来自定义一些约束条件以保证数据库中的一致性
  • 更多的一致性需求需要靠写业务代码的程序员自己保证,现实生活中复杂的一致性需求比比皆是,而由于性能问题把一致性需求交给数据库去解决这是不现实的,所以就把锅甩给了业务端程序员

原子性和隔离性都会对一致性产生影响,数据库某些操作的原子性和隔离性都是保证一致性的一种手段,在操作执行完成后保证符合所有既定的约束则是一种结果

4.持久性:状态转换后,这个转换的结果是永久保留的

事务的定义:把需要保证原子性、隔离性、一致性、持久性的一个或多个数据库操作称之为一个事务

事务的状态转换图如下
微信截图_20230218105257.png

隐式提交

当我们适用START TRANSACTION 或者BEGIN 语句开启了一个事务,或者把系统标量auto commit为OFF时,事务就不会进行自动提交,但是如果我们输入了某些语句之后就会悄悄的提交掉
1.定义或修改数据库对象的数据定义语言:所谓的数据库对象,指的就是数据库、表、视图、存储过程等,当我们使用CREATE、ALTER、DROP等语句去修改这些所谓的数据库对象时,就会隐式的提交前面语句所属的事务
2.隐式使用或修改数据库中的表:当我们使用ALTER USER、CREATE USER、DROP USER、GRANT、RENAME USER、REVOKE、SET PASSWORD等语句时也会隐式的提交前面语句所属于的事务
3.事务控制或关于锁定的语句:当我们在一个事务还没有提交或者回滚时就又使用START TRANSACTION 或者BEGIN语句开启了另一个事务,会隐式提交上一个事务
4.加载数据的语句:使用LOAD DATA等
5.关于MySQL复制的一些语句:使用START SLAVE、STOP SLAVE、RESET SLAVE、CHANGE MASTER TO等语句时也会隐式的提交前面语句所属的事务
6.其它的一些语句:使用ANALYZE TABLE、CACHE INDEX、CHECK TABLE、FLUSH、LOAD INDEX INTO CACHE、OPTIMIZE TABLE、REPAIR TABLE、RESET等语句

保存点

定义保存点的语法如下:

1
SAVEPOINT 保存点的名称
1
ROLLBACK [WORK] TO [SAVEPOINT] 保存点名称

条件简化

1.移除不必要的括号
2.常量传递
3.等值传递
4.表达式计算
5.HAVING子句和WHERE子句的合并

子查询的执行方式

  • 对于包含不相关的标量子查询或者行子查询的语句来说,MySQL会分别独立执行外层查询和子查询,就当作两个单表查询就行
  • 对于相关的标量子查询或者行子查询,它的执行方式如下:
    QQ截图20230217111828.png

IN子查询优化

如果子查询的结果集中的记录条数很少,那么把子查询和外层查询分别看成两个单独的单表查询效率还是很高的,但是子查询的结果集太多的话会导致一下问题

  • 结果集太多,内存无法存下
  • 对于外层查询来说,如果子查询的结果集太多,就意味着IN子句中的参数很多,会导致(1.无法有效的使用索引,只能对外层查询进行全表扫描 2.在对外层查询执行全表扫描时,由于IN子句中的参数太多,这会导致检测一条记录是否符合和IN子句中的参数匹配花费的时间太长)

    解决办法:不直接将不相关子查询的结果集当作外层查询的参数,而是将该结果写入一个临时表(1.该临时表的列就是子查询结果集中的列 2.写入临时表的记录会被去重 3.一般情况下子查询结果不会大的离谱,所以会为集合中的数据建立基于内存的存储引擎的临时表,并为该表建立哈希索引,如果子查询结果很大,会转而使用基于磁盘的存储引擎来保存结果集中的记录,索引类型也对应转变为B+树索引)

物化表转连接

松散索引扫描

如果IN子查询不满足转换为semi-join的条件,又不能转换为物化表或者转换为物化表的成本太大,那么它就会转换为EXISTS查询