sql分类，主要分为DDL，DML，DQL, DCL
DDL:定义数据库对象（数据库，表，字段）
DML：对数据库表中的数据增删改
DQL：数据查询语言，查询表中的记录
DCL：用来创建数据库用户，控制数据库的访问权限
DDL：
1.查看数据库：
show databases;
2.查看当前数据库：
select database();
3.创建数据库：
create database 数据库名；
create database if not exists 数据库名；
create database default charset utf8mb4;
4.删除数据库：
drop database if exists 数据库名；
5.切换数据库；
use 数据库名；
表操作：
1.查看当前数据库所有表
show tables；
2.查看表结构：
desc 表名； 3.查看建表语句；
show create table 表名；
4.创建表结构
create table 表名(
字段1 字段类型 )
create table user(
id int comment '主键ID',
name varchar(50) comment '姓名',
age int comment '年龄'
1. 问题记录 SQL SERVER 2019 安装失败，不知道什么原因。所以安装了 2016 但是之前备份的或者是附加的数据库文件都是 2019 的，版本不一致无法还原到 2016！！！
错误如下： 数据库 'FileServer' 的版本为 904，无法打开。此服务器支持 852 版及更低版本。不支持降级路径。 无法打开新数据库 'FileServer'。
2. 解决方案 2.1 生成数据库脚本 在SQLSERVER 2019 中选择要备份的数据库 —> 任务 —> 生成脚本 —> 设置脚本编辑选项 —> 高级 如下图：
选择指定的版本 2016，选择 要编写脚本的数据的类型：架构和数据 然后 另存为脚本文件
2.2 还原 在需要还原的电脑上打开命令窗口：Win+R cmd 通过命令来进行还原。注意大小写
sqlcmd -S 127.0.0.1,1433 -U sa -P password -d 数据库名 -i d:\data\script.sql -S 服务器 -U 数据库登录ID -P 数据库登录密码 -i 需还原数据库文件地址 -d 要还原数据库名称 注意: 通过命令还原前，必选先创建好数据库，该操作只是还原架构和数据，并不会创建数据库操作
如果proxy_pass末尾不带/，proxy_pass会拼接location的路径 如果proxy_pass末尾带/，proxy_pass不拼接location的路径 一、proxy_pass末尾有斜杠
location /api/ { proxy_pass http://127.0.0.1:8000/; } 请求地址：http://localhost/api/test转发地址：http://127.0.0.1:8000/test
二、proxy_pass末尾无斜杠
location /api/ { proxy_pass http://127.0.0.1:8000; } 请求地址：http://localhost/api/test转发地址：http://127.0.0.1:8000/api/test
三、proxy_pass包含路径，且末尾有斜杠
location /api/ { proxy_pass http://127.0.0.1:8000/user/; } 请求地址：http://localhost/api/test转发地址：http://127.0.0.1:8000/user/test
四、proxy_pass包含路径，末尾无斜杠
location /api/ { proxy_pass http://127.0.0.1:8000/user; } 请求地址：http://localhost/api/test转发地址：http://127.0.0.1:8000/usertest
or和in的效率对比 结论：对于索引字段or或者in的效率基本一致，非索引字段in的效率优于or
（1）or的效率为O(n)，
（2）in的效率为O(logn)，当n越大的时候效率相差越明显。
验证过程： 第一步：创建测试表，并生成测试数据，测试数据为1000万条记录。数据库中关闭了query cache，因此数据库缓存不会对查询造成影响。
#创建测试的test表 DROP TABLE IF EXISTS test; CREATE TABLE test( ID INT(10) NOT NULL, `name` VARCHAR(20) DEFAULT '' NOT NULL, PRIMARY KEY( ID ) )ENGINE=INNODB DEFAULT CHARSET utf8; #创建生成测试数据的存储过程 DROP PROCEDURE IF EXISTS test_insert; DELIMITER // CREATE PROCEDURE test_insert() BEGIN DECLARE i INT DEFAULT 1; SET autocommit = 0; WHILE i<= 10000000 DO INSERT INTO test ( ID,`name` ) VALUES( i, CONCAT( 'name', i ) ); SET i = i+1; IF i%2000 = 0 THEN COMMIT; END IF; END WHILE; END; // DELIMITER ; #执行存储过程生成测试数据 CALL test_insert(); 第二步：分三种情况进行测试
数据库备份 因数据量庞大，所以我们采用物理方式对mysql数据库进行备份。 使用xtrabackup工具包对mysql数据库进行物理备份： 特点： 备份过程快速、可靠； 备份过程不会打断正在执行的事务； 能够基于压缩等功能节约磁盘空间和流量； 自动实现备份检验； 还原速度快； 原理： 备份开始时首先会开启一个后台检测进程，实时检测mysql redo的变化，一旦发现redo中有新的日志写入，立刻将日志记入后台日志文件xtrabackup_log中。之后复制innodb的数据文件和系统表空间文件ibdata1，待复制结束后，执行flush tables with read lock操作，复制.frm，MYI，MYD，等文件（执行flush tableswith read lock的目的是为了防止数据表发生DDL操作，并且在这一时刻获得binlog的位置）最后会发出unlock tables，把表设置为可读可写状态，最终停止xtrabackup_log。 步骤： 1、 执行备份命令 innobackupex --user=backup --password=*** --socket=/tmp/mysqld.sock --defaults-file=/etc/my.cnf /data/backup/ 2、检查备份文件完整性 1）、查看以下文件是否存在 backup-my.cnf、 xtrabackup_binary、xtrabackup_binlog_info 、xtrabackup_checkpoints xtrabackup_logfile xtrabackup_info 2）、检查文件 xtrabackup_checkpoints —— 备份类型（如完全或增量）、备份状态（如是否已经为prepared状态）和LSN(日志序列号)范围信息； xtrabackup_binlog_info —— mysql服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置。 backup-my.cnf —— 备份命令用到的配置选项信息； xtrabackup_info ——记录备份的基本信息，uuid、备份命令、备份时间、binlog、LSN、以及其他加密压缩等信息。 数据库恢复 原理：
这一阶段会启动xtrabackup内嵌的innodb实例，回放xtrabackup日志xtrabackup_log，将提交的事务信息变更应用到innodb数据/表空间，同时回滚未提交的事务(这一过程类似innodb的实例恢复）。 步骤： 要先关闭mysql数据库，重命名或者删除原数据文件目录都可以，再创建一个新的数据文件目录，将备份数据复制到新的数据文件目录下，赋权，修改权限，启动数据库 1、/etc/init.d/mysqld stop 2、mv /data/mysql /data/mysql_bak 3、mkdir /data/mysql 4、innobackupex --apply-log /data/backup/2018-05-21_10-05-04/ 5、innobackupex --defaults-file=/etc/my.
一、复制集的作用
（一）复制集的主要意义在于实现服务的高可用
（二）他的视线依赖于两个方面的功能
（1）数据写入时将数据迅速复制在另一个独立节点上
（2）再接受写入的节点发生故障时自动选举出一个新的替代节点
（三）在实现高可用的同时，复制集实现了其他的几个附加作用
（1）数据分发。将数据从一个区域复制到另一个区域，减少另一个区域的读延迟（相当于在其他区域创建了一个从节点，方便其他区域读）
（2）读写分离。不同的类型的压力分别在不同的节点上执行
（3）异地容灾。在数据中心故障时候快速切花到异地
二、典型复制集结构
（一）一个主节点（promary）：接受写入操作和选举时投票（一半以上）
（二）两个（或多个）从节点（secondary）：复制主节点上的新数据和选举时投票 （从节点只能读）
（三）不推荐使用Arbiter（投票节点）。（很多时候会多出一个无数据节点作为投票节点。防止出现投票主机出现偶数的现象）推荐使用三数据节点
三、数据是如何复制
（一）当一个修改操作，无论是插入、更新、删除。达到主节点时，他对数据的操作被记录下来（经过一些必要的转换），这些记录被称为oplog（在mongo中是一个集合）。
（二）从节点通过在主节点上打开一个tailable游标不断获取新进入主节点的oplong。并在自己的数据上回放。以此保持跟主节点数据一致
四、通过选举完成故障恢复
（一）具有投票权的节点之间两两互相发送心跳（默认每两秒发送一次）
（二）当5次心跳未收到时判断为节点失联
（三）如果失联的是主节点，从节点会发起选举，选出新的主节点
（四）如果失联的从节点则不会产生新的选举
（五）选举基于RAFT一致性算法实现，选举成功的必要条件是大多数投票节点存活
（六）复制集中最多可以有50个节点但是具有选举全的节点最多有7个
五、影响选举的因素
（一）整个集群必须有大多数节点存活
（二）没选举的主节点的节点必须
（1）能够与多数节点建立连接 （2）具有较新的oplog（数据比较多）
（3）具有较高的优先级（如果有配置）
六、常见选项
（一）复制集节点有以下常见的选项
（1）是否具有投票权（v参数）：有则参与投票。默认都具有
（2）优先级（priority参数）优先级越高的节点越优先称为主节点。优先级为0的无法成为主节点
（3）隐藏（hidden参数）复制数据，但是对应用不可见。隐藏节点可以具有投票权。但是优先级必须为0（可以作为备份数据，有时候不需要参数据的操作和业务程序的服务）
（4）延迟（slaveDelay参数）复制N秒钟前的数据保持与主节点的时间差
理论 Redis事务的概念：
Redis 事务的本质是一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。
总结说：redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。
Redis事务没有隔离级别的概念：
批量操作在发送 EXEC 命令前被放入队列缓存，并不会被实际执行！
Redis不保证原子性：
Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。
Redis事务的三个阶段：
开始事务 命令入队 执行事务 Redis事务相关命令：
watch key1 key2 ... # 监视一或多个key,如果在事务执行之前，被监视的key被其他命令改动，则事务被打断 （ 类似乐观锁 ） multi # 标记一个事务块的开始（ queued ） exec # 执行所有事务块的命令 （ 一旦执行exec后，之前加的监控锁都会被取消掉 ） discard # 取消事务，放弃事务块中的所有命令 unwatch # 取消watch对所有key的监控 实践 正常执行
放弃事务
若在事务队列中存在命令性错误（类似于java编译性错误），则执行EXEC命令时，所有命令都不会执行。
若在事务队列中存在语法性错误（类似于java的1/0的运行时异常），则执行EXEC命令时，其他正确命令会被执行，错误命令抛出异常。
Watch 监控
悲观锁： 悲观锁(Pessimistic Lock),顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿到这个数据就会block直到它拿到锁。传统的关系型数据库里面就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在操作之前先上锁。
乐观锁：
乐观锁(Optimistic Lock),顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁。但是在更新的时候会判断一下再此期间别人有没有去更新这个数据，可以使用版本号等机制，乐观锁适用于多读的应用类型，这样可以提高吞吐量，乐观锁策略：提交版本必须大于记录当前版本才能执行更新。
测试：
1、初始化信用卡可用余额和欠额
vi /etc/sysconfig/network-scripts/ifcfg-ens33
从配置清单中可以发现 CentOS 7 默认是不启动网卡的(ONBOOT=no)。
把这一项改为YES(ONBOOT=yes)
然后按 Esc 退出 再出入命令 :wq 再按Enter即可 (备注 :wq 是保存然后退出的意思 )
然后重启网络服务： systemctl restart network
然后我们再输入 ip addr 或者 ip a 命令查看即可以了
问题描述：
* 针对 DB 中不存在的数据源，每次请求缓存和数据库都不存在
造成后果：
* 应用服务器压力变大
* Redis 命中率大幅度降低
* `数据库压力巨增甚至 down 掉`* 该现象对于 Redis 无影响，奔溃的是数据库 造成原因：
* 频繁访问不存在数据
解决方案：
1. 空值缓存：查询数据库返回为 null 时也进行缓存，但一定设置很短的过期时间
2. 实时监控：对 Redis 命中率进行实时监控，当发现命中率极速降低时，人为排查访问对象和访问数据，和运维人员配合，可以设置黑名单限制服务
3. 设置访问白名单：使用 bitmaps 类型定义一个可以访问的名单，名单 id 作为 bitmaps 的偏移量，每次访问和 bitmap 里面的 id 进行比较，如果访问 id 不在 bitmaps 里面，进行拦截，不允许访问。
4. 布隆过滤器：它实际上是一个很长的二进制向量 (位图) 和一系列随机映射函数（哈希函数）。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。
nginx安装包下载地址：http://nginx.org/en/download.html，注意下载Stable version
把nginx的源码包上传到linux系统
上传到 /usr/local 目录下
解压缩包，先执行 cd /usr/local 进入目录下
[root@localhost ~]tar zxf nginx-1.18.0.tar.gz
安装nginx，进入nginx目录，执行./configure
执行make && make install
启动nginx，进入sbin文件夹下，cd /usr/local/nginx/sbin
[root@localhost sbin]# ./nginx
检查是否启动成功
[root@localhost sbin]# ps -ef|grep nginx
关闭nginx：[root@localhost sbin]# ./nginx -s stop
关闭推荐使用：[root@localhost sbin]# ./nginx -s quit