每天学习一点点

找到要新增触发器的表，然后点击设计，找到触发器标签。根据实际需要，填写相关内容，操作完毕，点击保存按钮。在右侧的预览界面，可以看到新生成的触发器脚本。

将路径切换到Dockerflie所在的目录中，执行创建镜像的命令。sampledb是数据库镜像的名称，后面的点代表当前目录中的Dockerfile文件。

假如现在要查询用户表的数据，已知的是用户邮箱或者手机号码，那么key存储的是用户邮箱或者手机号。value存储的事用户表ID和数据所在服务器的编号。该条用户信息的用户ID是9，数据存储在1号服务器上。数据进行了分库分表后，要查询某一条数据的信息，事先是不清楚该条数据在哪台服务器上的，这时候可以使用倒排索引法，将数据的关键信息存储到Redis中，然后从Redis中获取到数据所在的服务器和数据ID。1.多一次查询（需要先从Redis中获取到ID和所在服务器），性能有所下降。

比如要查询ID=100的数据，直接找到存储了100这条记录的表进行查询，不需要找所有表的记录，可以有效缩小磁盘扫描范围。例如将id在1亿到2亿的数据放在一个数据库中，id在2亿到3亿的数据放在一个数据库中，id在3亿到4亿的数据放在一个数据库中。最后一个库中的数据访问概率会比其他表高，因为最后一张库一般存储的是最新产生的数据，访问概率高就会导致最后一个库的处理压力最大。无法预估服务器数据承载量，当前计划每个数据库存储1亿数据，实际可能单台数据库能够存储1.5亿数据，那么就会造成资源的浪费。

通过上面的案例分析，如果要对JSON中其他字段进行查询，同样也可以创建虚拟列，目的就是把JSON中的属性名称映射为一个一个的字段，然后对字段创建索引。因为JSON是弱约束的，因此存储数据非常灵活，同时也可基于虚拟列实现索引优化。$.XXX，$.表示要解析的是JSON数据，XXX是对应JSON中的属性名称。增加虚拟列，解决上述问题，虚拟列是需要跟JSON中的某个属性名称进行对应的。上面的SQL执行时，将会对整个表进行全表扫描，数据量大时，查询就会慢。会发现表中多了一列数据，这一列数据就是虚拟列。

我们再来看看ID = 2的语句究竟做了写什么返回了这么大量的数据，首先全表扫描employee表13317条记录，然后根据索引emp_certificate_empid关联emp_certificate表，rows = 1表示，每个关联都只锁定了一条记录，效率比较高。然后查表扫描了63727条记录，分为两部分，derived表示构造表，也就是不存在的表，可以简单理解成是一个语句形成的结果集，后面的数字表示语句的ID。运行一下，53条记录 1.87秒，又没有用聚合语句，比较慢。

MySQL Common Table Expressions（CTE，公用表表达式）是在MySQL 8.0及更高版本中引入的一种高级SQL构造，它允许用户定义一个临时的结果集，这个结果集可以在同一个查询中被多次引用，从而简化复杂的查询逻辑和提高代码的可读性。在同一个查询中，可以多次引用同一个 CTE，无需重复书写相同子查询。2.进行递归的连接，对应UNION ALL下面的部分，用employees表与递归上一层的结果进行关联，关联条件是员工表中的manager_id与递归结果中的emp_id进行关联。

使用explain extended关键字，查询更为详细的执行计划，在该执行计划中，可以看到MySQL发现的一些警告信息，这里有5个警告信息。在C表中，对user_id字段建立的索引，在执行计划中可以看到，被使用了（type=ref）。A表和C表的数据都是1条，所以选择数据量少的表作为查询的驱动表。2.在A表上建立了联合索引，考虑到如果回表取数据量较大，将关联字段和查询字段冗余到索引中。6.在C表上建立了联合索引，考虑到如果回表取数据量较大，将关联字段和查询字段冗余到索引中。c表可能是人员和订单的关联表；

NestedLoopJoin嵌套循环联接与编程中的二层嵌套类似外表（驱动表）中的每一条记录与内表（被驱动表）中的记录进行比较判断。以上图为例，从员工信息表中，先查询出来员工编号为2和3的员工，然后再去薪资表中查询员工2和3的薪资。此时左侧的员工信息表就是驱动表，关联右侧的薪资表完成查询操作。在查询时，驱动表选择的不同，会直接影响查询效率。一般驱动表的选择由MySQL自行选择。

查询速度上的差异，主要原因是test_table表的引擎为InnoDB，数据存储在磁盘上的。内存的读取速度会比磁盘快很多。MEMORY引擎虽然速度快，但也有缺点，缺点是数据在内存中保存，如果服务器重启，内存中的数据就会丢失。如果不方便使用触发器，也可以将程序代码改为同步双写，在往InnoDB表插入数据后，同步往Memory表中也插入一条数据。4.只读数据：如果数据是只读的，并且不需要长期保存，那么内存表可以提供极佳的查询性能。新表数据插入完毕后，执行分析语句，可以看到查询表完整数据，实际会花费296毫秒。

根据MySQL的执行计划信息，可以用来分析当前查询的执行过程，是否用到序列，是否可以在某些地方进行优化等操作。在navicate中，使用EXPLAIN关键字，就可以看到该SQL的执行计划信息。下面的这个SQL本身没有实际意义，只是为了说明执行计划的信息。EXPLAIN。

将脚本命名为db_back.bat，然后在c盘创建文件夹sql_back，用来存放生成的备份文件。

service crond restart 重启任务调动，一般在设置完成后重启。crontab -r 删除当前用户所有的crontab任务（终止任务调度）crontab -e 编辑crontab定时任务。crontab -l 查询crontab任务。根据实际情况修改相关的参数值。

两张表关联查询，CRT_HOUSESALESTATUS_CHECK表四百五十万的数据量，crt_houseinfo_check表有七百万的数据量。解决方法，通过创建临时表，先将两张表要关联的数据查询出来放到临时表中，用临时表的数据做关联查询，这样1.5S就出结果了。加上where条件后的数据分别为1100和2100。关联查询时，数据一直查询不出来。

如下图所示，在每天早上MySQL（5.7版本）服务都会自动停止，然后要手动重启才能正常运行。 于是查看了Windows系统的日志，发现在每天的凌晨三点多MySQL服务就会报错，然后自动停止。报错信息如下图所示： 网上查资料，说是缓冲区太小，需要更改缓冲区大小的配置参数，于是找到my.ini文件。 找到innodb_buffer_pool_size参数，原来的值为8M，将其改为1024M 修改后： 保存，然后重启MySQL服务。第二天查看服务运行情况，发现运行正常，不再宕机了，问题解决。参考文章：MySql

1.连接到mysql服务mysql -u root -p 2.找到需要操作的数据库show databases; 3.查询当前数据库中的jobshow events; 4.检查job是否启动show global variables like '%event_scheduler%';OFF代表没有启动，新建job后默认是OFF5.开启jobset global event_scheduler = on; 6.再次查询job状态，已经变成ON 7.设置mysql重启后，job能自动启动编辑/etc/my.cn

在MySQL的安装目录下的bin目录，打开控制台，登录root用户。 查询log开关，off代表关闭，on代表开启。可以看到目前是关闭状态。进入下面目录，找到my.ini配置文件C:\ProgramData\MySQL\MySQL Server 5.7 添加红色部分内容 重启MySQL服务再次查询日志开关开关已经打开 进入到上图中 log所在文件目录下可以看到多出了两个新的文件 删除一条记录，然后查询日志信息。参考下面文章：Mysql-Windows下开启binlog及查看 ---------------