Mysql

作者：付祥 现居珠海，次要负责 Oracle、MySQL、mongoDB 和 Redis 保护工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 1.故障景象一套运行快两年的MGR三节点多主环境（5.7.25），在节点1胜利导入一批数据后，开发反馈程序修改这批数据报错，报错信息如下： update match_equip set name = ?, type = ?, equips = ?,score = ? where id = ? andperson_id = ?Received #3101 error from MySQL server: "Plugin instructed the server to rollbackthe current transaction."1.1.尝试故障复原操作1通过初步剖析，发现导入的这批数据，在导入节点1能够更新，在其余节点更新失败，狐疑1节点有问题，本着疾速复原故障准则，询问开发得悉1节点能够重启，于是对其进行重启，重启后不能退出组复制，看来重启大法也不好使，报错信息如下： 2021-05-27T07:37:53.290267Z 0 [ERROR] Plugin group_replication reported: 'Thismember has more executed transactions than those present in the group. Localtransactions: 91f9d301-c234-11e9-b15f-fa163e13423a:1-156817757:156843131-157503127:158192163-158412212,a71d98a2-c234-11e9-b6db-fa163e3407f8:1-92,eba21052-c250-11e9-b0d0-fa163e134234:1-3 > Group transactions: 91f9d301-c234-11e9-b15f-fa163e13423a:1-156817825:156843131-157503172:158192163-158412212,eba21052-c250-11e9-b0d0-fa163e134234:1-3'2021-05-27T07:37:53.290348Z 0 [ERROR] Plugin group_replication reported: 'Themember contains transactions not present in the group. The member will now exitthe group.'Local transactions： ...

前言如果你应用过mysql数据库，对它的存储引擎：innodb，肯定不会感到生疏。 家喻户晓，在mysql8以前，默认的存储引擎是：myslam。但mysql8之后，默认的存储引擎曾经变成了：innodb，它是咱们建表的首选存储引擎。 那么，问题来了： innodb的底层是如何存储数据的？表中有哪些暗藏列？用户记录之间是如何关联起来的？如果你想晓得下面三个问题的答案，那么，请持续往下面看。 本文次要蕴含如下内容： 1.磁盘or内存？1.1 磁盘数据对系统来说是十分重要的货色，比方：用户的身份证、手机号、银行号、会员过期工夫、积分等等。一旦失落，会对用户造成很大的影响。 那么问题来了，如何能力保障这些重要的数据不丢呢？ 答案：把数据存在磁盘上。 当然有人会说，如果磁盘坏了怎么办？ 那就须要备份，或者做主从了。。。 好了，打住，这不是明天的重点。 言归正传。 大家都晓得，从磁盘上读写数据，至多须要两次IO申请能力实现。一次是读IO，另一次是写IO。 而IO申请是比拟耗时的操作，如果频繁的进行IO申请势必会影响数据库的性能。 那么，如何能力解决数据库的性能问题呢？ 1.2 内存把数据存在寄存器？ 没错，操作系统从寄存器中读取数据是最快的，因为它离CPU最近。 然而寄存器有个十分致命的问题是：它只能存储十分大量的数据，设计它的目标次要是用来暂存指令和地址，并非存储大量用户数据的。 这样看来，只能把数据存在内存中了。 因为内存同样能满足咱们，疾速读取和写入数据的需要，而且性能是十分可观的，只是比拟寄存器稍稍慢了一丢丢而已。 不过有个让人厌恶的中央是，内存绝对于磁盘来说，是更加低廉的资源。通常状况下，500G或者1T的磁盘，是很常见的。但你有据说过有500G的内存吗？他人会认为你疯了。内存大小探讨的数量级个别是16G或32G。 内存能够存储一些用户数据，但无奈存储所有的用户数据，因为如果数据量太大了，它可能还是存不下。 此外，即便用户数据能刚好存在内存，当前万一有一天，数据库服务器或者部署节点挂了，或者重启了，数据不就丢了？ 怎么做，能力不会因为异常情况，而丢数据。同时，又能保证数据的读写速度呢？ 2.数据页咱们能够把一批数据放在一起。 写操作时，先将数据写到内存的某个批次中，而后再将该批次的数据一次性刷到磁盘上。如下图所示： 读操作时，从磁盘上一次读一批数据，而后加载到内存当中，当前就在内存中操作。如下图所示： 将内存中的数据刷到磁盘，或者将磁盘中的数据加载到内存，都是以批次为单位，这个批次就是咱们常说的：数据页。 当然innodb中存在多种不同类型的页，数据页只是其中一种，咱们在这里重点介绍一下数据页。 那么问题来了，什么是数据页？ 数据页次要是用来存储表中记录的，它在磁盘中是用双向链表相连的，不便查找，可能十分疾速得从一个数据页，定位到另一个数据页。 很多时候，因为咱们表中的数据比拟多，在磁盘中可能寄存在多个数据页当中。 有一天，咱们要依据某个条件查问数据时，须要从一个数据页找到另一个数据页，这时候的双向链表就派上大用场了。磁盘中各数据页的整体构造如下图所示：通常状况下，单个数据页默认的大小是16kb。当然，咱们也能够通过参数：innodb_page_size，来从新设置大小。不过，个别状况下，用它的默认值就够了。 好吧，数据页的整体构造曾经搞明确了。 那么，单个数据页蕴含哪些内容呢？ 从上图中能够看出，数据页次要蕴含如下几个局部： 文件头部页头部最大和最小记录用户记录闲暇空间页目录文件尾部3.用户记录对于新申请的数据页，用户记录是空的。当插入数据时，innodb会将一部分闲暇空间调配给用户记录。 用户记录是innodb的重中之重，咱们平时保留到数据库中的数据，就存储在它外面。那么，它外面又蕴含哪些内容呢？你不好奇吗？ 其实在innodb反对的数据行格局有四种： compact行格局redundant行格局dynamic行格局compressed行格局咱们以compact行格局为例：一条用户记录次要蕴含三局部内容： 记录额定信息，它蕴含了变长字段、null值列表和记录头信息。暗藏列，它蕴含了行id、事务id和回滚点。真正的数据列，蕴含真正的用户数据，能够有很多列。上面让咱们一起理解一下这些内容。 3.1 额定信息额定信息并非真正的用户数据，它是为了辅助存数据用的。 3.1.1 变长字段列表有些数据如果间接存会有问题，比方：如果某个字段是varchar或text类型，它的长度不固定，能够依据存入数据的长度不同，而随之变动。 如果不在一个中央记录数据真正的长度，innodb很可能不晓得要调配多少空间。如果都按某个固定长度调配空间，但理论数据又没占多少空间，岂不是会节约？ 所以，须要在变长字段中记录某个变长字段占用的字节数，不便按需分配空间。 3.1.2 null值列表数据库中有些字段的值容许为null，如果把每个字段的null值，都保留到用户记录中，显然有些节约存储空间。 有没有方法只简略的标记一下，不存储理论的null值呢？ 答案：将为null的字段保留到null值列表。 在列表中用二进制的值1，示意该字段容许为null，用0示意不容许为null。它只占用了1位，就能示意某个字符是否为null，的确能够节俭很多存储空间。 3.1.3 记录头信息记录头信息用于形容一些非凡的属性。 它次要蕴含： deleted_flag： 即删除标记，用于标记该记录是否被删除了。min_rec_flag： 即最小目录标记，它是非叶子节点中的最小目录标记。n_owned：即领有的记录数，记录该组索引记录的条数。heap_no：即堆上的地位，它示意以后记录在堆上的地位。record_type：即记录类型，其中：0示意一般记录，1示意非叶子节点，2示意Infrimum记录， 3示意Supremum记录。next_record：即下一条记录的地位。3.2 暗藏列数据库在保留一条用户记录时，会主动创立一些暗藏列。如下图所示：目前innodb主动创立的暗藏列有三种： db_row_id，即行id，它是一条记录的惟一标识。db_trx_id，即事务id，它是事务的惟一标识。db_roll_ptr，即回滚点，它用于事务回滚。如果表中有主键，则用主键做行id，无需额定创立。如果表中没有主键，如果有不为null的unique惟一键，则用它做为行id，同样无需额定创立。 如果表中既没有主键，又没有惟一键，则数据库会主动创立行id。 也就是说在innodb中，暗藏列中事务id和回滚点是肯定会被创立的，但行id要依据理论状况决定。 3.3 真正数据列真正的数据列中存储了用户的实在数据，它能够蕴含很多列的数据。这个比较简单，没有什么好多说的。 3.4 用户记录是如何相连的？通过下面介绍的内容，大家对一条用户记录是如何存储的，应该有了肯定的意识。 ...

前言应用 mysql 很多年了，但也没怎么深入研究过，筹备最近理解下 mysql 的相干知识点。看看这款程序界里的神器是怎么运行的。 mysql 的架构模式mysql 采纳的是 C/S 架构，也就是咱们平时所说的客户端-服务器模型。像咱们平时所用的 workbench、nacivat 就是客户端，当然，还有命令行工具。 它们会依据指定的 ip、prot 连到服务器，通过肯定的协定来进行 SQL 的执行。这些协定包含最宽泛应用的 TCP 协定，也包含了实用于本地通信的套接字、共享内存、命名管道等。 mysql 的每一次连贯在服务端都有一个专门的线程来治理，并且采纳的网络 IO 模型是 select/poll，并非 epoll。 次要是因为 select/poll 可移植性好，很多零碎都反对。而且 mysql 的瓶颈不在于网络连接上，对于连接数少，并且连贯都很沉闷的 mysql 而言，select/poll 是更好的抉择。 (注：select、poll、epoll 是 IO 多路复用模型，能同时监听多个 I/O 事件的状态，占用资源少，性能高。) mysql 的 2 个阶段当服务器接管到客户端的申请连贯后，将会进入连贯阶段和命令阶段。 连贯阶段次要执行了以下工作： 确定客户端和服务器以后的版本性能；确定是否须要进行 SSL 通信；服务端进行客户端的身份认证；当下面的连贯阶段 ok 后，将会进入命令阶段，咱们平时所见的 SQL 操作就是在这个阶段执行的，如 COM_QUERY：用于向服务器发送一个立刻执行的 SQL 查问COM_CREATE_DB：用于创立数据库的命令 mysql 的 3 层架构下面的 2 个阶段是从 mysql 的连贯生命周期来划分的，理论从逻辑架构上，mysql 能够划分为 3 层： 连贯层：次要负责连接池、通信协议、认证受权等；SQL 层：这一层是 mysql 的大脑，通过一系列组件失去数据操作的最优解。存储层：负责数据的存储、检索。SQL 层后面曾经大体介绍过连贯层了， 咱们来看看 SQL 层，当接管到命令后，mysql 并不会傻乎乎的间接去拿数据，而是会剖析以后 sql 语句的各种执行效率，进而取得一个最优的执行打算。 ...

间隙锁的呈现是为了解决幻读,间隙锁只有再可反复读下能力应用 加锁准则加锁根本单位为next-key lock(左开右闭);查找过程中拜访的对象才会加锁(二级索引的间隙锁有可能会传递到主键上)惟一索引等值查问,next-key lock进化为行锁一般索引等值查问,向右遍历时最初一个不满足等值条件的时候,next-key lock进化为间隙锁(左开右开);惟一索引范畴查问会拜访到不满足条件的第一个值为止.

锁概念InnoDB存储引擎蕴含了三种行锁的算法，别离如下所示： Record Lock：行锁，针对的是单行记录；Gap Lock：间隙锁，锁定的是一个范畴，然而不蕴含记录自身；Next-Key Lock：其实就是行锁+间隙锁，蕴含了记录自身和范畴；为什么须要间隙锁数据库个别都有四种隔离级别，其中最罕用的就是：已提交读(Read committed)和可反复读(Repeatable read)；在已提交读隔离级别下会呈现不可反复读的景象，而在可反复读隔离级别下会呈现幻读(Phantom Read)的景象； 幻读：同一事务下，间断执行两次同样的SQL可能会导致不同的后果；Innodb引擎在可反复读隔离级别下并不会呈现幻读的景象，这次要是因为Innodb提供了多版本并发管制MVCC和间隙锁；常见的快照读其实就是应用的MVCC，而以后读就应用了间隙锁； 以下实例有两点阐明： Innodb的可反复读隔离级别下，对以后读应用了间隙锁来解决幻读的问题，所以上面的实例都是基于默认隔离级别RR；Innodb的锁机制都依赖索引，所以上面的实例围绕索引来开展；实战无索引的状况首先创立一个无索引的表，并初始化数据： mysql> create table t1(a int);mysql> insert into t1 values(1),(3),(5);启动事务1，执行以后读： mysql> begin;mysql> select * from t1 where a=3 for update;以上事务没有提交，再启动事务2，以下语句都被阻塞： mysql> select * from t1 where a=3 for update;mysql> insert into t1 values(1);mysql> insert into t1 values(2);mysql> insert into t1 values(5);mysql> insert into t1 values(7);然而这时候去执行快照读还是能够的： mysql> select * from t1 where a=3;能够发现在没有索引的状况下，除了快照读什么都干不了，感觉像是表被锁住了，表锁分为读和写锁，在写锁的状况下快照读同样被锁住，而在读锁的状况下能够应用快照读，相似下面无索引的状况； mysql> lock table t1 read; ## 读锁mysql> lock table t1 write; ## 写锁mysql> unlock tables; ## 解锁那是不是无索引的状况下就应用了表锁那，能够通过如下命令进行查看，首先看一下在表锁的状况下执行插入操作： ...

作者：周启超 爱可生北分团队 DBA，次要负责项目前期建设及前期疑难问题反对。做事认真，对事负责。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 先介绍下背景，利用连贯数据数执行工作,报 error 1135: Can't create a new thread (errno 11) 谬误日志信息如下： 2021-08-11T12:25:40.606774+08:00 0 [ERROR] [MY-000000] [connection_h] Error log throttle: 36 'Can't create thread to handle new connection' error(s) suppressed2021-08-11T12:25:40.606886+08:00 0 [ERROR] [MY-010249] [Server] Can't create thread to handle new connection(errno= 11)环境版本为 SLES12SP5 ，MySQL 版本为8.0.18。 看到“Can't create thread to handle new connection”的形容咱们首先会想到操作系统对应用户的 ulimit 是否正确。和用户确认了下 ulimit 确实是失常配置的。如果侥幸的话，咱们能够在网上查到一些 TaskMax 设置导致 MySQL 连贯异样的文章。 这次这个环境问题确实和 TaskMax 无关，察看如下截图能够看到 Tasks 达到了 limit 限度。 ...

前言： 当咱们装置好 MySQL 数据库后，会发现数据库实例自带有 information_schema 零碎库，你是否有去关注过这个零碎库呢？是否有查问过此库中的表数据呢？又是否分明此库存在的具体作用呢？带着这些疑难，咱们一起来看本篇文章。 1. information_schema 简介information_schema 顾名思义就是一个信息库，是用来存储数据库的元数据（比方数据库，表的名称，列的数据类型或者拜访权限等），在每个 MySQL 实例中，information_schema 保留了它保护的所有数据库的信息，这个库中蕴含了很多只读的表（它们实际上可看作为视图，因而并没有与之关联的文件，你也无奈为它们创立触发器）。 咱们来具体看下 information_schema 下的表，不同版本的数据库稍有区别，以 5.7.23 版本为例，关上 information_schema 库，咱们发现共有 61 个表。 能够很显著看出，information_schema 下的表大部分是 MEMORY 存储引擎，有个别是 InnoDB 存储引擎，再认真看这些表的创立语句，发现这些表都是长期表。上面展现局部表的作用： CHARACTER_SETS：可用的字符集信息表。COLLATIONS：字符集排序规定信息表。COLUMNS：每个表中的列的信息。ENGINES：存储引擎的信息，能够用于查看引擎是否反对。FILES：表空间数据存储文件的信息。GLOBAL_STATUS：全局状态变量值。GLOBAL_VARIABLES：全局零碎变量值。INNODB_BUFFER_PAGE：InnoDB 缓冲池中页的信息。INNODB_BUFFER_POOL_STATS：InnoDB 缓冲池统计信息。INNODB_LOCK_WAITS：InnoDB 事务锁期待信息INNODB_LOCKS：蕴含了事务申请然而未取得的锁或者阻塞其它事务的锁的信息。INNODB_TRX：所有以后正在执行的事务的信息。PARTITIONS：记录表分区信息。PLUGINS：服务器装置的插件信息。PROCESSLIST：记录正在运行的线程的各种信息。ROUTINES：存储过程及函数信息。SCHEMATA：数据库的信息。STATISTICS：表索引信息。TABLES：表的信息。TRIGGERS：触发器信息。VIEWS：数据库视图信息。2. information_schema 相干查问其实，在应用数据库的过程中，你常常与 information_schema 打交道，当咱们想查问 MySQL 中各种对象的信息时，基本上都是从 information_schema 库中查问失去的。一些常见的 show 语句背地的逻辑也是查问 information_schema 库，例如：show tables 其实查的就是 information_schema.TABLES 表；show databases、show processlist 等语句查问的都是 information_schema 库中的相干表。 咱们想理解数据库中的各种信息时，都能够查问 information_schema 库，上面分享几条笔者积攒的相干查问语句，来看下吧。 # 查看某个库中的表信息SELECT table_name, table_type, ENGINE FROM information_schema.TABLES WHERE table_schema = 'db5' ORDER BY table_name# 查看整个实例占用空间SELECT concat( round( sum( data_length / 1024 / 1024 ), 2 ), 'MB' ) AS data_length_MB, concat( round( sum( index_length / 1024 / 1024 ), 2 ), 'MB' ) AS index_length_MB FROM information_schema.TABLES;# 查看各个库占用空间SELECT TABLE_SCHEMA, concat( TRUNCATE ( sum( data_length )/ 1024 / 1024, 2 ), ' MB' ) AS data_size, concat( TRUNCATE ( sum( index_length )/ 1024 / 1024, 2 ), 'MB' ) AS index_size FROM information_schema.TABLES GROUP BY TABLE_SCHEMA ORDER BY data_length DESC; # 查看某个表占用空间SELECT concat( round( sum( data_length / 1024 / 1024 ), 2 ), 'MB' ) AS data_length_MB, concat( round( sum( index_length / 1024 / 1024 ), 2 ), 'MB' ) AS index_length_MB FROM information_schema.TABLES WHERE table_schema = 'test' AND table_name = 'test_tb' # 查看所有线程信息SELECT * FROM information_schema.PROCESSLIST # 查看非睡眠线程信息SELECT * FROM information_schema.PROCESSLIST WHERE command != 'sleep' # 查看某个用户发动的线程信息SELECT * FROM information_schema.PROCESSLIST WHERE USER = 'testuser' # 查看某个字符集反对的所有排序规定SELECT COLLATION_NAME, CHARACTER_SET_NAME, IS_DEFAULTFROM `information_schema`.`COLLATIONS` WHERE `CHARACTER_SET_NAME` = 'utf8' # 查看某个表的分区信息（如果有）SELECT TABLE_SCHEMA, TABLE_NAME, PARTITION_NAME FROM `information_schema`.`PARTITIONS` WHERE `TABLE_SCHEMA` = 'test' AND `TABLE_NAME` = 'tbname' # 查看某个表的索引信息SELECT * FROM `information_schema`.`STATISTICS` WHERE `TABLE_SCHEMA` = 'test' AND `TABLE_NAME` = 'tbname' # 查看 innodb 事务相干信息SELECT * FROM information_schema.INNODB_TRX总结： ...

背景在开发面向外部应用的「内容治理平台」的过程中，咱们不时会收到一些页面问题的反馈，但在本地调试的过程中，有大量无奈在本地重现的问题，这些问题的呈现跟用户的拜访设施、网络环境、拜访门路可能存在关联。为了方便快捷地去定位这些问题，咱们试图为所有页面点击操作都加上打点记录，但在实际操作中，因为业务变更频繁，开发框架的限度，展现打点数据较为简单等因素，通过打点排查问题的实际效果并不现实，因而咱们心愿引入残缺的流量统计和用户行为剖析来定位问题。 不同的计划剖析比照对于流量统计和用户行为剖析记录的工具，行业内曾经有大量成熟的解决方案，绝对于自行打点，这些专门的流量通过平台和工具对于业务的根本没有侵入性，也解决了如何展现数据的问题。这些平台和工具中，有驰名的 Google Analytics、百度统计、WebTrends 等，也有绝对冷门的明天的配角 —— Matomo，而这些计划之间各有优劣： 解决方案/平台劣势劣势Google Analytics部署简略，只需在页面退出 JS 追踪器代码，数据分析快（小时级别），功能强大，剖析维度丰盛数据量大的时候偶然会失落数据，无奈定制化Adobe Analytics数据展现清晰明了，功能强大部署简单，只有付费版本，技术支持和文档都较少WebTrends数据分析维度丰盛，报告全面，监控过程平安次要针对大客户，费用十分高CNZZ部署和接入简略，剖析性能易用，报告简洁没有用户细分数据，也不反对用户路径分析，性能较为繁多Matomo对标 Google Analytics 的性能，接入简略，功能强大，剖析维度丰盛，反对私有化部署，包含代码和数据都能够私有化解决，有弱小的插件机制，能够自行开发性能私有化须要自行部署和保护服务器、数据库等，局部剖析性能须要二次开发通过比照，Matomo 整体性能比拟弱小，对标了 Google Analytics 但在安全性和私密性方面更优，反对私有化部署，代码和数据都能够不走漏给第三方，并且能够通过插件的机制配合业务实现自定义，这些长处都是咱们最终抉择 Matomo 作为「内容治理平台」用户记录的工具的起因。 Matomo 是什么？这里介绍一下 Matomo，作为一套基于 PHP 与 MySQL 的网页流量统计和剖析平台，它的大部分性能曾经开源，并且做了很好的封装，能够轻松地进行私有化部署，它的性能次要分成两块： 收集并存储页面拜访数据，次要是用户信息，如设施型号、分辨率、用户地区、起源，以及页面信息，如页面拜访门路、拜访操作等。对收集起来的数据进行指标量化并可视化的展现，例如用户设施型号散布、地区散布、某个页面的浏览人数、拜访最多的页面、某个用户在某个页面的拜访门路和具体操作等，并且在收集数据时，Matomo 会有大量的策略爱护用户隐衷，例如上报 IP 时暗藏最初一位字节等。在理论应用时，用户信息的上报以及页面的拜访门路，只须要装置并引入 Matomo 即可实现，无需额定的配置。然而开发者能够通过接口加强上报的数据，例如上报某个弹窗的展现，或者上报某个申请的后果，这样最终能够在平台上展现出残缺的用户拜访门路和操作，联合业务日志，能够很精确地定位问题以及还原问题的触发门路。 Matomo 落地到业务在引入 Matomo 之前，先阐明一下 Matomo 的次要组成追踪器和 Matomo 服务端，追踪器基于 JS 实现，须要在网页引入，用于上报数据。服务端次要提供了三个性能： HTTP 接口，追踪器能够收集所在网页的数据但不上报，通过 HTTP 接口发送给 Matomo。归档工作运行并预处理数据，默认分为实时动静解决（页面拜访数据，用户拜访轨迹）和 cron 工作解决（用户维度的列表）。可视化展示数据，也能够数据接口或者报表接口来拜访这些数据。引入简略落地不易Matomo 有很成熟封装，因而自身部署很简略，次要分为两个步骤： 部署私有化 Matomo 服务。在须要流量统计ide页面上引入追踪器。其中部署私有化服务只须要下载 Matomo 的程序并上传到服务端，而后关上拜访地址就能够应用疏导程序部署服务，包含检测服务器环境是否符合要求，填写数据库信息，创立治理账号等，具体参考官网文档。 但在理论落地到内容平台的过程中，却遇到了问题——咱们须要基于 Docker 进行部署。 因为业务的部署都基于 Docker 和 k8s 进行，因而私有化的 Matomo 也须要基于此进行部署，这样会带来几个问题： Matomo 的设置分成系统配置与性能设置，其中性能设置贮存在 MySQL 中，而零碎设置则贮存在本地的配置文件中，当部署多个容器时，配置无奈对齐，另外 Docker 重新部署后，这些配置批改也会失落。这套部署须要域名 + 门路的模式拜访 Matomo，Matomo 社区镜像中是应用 Apache2 进行路由解决的，而 Apache2 默认的配置并不适配门路，须要批改 Apache 的配置文件。解决在 Docker 中部署 Matomo 的问题Matomo 有官网公布的社区镜像能够间接应用，但为了解决上述的问题，须要在构建 Docker 镜像时进行额定的解决。 ...

后面我写了很多Mysql相干的知识点，到这一篇略微能够串一下了，从SQL执行流程、MVCC到锁，很多时候可能感觉对于间隙锁和Next-Key Lock如同曾经了解了，然而如同又感觉了解差那么一点意思，这篇文章从头来梳理一下概念，明确一下这些常识。 锁首先，对于Mysql来说实现了两种行级锁： 共享锁：容许事务读一行数据，个别记为S，也称为读锁 排他锁：容许事务删除或者更新一行数据，个别记为X，也称为写锁 对于读写锁的互斥性，应该都很分明，读锁只能和读锁兼容，其余场景都无奈兼容，这里不再赘述吧。 隔离级别持续回顾下对于Mysql的4个隔离级别： 读未提交Read Uncommitted：能读到其余事务还没有提交的数据，这种景象叫做脏读。 读已提交Read Committed：只会读取其余事务曾经提交的数据，所以不会产生RC的脏读问题。所以又带来一个问题叫做不可反复读，一个事务中两次一样的SQL查问可能查到的后果不一样。 可反复读Repeatable Read：RR是Mysql的默认隔离级别，一个事务中两次SQL查问总是会查到一样的后果，不存在不可反复读的问题，然而还是会有幻读的问题。 串行Serializable：串行场景没有任何问题，齐全串行化的操作，读加读锁，写加写锁。 幻读、Next-Key Lock、MVCC简略的回顾完了根底，那么咱们看看RR级别下还会存在的幻读到底是什么问题，Mysql官网文档这样形容的： The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times. For example, if a SELECT is executed twice, but returns a row the second time that was not returned the first time, the row is a “phantom” row.翻译过去就是，幻读指的是同一事务下，不同的工夫点，同样的查问，失去不同的行记录的汇合。 如果说一个select执行了两次，然而第二次比第一次多进去行记录，这就是幻读。 所以，对于幻读来说那肯定是新增插入的数据！ 比如说在一个事务内，先查问select * from user where age=10 for update，失去的后果是id为[1,2,3]的记录，再次执行查问，失去了后果为[1,2,3,4]的记录，这是幻读。 ...

上一篇文章总结了 DDL、DML的应用，这一篇文章把剩下的 DQL 加上~ DQL（Data Query Language）即数据库查询语言，用来查问所须要的信息，在查问的过程中，须要判断所查问的数据与表之间的关系，可能须要的数据在一张表中能够查问到，可能须要联结多张表能力查问到，在这种状况下，查问的语句也不一样。 要进行查问之前，首先须要有表数据，以下sql语句创立一张products表，存储着不同品牌及型号的手机 CREATE TABLE IF NOT EXISTS `products` (    id INT PRIMARY KEY AUTO_INCREMENT,    brand VARCHAR(20),    title VARCHAR(100) NOT NULL,    price DOUBLE NOT NULL,    score DECIMAL(2,1),    voteCnt INT,    url VARCHAR(100),    pid INT)// 省略 insert into 插入数据局部首先来查看一下表中的所有数据 SELECT * FROM `products`;// * 代表展现所有的字段，如果只展现局部字段能够指定，可通过as对字段取别名，as可省略SELECT id, brand as phoneBrand, title phoneTitle, price, score FROM `products`; 有时候咱们并不需要查问出所有的数据，比方只须要查看所有品牌为华为的手机，这个时候就能够通过 where 来进行解决了 SELECT id, brand as phoneBrand, title phoneTitle, price, score From `products` WHERE brand = '华为';// where后能够跟多个条件，用 AND() 或者 OR 来进行连贯SELECT * From `products` WHERE brand = '华为' && price > 4000; // 查问价格大于4000的华为手机SELECT * From `products` WHERE score BETWEEN 5 AND 6; // 查问手机评分在5-6分之间的手机，蕴含5和6分SELECT * FROM `products` WHERE brand LIKE '%v%'; // 匹配品牌名称蕴含字母为V的数据SELECT * FROM `products` WHERE brand LIKE '_v%'; // 匹配品牌名称蕴含第二个字母为V的数据 ...

MySQL bug整顿整顿了一些遇到过的报错信息 近程连贯服务器数据库报错： Host ‘XXXXXX’ is blocked because of many connection errors. Sol: show global variables like ‘%max_connect_errors%';set global max_connect_errors=1000000;然而这不是问题的基本解决办法，只能一时无效，永恒无效可参考以下文章：https://blog.csdn.net/li_li_l... 跟权限相干的报错 ERROR 1290 (HY000): The MySQL server is running with the —skip-grant-tables option so it cannot execute this statement. Sol: 刷新权限列表 flush privileges;赋予权限：grant all privileges on . to USER@'%'identified by 'password'; SQL语句过长导致执行失败Sol: 更改最大限度 set global max_allowed_packet = 6*1024*1024;

出发点因为桥梁我的项目须要用到MySQL数据库，想着本人实验室服务器的MySQL曾经装好了，就装置Navicat筹备近程连贯，通过shell进行连贯发现运行失常 mysql -u root -p然而应用Navicat连贯时呈现谬误，回绝连贯，于是想到可能MySQL不容许近程登录 开启近程IP登录许可sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf将bind-address = 127.0.0.1后面加上# lc-messages-dir = /usr/share/mysqlskip-external-locking## Instead of skip-networking the default is now to listen only on# localhost which is more compatible and is not less secure.# bind-address = 127.0.0.1之后重启MySQL即可 /etc/init.d/mysql restart增加用户开启近程登录之后发现呈现了新的谬误：... is not allowed to connect to this MySql server于是通过shell登录MySQL，顺次执行以下命令 use mysql;update user set host=’%’ where user=’root’;遂近程连贯胜利

MySQL 全局配置 --secure-file-priv一则问题在执行导出 INFORMATION_SCHEMA.OPTIMIZER_TRACE 内容到本地文件时： SELECT TRACE INTO DUMPFILE "optimizer_trace.txt" FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE;报错提醒如下： (1290, 'The MySQL server is running with the --secure-file-priv option so it cannot execute this statement')起因剖析查看零碎变量 secure_file_priv： SHOW VARIABLES LIKE "secure_file_priv";+------------------+-------+| Variable_name | Value |+------------------+-------+| secure_file_priv | NULL |+------------------+-------+MySQL 对于导入导出的目录是有限度的，只容许指定的目录能力导入导出。 此处变量值为 NULL，即没设置容许操作的目录，所以没法导出到文件。 常识解读名词含意Command-Line Format--secure-file-priv=dir_nameSystem Variablesecure_file_privScopeGlobalDynamicNoTypeStringDefault Valueplatform specificValid Valuesempty string、dirname、NULLsecure_file_priv 这个变量被用于限度导入和导出的数据目录，比方 LOAD DATA 和 SELECT ... INTO OUTFILE 语句，以及 LOAD_FILE() 函数。这些操作限度了哪些用户领有文件操作权限。 secure_file_priv 有些设置选项: 如果为空，不做目录限度，即任何目录均能够。如果指定了目录，MySQL 会限度只能从该目录导入、或导出到该目录。目录必须已存在，MySQL 不会主动创立该目录。如果设置为 NULL，MySQL 服务器禁止导入与导出性能。该变量的默认值，是由编译时的 CMake 选项而定，具体可参考官网文档。 ...

引言：上一篇我介绍了 MySQL 范式标准化表设计，范式设计具备以下长处： 把如何打消数据冗余做到极致，从而缩小关系表对磁盘的额定占用。各个表之间的关系体现十分清晰，可读性十分强。注释：然而范式设计同样也有毛病：表范式标准化，等级越高，表数量就越多。比方 2NF 比 1NF 可能要多几张表，3NF 比 2NF 可能又要多几张表等等。表数量越多，查问时可能须要关联的表就越多。 咱们晓得，检索多表关联的开销比检索单表的开销要大的多。综上，咱们须要联合范式设计的长处，并且想方法去解决范式设计的毛病， 由此带来的思路就是容许数据有肯定水平的冗余，用空间换工夫。比方当初微服务设计、NOSQL 数据库等基本不会思考范式规范实践。 这样的思路也就是明天要讲的重点，简称反范式。 反范式也即通过肯定的冗余把原先高级别的范式设计升高为低级别的范式设计来缩小范式设计带来的表数量增多的毛病。比方满足 BCNF 的表，通过冗余肯定字段，升高为 3NF ，甚至升高到 2NF ，始终到 1NF 。有的场景为了查问性能甚至不须要满足 1NF 。比方表t1, 原本字段有100个，其中5个罕用，剩下95个都不罕用，那能够把这95个字段集成到一个大对象字段即可，比方 JSON 类型的字段。 接下来咱们用简略的示例看看反范式如何精简查问语句并且晋升效率。以下5张关系表别离代表员工表，部门表，薪水表，以及员工与部门关系表，员工与薪水关系表。 员工表： (debian-ytt1:3500)|(ytt)>desc employee;+-----------------+------------------+------+-----+---------+-------+| Field | Type | Null | Key | Default | Extra |+-----------------+------------------+------+-----+---------+-------+| employee_number | varchar(64) | NO | PRI | NULL | || employee_name | varchar(64) | YES | | NULL | || gender | char(1) | YES | | NULL | || age | tinyint unsigned | YES | | NULL | || register_date | date | YES | | NULL | |+-----------------+------------------+------+-----+---------+-------+5 rows in set (0.00 sec)部门表： ...

前言咱们平时在向MySQL数据库表中插入数据时，理论数据是以行记录的格局存储在磁盘上的，本篇咱们就一起来具体的理解下MySQL的行记录格局，了解了行记录的格局有助于咱们前面理解MySQL如何疾速在页中定位出行记录，以及MySQL的版本控制链，事务隔离级别等等，行记录格局是许多MySQL外围常识的根底。 InnoDB行记录类型MySQL中总共提供了四种类型的行格局：Compact,Redundant,Dynamic,Compressed。 在创立表或批改表的时候能够指定行记录的格局create table 表名 row_format=行格局名alter table 表名 row_format=行格局名 晓得就行，不须要去记住，基本上应用不到Compact行格局在四种类型的行格局中，咱们次要来学习Compact格局，其余格局的行记录相似； 从图中咱们能够看出行记录次要是由4局部组成：变长字段长度、Null值列表，行记录头信息以及列的实在数据 变长字段长度列表在MySQL中很一些变长的数据类型（varchar，text等），MySQL须要晓得这些数据的理论长度，这样能力正确的在实在数据中取出对应列的数据，所以变长字段是由两局部组成： 实在数据的长度实在数据的字节每个变长字段的长度要么用1字节要么用2字节示意，由此就决定了每个字段的最大字节数是65535； 如果字符类型若为gbk，每个字符最多占2个字节，最大长度不能超过32766;如果字符类型若为utf8，每个字符最多占3个字节，最大长度不能超过21845。那到底什么时候选用1字节什么时候选用2字节呢？ 这里须要定义三个变量：w,m,l 如果应用的字符集是utf8mb4，每个字符占用的字节数是4字节，那么w=4；如果字符类型若为utf8，每个字符最多占3个字节，那么w=3; 所以w示意字符集中每个字符所占的字节数varchr(m)，这里m示意的是定义的字符的长度l 示意的是该字段实在数据占用的字节数当 m*w <= 255；示意该字段定义的最大长度都不会超过1字节，那么该字段的长度就用1字节示意 当 m*w > 255 && l<=127; 示意该字段定义的长度可能会超过1个字节，然而以后的理论长度是小于127的，能够用1个字节示意 当 m*w > 255 && l>127; 用2字节来示意该字段的长度 思考：为什么与l比拟的值是127呢？当咱们定义的变长字段可能大于255（也就是超过一个字节）时，MySQL如何能力晓得以后读取的字节该字段的实现字段长度，还是该字段的半个字段长度，为了解决这个问题，MySQL应用了1字节的首位，当首位为0示意以后是1字节，当首位为0示意以后长度是2字节；因为占用了1字节的首位，所以剩下7位所能示意的最大值是127变长字段不会存储为Null列的长度；其次并不是行记录中肯定须要变长字段长度这段内容，如果行记录中没有定义变长字段或者是变长字段都为Null，那么就不会有变长字段长度这部分 变长字段占用的字节数依照程序逆序存储Null值列表一条记录中某些列通常可能容许为null，所以Compact行格局把这些容许为null的进行了对立治理； 首先统计出表中定义的哪些列容许为null如果表中的字段都不能为空，那么就不存在null值列表；如果存在容许为null的字段，那么就依照字段的程序为每个字段对应一个二进制位，当二进制位为1时示意该列值为空；当二进制位位0时示意该列值不为空Null值列表必须有整数个字节来示意，所以对应没有占用的位应用0补位 行记录的头信息头信息中次要蕴含了6个字段，其中5个字段也是在面试中常常被问到的，为了不便记忆，咱们把5个字段对应到手的5根指头： n_owned（拇指）: 一个数据页会被分成很多个组，每组最初的一条记录该字段为1，其余记录该字段为0，就像分组中所有的记录的大哥；（对应拇指）deleted_flag（食指）: 标记该记录是被删除的；当记录被删除时不会实在删除，而是用该字段标记，并且把所有删除的记录应用链表连接起来，当前的文章会持续说到这个字段。（设想下你平时挖鼻屎是不是用的食指）heap_no（中指）: 示意以后记录在数据页中的绝对地位（MySQL应用该字段来示意记录地位，能够和中指对应，不可形容）record_type（无名指）: 示意以后记录属于哪种类型，（无名指用来带戒指的，与分类无关，能够把人分为已婚和未婚，） 0示意一般记录1示意目录项记录，索引中非叶子结点中的数据记录都是12示意infrmum记录，每个数据页中至多会有两条记录，其中最小记录的record_type=23示意Supremum记录，每个数据页中至多会有两条记录，其中最大记录的record_type=3next_record（小拇指）: 寄存下一条记录的绝对地位（当数数时，左手的小拇指数完之后就该换右手了，和next_record表白的意思类型）最初一个字段min_rec_flag : B+树中每层非叶子结点最小目录项记录该字段为1；该字段绝对于其余5个字段显得不那么重要，不会影响了解B+树索引暗藏列除了用户自定义的数据列以外，MySQL还会为每行记录生成3个暗藏列 row_id: 行ID，记录的惟一标识；当用户在表中定义了主键字段就优先选择用户定义的主键，如果没有，就查找是否有定义不为null的惟一索引，如果有就把该列作为主键，如果没有MySQL就会生成一列row_id暗藏列作为主键trx_id: 事务的ID；该字段对于实现一致性视图和事务隔离级别至关重要，当前会具体阐明roll_pointer: 回滚指针，指向的是该记录的上一个版本号，MySQL的MVCC次要就是通过这个字段来实现的。溢出列MySQL中所有的行记录都会被存储在数据页中，每个数据页的大小是16KB，也就是16384个字节；在后面咱们讲过变长字段的长度能够用两个字节来示意，所以列的最大长度能够是65535，当遇到这种极其状况时，一个数据页是存储不下这一条记录的。 Compact行格局针对这种状况的解决形式是在实在的数据处记录该列的一部分数据（768字节），其余多余的数据会存储到新的数据页中（溢出页），而后在该记录中应用20个字节存储这些数据页的地址 溢出页与溢出页之间应用的链表相连接 其余的行记录格局：Redundant：MySQL5.0之前的格局，间接疏忽 Dynamic,Compressed与Compact很像，只是在溢出列的解决有些差别，他们只会在实在数据列中应用20个字节存储溢出页的地址 面试题char(M)定义的字段，在变长字段的长度列表中会记录该字段的长度吗？欢送大家在评论区留言探讨 最初（点关注，不迷路）文中或者会存在或多或少的有余、谬误之处，有倡议或者意见也十分欢送大家在评论交换。 最初，写作不易，请不要白嫖我哟，心愿敌人们能够点赞评论关注三连，因为这些就是我分享的全副能源起源 程序员罕用的IDEA插件：https://github.com/silently9527/Toolkit原文链接：https://silently9527.cn/?p=62

在上一篇《面试官：你说说一条查问SQL的执行过程？》中形容了Mysql的架构分层，通过解析器、优化器和执行引擎实现一条SQL查问的过程，那这一篇续上持续阐明一条更新SQL的执行过程。 对于一个SQL语句的更新来说，后面的流程都能够说相似的，通过解析器进行语法分析，优化器优化，执行引擎去执行，这个都没有什么问题，重点在于多了一点货色，那就是redo_log、undo_log和binlog。 执行流程大抵如下： 首先客户端发送申请到服务端，建设连贯。服务端先看下查问缓存，对于更新某张表的SQL，该表的所有查问缓存都生效。接着来到解析器，进行语法分析，一些零碎关键字校验，校验语法是否合规。而后优化器进行SQL优化，比方怎么抉择索引之类，而后生成执行打算。执行引擎去存储引擎查问须要更新的数据。存储引擎判断以后缓冲池中是否存在须要更新的数据，存在就间接返回，否则去从磁盘加载数据。执行引擎调用存储引擎API去更新数据。存储引擎更新数据，同时写入undo_log、redo_log信息。执行引擎写binlog，提交事务，流程完结。能够看到相比于查问流程，实际上更新多了对于undo_log和redo_log的流程，接下来再具体探讨一下这几个流程的执行过程是什么样子。 redo_logredo_log依照字面翻译称为重做日志，是InnoDB存储引擎特有的，用于保障事务的原子性和持久性。怎么了解呢？简略来说就是保留咱们执行的更新语句的记录，如果服务器或者Mysql宕机，通过redo_log能够复原更新的数据。 依照上述流程来举例的话，比方update user set age=20 where id=1这样的简略更新SQL，咱们不论执行引擎怎么拿到的数据，不论是从缓冲池拿的还是磁盘拿到的，这条当初数据都在缓冲池外面，而后去缓冲池的数据把age改成10。 缓冲池内存中的数据曾经更新好了，那么接下来就该开始写redo_log了，只是redo_log也不是间接写文件的，个别都是这样对吧，间接写的话性能太差了，所以就有redo_log_buffer叫做redo_log缓冲。 在写redo_log的时候先把数据写到redo_log缓冲区，而后异步写入磁盘，很显然，极其状况下会有失落数据的可能。 管制这个刷盘策略的的参数叫做innodb_flush_log_at_trx_commit。 这个参数有3个值：0|1|2，默认的话是1。 0代表提交事务时不会写入磁盘，这样的话性能当然最好，然而在Mysql宕机的状况会失落上一秒的事务的数据。 1代表提交事务肯定会进行一次刷盘，同步当然性能最差，然而也最平安。 2代表写入文件系统的缓存，不进行刷盘。这个选项性能略差于1，Mysql宕机的话对数据没有任何影响，只有在操作系统宕机才会失落数据，这种状况下默认Mysql每秒会执行一次刷盘。 应用0或者2尽管进步了性能，然而变相的也丢失了事务的持久性。 undo_log重做日志保障了事务的持久性，保障可能在宕机后复原事务的数据，那么另外一种状况就是事务在须要回滚的时候怎么办？这时候就是undo_log的作用了，它保障了事务的一致性。 对于undo_log来说，简略了解就是做了逆向操作。 比方insert一条数据，就对应生成delete，update语句则生成相同的更新语句，这样做到将数据批改回之前的状态。 binlogbinlog称为二进制日志，大家都很相熟，记录了扭转数据库的那些SQL语句，对于这里来说，更新语句当然是了。 通过不同于redo_log是独属于存储引擎独有的货色，binlog则是Mysql自身产生的日志。 不同于redo_log是物理日志，binlog和undo_log都属于逻辑日志。 这有什么区别呢？ 简略来说，逻辑日志能够认为就是存储的SQL自身，而物理日志看看redo_log存储的是啥就晓得了，对于page_id页ID，offset偏移量啊这些货色，记录的是对页的批改。 另外物理日志能够保障幂等性，而逻辑日志则不肯定能，除非自身SQL就是幂等的。 下面咱们提到了redo_log的刷盘策略，binlog就和它十分相似了，控制参数是sync_binlog。 默认值为0，相当于是innodb_flush_log_at_trx_commit的值为2，由文件系统管制，同样如果服务器宕机，binlog失落，当然咱们也能够改成1，就和redo_log的成果是一样，每1次事务提交都同步写入磁盘。 事务为了保障写redo_log和binlog的一致性，理论采纳了二阶段提交的形式。 prepare阶段：依据innodb_flush_log_at_trx_commit设置的刷盘策略决定是否写入磁盘，标记为prepare状态。 commit阶段：写入binlog日志，事务标记为提交状态。 总结

GROUP_CONCAT实用于拼接多条数据雷同列,须要应用宰割符的字符串查问后果.默认应用逗号作为分隔符语法: 必须配合GROUP BY一起应用 GROUP_CONCAT(字段)GROUP_CONCAT(字段 separator "分隔符")GROUP_CONCAT(DISTINCT 字段 ORDER BY 字段 SEPARATOR "分隔符")示例: SELECT employeeNumber, firstName, lastName, GROUP_CONCAT(DISTINCT customername ORDER BY customerName)FROM employeesINNER JOIN customers ON customers.salesRepEmployeeNumber = employeeNumberGROUP BY employeeNumberORDER BY firstName,lastnameCONCAT_WS实用于拼接一条数据不同列,须要应用分隔符的字符串查问后果,指定应用的分隔符语法: CONCAT_WS("分隔符",str1,str2,...)示例: SELECT CONCAT_WS(';',o.user_code,o.user_name) FROM sys_user o WHERE id = 5201314留神: 如果要拼接的字符串中有null,不会返回为null的后果 CONCAT实用于拼接一条数据不同列,不须要应用分隔符的字符串查问后果语法: CONCAT(str1,str2...)示例: SELECT CONCAT(o.user_code,o.user_name) FROM sys_user o WHERE id = 5201314留神: 如果要拼接的字符串中有一个是null,那么返回的后果就是null

(原文来自Uber Engineering, 原文链接点这，作者为Evan Klitzke) 简介Uber的晚期的架构设计是由Python编写的一体式后端架构，并应用Postgres进行数据长久化。时至今日，Uber的架构已产生了巨大变化，曾经成为了业界微服务和新型数据平台的模板。具体来说，以前大多状况下咱们会优先思考Postgres，但当初咱们放弃了Postgres而抉择应用Schemaless。这是一种基于MySQL的新型的数据库分片技术。在本文中，咱们将探讨在团队在应用Postgres中发现的一些毛病，并解释为何要放弃Postgres转而在MySQL上构建Schemaless和其余相干的后端服务决定。 Postgres的体系结构在咱们刚应用postgres的时候意识到了一些Postgres的问题： 单次操作导致磁盘的屡次写入数据冗余表数据容易净化问题蹩脚的MVCC版本升级艰难咱们通过postgres对磁盘上的表和索引的剖析来进一步意识这些问题，并与MySQL(InnoDB)进行比照。另外，咱们的所有剖析基于Postgres 9.2版本。据我所知，以下将要探讨的内容在较新的Postgres版本(此处我比照了下日期指的应该是指v10.1)中并未产生显著的改变。 磁盘存储形式(on-disk format)关系数据库必须提供一些要害的性能，诸如： 增删改查提供进行数据结构更改的性能提供多版本并发管制（MVCC）最重要的是如何使这些性能协同工作Postgres的外围设计之一便是一种不可变行数据，在Postgres中被称为“元组”(tuple)。这些元组被定义为惟一标识称之为ctid。ctid示意了元组在磁盘上的地位（物理盘偏移）。多个ctid能够潜在地形容单个行（例如，当出于MVCC目标而存在该行的多个版本时，或者当主动真空解决尚未回收该行的旧版本时）。有组织的元组的汇合形成一个表。表本身具备索引，这些索引被结构成一些特定的数据结构(如B-trees)，并将索引字段映射到ctid 无效。通常，用户是在应用中是觉察不到ctid的，然而理解它们的工作原理将有助于理解Postgres的磁盘存储构造。要查看行的以后ctid能够输出如下命令： uber@[local] uber=> SELECT ctid, * FROM my_table LIMIT 1;-[ RECORD 1 ]--------+------------------------------ctid | (0,1)为了进一步解释，让咱们思考以用户表为示例。对于每个用户，咱们都有一个自增的ID作为主键，其余内容包含名字、姓氏以及出世年份。咱们还在用户的全名（名字和姓氏）上定义了一个二级索引，并为出世年份定义了另一个二级索引。创立这样的表的DDL可能是这样的： CREATE TABLE users ( id SERIAL, first TEXT, last TEXT, birth_year INTEGER, PRIMARY KEY (id)); CREATE INDEX ix_users_first_last ON users (first, last); CREATE INDEX ix_users_birth_year ON users（birth_year);留神此表定义的三个索引：主键索引加上咱们定义的两个二级索引。上面咱们插入一些数据，该数据由一些驰名的数学家组成:如前所述，每一条数据都对应着一个隐式具惟一的，不通明的ctid。因而，咱们能够这样思考表的外部示意模式：将id 映射到ctid的主键索引如图所示：B树是在主键字段定义的，并且每个节点都保留了ctid的 值。留神，在这种状况下，因为应用了自增的id ，因而B树中字段的程序恰好与表中的程序雷同。二级索引看起来都差不多。次要区别在于字段的存储程序不同，因为B树必须像字典一样程序组织。每个索引以名字结尾，指向字母表的顶部：同样，birth_year的索按升序排列，如图所示：在这两种状况下，二级索引中的ctid 字段在字典上都没有减少，这与自增的主键是不同的。假如咱们须要更新该表中的一条记录。举个栗子，假如咱们要更新出世年份字段，以估算al-Khwārizmī(代数之父-阿尔·花剌子模)的出世年份公约前770。像我方才所说的，元组是不变的。因而，为了更新记录，咱们向表中插入一个新的元组。这种新的元组有一个新的CTID ，定义为I 。Postgres须要将I处的元组与D处的旧元组辨别开。在Postgres的外部，每个元组都存储一个版本字段和一个指向前一个元组的指针（如果有的话）。因而，表的新构造如图所示：只有存在al-Khwārizmī行的两个版本，索引就必须同时蕴含两个行的条目。为简便起见，咱们省略了主键索引，而在此处仅显示了辅助索引，如图所示：咱们用红色示意旧版本，用绿色示意新版本。Postgres应用另一个保留行版本的字段来确定哪个元组是最新的。依附这样的字段，数据库能够确定哪个元组能够会不被新版的事务所看到。 Postgres通过将主库上的WAL发送到从库来实现流复制。每个从库在解体复原中都是无效的，通过一直地更新WAL，就像解体后启动一样。流复制和理论场景的解体复原之间的惟一区别就是，处于“热备用”(hot standyby)模式的从库在利用WAL时会提供查问，但实际上处于解体复原状态下的Postgres数据库通常会回绝提供任何查问，直到数据库的实例实现解体复原过程。因为WAL实际上是为解体复原目标而设计的，所以它蕴含无关磁盘更新的底层信息。WAL的内容处于元组及其磁盘偏移量（即ctids ）的理论磁盘地位的层面上。如果在主库和从库同步之前敞开Postgres主库和从库，那么从库上的理论磁盘内容与主库上的内容将齐全匹配。因而，像rsync之类的工具有可能修复呈现数据净化的从库。然而，这样的设计导致咱们解决数据时更简单更繁琐。 写入放大(Write Amplification)Postgres设计的第一个问题在其余状况下称为写放大。通常，写入放大是指将数据写入SSD磁盘时遇到的问题：小的更新（例如，写入几个字节）在转换到物理层时会变得更大，或者说更低廉。在Postgres中也会呈现同样的问题。在后面的示例中，当咱们对al-Khwārizmī的出世年进行了小的逻辑更新时，咱们至多要触发四个底层的更新： 将新的行元组写入表空间更新主键索引以增加新元组记录更新first和last的索引以增加新元组记录更新birth_year 索引以增加新元组记录实际上，这四个更新仅反映了对主表空间的写操作。这些写操作中的每一个也须要反映在WAL中，因而磁盘上的写操作总数甚至更大。 这里值得注意的是二、三步骤。当咱们更新al-Khwārizmī的出世年份时，咱们实际上没有更改他的主键，也没有更新他的last和first。即便如此，咱们依然通过在数据库中为行记录创立新的元组来更新这些索引。对于具备大量二级索引的表，这些多余的步骤可能会导致查问效率机器低下。例如，如果咱们在一个表上定义了十二个索引，那么将必须对仅由一个索引笼罩的字段的更新流传到其余11个索引中。 主从复制因为复制产生在磁盘级别，因而将屡次写入的问题天然也转化到了物理层。postgres没有复制一个个数据库改变的记录，例如“将ctid = D的出世年份更改为当初的770”，而是为咱们方才形容的所有四次操作都写入了WAL，并且所有这四个WAL条目都同步给其余的服务。因而，屡次写入问题又转化为了屡次传输的问题，并且Postgres同步的数据流很快变得贼长，并且占用大量带宽。 ...

作者：苏厚镇 青云科技数据库研发工程师 目前从事 RadonDB ClickHouse 相干工作，热衷于钻研数据库内核。 连续上篇《容器化 ClickHouse on K8s 基本概念解析篇》，能够理解到 Operator 提供简便治理 ClickHouse 集群性能，Helm 提供便捷部署集群性能。 本篇将以部署 RadonDB ClickHouse[1] 作为示例。在同样选用 Operator 的条件下，比拟Kubectl 和 Helm 两种形式在 K8s 上部署 ClickHouse 集群的便捷性。并简要介绍如何在 K8s 上通过 Operator 轻便疾速地治理 ClickHouse 集群。 | 应用 Kubectl + Operator 部署前置条件已装置 Kubernetes 集群。 部署步骤1、部署 RadonDB ClickHouse Operator $ kubectl apply -f https://github.com/radondb/radondb-clickhouse-kubernetes/clickhouse-operator-install.yaml留神：若需 Operator 监控所有的 Kubernetes namespace，则需将其部署在 kube-system namespace 下。否则只会监控部署到的 namespace。2、编写 CR 的部署文件 以下 yaml 文件形容了利用 RadonDB ClickHouse Operator 装置两分片两正本集群的 ClickHouse 的配置标准。 ...

CREATE TABLE `t` ( `id` int(11) NOT NULL, `city` varchar(16) NOT NULL, `name` varchar(16) NOT NULL, `age` int(11) NOT NULL, `addr` varchar(128) DEFAULT NULL, PRIMARY KEY (`id`), KEY `city` (`city`)) ENGINE=InnoDB;如果要查问city是杭州的所有人名字,并且按姓名排序返回前1000集体的姓名和年龄,sql能够这么写: select city,name,age from t where city='杭州' order by name limit 1000 ;全字段排序: 初始化 sort_buffer，确定放入 name、city、age 这三个字段；从索引 city 找到第一个满足 city='杭州’条件的主键 id，也就是图中的 ID_X；到主键 id 索引取出整行，取 name、city、age 三个字段的值，存入 sort_buffer 中；从索引 city 取下一个记录的主键 id；反复步骤 3、4 直到 city 的值不满足查问条件为止，对应的主键 id 也就是图中的 ID_Y；对 sort_buffer 中的数据依照字段 name 做疾速排序；依照排序后果取前 1000 行返回给客户端。排序过程中,可能在内存中实现,也可能应用内部排序,取决于排序所需内存以及参数 sort_buffer_size,小于这个值则应用内存疾速排序,否则应用内部归并排序 ...

MyISAM 引擎把一个表的总行数存在了磁盘上，因而执行 count(*) 的时候会间接返回这个数，效率很高InnoDB 引擎执行 count(*) 的时候，须要把数据一行一行地从引擎外面读出来，而后累积计数 count(id) innoDB会遍历表,把id取出来,返回server层,server层进行判断,不为空则累加1;count(1) innoDB会遍历表,但不取出来,返回server层,server层进行判断,不为空则累加1;count(字段)innoDB会遍历表,把字段取出来,返回server层,server层进行判断,不为空则累加1;count() innoDB专门做了优化,不取值,cout()必定不是null,按行累加 效率排序:count(字段)<count(主键 id)<count(1)≈count(*)尽量应用count(*)

算起来，从真正开始用Rust进行我的项目开发曾经快一年了，对Rust也愈发青眼；在这过程中踩了很多坑，因为Rust的变态也不得不恶补了很多被废除的常识；当然对计算机的了解也更深了，头发天然也越发稠密了。 ”圆“规正传明天给大家分享一个本人的一个crate，因为近几年转Rust的小伙伴越来越多，很多都是从Java岗转的，他们转过来的第一件事就是疯狂的寻找一个好用的ORM框架，然而Rust中目前比拟好用的相干数据库框架有diesel、sqlx等，基本上都能满足日常的工作需要。为了不便更多小伙伴过渡Rust，就手撸了一个小框架，参考MyBatisPlus的相干API，置信只有用过该框架的小伙伴应该根本能够无缝过渡。目前曾经过渡到0.2.0版本，基本上更新还是比拟频繁，因为后期想法比拟多，也没有一个固定的方向所以常常颠覆重来。 这个crate叫做akita，翻译过去就是秋田犬的意思，也代表了呆萌可恶的意思。根本的实现思路就是通过Rust的过程宏来实现对数据库表构造的映射，而后封装了一些便捷的SQL组装的工具办法。目前我的项目临时只反对MySQL，所应用的线程池为r2d2，行将打算反对ClickHouse、SQLite、MSSQL、ORACLE等数据库。 间接开码话不多说咱间接码，好不好用咱用一个试试。首先增加依赖，当初目前版本在0.2.4。 [dependencies]# The core APIs, including the Table traits. Always# required when using Akita. using #[derive(Table)] # to make Akita work with structs defined in your crate.akita = { version = "0.2.0"] }首先咱们定义一个构造体SystemUser，Akita提供了三个trait，别离是FromAkita、ToAkita还有Table，次要是用来解析构造体的字段构造以及生成根本的CRUD成员办法。另外提供了table注解用来标注数据库表名，field和table_id标注列名和主键，别离都有name属性，同时保留了MyBatisPlus中的exist属性。 #[derive(Debug, FromAkita, ToAkita, Table, Clone)]#[table(name="t_system_user")]struct SystemUser { #[field = "name"] id: Option<i32>, #[table_id] username: String, #[field(name="ages", exist = "false")] age: i32,}来来来，Akita中提供了两个公共的管理器，AkitaManager和AkitaEntityManager，前者次要封装了一些原始的SQL操作，后者则退出了比拟残缺的API，同时在构造体中也实现了这些API。咱们以CRUD操作举例： use akita::*;use akita::prelude::*;fn main() { let mut pool = Pool::new(AkitaConfig{ max_size: None, url: String::from("mysql://root:password@localhost:3306/akita"), log_level: None }).unwrap(); let mut em = pool.entity_manager().expect("must be ok"); let user = SystemUser { id: 1.into(), username: "fff".to_string(), age: 1 }; // 新增 match em.save(&user) { Ok(res) => { } Err(err) => { } } /// 构造体示例 match user.insert(&mut em) { Ok(res) => { } Err(err) => { } } // 删除 match em.remove_by_id::<SystemUser, String>("id".to_string()) { Ok(res) => { } Err(err) => { } } // 批改 match em.update_by_id(&user, "id") { Ok(res) => { } Err(err) => { } } // 查问分页 let mut wrapper = UpdateWrapper::new(); wrapper.eq( "username", "ussd").eq("id", 1); match em.page::<SystemUser, UpdateWrapper>(1, 10,&mut wrapper) { Ok(res) => { } Err(err) => { } } // 查问单条 match em.select_one::<SystemUser, UpdateWrapper>(&mut wrapper) { Ok(res) => { } Err(err) => { } } ...}看完是不是很打动，对于手写了大半年SQL的我，几乎是个福音...另外性能方面的话还有很多咱们正在优化，比方大数据量的分页以及相干慢SQL的拦挡以及一些其余的优化。 ...

开发中存在着各种数据，比方用户的个人信息、商品详情、购买记录，这些数据都要以肯定的形式贮存，如果以文本的模式贮存，每一次获取都要读取文件，如果信息有批改则须要间接批改文本，大量的数据会须要保留大量的文件，这样不仅不便于操作、保护，还给服务器带来微小的累赘，什么样的形式可能贮存大量的数据并且便于批改？答案就是数据库。 关系型数据库以二维数组组成的表构造来贮存数据，各表之间能够设置一对一，一对多，多对多的关系，比方用户个人信息的表中id为1的用户，她在xx商品购买记录的表中存在着一条购买商品的数据，通过各种对应关系，可能从不同的维度保留数据，当须要应用的时候，间接依据某些条件下操作数据。 而非关系型数据库，它的存储更为自在，应用 key-value 这样的模式去保留数据，比方在登陆状态后，保留某个用户的姓名、手机号、身份等信息，获取和写入都比拟的简略。 关系型数据库包含mysql、oracle、sql server 等，非关系型数据库包含 MongoDB、Redis等，这里来聊聊mysql。 mysql的语句大抵能够分为四类，别离是DDL（Data Definition Language）：数据定义语言，用来对数据库或者表进行：创立、删除、批改等操作，DML（Data Manipulation Language）：数据操作语言，用来对表进行：增加、删除、批改等操作，DQL（Data Query Language）：数据查询语言，用来从数据库中查问记录，DCL（Data Control Language）：数据管制语言 对数据库、表格的权限进行相干访问控制操作。 首先来看对数据库操作，这里有一个编写习惯，通常把sql语句局部大写，数据库名、表名、字段名小写 // 1、展现所有的数据库，即便没有创立任何一个数据库，零碎默认也会有四个数据库SHOW DATABASES;// 2、抉择数据库 mysqlUSE mysql;// 3、显示以后所抉择的数据库SELECT DATABASE();// 4、如果不存在数据库 studySql 则创立CREATE DATABASE IF NOT EXISTS `studySql`;// 5、如果存在数据库 studySql 则删除DROP DATABASE IF EXISTS `studySql`; 再来看看对表的操作，比方在我的项目里，咱们须要保留用户的个人资料，那么此时要创立一个用户表，表外面存储着用户的姓名、手机号码、出生年月，以上的这三种字段对应的是不同的类型，姓名须要字符串类型，手机号码须要数字类型，而出生年月须要应用日期类型，通过数据类型来对保留的数据进行限度，那么常见的数据类型有以下几种。 1、字符串类型char定义固定长度的字符串，长度在0-255之间，varchar定义可变长的字符串，长度在0到65535之间的值，text可存储更大的字符串2、数字类型数字分为整数、浮点数、准确到小数点的数整数类型：INT，浮点类型：FLOAT，DOUBLE，准确数字：DECIMAL，NUMERIC3、日期类型(1) YEAR，格局如YYYY，只有年份，范畴从 1901到2155，和 0000(2) DATE，格局如YYYY-MM-DD，有年月日，范畴从 '1000-01-01' 到 '9999-12-31'(3) DATATIME，格局如 YYYY-MM-DD hh:mm:ss，有年月日时分秒，范畴从 '1970-01-01 00:00:01' 到'2038-01-19 03:14:07'(4) DATASTAMP / TIMESTAMP，比DATATIME还要准确6位，格局如 YYYY-MM-DD hh:mm:ss.xxxxxx，范畴从'1000-01-01 00:00:00.000000'到'9999-12-31 23:59:59.999999'以上的数据类型用于创立表时对字段进行补充，除了补充之外，还应该对字段有限度，比方用户的手机号码不可反复，用户要增加一个惟一的id值来示意其“身份”，这些限度就是表束缚，咱们通常有以下几种形式来对表进行束缚 1、主键主键代表惟一的值，如id，主键不可反复，也不能够为空，用字段 PRIMARY KEY 来示意2、惟一键不可反复，但容许为空，比方手机号码，用字段UNIQUE来示意3、AUTO_INCREMENT当咱们没有给某一字段设置值的时候，心愿它主动增长，须要数据类型为数字类型4、NOT NULL不容许为空5、DEFAULT设置默认值6、外键在下一篇对于DQL的总结中具体阐明~有了以上的概念，咱们就能够在数据库中创立一张“用户表”了 ...

download：高并发 高性能 高可用 MySQL 实战//特点界说 //用来接管客户端连接的服务端的ServerSocket private ServerSocket server; //用来办理解决客户端申请的线程的线程池 private ExecutorService threadPool; //保留所有客户端发送过去配对日志的文件 private File serverLogFile; //消息行列 private BlockingQueuemessageQueue = new LinkedBlockingQueue(); public DMSServer() throws Exception{ try { System.out.println("服务端正在初始化..."); //1 解析配备文件server-config.xml Map config = loadConfig(); //2 根据配备文件内容初始化特点 init(config); System.out.println("服务端初始化完结...");} catch (Exception e) { System.out.println("初始化服务端得胜!"); throw e;}} /** 构造方法初始化第一步，解析配备文件@return 回来的Map中保留的是配备文件中的每一条内容，其中key:标签的姓名，value为标签两头的文本@throws Exception */ private Map loadConfig() throws Exception{ try { SAXReader reader = new SAXReader(); Document doc = reader.read(new File("server-config.xml")); Element root = doc.getRootElement(); ...

步骤子项目提供数据同步接口，可依据状况抉择同步的线程数以及批量插入的数据量。具体步骤： 全量迁徙：搬迁以后库中所有的历史数据（新我的项目提供数据迁徙的接口，可批量迁徙数据，该过程会搬掉库中大部分数据）增量迁徙：记录全量迁徙开始的工夫，搬迁全量迁徙过程中变更了的数据数据比对：通过接口比对 Cassandra 和 MySQL 中的数据，最终数据一致性达到肯定99.99%以上开双写：通过数据比对确保全量迁徙和增量迁徙没问题当前，关上双写。如果双写有问题，数据比对还能够发现双写中的问题。切 Cassandra 读：确保双写没问题当前，敞开MySQL写。测试后果Spring-data-cassandra5个线程，每个线程150条数据，一个小时，808万条数据，13.4万/分钟5个线程，每个线程500条数据，15分钟，274万条数据，22.8万/分钟应用 Spring-data-cassandra 连贯驱动时速度过慢，查看后发现，Spring-data-cassandra 的API中，批量插入操作，外部实现是一条一条插入的Cassandra-driver在本机运行，批改 Cassandra 并发读和并发写的线程数为32，每次批量数据大小为5000kb,读写超时揭示为500000毫秒，测试后果如下： 应用一个节点 10个线程，查问5000，每次1000，三分钟，137万 45.6万/分 1000万条数据 21.9分钟 10个线程，查问5000，每次2000，两分钟，76万 38万/分 1000万条数据 26.3分钟 6个线程，查问5000，每次2000，二分钟，99万 50万/分 1000万条数据 20分钟 6个线程，查问5000，每次5000，一分钟，52万 52万/分 1000万条数据 19.2分钟 5个线程，查问5000，每次1000，7分钟，400万 57万/分 1000万条数据 17.5分钟 5个线程，查问5000，每次2000，一分钟，56万 56万/分 1000万条数据 17.8分钟 5个线程，查问5000，每次5000，一分钟，36万 36万/分 1000万条数据 27.7分钟减少到两个节点： 5个线程，查问5000，每次5000，十分钟，790万 79万/分 1000万条数据12.6分钟 5个线程，查问10000，每次5000，十分钟，632万 63.2万/分 1000万条数据15.8分钟 10个线程，查问5000，每次5000，十分钟，650万 65万/分 1000万条数据15.3分钟敞开commitLog，两个节点 5个线程，查问5000，每次5000，十分钟，760万 76万/分 1000万条数据13.1分钟敞开commitLog，一个节点 5个线程，查问5000，每次5000，十分钟，690万 69万/分 1000万条数据14.5分钟 5个线程，查问5000，每次5000，2.5分钟，110万，44万/分 1000万条数据22.7分钟 5个线程，查问1000，每次5000，3分钟，133万， 44万/分 1000万条数据22.7分钟 5个线程，查问10000，每次5000，3分钟，84万， 28万/分 1000万条数据35.7分钟 10个线程，查问10000，每次5000，2分钟，87万， 43.5万/分 1000万条数据22.9分钟 服务器上运行，三个节点 ...

原我的项目中诸如 用户浏览文章记录等写多读少的表，数据量亿级以上，用MySQL存储性能不太佳，所以尝试迁徙到 NoSQL 数据库，比照后抉择了 ScyllaDB。 ScyllaDB介绍 Scylla是一个开源、分布式、去中心化、弹性可扩大、高可用、容错、可调一致性、面向行的数据库。 Scylla应用C++从新实现了Cassandra，以进步性能并利用多核服务。它解决了Apache Cassandra的一些陷阱，是Apache Cassandra的嵌入式替换数据库，这两个数据库之间的驱动程序相互兼容。 Hbase与ScyllaDB Scylla是p2p架构，无单点生效问题，Hbase是主从构造，须要选主，保护主从关系；Scylla是AP零碎，也能够通过调整参数使它成为CP零碎（只有R+W>N），HBase是CP零碎，对数据有强一致性需要就应用HBase；Scylla是一个数据存储和数据管理系统。HBase只负责数据管理，它须要配合HDFS和zookeeper来搭建集群；Scylla写性能好一些，因为数据哈希较扩散，读性能不如HBase。HBase写过程比拟繁琐，但其数据在regin内是排序的，读性能更好；两个都适宜寄存 time-series data，例如传感器数据，网站拜访，用户行为，股市交易数据等；Scylla善于数据接入，因为写性能比拟好。Docker搭建ScyllaDB集群 docker run --name scylla-node2 -p 8042:9042 -p 8160:9160 -p 1000:10000 -p 8180:9180 -v /data/scylladb2:/var/lib/scylla -d scylladb/scylla --seeds="$(docker inspect --format='{{ .NetworkSettings.IPAddress }}' scylla)"docker run --name scylla-node3 -p 10042:9042 -p 10160:9160 -p 1100:10000 -p 10180:9180 -v /data/scylladb3:/var/lib/scylla -d scylladb/scylla --seeds="$(docker inspect --format='{{ .NetworkSettings.IPAddress }}' scylla)"docker run --name scylla-node4 -p 11042:9042 -p 11160:9160 -p 1200:10000 -p 11180:9180 -v /data/scylladb4:/var/lib/scylla -d scylladb/scylla --seeds="$(docker inspect --format='{{ .NetworkSettings.IPAddress }}' scylla)"接下来先介绍Cassandra的根底信息。 ...

作者：苏厚镇 青云科技数据库研发工程师 目前从事 RadonDB ClickHouse 相干工作，热衷于钻研数据库内核。 ClickHouse[1] 是一款用于联机剖析（OLAP）的列式数据库管理系统（DBMS）。由号称“俄罗斯 Google”的 Yandex 公司开发，并于 2016 年开源，近年在计算引擎技术畛域受到越来越多的关注，算是数据库后起之秀。 Kubernetes[2] 是 Google 公司于 2014 年 6 月开源的一款容器集群管理系统。实用于治理云平台多个主机的容器化利用，旨在让部署容器化的利用简略并且高效，致力成为跨主机集群的主动部署、扩大以及运行应用程序容器的平台。 借助 K8s 和容器化技术，咱们不仅能够使得利用的部署和治理更加简略高效、进步硬件资源利用率等，还能够实现健康检查和自修复、主动扩缩容、负载平衡等高级性能。 那么，如果黑马数据库 ClickHouse 遇上炽热的容器化治理技术 K8s，会擦出怎么的火花呢？ | ClickHouse 容器化计划概览以后 ClickHouse 的支流容器化计划包含 原生（Kubectl）部署 和 Helm 部署 两种，而每种又包含 是否应用 Operator 两种状况。 部署形式Kubectl 原生部署Kubectl 原生部署Helm 部署Helm 部署是否应用Operator×√×√部署不便水平难中易易治理不便水平难中难易| Helm 部署计划Kubernetes 基于服务力度提供了很多资源类型，比方 Service、Deployment 等。当须要部署一个利用时，尤其是有状态利用，须要组合应用大量的 Kubernetes 资源，部署之后还须要治理它们，包含降级、更新换代、删除等等。这时咱们会想，是否有这样一个工具能够在更下层的维度去治理这些利用呢？这个时候就有了社区的一个包管理工具：Helm[3]。 简略来讲，可把 Helm 看作是 Linux 中的 Yum，Java 中的 Maven。 对于利用发布者而言，能够通过 Helm 打包利用，治理利用依赖关系，治理利用版本并公布利用到软件仓库。对于使用者而言，应用 Helm 后不必须要理解 Kubernetes 的 Yaml 语法并编写利用部署文件，能够通过 Helm 下载并在 Kubernetes 上装置须要的利用。 ...

连贯类型：左连贯(left join)：返回左表全副数据和右表合乎连贯条件的数据右连贯(right join)：返回右表全副数据和左表合乎连贯条件的数据内连贯(inner join)：只返回合乎连贯条件的数据全连贯(full join)：返回左表全副数据和右表全副数据 例子：A表： id name age sex b_id1 张三 10 男 12 李四 8 女 23 麻子 11 男 3B表： id name1 翻新班 2 尖子班左连贯： select a.name,a.age,a.sex,b.name as b_name from a left join b on a.b_id = b.id;后果：右连贯： select a.name,a.age,a.sex,b.name as b_name from a right join b on a.b_id = b.id;后果：内连贯： select a.name,a.age,a.sex,b.name as b_name from a inner join b on a.b_id = b.id;后果：注：内连贯返回的是合乎on连贯条件的数据，右连贯返回的是右表数据 全连贯（mysql暂不反对） 多表查问： ...

MySQL 源代码是基于关系模型实践的具体实现，是数据库实践与实际的联合。 浏览 MySQL 及相干工具的源代码，不仅是数据库研发人员的日常，也是 DBA 进阶的必经之路，全方位进步技术水平。 夯实原理： 对数据库基础理论以及事务等相干实践更加粗浅的意识；优化性能： 更加深刻了解配置项的作用，适配环境，晋升性能；定位故障： 有助于数据库故障的疾速定位，知其然也知其所以然；拥抱开源： 批改源代码（批改 Bug、欠缺性能、晋升性能），回馈开源。| 从哪开始浏览？浏览 MySQL 源代码，次要是指浏览 mysql-server[1] 外面的代码。不仅须要理论知识的深刻学习，还须要理论利用上手实际，具体可从以下几个角度着手，从不同维度，不同深度去理解 MySQL 源代码。 1. SQL 执行流程通过环境调试，从实践根底实际把握 SQL 语句（DDL/DML 等）残缺的执行流程。 2. 构造档次通过 MySQL 源代码构造档次，把握底层技术原理。 接入层：MySQL 协定、连接线程池等;SQL 层：词法、语法解析、执行器、优化器;存储引擎层：插件框架、存储引擎设计原理，例如 InnoDB、RocksDB 架构等。3. 数据抽象/数据转换数据库对于使用者展示的是二维的关系表。在浏览源码的时候，能够从数据抽象/数据转换的角度去浏览。 数据抽象：二维的关系表在 SQL 层/存储引擎中的数据表现形式数据转换：二维关系表在 SQL 层到存储引擎的数据转换/存储引擎到磁盘的数据转换4. 性能实现通过观察数据库中每种具体性能的实现形式，来相熟 MySQL 源代码。 | 筹备调试环境正所谓：“工欲善其事必先利其器”，浏览源代码必须要浏览 "动" 态的代码，仅看 "静" 态代码必然是干燥且无用的。那么搭建一个可能调试 MySQL 源代码的环境，则是浏览 MySQL 源代码，实际并把握 MySQL 技术常识必不可少的过程。 本文介绍应用 CLion 在 Ubuntu 下的调试过程，来实例演示 MySQL 源代码环境的调试过程，即从实际把握 SQL 执行流程。 CLion 简介CLion[2] 是一款专门为开发 C 及 C++ 所设计的跨平台 IDE。它蕴含了插件以及智能性能来帮忙开发人员进步开发代码的效率。 ...

之前的文章把 InnoDB 中的所有的锁都介绍了一下，包含意向锁、记录锁...自增锁巴拉巴拉的。然而前面我本人回过头去看的时候发现，对自增锁的介绍竟然才短短的一段。 其实自增锁（AUTO-INC Locks）这块还是有很多值得探讨的细节，例如在并发的场景下，InnoDB 是如何保障该值正确的进行自增的，本章就专门来简略讨论一下 InnoDB 中的自增锁。 什么是自增锁之前咱们提到过，自增锁是一种比拟非凡的表级锁。并且在事务向蕴含了 AUTO_INCREMENT 列的表中新增数据时就会去持有自增锁，假如事务 A 正在做这个操作，如果另一个事务 B 尝试执行 INSERT语句，事务 B 会被阻塞住，直到事务 A 开释自增锁。 这怎么说呢，说他对，然而他也不齐全对。 行为与限度其实下面说的那种阻塞状况只是自增锁行为的其中一种，能够了解为自增锁就是一个接口，其具体的实现有多种。具体的配置项为 innodb_autoinc_lock_mode ，通过这个配置项咱们能够扭转自增锁中运行的一些细节。 并且，自增锁还有一个限度，那就是被设置为 AUTO_INCREMENT 的列必须是索引，或者该列是索引的一部分（联结索引），不过这个限度对于大部分开发场景下并没有什么影响。 毕竟咱们的基操不就是把 id 设置为 AUTO_INCREMENT 吗。锁模式其实在 InnoDB 中，把锁的行为叫做锁模式可能更加精确，那具体有哪些锁模式呢，如下： 传统模式（Traditional）间断模式（Consecutive）穿插模式（Interleaved）别离对应配置项 innodb_autoinc_lock_mode 的值0、1、2. 看到这就曾经晓得为啥下面说不精确了，因为三种模式下，InnoDB 对并发的解决是不一样的，而且具体抉择哪种锁模式跟你以后应用的 MySQL 版本还有关系。 在 MySQL 8.0 之前，InnoDB 锁模式默认为间断模式，值为1，而在 MySQL 8.0 之后，默认模式变成了穿插模式。至于为啥会扭转默认模式，前面会讲。 传统模式传统模式（Traditional），说白了就是还没有锁模式这个概念时，InnoDB 的自增锁运行的模式。只是前面版本更新，InnoDB 引入了锁模式的概念，而后 InnoDB 给了这种以前默认的模式一个名字，叫——传统模式。 传统模式具体是咋工作的？ 咱们晓得，当咱们向蕴含了 AUTO_INCREMENT 列的表中插入数据时，都会持有这么一个非凡的表锁——自增锁（AUTO-INC），并且当语句执行完之后就会开释。这样一来能够保障单个语句内生成的自增值是间断的。 这样一来，传统模式的弊病就天然裸露进去了，如果有多个事务并发的执行 INSERT 操作，AUTO-INC的存在会使得 MySQL 的性能略有降落，因为同时只能执行一条 INSERT 语句。 间断模式间断模式（Consecutive）是 MySQL 8.0 之前默认的模式，之所以提出这种模式，是因为传统模式存在影响性能的弊病，所以才有了间断模式。 ...

Mysql5.5双机热备实现计划 装置两台Mysql装置Mysql5.5 sudo apt-get updateapt-get install aptitudeaptitude install mysql-server-5.5或sudo apt-cache search mariadb-serverapt-get install -y mariadb-server-5.5卸载 sudo apt-get remove mysql-*dpkg -l |grep ^rc|awk '{print $2}' |sudo xargs dpkg -P配置权限 vim /etc/mysql/my.cnf#bind-address = 127.0.0.1mysql -u root -pgrant all on *.* to root@'%' identified by 'root' with grant option;flush privileges;配置两台Mysql主主同步配置节点1vim /etc/mysql/my.cnfserver-id = 1 #节点IDlog_bin = mysql-bin.log #日志 binlog_format = "ROW" #日志格局auto_increment_increment = 2 #自增ID距离(=节点数，避免ID抵触)auto_increment_offset = 1 #自增ID起始值(节点ID)binlog_ignore_db=mysql #不同步的数据库binlog_ignore_db=information_schemabinlog_ignore_db=performance_schema重启mysql service mysql restartmysql -u root -p记录节点1的binlog日志地位 ...

1. 全局锁对整个数据库加锁 Flush tables with read lock (FTWRL)//整库只读数据更新语句（数据的增删改）、数据定义语句（包含建表、批改表构造等）和更新类事务的提交语句都会被阻塞。全局锁的典型应用场景是，做全库逻辑备份应用msqldump工具并加上–single-transaction能够开启一个事务,进行逻辑备份,数据也是能够失常更新的 set global readonly=true //全库只读,readonly个别用来判断主库还是备库,遇到异样时FTWRL会开释全局锁,readonly遇到异样会始终导致库不可写,危险较高2. 表级锁MySQL 外面表级别的锁有两种：一种是表锁，一种是元数据锁（meta data lock，MDL)。 表锁: lock tables ... read/writeunlock tables如果在某个线程 A 中执行 lock tables t1 read, t2 write; 这个语句，则其余线程写 t1、读写 t2 的语句都会被阻塞。同时，线程 A 在执行 unlock tables 之前，也只能执行读 t1、读写 t2 的操作。连写 t1 都不容许，天然也不能拜访其余表。 MDL锁执行增删改查语句(DML语句)时主动会加上MDL读锁;执行表构造更改语句(DDL)时主动会加上MDL写锁; session C在获取MDL写锁时会被阻塞,session D在获取MDL读锁时受session C的影响也会被阻塞 3. 行锁 innoDB事务中,行锁是在须要的时候才加上的,事务完结时才开释; 假如你负责实现一个电影票在线交易业务，顾客 A 要在影院 B 购买电影票。咱们简化一点，这个业务须要波及到以下操作： 从顾客 A 账户余额中扣除电影票价；给影院 B 的账户余额减少这张电影票价；记录一条交易日志。锁竞争抵触的最大局部在于2步骤, 如果把2步骤放到最初一行,则最大限度能够缩小事务之间的锁竞争 死锁 事务AB相互期待对方开释资源,即进入死锁状态,当呈现死锁当前有两种策略 当进入死锁状态时,个别有两种策略: 间接进入期待,直到超时,超时工夫能够通过参数innodb_lock_wait_timeout来设置,默认50s发动死锁检测,发现死锁后被动回滚其中一个事务,innodb_deadlock_detect设置为on示意开启死锁检测时间复杂度为O(n²),即1000个并发线程更新同一行,死锁检测操作量级为百万级 优化计划为: 1.拆行,一行数据拆多行,管制并发度2.限流,管制同一时间的线程数3.敞开死锁检测,会呈现大量业务超时 ...

作者：任坤 现居珠海，先后负责专职 Oracle 和 MySQL DBA，当初次要负责 MySQL、mongoDB 和 Redis 保护工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 1、背景上班时间收到一条磁盘空间报警 登录该机器查看，根分区只有不到16G，此刻曾经应用超过了80%。 查看根分区下最大的10个文件并依照size降序排列 du ‐Sm / ‐‐exclude="/data" | sort ‐k1nr | head ‐10这条命令在其余环境执行几秒钟就返回了，在这个机器上执行了将近1分钟，最初定位到是几个日志文件，间接删除即可。 刚筹备退出登录，又收到一条内存报警，还是这台机器。 2、诊断查看内存应用状况，的确曾经被耗尽 top查看最耗内存的几个过程 耗费内存每多的mysqld只占用了43G，就算加上截图中的其余几个过程，顶多占用44G。为防止漏算，统计一下所有过程占用的物理内存总和: [root@centos6564‐220 ~]# more RSS.sh#/bin/bashfor PROC in `ls /proc/|grep "^[0‐9]"`doif [ ‐f /proc/$PROC/statm ]; thenTEP=`cat /proc/$PROC/statm | awk '{print ($2)}'`RSS=`expr $RSS + $TEP`fidoneRSS=`expr $RSS \* 4 / 1024 / 1024`echo $RSS"GB"[root@centos6564‐220 ~]# sh RSS.sh44GB注：该脚本来自于褚霸多年前的一篇文章 http://blog.yufeng.info/archi... 问题来了，残余的10多G内存被谁占用了？top 和 ps 都给不出答案，只能查看/proc/meminfo文件 ...

一、前言在进行高性能 Java 持久性培训时，我意识到有必要解释关系数据库的工作原理，否则，很难把握许多与事务相干的概念，例如原子性、持久性和检查点。 在这篇文章中，我将对关系数据库的外部工作形式进行高层次的解释，同时还暗示一些特定于数据库的实现细节。 二、一图胜千文 三、Data pages磁盘访问速度很慢。另一方面，内存甚至比固态硬盘还要快几个数量级。出于这个起因，数据库供应商试图尽可能提早磁盘拜访。无论咱们议论的是表还是索引，数据都被分成肯定大小（例如 8 KB）的 page。 当须要读取数据（表或索引）时，关系数据库会将基于磁盘的页面映射到内存缓冲区。当须要批改数据时，关系数据库会更改内存 pages。要将内存 pages 与磁盘同步，必须进行 flush（例如 fsync）。 存储基于磁盘的 page 的缓冲池大小无限，因而通常须要存储数据工作集。只有当整个数据能够放入内存时，缓冲池能力存储整个数据集。然而，如果须要缓存新 page 时磁盘上的总体数据大于缓冲池大小，则缓冲池将不得不逐出旧 pages 为新 pages 腾出空间。四、Undo log因为内存中的变动能够被多个并发事务拜访，所以必须采纳并发管制机制（例如 2PL 和 MVCC）来确保数据完整性。因而，一旦事务批改了表行，未提交的更改将利用于内存构造，而先前的数据会长期存储在 undo log append-only 构造中。 尽管这种构造在 Oracle 和 MySQL 中称为 undo log，但在 SQL Server 中，事务日志起着这种作用。PostgreSQL 没有 undo log，然而通过多版本表构造达到了雷同的目标，因为表能够存储同一行的多个版本。然而，所有这些数据结构都用于提供回滚能力，这是原子性的强制性要求。如果以后运行的事务回滚，undo log 将用于重建事务开始时的内存 pages。 五、Redo log一旦事务提交，内存中的更改必须放弃不变。然而，这并不意味着每个事务提交都会触发 fsync。事实上，这对应用程序性能十分不利。然而，从 ACID 事务属性，咱们晓得提交的事务必须提供持久性，这意味着即便咱们拔掉数据库引擎，提交的更改也须要长久化。 那么，关系数据库如何提供持久性而不在每次事务提交时收回 fsync 呢？ 这就是 redo log 发挥作用的中央。redo log 也是一种 append-only 基于磁盘的构造，用于存储给定事务所经验的每个更改。因而，当事务提交时，每个数据页更改也将写入_redo log_。与刷新固定数量的 data pages 相比，写入 redo log 十分快，因为程序磁盘拜访比 Random access 快得多。因而，它还容许事务疾速解决。 ...

mysql> create table T (ID int primary key,k int NOT NULL DEFAULT 0, s varchar(16) NOT NULL DEFAULT '',index k(k))engine=InnoDB;insert into T values(100,1, 'aa'),(200,2,'bb'),(300,3,'cc'),(500,5,'ee'),(600,6,'ff'),(700,7,'gg'); select * from T where k between 3 and 5执行流程:在 k 索引树上找到 k=3 的记录，获得 ID = 300；再到 ID 索引树查到 ID=300 对应的 R3；在 k 索引树取下一个值 k=5，获得 ID=500；再回到 ID 索引树查到 ID=500 对应的 R4；在 k 索引树取下一个值 k=6，不满足条件，循环完结。 在这个过程中，回到主键索引树搜寻的过程，咱们称为回表。能够看到，这个查问过程读了 k 索引树的 3 条记录（步骤 1、3 和 5），回表了两次（步骤 2 和 4）。 ...

前言： 在 MySQL 数据库中，在创立视图及函数的时候，你有留神过 definer 选项吗？在迁徙视图或函数后是否有过报错状况，这些其实都可能和 definer 有关系。本篇文章次要介绍下 MySQL 中 definer 的含意及作用。 1.DEFINER简略介绍以视图为例，咱们来看下官网给出的视图创立根底语法： CREATE [OR REPLACE] [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}] [DEFINER = user] [SQL SECURITY { DEFINER | INVOKER }] VIEW view_name [(column_list)] AS select_statement [WITH [CASCADED | LOCAL] CHECK OPTION]认真看下面语法，发现 definer 呈现了两次，一次是 DEFINER = user 一次是 SQL SECURITY 选项能够设置为 DEFINER 或 INVOKER ，看到这里，你有猜到 definer 的作用了吗？ definer 翻译成中文是“定义者”的意思。MySQL中，创立视图(view)、函数(function)、存储过程(procedure)、触发器(trigger)、事件(event)时，都能够指定 DEFINER = user 选项，即指定此对象的定义者是谁，若不显式指定，则创立此对象的用户就是定义者。 对于视图、函数及存储过程，还能够指定 SQL SECURITY 属性，其值能够为 DEFINER（定义者） 或 INVOKER（调用者），示意在执行过程中，应用谁的权限来执行。DEFINER 示意按定义者领有的权限来执行，INVOKER 示意用调用者的权限来执行。 ...

逛V站遇到这个问题，也有点懵，看到评论答案形形色色，还是本人入手试下吧。 1.建一个表：2.插入10000条数据 DROP PROCEDURE IF EXISTS proc_initData;--如果存在此存储过程则删掉DELIMITER $CREATE PROCEDURE proc_initData()BEGIN DECLARE i INT DEFAULT 1; WHILE i<=10000 DO INSERT INTO test(id,a,b,c) VALUES(i,i,i,i); SET i = i+1; END WHILE;END $CALL proc_initData();3.建索引 ALTER table test ADD INDEX indextest(a,b,c);4.测试 explain select * from test where a=1; explain select * from test where a=1 and b > 2; explain select * from test where a=1 and b > 2 order by c; 由此可知，的确满足最左匹配会应用索引没有问题，a 等值，b 范畴，ab会应用到索引，范畴后的操作不会应用索引，c不会用到索引，但总体来看还是用到了组合索引。 ...

事务下图依照工夫执行两个事务create table T(c int) engine=InnoDB;insert into T(c) values(1);隔离级别 读未提交： V1=2，V2=2，V3=2读提交： V1=1，V2=2，V3=2可反复读： V1=1，V2=1，V3=2串行化: V1=1，V2=1，V3=2 串行化则在事务 B 执行“将 1 改成 2”的时候，会被锁住。直到事 务 A 提交后，事务 B 才能够继续执行在实现上，数据库外面会创立一个视图，拜访的时候以视图的逻辑后果为准。在“可反复 读”隔离级别下，这个视图是在事务启动时创立的，整个事务存在期间都用这个视图。 在“读提交”隔离级别下，这个视图是在每个 SQL 语句开始执行的时候创立的。在“读未提交”隔离级别下间接返回记录上的最新值，没有视图概念;而“串行 化”隔离级别下间接用加锁的形式来防止并行拜访。 MVCC暗藏字段：DB_TRX_ID 创立这条记录的事务id或者最初一次批改的事务idDB_ROLL_PTR 回滚指针， 指向这条记录的上一个版本DB_ROW_ID 暗藏主键， 如果没有主键，会生成一个6字节的row_idundo log 快照读 读历史reaview

运行必要的 binlog, redo log, undo logmysql(WAL)日志优先策略，日志刷盘，数据就不会失落更新流程： binlog(归档日志)server层产生的逻辑日志，用来数据复制或闪回 undo log(回滚日志)采纳段(segment)的形式来记录的，每个undo操作在记录的时候占用一个undo log segment。InnoDB产生的逻辑日志，保障事务的隔离性，原子性对数据(缓存)的任何更新 都先写undo log提供回滚和多个行版本控制(MVCC) redo log(重做日志)InnoDB产生的物理日志，记录数据页的变动，保障事务的持久性日志优先于数据，记录redo log 视为数据已更新存储再4个1G的文件中，循环写入 刷盘策略（双1设置保障数据安全）innodb_flush_log_at_trx_commit 参数0：异步每秒刷盘1：每一个事务刷盘N：每个事务刷盘 sync_binlog 参数0：自动控制刷盘1：每一个事务刷盘N：每个事务刷盘 为什么redo log 肯定在binlog 之前(两阶段提交)redo log刷盘前：零碎解体，数据失落redo log刷盘后：零碎解体， 重启后对redo log重放，重写数据页， 重写binlog 若先写binlog 数据会被传送到备库，而此刻redo log 未写 造成数据不统一 因为 redo log 和 binlog 是两个独立的逻辑, 两阶段提交是为了让两份日志之间的逻辑统一。

聚簇索引——页决裂第十页 第十一页 此时27没有中央插入InnoDB的做法（简化版）： 1.创立新页2.判断当前页（页#10）能够从哪里进行决裂（记录行层面）3.挪动记录行4.从新定义页之间的关系 页#11放弃原样，然而页之间的关系产生了扭转： 页#10相邻的前一页不变，后一页为页#12；页#12相邻的前一页为页#10，后一页为页#11；页#11相邻的前一页为页#12，后一页不变。所以一次页决裂操作，须要批改3个页。

1、更新my.cnf配置文件 1.cat /etc/mysql/my.cnf[mysqld_multi]mysqld=/usr/local/mysql/bin/mysqld_safemysqladmin=/usr/local/mysql/bin/mysqladminLog=/usr/local/mysql/logs/multi.log[mysqld1]datadir=/usr/local/mysql/data1socket=/usr/local/mysql/run/mysql.sock3307pid-file=/usr/local/mysql/run/mysql1.pidport=3307[mysqld2]datadir=/usr/local/mysql/data2socket=/usr/local/mysql/run/mysql.sock3308pid-file=/usr/local/mysql/run/mysql2.pidport=3308[mysqld3]datadir=/usr/local/mysql/data3socket=/usr/local/mysql/run/mysql.sock3309pid-file=/usr/local/mysql/run/mysql3.pidport=33092、初始化mysqld（记录每个实例产生的随机明码） bin/mysqld --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data1 --user=mysql --initializebin/mysqld --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data2 --user=mysql --initializebin/mysqld --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data3 --user=mysql --initialize3、启动多实例 mysqld_multi reportmysqld_multi start 1mysqld_multi start 2mysqld_multi start 34、别离连贯每个实例，而后批改明码 mysql -u root -S /usr/local/mysql/run/mysql.sock3307 -pmysql -u root -S /usr/local/mysql/run/mysql.sock3308 -pmysql -u root -S /usr/local/mysql/run/mysql.sock3309 -p5、增加开机自启动mysqld_multi cp support-files/mysqld_multi.server /etc/init.d/mysqld_multichkconfig --add mysqld_multichkconfig --list | grep mysql

一、筹备环境1、查看以后环境是否装置MySQL，如果有则删除卸载 rpm -qa | grep mysqlpm -qa |grep mariadbyum remove mariadb-libs-5.5.64-1.el7.x86_642、查看my.cnf文件，如果有则删除 rm /etc/my.cnfrm /etc/mysql/my.cnf二、下载安装MySQL1、从官网下载MySQL5.7.34 1. 官网地址：https://downloads.mysql.com/archives/community2. MySQL5.7.34 安装包下载地址：https://downloads.mysql.com/archives/get/p/23/file/mysql-5.7.34-linux-glibc2.12-x86_64.tar.gz2、装置MySQL 5.7.34 1.创立mysql用户groupadd mysqluseradd -r -g mysql -s /bin/false mysql2.解压安装包cd /usr/localtar zxvf mysql-5.7.34-linux-glibc2.12-x86_64.tar.gz -C /usr/localln -s mysql-5.7.34-linux-glibc2.12-x86_64 mysqlcd mysql3.创立run、logs门路mkdir run && chown mysql.mysql runmkdir logs && chown mysql.mysql logs4.初始化mysqlbin/mysqld --initialize --user=mysql5.首次启动mysql，记录此命令返回的随机明码bin/mysqld_safe --user=mysql &[Note] A temporary password is generated for root@localhost: :qq:&XSwq6HL6.创立启动脚本cp support-files/mysql.server /etc/init.d/mysql.server/etc/init.d/mysqld status /etc/init.d/mysqld start/etc/init.d/mysqld stop/etc/init.d/mysqld restart7.设置mysql环境变量echo 'export PATH=$PATH:/usr/local/mysql/bin' >> /etc/profile3、批改MySQL明码，创立用户 ...

明天收到经营同学的一个 SQL，有点简单，尤其是这个 SQL explain 都很长时间执行不进去，于是咱们后盾团队帮忙解决这个 SQL 问题，却正好发现了一个暗藏很深的线上问题。 select a.share_code,a.generated_time,a.share_user_id,b.user_count,b.order_count,a.share_order_id,b.rewarded_amountfrom t_risk_share_code a,(select count(distinct r.user_id) user_count,count(distinct r.order_id) order_count,s.rewarded_amount,r.share_codefrom t_order s,t_order_rel rwhere r.order_id = s.id and r.type = 1 and r.share_code = '我刚刚分享的订单编码'group by r.share_code) bwhere a.share_code = b.share_code and a.type = 1首先，咱们发现，间接 EXPLAIN 这个 SQL 也很慢，也就是可能某些子查问被理论执行了导致。所以，第一步咱们先将其中的子查问拆解进去，逐渐剖析，即： select count(distinct r.user_id) user_count,count(distinct r.order_id) order_count,max(s.rewarded_amount),r.share_codefrom t_order s,t_order_rel rwhere r.order_id = s.id and r.type = 1 and r.share_code = '我刚刚分享的订单编码'group by r.share_codeEXPLAIN 这个 SQL，执行很快，咱们发现后果是： ...

之前我有一篇文章，介绍了分布式事务最经典的七种解决方案，这里咱们从业务需要的角度，依据不同的业务场景，给出最适宜的解决方案。 当咱们采纳服务/微服务架构，对业务进行分拆解耦后，原先在一个单体内，应用本地数据库保障ACID的数据批改，因为跨了多个服务，就不再实用了，就须要引入分布式事务来保障新的原子性。 因为分布式事务计划，无奈做到ACID的保障，没有一种完满的计划，可能解决掉所有业务问题。因而在理论利用中，会依据业务的不同个性，抉择最适宜的分布式事务计划。 业务分类上面是常见的几种业务分类，以及适宜的解决方案介绍 多个微服务组合成原子操作有一类业务场景是须要把多个微服务组合成原子操作：假如您有一个流动业务，用户点击支付按钮后，会支付一张优惠券，和一个月的会员。优惠券和会员别离属于不同的服务，须要都被调用，不心愿呈现一个服务调用胜利，另一个因为网络或者其余故障导致没有胜利。 这个场景适宜可靠消息计划，能够应用rocketmq、rabbitmq等，发送给音讯队列的音讯，肯定要等收到队列接管确认，再返回应用程序。 本地事务+多个微服务组合为原子操作有一类业务与前一种业务状况相似，但有一些差异：假如您有一个新用户注册胜利后，支付一张优惠券和一个月会员。如果注册不胜利，不心愿调用支付；只有注册胜利才支付。 这种状况，适宜本地音讯计划，或者事务音讯计划。这两种计划都能保障本地事务和音讯的原子性。 订单类对一致性要求较高的业务订单交易类业务，波及资金、库存、优惠券等多个服务，实现一个订单，须要相干的各个服务组合成一个整体可回滚的事务。如果订单进行过程中金额先扣减，后续因为库存不够只能退款，把金额弥补加回来。在这个过程中用户看到了金额缩小，又金额变回来，体验很差。个别这类业务都会先冻结资金，如果订单能胜利，在扣减资金，不能胜利，则冻结资金，这样可能让资金信息对用户更敌对。 这种场景适宜TCC计划，能够在TCC的Try中冻结资金，Confirm中扣减资金，Cancel中冻结资金 一致性要求不高的可回滚业务如果业务对事务中的一致性要求不高，容许用户看到中间状态，例如用户的积分数据等。 这种模式实用SAGA模式，SAGA比照与TCC，只有正向操作和逆向弥补操作，会更加简略 耗时较久的全局事务耗时较旧的全局事务适宜可靠消息和SAGA，不适宜TCC和XA，因为大多数的XA和TCC实现，为了不便用户灵便的定义事务，通常把事务的进度保留在应用程序，一旦事务进行中应用程序解体，无奈往前进行下一步，只能回滚。 SAGA和可靠消息，把事务进度保留在数据库或音讯零碎中，任何一个组件长期的失败，都能够重试。其中如果整个事务是须要回滚的，那么适宜SAGA，不须要回滚的，适宜可靠消息 并发度较低的业务如果业务并发度不高，事务有须要反对回滚，那么适宜XA计划。XA计划，除了并发不高，也还须要本地数据库能反对XA接口。这个计划的长处是，应用上较简略，比拟靠近本地事务 实际下面介绍完各种业务类型，以及适宜的事务计划，通常状况下，您须要抉择适合的开源我的项目来施行技术计划。在分布式事务畛域，利用比拟宽泛的有DTM、SEATA、RocketMq 其中seata用Java开发，反对Java语言的接入，反对TCC、SAGA、XA、AT(相似XA，性能更高，但有脏回滚) RocketMq用Java开发，反对各类语言的接入，仅反对可靠消息、事务音讯模式 这里重点介绍DTM，它用GO开发，基于HTTP协定，反对多种语言接入，反对TCC、SAGA、XA、可靠消息、事务音讯模式。 可靠消息例子咱们拿第一个最简略的业务场景“多个微服务组合成原子操作”来看DTM是如何解决问题的 假如支付优惠券和会员的处理函数别离是：ObtainCoupon和ObtainVip，那么解决支付逻辑的处理函数（用Go做示例）只用这么写： msg := dtmcli.NewMsg(DtmServer,gid). Add(Busi+"/ObtainCoupon", req). Add(Busi+"/ObtainVip", req) err := msg.Submit()dtm收到客户端提交的音讯后，会保障ObtainCoupon和ObtainVip被调用，如果任何一个呈现失败，会一直重试，直到胜利。 如果您采纳的是rocketmq计划，那么您须要做一下几个步骤： 发送"支付"的音讯给队列生产"支付”的音讯，而后调用ObtainCoupon和ObtainVip，而后确认音讯已胜利生产比照dtm和rocketmq的计划，dtm仅须要简略的几行代码即可（dtm也提供http的接口，能够用任何语言间接发http申请），清晰简略。而rocketmq计划，波及较多队列的常识，要做的工作较多 SAGA例子假如咱们有一个积分兑换课程的业务，一方面积分不属于十分外围的资产，另一方面兑换课程可能呈现课程已领有权限，则须要回滚，因而该业务属于“一致性要求不高的可回滚业务“。 咱们采纳SAGA计划来解决这个问题，来看看DTM的解决形式，代码大抵如下： saga := dtmcli.NewSaga(DtmServer, gid). Add(Busi+"/AdjustIntegral", Busi+"/AdjustIntegralRevert", req). Add(Busi+"/AuthCourse", Busi+"/AuthCourseRevert", req) saga.WaitResult = true err := saga.Submit()dtm收到客户端提交的saga事务之后，会按顺序调用AdjustIntegral，AuthCourse，如果函数返回谬误要求回滚，dtm则会调用AuthCourseRevert，AdjustIntegralRevert进行回滚。 如果您没有采纳dtm计划，那么您能够采纳SEATA的SAGA，波及比拟多的背景常识，接入较简单。 更多的例子您能够拜访https://github.com/yedf/dtm ，外面有很多的分布式事务例子 多种模式并存如果您的理论我的项目，波及分布式事务的场景较多，可能须要应用SEATA+Rocketmq，会比较复杂。而DTM提供了一站式的解决方案，对常见的各种业务场景都提供了便捷的反对。 小结dtm作为一个新衰亡的分布式事务框架，提供了弱小的性能，以及简略易用的接口，极大的简化了微服务架构下，分布式事务的应用。 上面是dtm与seata的次要个性比照： 个性DTMSEATA备注反对语言Golang、python、php、c# 及其他Javadtm可轻松接入一门新语言异样解决子事务屏障主动解决手动解决dtm解决了幂等、悬挂、空弥补TCC事务✓✓ XA事务✓✓ AT事务✗✓AT与XA相似，性能更好，但有脏回滚SAGA事务简略模式状态机简单模式dtm的状态机模式在布局中事务音讯✓✗dtm提供相似rocketmq的事务音讯通信协议HTTPdubbo等协定，无HTTPdtm后续将反对grpc类协定dtm的我的项目地址为https://github.com/yedf/dtm ，欢送大家拜访、试用、点亮star

前言@TOC本文将按以下程序探讨SQL中应用的各种运算符： 本文将按以下程序探讨SQL中应用的各种运算符： 什么是运算符？运算符的分类：算术运算符比拟运算符逻辑运算符 什么是运算符？SQL运算符是SQL语句的WHERE子句中用来执行算术、逻辑和比拟操作的保留关键字。运算符在SQL语句中充当连接词，以满足语句中的多个条件。 运算符的分类：算术运算符这些运算符用于执行加法、乘法、减法等运算。 例子： SELECT 40 + 20; SELECT 40 - 20; SELECT 40 * 20; SELECT 40 / 20; SELECT 40 % 20;输入： 60 20 800 2 0比拟运算符这些运算符用于执行等于、大于、小于等操作。 例子： 为了更好地了解，我将思考下表来执行各种操作。 例子（等于）： SELECT * FROM StudentsWHERE Age = 20;输入： 例子（大于）： SELECT * FROM studentsWHERE Age > 23;输入： 例子（小于等于）： SELECT * FROM studentsWHERE Age <= 21;输入： 例子（不等于）： SELECT * FROM studentsWHERE Age <> 25;输入： ...

在公司加班到八点，此为背景。加班起因是上线，解决线上数据库存在反复数据的问题，发现了程序的bug，很好解决，有点问题的是，修改线上的反复数据。 线上库有6个表存在反复数据，其中2个表比拟大，一个96万+、一个30万+，因为之前解决过雷同的问题，就间接拿来了上次的Python去重脚本，脚本很简略，就是连贯数据库，查出来反复数据，循环删除。 emmmm，然而这个效率嘛，切实是太低了，1秒一条，反复数据大概2万+，预估工夫大概在8个小时左右。。。 自觉依附前人的货色，而不去本人思考是有问题的！总去想之前怎么能够，当初怎么不行了，这也是有问题的！我发现，最近的确状态不太对，失去了摸索和求知的欲望，明天算是一个警醒，颇有误入歧途的感觉。 言归正传，上面具体介绍去重步骤。 CREATE TABLE `animal` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(20) DEFAULT NULL, `age` int(11) DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;INSERT INTO `pilipa_dds`.`student` (`id`, `name`, `age`) VALUES ('1', 'cat', '12');INSERT INTO `pilipa_dds`.`student` (`id`, `name`, `age`) VALUES ('2', 'dog', '13');INSERT INTO `pilipa_dds`.`student` (`id`, `name`, `age`) VALUES ('3', 'camel', '25');INSERT INTO `pilipa_dds`.`student` (`id`, `name`, `age`) VALUES ('4', 'cat', '32');INSERT INTO `pilipa_dds`.`student` (`id`, `name`, `age`) VALUES ('5', 'dog', '42');指标：咱们要去掉name雷同的数据。 ...

作者：丁源 RadonDB 测试负责人 负责 RadonDB 云数据库、容器化数据库的品质性能测试，迭代验证。对包含云数据库以及容器化数据库性能和高可用计划有深入研究。 接上期《混沌工程工具 ChaosBlade Opeator 系列的入门篇》，本期将应用 ChaosBlade Opeator 工具，针对 Node 类资源的利用场景进行测试，测试场景包含： CPU 负载场景网络提早场景网络丢包场景kill 指定过程stop 指定过程| 试验环境测试对象基于 KubeSphere 平台的 RadonDB MySQL 容器化数据库进行测试。 RadonDB MySQL 部署阐明请参见 在 KubeSphere 中部署 RadonDB MySQL 集群。 环境参数集群名称主机类型CPUMemoryKubeSphere高可用类型8C16GRadonDB MySQL-4C16G测试环境部署实现后，即可从以下五个针对节点的场景做相应验证。 1. CPU 负载场景1.1 测试指标指定节点做 CPU 负载 80% 验证。 1.2 开始测试配置 yaml 测试参数值。 apiVersion: chaosblade.io/v1alpha1kind: ChaosBlademetadata: name: cpu-lodespec: experiments: - scope: node target: cpu action: fulllode desc: "increase node cpu load by names" #试验模型名称 matchers: - name: names value: - "worker-s001" #测试对象 node 名称 - name: cpu-percent value: "80" #节点负载百分比 - name: ip value:192.168.0.20 #节点负载百分比抉择一个节点，批改 node_cpu_load.yaml 中的 names 值。 ...

1. 隔离级别

1. redo log简述: 引擎层的redo log 是为了防止每一次更新操作都去查找记录再批改记录(随机读写),采纳WAL技术(Write-Ahead Logging写前日志)来转换成程序读写; 更新数据时,innoDB先把记录写到redo log中,并更新内存,这时便能够返回后果.同时在InnoDB闲暇的时候将操作记录更新到磁盘外面. InnoDB 的 redo log 是固定大小的，比方能够配置为一组 4 个文件，每个文件的大小是 1GB，那么总共就能够记录 4GB 的操作。从头开始写，写到开端就又回到结尾循环写，如上面这个图所示。 write pos 是以后记录的地位，一边写一边后移checkpoint 是以后要擦除的地位，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。write pos 和 checkpoint 之间是可记录闲暇空间,当write pos 追上 checkpoint时,须要暂停更新并将数据写入磁盘,而后推动下checkpoint 2. binlog简述: Server层的binlog记录的是原始逻辑的语句,属于归档日志

1. Mysql根本架构示意图! 1.1 连接器用户名明码登录胜利后,连接器会到权限表里查问登录账户的权限,再次批改权限只有新建的连贯才会应用新权限 show processlist //查看所有连贯 wait_timeout //客户端无反馈超时断开工夫,默认为8小时MySQL 在执行过程中长期应用的内存是治理在连贯对象外面的,这些资源会在连贯断开的时候才开释如果内存占用太大,会被零碎强行杀掉解决方案:1.定期断开链接,程序里判断下执行过一个占用大内存的查问后,断开链接再重连2.mysql5.7当前 ,能够执行mysql_reset_connection来初始化链接,复原到刚刚创立连贯的状态(此处存疑,有说此办法是C语言API调用) 2.查问缓存拿到执行语句时,mysql会去判断是否最近执行过,如果缓存缓存中有执行后果,间接返回(查问语句需放弃一致性,且数据没有被批改过)因为缓存生效性很强,故不举荐应用查问缓存,且8.0版本后无此性能通过调整参数,能够按需应用,默认查问不实用缓存,指定查问应用 query_cache_type=demand //设置按需加载mysql> select SQL_CACHE * from T where ID=10；//应用查问缓存3.分析器分析器会对sql语句做解析首先是词法剖析,辨认出字符串别离是什么,代表什么其次是语法分析,判断是否满足mysql语法 4.优化器优化器是在表外面有多个索引的时候，决定应用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连贯程序 5. 执行器首先校验下登录账户对表T是否具备查问的权限(优化器之前也会调用precheck验证权限),其次执行器会调用存储引擎接口扫描接口,并做扫描行数累加(rows_examined)

作者：丁源 RadonDB 测试负责人 负责 RadonDB 云数据库、容器化数据库的品质性能测试，迭代验证。对包含云数据库以及容器化数据库性能和高可用计划有深入研究。 近日，国内多家网站同时产生短期服务不可用景象，一夜冲上圈内热搜。据官网回答，是因为局部服务器机房产生故障，导致网站无法访问。为了防止这种状况，进步零碎架构的可靠性，保障业务的连续性，心愿能在故障之前找到导致 “崩盘” 的缺口。 十多年前，国外的互联网公司就曾经在云化、分布式、微服务等前沿技术的应用过程中，遇到了相似的问题，并由此诞生了混沌工程。 什么是混沌工程？混沌工程即 Chaos Engineering[1]，被定义为 在分布式系统上进行试验的学科，目标是建设对系统抵挡生产环境中失控条件的能力以及信念。混沌工程属于一门新兴的技术学科，是一种进步技术架构弹性能力的简单技术手段。最早由 Netflix 技术部门创立了名为 Chaos Monkey 的我的项目，通过随机性测试，来检测零碎架构的衰弱状况，并设计足够的预案来应答可能到来的新一轮故障。 随着云化技术的倒退和云原生(Cloud Native)的概念的提出，混沌工程的反软弱哲学思想，也引入了云原生体系，可简略高效地为零碎进步容错能力。 什么是 ChaosBlade Operator？ChaosBlade[2] 是阿里巴巴开源的一款遵循混沌工程原理和混沌试验模型的试验注入工具，帮忙企业晋升分布式系统的容错能力，并且在企业上云或往云原生零碎迁徙过程中业务连续性保障。 而ChaosBlade Operator[3] 是 Kubernetes 平台试验场景的实现，将混沌试验通过 Kubernetes 规范的 CRD 形式定义，很不便的应用 Kubernetes 资源操作的形式来创立、更新、删除试验场景，包含应用 kubectl、client-go 等形式执行，而且还能够应用上述的 chaosblade cli 工具执行。 把试验定义为 Kubernetes CRD 资源，将试验模型中的四局部映射为 Kubernetes 资源属性，完满将混沌试验模型与 Kubernetes 申明式设计联合在一起（依附混沌试验模型便捷开发场景，并联合 Kubernetes 设计理念）。 通过 kubectl 或者编写代码间接调用 Kubernetes API 来创立、更新、删除混沌试验，可清晰获取资源模拟实验的执行状态，实现 Kubernetes 故障注入的标准化。通过 Chaosblade cli 形式 可十分不便的执行 Kubernetes 试验场景，查问试验状态等。ChaosBlade 混沌试验模型与 Kubernetes CRD 的联合，实现 根底资源、应用服务、Docker 容器 等场景复用，不便 Kubernetes 场景的扩大。反对的场景目前反对的试验场景由以下三大类（继续更新中）： ...

作者：丁源 RadonDB 测试负责人 负责 RadonDB 云数据库、容器化数据库的品质性能测试，迭代验证。对包含云数据库以及容器化数据库性能和高可用计划有深入研究。 近日，国内多家网站同时产生短期服务不可用景象，一夜冲上圈内热搜。据官网回答，是因为局部服务器机房产生故障，导致网站无法访问。为了防止这种状况，进步零碎架构的可靠性，保障业务的连续性，心愿能在故障之前找到导致 “崩盘” 的缺口。 十多年前，国外的互联网公司就曾经在云化、分布式、微服务等前沿技术的应用过程中，遇到了相似的问题，并由此诞生了混沌工程。 什么是混沌工程？混沌工程即 Chaos Engineering[1]，被定义为 在分布式系统上进行试验的学科，目标是建设对系统抵挡生产环境中失控条件的能力以及信念。混沌工程属于一门新兴的技术学科，是一种进步技术架构弹性能力的简单技术手段。最早由 Netflix 技术部门创立了名为 Chaos Monkey 的我的项目，通过随机性测试，来检测零碎架构的衰弱状况，并设计足够的预案来应答可能到来的新一轮故障。 随着云化技术的倒退和云原生(Cloud Native)的概念的提出，混沌工程的反软弱哲学思想，也引入了云原生体系，可简略高效地为零碎进步容错能力。 什么是 ChaosBlade Operator？ChaosBlade[2] 是阿里巴巴开源的一款遵循混沌工程原理和混沌试验模型的试验注入工具，帮忙企业晋升分布式系统的容错能力，并且在企业上云或往云原生零碎迁徙过程中业务连续性保障。 而ChaosBlade Operator[3] 是 Kubernetes 平台试验场景的实现，将混沌试验通过 Kubernetes 规范的 CRD 形式定义，很不便的应用 Kubernetes 资源操作的形式来创立、更新、删除试验场景，包含应用 kubectl、client-go 等形式执行，而且还能够应用上述的 chaosblade cli 工具执行。 把试验定义为 Kubernetes CRD 资源，将试验模型中的四局部映射为 Kubernetes 资源属性，完满将混沌试验模型与 Kubernetes 申明式设计联合在一起（依附混沌试验模型便捷开发场景，并联合 Kubernetes 设计理念）。 通过 kubectl 或者编写代码间接调用 Kubernetes API 来创立、更新、删除混沌试验，可清晰获取资源模拟实验的执行状态，实现 Kubernetes 故障注入的标准化。通过 Chaosblade cli 形式 可十分不便的执行 Kubernetes 试验场景，查问试验状态等。ChaosBlade 混沌试验模型与 Kubernetes CRD 的联合，实现 根底资源、应用服务、Docker 容器 等场景复用，不便 Kubernetes 场景的扩大。反对的场景目前反对的试验场景由以下三大类（继续更新中）： ...

大家好，我是冰河~~ MySQL作为互联网行业应用最多的关系型数据库之一，与其收费、开源的个性是密不可分的。然而，很多小伙伴工作了很多年，只晓得应用MySQL进行CRUD操作，这也导致很多小伙伴工作多年后，想跳槽进入大厂，却在面试的时候每每碰壁。 问个简略的问题：select语句是如何在MySQL中执行的？ 这也是很多面试官喜爱问的问题，如果你连这个简略的问题都不能答复的话，那就要好好布局下本人的职业生涯了。 好了，明天咱们就一起来聊聊select语句是如何在MySQL中执行的。文章的次要内容如下。 频繁应用的select语句为了更好地贯通全文，这里先来列举一个最简略的select查问语句，例如：查问user表中id为1001的用户信息，应用上面的SQL语句进行查问。 select * from user where user_id = 1001;当咱们在MySQL的命令行中输出上述SQL语句时，这条SQL语句到底在MySQL中是如何执行的呢？接下来，咱们就以这条SQL语句为例，说说select语句是如何在MySQL中执行的。 MySQL逻辑架构在介绍select语句在MySQL中的执行流程之前，咱们先来看看MySQL的逻辑架构，因为任何SQL语句的执行都离不开MySQL逻辑架构的撑持。也就是说，SQL语句在MySQL中的执行流程与MySQL的逻辑架构是密不可分的。 在上图中，咱们简略的画了下MySQL的逻辑架构图，并且给出了逻辑分层和每层中各局部的性能。从逻辑上，咱们能够将MySQL粗略地分成三层：Server层、存储引擎层和系统文件层，而Server层中又能够分成网络连接层（连接器）和数据服务层（Server层）。 Server层中蕴含了连接器、查问缓存、分析器、优化器和执行器等MySQL的外围组成部分，另外，在Server层中还蕴含了所有的内置函数（比方：日期工夫函数、加解密函数、聚合函数、数学函数等），存储引擎、触发器、视图等等。 存储引擎层次要负责和系统文件层进行交互，存储引擎层自身是插件式的架构设计，反对InnoDB、MyISAM、Archive、Memory等存储引擎。在MySQL 5.5.5及当前的版本中，MySQL的默认存储引擎是InnoDB。 系统文件层次要负责存储理论的数据，将数据以文件的模式存储到服务器的磁盘上。 接下来，咱们就来说说一条select语句在MySQL的逻辑架构的每一部分到底是如何执行的。 连接器是如何受权的？首先，咱们先来看看在服务器命令行输出连贯MySQL的命令时，MySQL的连接器是如何进行验证的。比方，咱们在服务器的命令行输出了如下命令。 mysql -ubinghe -p执行“回车”后，输出binghe账户的明码，与MySQL进行连贯。此时，连贯的过程须要实现经典的TCP握手操作。之后，连接器就开始认证连贯的身份是否非法，最间接的就是验证用户名和明码是否正确。 如果用户名或者明码谬误，MySQL会提醒 Access denied for user 。如果用户名和明码正确，则连接器会到MySQL的权限表中查问以后连贯领有的权限。查问到权限之后，只有这个连贯没有断开，则这个连贯波及到的权限操作都会依赖此时查问到的权限。 换句话说，一个用户登录MySQL并胜利连贯MySQL后，哪怕是管理员对以后用户的权限进行了批改操作，此时只有这个用户没有断开MySQL的连贯，就不会受到治理批改权限的影响。管理员批改权限后，只有对新建的连贯起作用。 如果客户端连贯MySQL后，长时间没有执行任何操作，则连接器会主动断开与这个客户端的连贯。具体多长时间断开是由MySQL的参数wait_timeout管制的，这个值默认是8小时。咱们能够依据理论业务须要，自行调整这个参数的值，以使MySQL可能满足咱们的理论业务场景。 因为客户端与MySQL的连贯是比较复杂的，这个过程也是比拟耗时的，它会波及TCP的握手操作，还会查问以后连贯的权限信息等。往往在理论的工作过程中，咱们会应用数据库连接池的形式，将数据库的连贯缓存起来，这就意味着咱们是应用长连贯与MySQL进行交互的。 然而应用长连贯连贯MySQL也会有一个问题：那就是有时候会发现MySQL占用的内存涨得特地快，这是因为MySQL在执行的过程中，应用的长期内存是在连贯对象外面进行治理的。这些占用的资源只有在连贯断开的时候，才会被开释。如果连贯长时间不开释，就会呈现大量的长期内存占用内存空间。如果工夫久了，可能会导致占用过多的内存，从而被操作系统“毁灭”了，给人的感觉就是MySQL意外重启了。 咱们能够应用如下的计划来解决这个问题： 定期或者执行过一个比拟占内存的查问操作后，断开连接，当前再从新建设和MySQL的连贯。如果应用MySQL 5.7或更新的MySQL版本，能够通过执行mysql_reset_connection从新初始化MySQL的资源。从新初始化的过程不会从新连贯MySQL，也不会从新做权限的验证操作。查问缓存的作用是什么？登录MySQL后，客户端就会与MySQL建设连贯，此时执行select语句时，首先会到查问缓存中查问是否执行过以后select语句。如果之前执行过相应的select语句，则执行过的select语句和查问后果会以key-value的模式寄存在查问缓存中，其中，key是查问语句，value是查问的后果数据。 如果在查问缓存中没有找到相应的数据，则会继续执行后续的查问阶段。执行实现后，会将后果缓存到查问缓存中。后续的查问如果命中缓存，则间接返回查问缓存中的数据，性能还是挺高的。 然而，大多数时候我不太倡议小伙伴们开启查问缓存，为啥？起因很简略：查问缓存生效的频率是十分频繁的，只有对一个表进行更新操作，则这张表上所有的查问缓存都会被清空。 而且在MySQL 8.0中，间接删除了查问缓存的性能（冰河在看MySQL源码时，也证实了这一点）。 分析器对select语句做了什么？分析器次要是对select语句进行 词法剖析和语法分析 操作。 如果select语句没有命中缓存，则首先会由分析器对其进行“词法剖析”操作，此时，MySQL会辨认select语句中的每个字符串代表什么含意。 例如，MySQL会通过"select"关键字辨认出这是一个查问语句，也会把"user"辨认为"数据表名user"，把"id"辨认成"字段名id"。接下来，就要进行“语法分析了”，依据语法规定，判断select语句是否满足MySQL的语法。如果判断出输出的SQL语句不满足语法规定，则MySQL会提醒相应的错误信息。 优化器是如何优化select语句的？对select语句进行了词法剖析和语法分析后，还要通过优化器的优化解决能力执行。比方，咱们的select语句中如果应用了多个索引，则优化器会决定应用哪个索引来查问数据；再比方，在select语句中，有多表关联的操作，优化器会决定各表的连贯程序，数据表的连贯程序不同，对于执行的效率会大不相同，优化器往往会抉择应用查问效率高的连贯程序。 如果select语句通过优化器的优化之后，就会进入执行阶段了。 执行器如何执行select语句？进入执行阶段的select语句，首先，执行器会对以后连贯进行权限查看，最间接的形式就是查看以后连贯是否对数据表user具备查问权限。如果以后连贯对数据表user没有查问权限，就会返回没有权限的谬误。例如，会返回如下谬误。 ERROR 1142 (42000): SELECT command denied to user 'binghe'@'localhost' for table 'user'如果以后连贯具备对数据表user的查问权限，则会继续执行。首先会进行关上数据表的操作，此时优化器会依据创立表时应用的存储引擎，应用相应存储引擎的接口执行查问操作。这里，咱们举一个例子： 假如，咱们在id字段上没有建设索引，执行器执行的流程大抵如下所示。 （1）通过存储引擎读取数据表user的第一行数据，判断以后行的id值是否等于1001，如果不等于1001，则持续读取下一行数据；如果等于1001，则将以后行放入后果集中。 （2）持续通过存储引擎读取下一行数据，执行与（1）雷同的逻辑判断，直到解决完user表中的所有数据。 （3）解决完所有的数据后，执行器就会将后果集中的数据返回给客户端。 如果在id字段上有索引的话，执行的整体逻辑与id字段上没有索引大体一致。 ...

前言： 在学习 MySQL 的过程中，可能你理解过触发器的概念，不分明各位是否有具体的去学习过触发器，最近看了几篇对于触发器的文档，分享下 MySQL 触发器相干常识。 1.触发器简介触发器即 triggers ，它是与表无关的数据库对象，在满足定义条件时触发，并执行触发器中定义的语句汇合。它的执行不是由程序调用，也不是手工启动，而是由事件来触发，比方当对一个表进行操作（ insert，delete， update）时就会激活它执行。触发器常常用于增强数据的完整性束缚和业务规定等。 参考官网文档，触发器创立语法模板如下： CREATE [DEFINER = user] TRIGGER trigger_name trigger_time trigger_event ON tbl_name FOR EACH ROW [trigger_order] trigger_bodytrigger_time: { BEFORE | AFTER }trigger_event: { INSERT | UPDATE | DELETE }trigger_order: { FOLLOWS | PRECEDES } other_trigger_name触发器只能创立在永恒表上，不能对长期表或视图创立触发器。触发器的名称在单个数据库内是惟一的。参考下面创立语句，触发器创立有几点因素，上面简要阐明下： trigger_time：是触发动作工夫，能够是 BEFORE 或 AFTER ，示意触发器在要批改的每一行之前或之后激活。 trigger_event：批示激活触发器的操作类型。这些 trigger_event 值是被容许的： insert：只有向表中插入新行，触发器就会激活。例如 insert 、load data、replace 语句。update：更改表中某一行数据时激活触发器。例如 update 语句。delete：从表中删除某一行数据时激活触发器。例如 delete 和 replace 语句。表上的 DROP TABLE 和 TRUNCATE TABLE 语句不会激活此触发器，因为它们不应用 delete ，删除分区也不会激活 delete 触发器。trigger_body：是触发器激活时要执行的语句。如果要执行多个语句，可应用 BEGIN…END 复合语句构造。在触发器主体中，能够应用 old 和 new 来援用触发器中发生变化的记录内容。 ...

前言时刻：这是一个从零学习 MySQL 的笔记教程，从初学者的角度写笔记，更懂初学者。如果 你也想学习 MySQL ，那么接着往下看吧！ 上面开始介绍MySQL的装置教程，手把手带你。 本地环境： 零碎：windows10 64位 MySQ版本：5.7.19版本 学习课程：跟的是 B 站韩顺平老师的 MySQL 课程，韩老师最近辞职本人单干了，所以放了些收费的课程给本人减少名气，为起初的付费课程打下基础，嘿嘿我猜的，然而能学到货色就能够，果决给老师一键三连。 1、 下载 MySQL 软件：咱们进入 MySQL 官网，抉择喜爱的版本，这里老师举荐的是 5.7.19 版本，对于学习来说，其实各个版本都差不多，所以不用纠结，跟着做就好。 下载完这个压缩包后，将软件解压到一个不含中文门路的文件夹中，留神门路中肯定不要有中文，否则前面会有莫名 bug 。 2、增加到环境变量而后进入到解压后的 MYSQL 文件夹中，找到 bin 文件夹并复制该文件夹的门路。 关上管制面板-->零碎和平安-->（左边找到）零碎-->（右边找到）高级零碎设置-->（最下边找到）环境变量-->（上边用户变量栏找到）Path-->编辑，而后点新建，将之前复制的bin目录的门路粘贴进去，点击确定即可。 3、初始化MySQL（1）新建一个 MySQL 配置文件：my.ini 进入到 MySQL 的装置文件夹中，新建一个 my.ini 文件，写入以下内容。留神上面的门路须要替换成本人本地的 MySQL 装置门路，一般来说复制的门路中的分隔符是一个反斜杠 \，但在MYSQL的初始化中会把 \ 本义，导致初始化失败，所以须要将门路中的反斜杠替换成两个 反斜杠 \ 。 [client]port=3306default-character-set=utf8[mysqld]#设置MySQL的装置目录basedir=C:\\software\\MySQL\\mysql-5.7.19-winx64#设置MySQL的数据目录datadir=C:\\software\\MySQL\\mysql-5.7.19-winx64\\dataport=3306character_set_server=utf8#跳过安全检查，不必明码也能够登录，一会设置管理员明码后，肯定要引掉。skip-grant-tables（2）新建一个 data 文件夹： （3）运行命令窗口： 首先以管理员的身份运行 cmd 命令提示符窗口，而后进入到命令窗口。 输出以下命令： 装置 mysql ： mysqld -install 初始化 mysql：mysqld --initialize-insecure --user=mysql ...

先上图 根底测试create table demo (id int primary key auto_increment not null,name varchar(20) default ''); insert into demo (name) values ("zhansan"),("wangwu"); 以下两种谬误都是在分析器执行阶段报进去的

Mariabd平安配置向导**1.装置完mariadb-server后，运行mysql_secure_installation去除安全隐患mysql_secure_installation会执行几个设置：** 为root用户设置明码删除匿名账号勾销root用户近程登录删除test库和对test库的拜访权限刷新受权表使批改失效[root@xuegod63 ~]# mysql_secure_installation #进入平安配置向导**通过这几项的设置可能进步MySQL库的平安。倡议生产环境中MySQL装置实现后肯定要运行一次mysql_secure_installation，具体步骤请参看上面的命令：** NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MySQLSERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!In order to log into MySQL to secure it, we'll need the currentpassword for the root user. If you've just installed MySQL, andyou haven't set the root password yet, the password will be blank,so you should just press enter here.Enter current password for root (enter for none): #首次运行间接回车，因为root用户没有明码OK, successfully used password, moving on…Setting the root password ensures that nobody can log into the MySQLroot user without the proper authorisation.Set root password? [Y/n] Y #是否设置root用户明码,输出YNew password: 123456 #新密码123456Re-enter new password: 123456Password updated successfully!。。。Remove anonymous users? [Y/n] Y #是否删除匿名用户,生产环境倡议删除，所以间接回车或 Y... Success!Normally, root should only be allowed to connect from 'localhost'. Thisensures that someone cannot guess at the root password from the network.Disallow root login remotely? [Y/n] Y #是否禁止root近程登录,依据本人的需要抉择Y/n并回车,倡议禁止... Success!By default, MariaDB comes with a database named 'test' that anyone canaccess. This is also intended only for testing, and should be removedbefore moving into a production environment.Remove test database and access to it? [Y/n] Y #是否删除test数据库,间接回车或Y - Dropping test database...... Success!- Removing privileges on test database...... Success!Reloading the privilege tables will ensure that all changes made so farwill take effect immediately.Reload privilege tables now? [Y/n] Y #是否从新加载权限表，间接回车... Success!Cleaning up...All done! If you've completed all of the above steps, your MariaDBinstallation should now be secure.Thanks for using MariaDB!如果不做平安配置，设置root明码 ...

《MySQL必知必会》读书笔记前言 第一次残缺的技术书籍的读书笔记，这本书200多页，看起来轻松又简略，当然因为内容自身十分根底的缘故，这本书我也只是翻了一遍，等接触到具体内容的时候能够拿起来再看看，看这本书的意义就在于此。 资源链接：链接：https://pan.baidu.com/s/1RnsH_-HjTCgKOKlxWg4dTg 提取码：6nta --来自百度网盘超级会员V6的分享举荐语 这本书非常的根底，适宜没有学过数据库的小白学习，当然不要过于纠结版本个性，只须要理解根本的sql操作即可。这本书能够让老手疾速上手mysql，十分典型的一本入门指导书。 对于曾经相熟mysql的人，这本书能够作为回顾应用，包含mysql外面根本内容以及须要学习的重点，后续介绍的触发器，存储过程，游标等内容可能可能会感觉平时工作用的不多然而其实也是非常重要的内容。 当然这本书不倡议购买实体书。买个电子版的翻一翻还是不错的，有种疾速学会一本书所有内容的畅快感。 集体评估 这本书从新手入门的角度能够说是一本很适宜的书，讲的内容是十分根底然而能够让你刚好入门的水平，翻起来也不会非常的苦楚，同时在内容的编排方面也是典型的由浅入深，这本书 没有什么废话，根本就是间接用案例通知你sql如何应用，对于老手来说是特地敌对的一本书。 另外阐明一下书中介绍的mysql5.1是十分老的版本，所以旧版本的个性齐全不倡议深刻学习，而是应该多看看mysql5.5之后的版本新个性，当然如果公司有遗留我的项目应用低版本的mysql，这里有些内容还是有肯定的参考价值的（仅实用于mysql5.1）。 内容概要 实操大于实践的一本书，这里提一些日常比拟容易疏忽的一些点： 尾空格的like 一条记录存储的格局如下，如果此时写入一条如下的查问条件like %anvil是不会匹配上第二条记录的，因为尾部空格的缘故，导致第二条记录是检索不到的，这里的解决办法是能够应用trim()函数或者写成%anvil%的形式： prod_id | prod_namea1 2 ton anvila2 4 ton anvil[空格]a3 1 ton anvil 其实这种谬误只有入库的时候数据进行严格的解决个别不会出什么问题，这里引申一下java中一个还算比拟容易犯的谬误： @Testpublic void test() { Map<String, Object> map = new HashMap<>(); map.put(" a1", "test1"); map.put("a3", "test3"); map.put("a2", "test2"); System.out.println(map.get("a1"));}/*运行后果：null*/ 不晓得碰到这种BUG的人有多苦楚，集体没有碰到过，然而已经给共事排查问题的发现了相似的状况，当然不是这么显著的错，而是因为前端传递的时候，json当中的key后面多了一个空格，也是因为这个空格，导致花了好几个小时才排查进去！这里心愿读者引以为戒，在编写相似代码时候严格查看有没有手贱多敲空格。 and和or的优先级问题： 有时候咱们会写出这样的sql： select * from t_user where name = 'xxx' or age > 18 and email like '@qq.com' 这里依据优先级的就近匹配准则，百分之百的会呈现意想不到的状况，因为此时mysql会误认为是上面这样的状况，进行查问之后，数据必定和咱们料想的or条件不统一了： ...

本地缓存缓存作为进步性能一种可选形式最先被思考，其具备简略、易用、高效的个性。在联合Java8之后的新个性 Lambda 表达式，能够轻松实现相似 Join、Groupby、Sort 操作。 这个形式也是我首选的解决形式。其本质是将本来数据库解决压力转嫁到服务器内存中，鉴于当初绝大多数公司都是分布式架构，服务性能相比单体架构有显著的晋升，反观，MySQL 在分布式时代经常成为性能的瓶颈，从而衍生出 TiDB 这类分布式数据库。 但缓存形式存在显著的短板—不适宜大数据量操作，容易导致 Out Of Memory。但我有一个大胆，其实也称不上大胆想法，咱们是不是能够实现 Spark SQL 一样在内存中构建表构造，处理表相干操作呢？如果有机会的话，再跟大家进行分享。 冗余退而求其次，冗余也是经常被采纳的形式，但其往往存在实时性和准确性的问题，因此只适宜容许不精准和对变动宽容的场景。从实质来说，我认为冗余也是缓存的一种实现形式，如果这个问题，不局限于本身数据库去实现冗余，咱们能够尝试应用 Redis 实现实时性的冗余，把所有服务都须要的用户手机号码信息放到 Redis 中，其余服务通过间接调用 Redis 获取数据，或者用户核心提供一系列查问 API 供其余业务线服务应用。而且 Github 上存在一个 rediSQL 开源我的项目，反对 Redis 数据通过 SQL 形式实现数据查问，当初曾经孵化成为 zeeSQL，这样是不是能够更加 Think Big 了呢。 Join 查问尽管本文曾经应用大量的篇幅表明不违心在数据库层面解决 Join 查问，但还是存在大量场景选用数据库 Join 操作才是比较简单高效的形式。因此，当不得不抉择该种形式时，咱们又有哪些进步查问性能的形式呢？ 很多时候不是产品不够好，而是应用的人不会用。Join 查问也是一样，如果从实现原理理解，从根上对其有深刻的理解，能力施展其真正的作用。上面是我的一些摘记，与大家分享： 本文以 Left Join 作为示例阐明，其余 Join 相似。前提： 被 Join 表 关联字段须要存在索引两表的关联字段须要编码格局一样，否则索引会生效优化： 依据理论状况抉择适合的Join算法（NLJ 和 BNL）尽量应用 hash join（8.0.18 ）依据业务场景抉择 Join 类型，尽可能抉择 Join，而防止应用 Left Join 、Right Join、Full Join关联条件存在 NULL 状况，在 where 语句中增加排除为空的条件不应用子查问结合实际业务场景抉择适合 Join 计划答疑： ...

前言本文对 Elasticsearch 7.13 无效创立工夫（create_time）没找到好的实现形式如果入库的数据不会更新，文中的 create_time 可等同于 update_timeupdate_time 示例创立 Ingest pipelines（script、date）PUT _ingest/pipeline/add_update_time{ "processors": [ { "script": { "lang": "painless", "source": """DateFormat df = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssX"); df.setTimeZone(TimeZone.getTimeZone("Asia/Shanghai")); Date date = new Date(); ctx.update_time = df.format(date);""" } } ]}创立索引，并设置默认 pipelinePUT my_index{ "settings": { "index.default_pipeline": "add_update_time" }}插入数据POST my_index/_doc/1{ "title": "nothing"}查看 mappingGET my_index/_mapping{ "my_index" : { "mappings" : { "properties" : { "title" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } }, "update_time" : { "type" : "date" } } } }}查问数据GET my_index/_search{ "query": { "range": { "update_time": { "time_zone": "+08", "gte": "2021-07-28T16:00:00", "lte": "now" } } }}{ "took" : 0, "timed_out" : false, "_shards" : { "total" : 1, "successful" : 1, "skipped" : 0, "failed" : 0 }, "hits" : { "total" : { "value" : 1, "relation" : "eq" }, "max_score" : 1.0, "hits" : [ { "_index" : "my_index", "_type" : "_doc", "_id" : "1", "_score" : 1.0, "_source" : { "update_time" : "2021-07-28T18:03:35+08", "title" : "nothing" } } ] }}本文出自 qbit snap

配置流程如下： 更新零碎源下载mysql，并批改明码批改mysql配置文件设置root近程登录权限一、更新零碎源sudo apt-get update; // 更新源的sources.list文件sudo apt-get upgrade; // 下载须要更新的源二、下载mysql，并批改明码1、装置mysql sudo apt-get install mysql-server2、登录mysql sudo mysql -u root -p // 第一次的明码为登录零碎的明码3、批改明码在应用mysql的时候须要特地留神mysql的版本，因为不同版本的mysql，它的一些指令是不一样的 use mysql; // 切换到mysql数据库，因为用户信息是保留在mysql数据库外面的ALTER user 'root'@'localhost' IDENTIFIED BY '新密码'; // 扭转root的明码flush privileges; // 刷新exit; // 退出mysql三、批改mysql配置文件在批改配置文件之前能够输出 netstat -aptn 查看监听的 mysql 的 3306 端口容许拜访IP地址 能够发现容许拜访的ip地址为 127.0.0.1 ，即只容许本地拜访。 批改mysql配置文件 mysql配置文件地位： /etc/mysql/mysql.conf.d/mysqld.cnf不同版本的mysql的配置文件可能不同，但都会在 etc/mysql 这个文件夹上面将mysqld.cnf文件外面的 bind-address 批改为 0.0.0.0 重启mysql，使其从新加载配置文件 sudo service mysql start // 启动mysqlsudo service mysql stop // 进行mysqlsudo service mysql restart // 重启mysql重新启动mysql之后，再次应用 netstat -aptn 发现原来3306端口容许拜访的ip地址变成了0.0.0.0，即容许所有ip地址拜访3306端口 ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 MySQL 和 TIDB 有80%的语法兼容，大部分场景下能够混用，MySQL 能够做 TIDB 的上游，TIDB 也能够做 MySQL 的上游，明天来分享下两种数据库之间数据如何逻辑全量导入导出。 一般来讲，逻辑导入导出格局有两种，一种是 CSV 、TSV 等格局，另外一种就是 SQL 语句的格局。 这里我用两张表作为导入导出示例，一张是表 t1 ，另外一张是表 t1_csv ，记录都有 200W ; TIDB 版本为3.1.2，MySQL 版本为 5.7.31。 第一局部，TIDB 为上游导出数据，MySQL 作为上游导入数据。TIDB 数据库自身不反对表记录间接导出为 CSV 文件，不过 TIDB 有额定的工具来导出(3.0 版本 mydumper 来导出 SQL 文件、4.0 版本有 dumpling 来导出 SQL 和 CSV )。 别离用 dumper 导出表 t1 ，后果为 SQL 文件；dumpling 导出表 t1_csv 后果为 CSV 文件；这两个导出程序和 mysqldump 一样，须要连贯在线数据库。 ...

MySQL 主从复制主从复制原理 主从复制的根本准则每个 slave 只有一个 master每个 slave 只能有一个惟一的服务器 ID每个 master 能够有多个 salve一主一从常见配置mysql 版本统一且后盾以服务运行主从都配置在 [mysqld] 节点下，都是小写主数据库配置，批改 /etc/my.cnf 配置文件主服务器惟一 ID 必须server-id=1启用二进制日志 必须# mysqlbin 为官网举荐的文件名log-bin=本人的本地门路/mysqlbinlog-bin=/var/local/mysql-server5.7/data/mysqlbin启用谬误日志 可选# mysqlerr 为官网举荐的文件名log-err=本人的本地门路/mysqlerrlog-err=/var/local/mysql-server5.7/data/mysqlerr根目录 可选basedir="本人的本地门路"basedir="/var/local/mysql-server5.7/"长期目录 可选tmpdir="本人的本地门路"tmpdir="/var/local/mysql-server5.7/"数据目录 可选datadir="本人的本地门路"datadir="/var/local/mysql-server5.7/"主机，读写都能够 可选read-only=0设置不要复制的数据库 可选binlog-ignore-db=mysql设置须要复制的数据库 可选binlog-do-db=须要复制的主数据库名字残缺的配置为： [mysqld]port=3306server-id=1log-bin=/var/local/mysql-server5.7/data/mysqlbinlog-err=/var/local/mysql-server5.7/data/mysqlerrbasedir="/var/local/mysql-server5.7/"tmpdir="/var/local/mysql-server5.7/"datadir="/var/local/mysql-server5.7/"read-only=0binlog-ignore-db=mysql从数据库配置，批改 /etc/my.cnf 配置文件从服务器惟一 ID 必须# 默认配置文件中将此行正文掉了，能够间接勾销正文即可，如果没有找到，也能够本人增加server-id=2启用二进制日志 必须# 默认配置文件中将此行正文掉了，能够间接勾销正文即可，如果没有找到，也能够本人增加log-bin=mysql-bin主从机器都敞开掉防火墙在主数据库上建设账户并受权 slave# 从数据库用于拷贝的账号为：alex# 从数据库用于拷贝的明码为：123456# 从数据库所在服务器的 ip 地址为：127.0.0.12grant replication slave on *.* to 'alex'@'127.0.0.12' identified by '123456';# 刷新权限flush privileges;# 查问 master 的状态，并记录下 File 和 Position 的值show master status;在从数据库上配置# 主数据库所在服务器的 ip 地址为：127.0.0.1# 在主数据库建设用于从数据库拷贝的账号为：alex# 在主数据库建设用于从数据库拷贝的明码为：123456# 主数据库中查问出的 File 值为：mysqlbin.000035# 主数据库中查问出的 Position 的值为：341change master to master_host='127.0.0.1', master_user='alex',master_password='123456',master_log_file='mysqlbin.000035',master_log_pos=341; # 启动从服务器复制性能start slave;# 执行以下命令，当 Slave_IO_Running: Yes 和 Slave_SQL_Running: Yes 同时为 yes 时，示意主从复制曾经买通了show slave status\G测试主从复制是否胜利？ ...

问题：max函数中类型不是数值时，比方字段类型是varcher类型，max(9)比max(10)大？例：查问最大年龄，两个人，一个age = 9，另外一个age = 10。 sql： select max(age) from t_user;查问后果： 替换函数：cast(age as UNSIGNED INTEGER) sql： select max(cast(age as UNSIGNED INTEGER)) from t_user;这里的UNSIGNED 能够为： 浮点数 : DECIMAL 整数 : SIGNED　无符号整数 : UNSIGNED 二进制，同带binary前缀的成果 : BINARY 字符型，可带参数 : CHAR() 日期 : DATE 工夫: TIME 日期工夫型 : DATETIME

前言： 常常有小伙伴问我：MySQL 应该怎么学？小白如何入门？我在想，我过后是如何学习 MySQL 的，是否能够给到初学者几点倡议，本篇文章，笔者将以本人的教训及认知，谈谈我对老手学习 MySQL 的倡议。 搭建好环境，弄清根底概念。学习 MySQL ，首先要有个本人的环境，能够在本人本机或某台虚构机上安装下 MySQL ，倡议最好应用 Linux 零碎，体验下残缺的装置步骤，尽量了解分明每个步骤的作用。 接下来，你要弄清一些根底概念了，比方什么是库、表、字段、索引啊等等。说到这里，就简略介绍下一些常见的根底概念吧： 实例（instance）：指的是操作系统上的一组过程/线程和内存的汇合。比方咱们在本机装置好 MySQL ，那就代表着咱们本地有一套 MySQL 实例。数据库（database）：指的是文件系统上的一组文件，等同于 schema 。表（table）：表是数据的矩阵。在一个数据库中的表看起来像一个简略的电子表格。字段（column）：字段是指数据表的列，表由字段组成。索引（index）：索引是对数据库表中一列或多列的值进行排序的一种构造。相似于书籍的目录。主键（primary key）：主键是惟一的。一个数据表中只能蕴含一个主键。记录（record）：指数据，一行可称为一条记录。服务端（server）：指 MySQL 服务所在端，个别可了解为 MySQL 所在主机。客户端（client）：连贯数据库局部，比方 Navicat、jdbc 程序都可称为客户端。数据类型（Data Types）：又称字段类型，即定义某个字段所能存储的类型，如 int 、varchar 等。字符集（character set）：字符是各种文字和符号的总称，字符集是多个字符的汇合。学习根底操作，相熟命令标准。理解过根底概念后，倡议你逐渐学习一些根底操作，比方如何建库、建表、插入数据、批改数据、删除数据、查问数据等等。这部分次要练习的是 DDL 及 DML 语句。倡议大家肯定要依照命令标准来，比方插入数据时指定字段名，建表时指定字符集。 你能够应用 MySQL 命令行来执行 SQL ，也能够应用可视化客户端，要害是要明确你每步操作的意义及每条 SQL 的作用。 理解报错内容，学会应用搜索引擎。在执行 SQL 或连贯数据库过程中，难免会遇到各种报错，这个时候倡议你先认真看下是否存在书写及标点谬误，要害还是要注意报错内容，依据报错内容大概率就能发现问题所在，比方 Access denied for user xxx 、able 'xxx' doesn't exist ... 有些看到报错内容很显著就能够发现问题，若切实找不到问题，能够复制报错内容到搜索引擎查找下，要置信不只你一个人遇到过这类谬误。 依据你的岗位，有目标的进行学习。在互联网行业，不同岗位的小伙伴可能都会用到 MySQL ，但不同岗位员工学习 MySQL 的侧重点却不尽相同。例如做数据分析的同学可能平时写查问 SQL 比拟多，开发同学更偏重程序逻辑如何与数据库交互，DBA 同学可能偏重在数据库高性能高可用方面。所以倡议你依据本人的需要，有侧重点的进行学习。 要零碎、循序渐进的学习。市面上对于 MySQL 的学习材料有很多，倡议选取一个零碎的材料进行学习，能够是一本书、一个网站等。切记不要这个材料看一点又转向另外一些材料。 ...

问题：mybatis-generator报错:generate (default-cli) on project XXX <properties> resource xx.properties does not exist 起因： mybatis-generator.xml文件中无奈找到数据源的properties文件 解决： 个别都是用完pom.xml中配置了： <resources> <!--打包指定目录中的xml文件(在java目录寄存xml时须要配置)--> <resource> <directory>src/main/java</directory> <includes> <include>**/*.xml</include> </includes> </resource> </resources>导致mybatis-generator.xml默认查找不到数据源的properties文件，把这个配置正文掉就好

关注我，更多精彩文章第一工夫推送给你 MySQL的在文件中是如何存储的？ 答：数据是存在页中的，一页的大小是 16kb, 一个表由很多的页组成，这些页组成了 B+树。 MYSQL内存中，多个这样的数据结构组成一个双向链表 SQL语句是如何执行的呢？MySQL的逻辑架构图如下所示： 当咱们须要更新一条数据时，是须要先从磁盘中取出来，更新后再长久化到磁盘中吗？ 答：不是的，如果这样的话，一条 SQL 的执行过程太慢了，因为对一个大磁盘文件的读写操作是要消耗大量工夫的。 所以真正的执行过程是，当须要更新或者读取某条数据的时候，会把对应的页加载到内存中的 Buffer Pool 缓冲池中（默认为 128m 当然为了进步零碎的并发度，你能够把这个值设置大一点） 当更新数据的时候，如果对应的页在 Buffer Pool 中，则间接更新 BP中的数据页即可，如果不在BP中，才会加载磁盘中对应的页到BP中，而后更新，此时BP中的页则跟磁盘中的页不统一，称为脏页。这些脏页是要被刷回磁盘中的。 ①. BP不够用了，要给新加载的页腾地位，所以会利用改良的 LRU 算法，将最近最久未应用的脏页刷回磁盘。 ②. 后盾线程会在MySQL闲暇的时候，将脏页刷回到磁盘中 ③. redolog写满时 ④. 数据库敞开时会将所有脏页刷回到磁盘中 redo log问：如果脏页没有刷回，数据库宕机了怎么办？批改不就失落了吗？ 这就要说道 redo log了(重做日志文件，次要是记录数据物理页的批改)，内存中所做的批改都是写到 redo log buffer中的，这是内存中的一个缓冲区，用来存储redo 日志。 Redo log的大小是固定的，比方能够配置一组 4 个文件，每个文件的大小是 1G ，总大小就是 4 G ，从头开始写，写到开端就从头再次开始写，循环程序写的效率高于随机写。 write pos是以后要写的地位，checkpoint是要擦除的地位，擦除前要把对应的脏页刷回到磁盘中。他两个之间的绿色区域是能够写的地位。当零碎能反对的并发比拟低的时候，能够看看对应的 redo log 是不是设置的太小了。太小的话会导致频繁的刷脏页，能够通过工具监控 redo log的大小。redo log的大小 = innodb_log_file_size * innodb_log_file_in_group (默认为2) ...

数据类型tinyint 1字节 (-128,127) (0,128) 小整数类型smallint 2 字节 (-32 768，32 767) (0，65 535)mediumint 3 字节 (-8 388 608，8 388 607) (0，16 777 215)int/integer 4 字节bigint 8字节 超大整数float 4字节 单精度浮点数double 8字节 双精度decimal M+2 定点数char 0-255字节 定长字符串varchar 0-65535 字节 变长字符串text 0-65 535字节 长文本数据mediumtext 0-16 777 215字节 中等长度文本数据longtext 0-4 294 967 295字节 极大文本数据date 3字节 YYYY-MM-DD日期time 3字节 HH:MM:SSyear 1字节 YYYY年datetime 字节 YYYY-MM-DD HH:MM:SStimestamp 4字节 YYYYMMDD HHMMSSenum 65535个 枚举类型运算符+ - * / %取余= != < <= > >=between 1 and 10; 1到10蕴含两端in (1,2,3,4,5) ;not in (1,2,3,4,5)is null ; is not nulllike "%" 匹配多个 ; like "_" 匹配一个and or not常见函数随机数 rand()连贯字符串 concat('中国','打日本')转换小写 lcase('ABC') lower转换大写 upper ucase去除空格 trim(str)curdate()+0 返回20160916curdate() 2016-09-16curtime() 21:53:23now() 2019-07-10 21:52:23日期工夫unix_timestamp(now()) 返回工夫戳 1562767275from_unixtime( 1539659520) 返回 2018-10-16 11:12:00 from_unixtime(1515980716, '%Y-%m-%d %H:%i:%S') 2018-01-15 09:45:16 格式化工夫date_format(now(), '%Y-%m-%d') 2018-01-15date( now()) 2019-07-10 提取日期year('2019-7-10') 返回2019 month('2016-04-28') 4day(now()) 11 返回天hour('2019-12-6 14:7:50') 14minute('2019-12-6 14:7:50') 7second('2019-12-6 14:7:50') 50last_day('2019-12-6 14:7:50') 2019-12-31 给定日期最初一天quarter('2016-04-28') 2 季度,1,2,3,4dayofweek('2019-7-10') 返回4 星期三 -1weekday('2019-7-10') 返回2 星期三+1dayofyear('2019-7-10') 返回明天是191天to_days('2019-12-6 14:7:50') 737764计算日期 d 间隔 0000 年 1 月 1 日的天数from_days(733627) 2008-08-08 同上相同day(last_day(now())) 返回本月天数date_add('2019-12-6 14:7:50',INTERVAL 1 day) +1天date_sub('2019-12-6 14:7:50',INTERVAL 1 day) -1天timestamp('2008-08-08') 2008-08-08 00:00:00版本version聚合函数avg(col) 平均值count(*) 记录数min(col) max(col)最小 最大值sum(col)求和规范查问set names utf8; 设置编码select * from biao 根本查问select distinct id from biao 后果字段不反复select * from biao order by id desc ,time asc; 升序降序select * from biao group by sex having; 分组筛选select * from biao limit 4 返回4条select * from biao 4,3 返回3条,从第5条记录开始select a,b,c from A inner join B on A.id = B.id; 内连贯select a,b,c from A,B where A.id=B.id;内连贯select * from A left join B on A.id=B.id; 左连贯select * from A right join B on A.id=B.id;右连贯select id from Table where id2 in(select id3 from Table2) 子查问select id from Table where find_in_set(type,"ssq,sd,pls") 查问分类select id as ID from A as a 别名select * from A union all select * from B 合并后果集select * from A union select * from B 去反复SELECT id,title FROM article WHERE id<$id ORDER BY id desc LIMIT 1 上一篇SELECT id,title FROM article WHERE id>$id ORDER BY id ASC LIMIT 1 下一篇select count(distinct openid) as total from TB 统计记录去反复高级查问select * from list where to_days(FROM_UNIXTIME(createtime))=to_days(now()) 明天where to_days(now())-to_days(FROM_UNIXTIME(createtime))<1 明天where to_days(now())-to_days(FROM_UNIXTIME(createtime))=1 昨天where DATE_SUB(CURDATE(), INTERVAL 7 DAY) < date(FROM_UNIXTIME(createtime))近七天含明天where YEARWEEK(date_format(FROM_UNIXTIME(createtime),'%Y-%m-%d')) = YEARWEEK(now()) 本周where YEARWEEK(date_format(FROM_UNIXTIME(createtime),'%Y-%m-%d')) = YEARWEEK(now())-1 上周where DATE_SUB(CURDATE(), INTERVAL 30 DAY) < date(FROM_UNIXTIME(createtime))近30天含明天where DATE_FORMAT(FROM_UNIXTIME(createtime), '%Y%m') = DATE_FORMAT(CURDATE(), '%Y%m') 查问本月where PERIOD_DIFF(DATE_FORMAT(NOW(),'%Y%m'), DATE_FORMAT(FROM_UNIXTIME(createtime),'%Y%m')) =1 上月where QUARTER(FROM_UNIXTIME(createtime))=QUARTER(NOW()) 本季度where QUARTER(FROM_UNIXTIME(createtime))=QUARTER(DATE_SUB(NOW(),INTERVAL 1 QUARTER)) 上季度where YEAR(FROM_UNIXTIME(createtime))=YEAR(NOW()) 往年where YEAR(FROM_UNIXTIME(createtime))=YEAR(DATE_SUB(NOW(),INTERVAL 1 YEAR)) 去年SELECT @rank := @rank + 1 AS rank,t.* FROM (SELECT @rank := 0) r, user AS t ORDER BY t.score DESC; 雷同分数依照id小的在前,排名不反复SELECT rank,score,id FROM ( SELECT USER .*, @c := IF ( @p = score, @c, @r ) AS rank, @p := score, @r := @r + 1 FROM USER, ( SELECT @p := NULL, @r := 1, @c := 0 ) r ORDER BY score DESC ) c; 雷同排名反复后去掉前面UPDATE user INNER JOIN (SELECT @rank := @rank + 1 AS rank,t.id FROM (SELECT @rank := 0) r, user AS t ORDER BY t.score DESC) t2 ON t2.id=user.id SET user.rank=t2.rank 更新表本身排名,更新前rank都是0,没有反复UPDATE user INNER JOIN (SELECT rank,id FROM ( SELECT user.*, @c := IF ( @p = score, @c, @r ) AS rank, @p := score, @r := @r + 1 FROM user, ( SELECT @p := NULL, @r := 1, @c := 0 ) r ORDER BY score DESC ) c) t2 ON t2.id=user.id SET user.ranking=t2.rank 有反复同上UPDATE userSET rank= rank+1 WHERE id=5 主动加一SELECT * FROM user ORDER BY RAND() LIMIT 5; 随机数据性能低下1000以内SELECT * FROM user AS t1 JOIN (SELECT ROUND(RAND() * (SELECT MAX(id) FROM user)) AS id) AS t2 WHERE t1.id >= t2.id ORDER BY t1.id ASC LIMIT 2;间断的id高效率SELECT * FROM user WHERE id >= ((SELECT MAX(id) FROM user)-(SELECT MIN(id) FROM user)) * RAND() + (SELECT MIN(id) FROM user) limit 2; 随机id不间断select * from user where id<7 order by id desc limit 1; 上一条6select * from user where id>7 limit 1; 下一条

前端开发工程师为什么要学习node ? 理论开发中会用到吗 ？答案是必定的。 Node.js 是前端工程师必学的，如果你想在软件开发这行走的更远的话。 node.js 并不难学 ， 反而收益会很大 。 此篇文章针对与有node.js根底的 我的项目的创立1. 全局装置koa-generator疾速生成器npm install koa-generator -g 相似于express我的项目的疾速生成器 ， 有一个根本的模板进行应用 装置实现 2. 生成koa 我的项目应用 koa + 我的项目名字。进行生成 根底我的项目目录 3.启动我的项目这里咱们须要先 装置依赖npm install而后应用 npm run start 进行启动我的项目 批改我的项目文件这里能够看见 生成的目录以及文件。 其中 app.js 为入口文件 咱们将app.js进行如下批改。 const Koa = require('koa') // 导入koaconst app = new Koa()// const views = require('koa-views') 模板引擎须要用到koa-views渲染const json = require('koa-json') //解决json格局须要用到const onerror = require('koa-onerror')const bodyparser = require('koa-bodyparser') //获取post提交的数据 ctx.requset.bodyconst logger = require('koa-logger') //日志const mysql = require('./utils/db.js') // 这里为导入连贯mysql的js文件// error handleronerror(app)// middlewaresapp.use(bodyparser({ enableTypes: ['json', 'form', 'text']}))app.use(json())// 控制台日志app.use(logger())app.use(require('koa-static')(__dirname + '/public'))// app.use(views(__dirname + '/views', {// extension: 'pug'// }))// 控制台日志app.use(async (ctx, next) => { const start = new Date() await next() const ms = new Date() - start console.log(`${ctx.method} ${ctx.url} - ${ms}ms`)})// 导入路由const index = require('./routes/index')const users = require('./routes/users')// 应用路由app.use(index.routes(), index.allowedMethods())app.use(users.routes(), users.allowedMethods())// error-handlingapp.on('error', (err, ctx) => { console.error('server error', err, ctx)});app.listen(3000, () => { console.log('http://localhost:3000')})module.exports = app批改后的文件目录 ...

数据结构非结构化数据，各种文档、图片、视频/音频等都属于非结构化数据。对于这类数据，咱们个别间接整体进行存储，而且个别存储为二进制的数据格式（如文件、图片、视频、语音等需存入文件系统中）结构化数据，结构化的数据是指能够应用关系型数据库示意和存储，体现为二维模式的数据。个别特点是：数据以行为单位，一行数据表示一个实体的信息，每一行数据的属性是雷同的（如行数据等需存入关系型数据库中）半结构化数据，半结构化数据是结构化数据的一种模式，它并不合乎关系型数据库或其余数据表的模式关联起来的数据模型构造，但蕴含相干标记，用来分隔语义元素以及对记录和字段进行分层。因而，它也被称为自描述的构造。（常见的半构造数据有XML和JSON，可存入NoSQL数据库中）简介关系型数据库,瑞典基于C++语言开发玲珑、实用、性能高其余数据库如Oracle(甲骨文)、SQLServer(微软)、DB2(IBM)特点开源社区版收费跨平台安全性高成本低反对各种开发语言反对弱小的内置函数数据存储量大架构 装置形式可应用xdja_centos7.4裁剪版自带MySQL5.7安装包一键装置可应用以下脚本设置连贯权限常用命令连贯数据库mysql -uroot -p显示数据库show databases;抉择数据库use xxx(databasename);显示数据库表show tables;查看表形容DESC xxx(datatable);显示数据库版本、工夫等SELECT VERSION(),CURRENT_DATE(),CURRENT_TIME();显示运行的过程show processlist;查看配置项show variables like '%tx_isolation%';查看innodb状态show engine innodb status\G;DDLDDL(Data Definition Languages):数据定义语言，定义不同的数据段、数据库、表、列、索引等数据库对象，罕用的关键字包含create、drop、alter等创立数据库test1create database test1;删除指定数据库drop database test1;批改表字段alter table emp modify ename varchar(20);减少、删除表字段alter table emp add column age int(3);alter table emp drop column age;DMLDML(Data Manipulation Language):数据操作语言，用于增加、删除、更新和查询数据库记录，并查看数据完整性，罕用的关键字次要包含insert、delete、update和select等插入记录insert into emp(ename,sal,deptno) values('zhangsan','2015-08-01','2000',1);insert into emp(ename,sal,deptno) values('lisi','2015-08-01','3000',1);create table dept(deptno int(3),deptname varchar(20);insert into dept values(1,'tech'),(2,'sales'),(3,'fin');更新、删除记录update emp set sal=4000 where ename='lisi';delete from emp where ename='lisi';查问指定列、查问不重复记录select ename,hiredate,sal,deptno from emp;select distinct deptno from emp;条件查问与排序select * from emp where deptno =1 and sal<3000;select * from emp order by sal;分组统计select count(1) from emp;select deptno,count(1) as empnum from emp group by deptno分组统计+条件过滤select deptno,count(1) as empnum from emp group by deptno with rollup;select deptno,count(1) as empnum from emp group by deptno having count(1)>1;聚合函数与多表关联查问select sum(sal),max(sal),min(sal) from emp;select ename,deptname from emp,dept where emp.deptno=dept.deptno;存储引擎存储引擎就是如何存储数据、如何为存储的数据建设缩影和如何更新、查问数据等技术的实现办法；在关系数据中数据的存储是以表的模式存储，所以存储引擎也能够称为表类型（即存储和操作此表的类型）；类型有MyISAM、InnoDB、MERGE、MEMORY(HEAP)等；show engines;+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+| Engine | Support | Comment | Transactions | XA | Savepoints |+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+| InnoDB | DEFAULT | Supports transactions, row-level locking, and foreign keys | YES | YES | YES || CSV | YES | CSV storage engine | NO | NO | NO || MyISAM | YES | MyISAM storage engine | NO | NO | NO || BLACKHOLE | YES | /dev/null storage engine (anything you write to it disappears) | NO | NO | NO || PERFORMANCE_SCHEMA | YES | Performance Schema | NO | NO | NO || MRG_MYISAM | YES | Collection of identical MyISAM tables | NO | NO | NO || ARCHIVE | YES | Archive storage engine | NO | NO | NO || MEMORY | YES | Hash based, stored in memory, useful for temporary tables | NO | NO | NO || FEDERATED | NO | Federated MySQL storage engine | NULL | NULL | NULL |+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+9 rows in set (0.03 sec)InnoDB数据和索引合并存储为一个文件，.frm(形容表的构造) .ibd(表数据文件)反对外键，事务处理行锁定具备提交、回滚和解体恢复能力的事务平安并行读写，实用于大量的写操作的表备份备份所有数据库mysqldump -uroot -p --all-databases > itsca.sql输出明码后即可备份所有库[root@xdja wch]# mysqldump -uroot -p --all-databases > itsca.sqlEnter password: Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database. If you don't want to restore GTIDs, pass --set-gtid-purged=OFF. To make a complete dump, pass --all-databases --triggers --routines --events.备份指定数据库mysqldump -u root -p --databases 数据库1 数据库2 > xxx.sql还原mysql备份内容在系统命令行中，输出如下实现还原：mysql -uroot -p123456 < /data/mysqlDump/mydb.sql在登录进入mysql零碎中,通过source指令找到对应零碎中的文件进行还原：mysql> source /data/mysqlDump/mydb.sql根底优化存储引擎的抉择、字段设计、索引、SQL语句等都是影响MySQL性能的重要因素，本次暂不具体探讨。 ...

Java连贯Mysql数据库正告：Establishing SSL connection witho 解决Thu Dec 20 12:50:09 CST 2018 WARN: Establishing SSL connection without server's identity verification is not recommended. According to MySQL 5.5.45+, 5.6.26+ and 5.7.6+ requirements SSL connection must be established by default if explicit option isn't set. For compliance with existing applications not using SSL the verifyServerCertificate property is set to 'false'. You need either to explicitly disable SSL by setting useSSL=false, or set useSSL=true and provide truststore for server certificate verification.解决办法 在连贯数据库的url中增加useSSL=false 记得多个参数之间要用&连贯 ...

索引并不是时时都会失效的，比方以下几种状况，将导致索引生效： 1.如果条件中有or，即便其中有条件带索引也不会应用(这也是为什么尽量少用or的起因) 留神：要想应用or，又想让索引失效，只能将or条件中的每个列都加上索引 2.对于多列索引，不是应用的第一局部(第一个)，则不会应用索引 3.like查问是以%结尾 4.如果列类型是字符串，那肯定要在条件中将数据应用引号援用起来,否则不应用索引 5.如果mysql预计应用全表扫描要比应用索引快,则不应用索引 此外，查看索引的应用状况show status like ‘Handler_read%';大家能够留神：handler_read_key:这个值越高越好，越高示意应用索引查问到的次数handler_read_rnd_next:这个值越高，阐明查问低效 others 1) 没有查问条件，或者查问条件没有建设索引 2) 在查问条件上没有应用疏导列 3) 查问的数量是大表的大部分，应该是30％以上。 4) 索引自身生效5) 查问条件应用函数在索引列上，或者对索引列进行运算，运算包含(+，-，，/，! 等) 谬误的例子：select from test where id-1=9; 正确的例子：select * from test where id=10; 6) 对小表查问 7) 提醒不应用索引8) 统计数据不实在 9) CBO计算走索引破费过大的状况。其实也蕴含了下面的状况，这里指的是表占有的block要比索引小。 10)隐式转换导致索引生效.这一点该当引起器重.也是开发中常常会犯的谬误. 因为表的字段tu_mdn定义为varchar2(20),但在查问时把该字段作为number类型以where条件传给Oracle,这样会导致索引生效. 谬误的例子：select from test where tu_mdn=13333333333; 正确的例子：select from test where tu_mdn='13333333333'; 12) 1,<> 2,独自的>,<,(有时会用到，有时不会) 13,like "%_" 百分号在前. 4,表没剖析. 15,独自援用复合索引里非第一地位的索引列. 16,字符型字段为数字时在where条件里不增加引号. 17,对索引列进行运算.须要建设函数索引. 18,not in ,not exist. 19,当变量采纳的是times变量，而表的字段采纳的是date变量时.或相同状况。 20,B-tree索引 is null不会走,is not null会走,位图索引 is null,is not null 都会走 21,联结索引 is not null 只有在建设的索引列（不分先后）都会走, in null时 必须要和建设索引第一列一起应用,当建设索引第一地位条件是is null 时,其余建设索引的列能够是is null（但必须在所有列 都满足is null的时候）,或者=一个值； 当建设索引的第一地位是=一个值时,其余索引列能够是任何状况（包含is null =一个值）,以上两种状况索引都会走。其余状况不会走。 ...

客户端反复提交？定时工作执行了多遍？不必放心，分布式锁来帮您 当多个不同线程拜访同一资源时会造成竞态关系，也会呈现诸如资源被解决两次等恶性事件的产生。所以须要一种机制保障某一资源在某一时刻只会被惟一的服务解决。至此分布式锁服务机制油然而生。 实现分布式锁服务的形式很多，通常分布式锁服务须要具备三种个性 排他性：即对于锁来说任意时刻，能且仅能有一个用户能够取得锁防止死锁：保障不会死锁这种状况，即使是在开释锁之前容错性：只有服务集群有大多数节点存活就能够保障加解锁操作Redis实现形式Redis分布式锁官网文档：Distributed locks with Redis 概述Redis因为其效率高操作简略等长处曾经成为了目前最为广泛的一种实现形式了。作为一种kv数据库，Redis保障了key为全局惟一，实现形式也较为简单。在版本2.6.12之前须要两条命令来创立一个具备时效性的不能被笼罩的记录作为锁 SETNX lock 1 // 创立一个key为lock，value为1的值，并禁止笼罩EXPIRE lock 10 // 为key为lock的记录设置有效期10秒然而办法因为须要两条语句毁坏了其原子性，导致会呈现一些不可意料的问题。在2.6.12版本后，退出了新的set的参数使得能够用一条语句实现上述的两条命令 SET lock 1 EX 10 NX上面介绍一下在实在场景中会产生的问题 锁被非持有者销毁了？避免其余线程误操把锁删除还须要用lua脚本实现原子性判断是销毁锁的线程是否为锁持有者，解决思路是不同的线程销毁锁时用本身的标示去销毁，lua代码思路如下： if redis.call("GET",KEYS[1]) == ARGV[1]then return redis.call("DEL", keys[1])else return 0end解决数据的工夫太长被别的线程拿到锁了？在理论状况中会有这样一种状况，AB两线程去拿锁，A胜B负，然而A解决的数据处理的好慢或者是在执行gc。这时锁曾经过期了，被B拿到了锁，B很快解决完了数据并曾经提交了。之后A解决完了数据并提交导致数据被解决了两遍。尽管能够冗余过期工夫或者应用守护过程主动为其续时然而这两种计划也有造成死锁的可能。如何解决这种问题请大伙在评论区留言通知我，谢谢。 Redis集群模式下用锁？在集群的Redis环境下应用分布式锁状况会更简单一点，如某线程在Redis的主节点set lock胜利，但主节点解体而数据尚未同步給其余节点时，这时锁的作用就隐没了。为了解决这个问题，Redis的作者设计出Redlock计划来应答主从切换后锁生效的问题。Redlock设计基于两个前提 部署形式采纳多个实例独自部署节点要多，官网举荐5个以上而上锁过程也改为了获取以后的unix工夫顺次对各Redis各节点应用雷同的key和全局惟一的value进行上锁，并设置小于锁过期工夫的超时工夫仅当半数以上的节点返回胜利并且应用的工夫小于锁生效工夫才视为上锁胜利若半数以上的节点未上锁胜利则须要对上锁胜利的节点进行解锁操作Redlock的设计实质上还是基于分布式系统中的容错问题，即只有大多数节点可用，那么整个零碎便还可对外提供服务。对于Redlock计划还引出业界两位大佬antirez和Martin的争执，在此就不多赘述，Martin对于分布式锁的阐述可见咋做分布式锁。Zookeeper实现形式Zk是一个分布式的文件服务零碎，Znode是其根底的节点，也是实现分布式锁服务机制的要害，对于zk来说Znode的门路是具备唯一性的，这便为分布式锁的互斥性提供了反对；创立节点时可应用-e参数使其节点成为长期节点，长期象征当此次连贯断开后改节点将自行销毁，这样如果某个线程在解决数据时出现异常解体会主动开释该锁，不会呈现死锁的状况；最初就是zookeeper集群也是保障高可用的，这样只有半数也上的zk还在失常工作就不会呈现问题。 理论流程为： 线程A、B同时创立/lock节点(create -e /lock 1)线程A拿到锁，开始解决数据；线程B未拿到锁注册监听器，期待告诉线程A解决数据结束，删除/lock节点(delete /lock)，将锁销毁羊群效应问题现实情况中会有多个线程尝试去获取锁，未获取到的失败者们将对立注册watcher，这样须要告诉到各个线程时也须要将音讯推送给所有的线程，造成大量的资源节约。然而实际上咱们并不需要告诉給所有线程，只须要告诉給一个线程就够了。所以在应用中会应用长期的程序节点来作为锁的实现，不同线程监听前一个节点的数据，实现排队监听。防止每个告诉都发給多个线程。 与Redis计划比拟因为Zookeeper自身作为提供分布式协调性能，所以自身具备高可用性、强一致性等能力，所以锁的模型绝对Redis来说更加强壮因为Watcher的存在，防止了未拿到锁的线程不停重试造成资源节约因为Zookeeper创立节点与销毁节点的操作要比Redis创立记录删除记录耗费更多，所以性能上弱于Redis计划

本文次要是带大家疾速理解 InnoDB 中锁相干的常识为什么须要加锁首先，为什么要加锁？我想我不必多说了，设想接下来的场景你就能 GET 了。 你在商场的卫生间上厕所，此时你肯定会做的操作是啥？锁门。如果不锁门，上厕所上着上着，啪一下门就被关上了，可能大略兴许仿佛貌似有那么一丁点的不太适合。数据也是一样，在并发的场景下，如果不对数据加锁，会间接毁坏数据的一致性，并且如果你的业务波及到钱，那结果就更重大了。 锁门表情包 锁的分类在 InnoDB 中，都有哪些锁？其实你应该曾经晓得了很多了，例如面试中会问你存储引擎 MyISAM 和 InnoDB 的区别，你会说 MyIASM 只有表锁，然而 InnoDB 同时反对行锁和表锁。你可能还会被问到乐观锁和乐观锁的区别是啥。 锁的概念、名词很多，如果你没有对锁构建出一个残缺的世界观，那么你了解起来就会比拟有妨碍，接下来咱们把这些锁给分一下类。 依照锁的粒度依照锁的粒度进行划分能够分为： 表锁行锁这里就不探讨页锁了，页锁是 BDB（BerkeleyDB） 存储引擎中才有的概念，咱们这里次要探讨 InnoDB 存储引擎。 依照锁的思维依照加锁的思维能够分为： 乐观锁乐观锁这里的乐观、乐观和你平时了解的名词是同一个意思。乐观锁认为大概率不会发生冲突，只在必要的时候加锁。而乐观锁认为大概率会抵触，所以无论是否必要加锁都会执行加锁操作。 依照兼容性依照兼容性能够把锁划分为： 共享锁排他锁被加上共享锁的资源，可能和其他人进行共享，而如果被加上了排他锁，其他人在拿不到这把锁的状况下是无奈进行任何操作的。 依照锁的实现这里的实现就是 InnoDB 中具体的锁的品种了，别离有： 意向锁（Intention Locks）记录锁（Record Locks）间隙锁（Gap Locks）临键锁（Next-Key Locks）插入意向锁（Insert Intention Locks）自增锁（AUTO-INC Locks）即便依照这种分类来对锁进行了划分，看到了这么多的锁的名词可能依然会有点懵。比方我SELECT ... FOR UPDATE 的时候到底加的是什么锁？ 咱们应该透过景象看实质，实质是什么？实质是锁到底加在了什么对象上，而这个很好答复： 加在了表上加在了行上而对于加在行上的锁，其本质又是什么？实质是将锁加在了索引上。 意向锁在 InnoDB 中反对了不同粒度的锁，行锁和表锁。例如lock tables命令就会持有对应表的排他锁。为了使多种不同粒度的锁更实用，InnoDB 设计了意向锁。 意向锁是一种表级锁，它表明了接下来的事务中，会应用哪种类型的锁，它有以下两种类型： 共享意向锁（IS） 表明该事务会打算对表中的记录加共享锁独占意向锁（IX） 则是加排他锁例如，select ... for share就是加的共享意向锁，而SELECT .. FOR UPDATE则是加的独占意向锁。其规定如下： 一个事务如果想要获取某张表中某行的共享锁，它必须先获取该表的共享意向锁，或者独占意向锁。同理，如果想获取排他锁，它必须先获取独占意向锁下图是这几种锁的组合下互相互斥、兼容的状况 对照下面的表，在互相兼容的状况下，对应的事务就能获取锁，然而如果不兼容则无奈获取锁，直到不兼容的锁开释之后能力获取。 看到这里你可能就会有问题了，那既然意向锁除了 LOCK TBALES 之外什么都不阻塞。那我要它何用？ 还是通过例子，假如事务 A 获取了 student 表中 id = 100 这行的共享锁，之后事务 B 须要申请 student 表的排他锁。而这两把锁显著是抵触的，而且还是对于同一行。 ...

前言： mysqldump 是日常比拟罕用的一个工具了，在对数据库进行导出工作时，常常会用到 mysqldump 。本篇文章将介绍 mysqldump 工具的应用办法并分享几点备份技巧。 1.mysqldump应用简介mysqldump 是 MySQL 零碎自带的逻辑备份工具，次要用于转储数据库。它次要产生一系列的 SQL 语句，能够封装到文件，该文件蕴含重建数据库所须要的 SQL 命令如 CREATE DATABASE ，CREATE TABLE ，INSERT 等等。当咱们须要还原这些数据时，只须要执行此文件，即可将对应的数据还原。 mysqldump 根底应用语法如下： Usage: mysqldump [OPTIONS] database [tables]OR mysqldump [OPTIONS] --databases [OPTIONS] DB1 [DB2 DB3...]OR mysqldump [OPTIONS] --all-databases [OPTIONS]执行 mysqldump --help 或参考 MySQL 官网文档，咱们发现 mysqldump 工具可配置的参数有很多，以下简要阐明局部罕用的参数。 上表展现了一些常见的 mysqldump 相干选项，当你不理解某个参数的作用时，能够执行 mysqldump --help 来获取帮忙。对于布尔类型的参数，个别还存在一个与之对抗的参数，如 --triggers 默认开启，能够应用 --skip-triggers 来禁用它。 2.几点备份小技巧尽管 mysqldump 不太实用于大数据量的备份，但因其具备灵便不便、可依据场景定制参数等长处，还是被广泛应用在数据导出畛域。 笔者依据本人的应用教训，简略分享几点 mysqldump 备份小技巧： 倡议应用 --single-transaction 参数来取得一致性备份，缩小锁表。按需要来导出，只有本人想要的数据，尽量减少导出文件大小。若想用于搭建从库，倡议应用 --master-data = 2 参数记录主库 binlog 信息。若想备份存储过程、自定义函数及事件，请加 -R -E 参数，此二者默认不开启。不理解的参数不要随便加，按默认即可。上面分享几个不同场景下的 mysqldump 应用办法： ...

作者：朱庆林 大家晓得MySQL中的事务是基于MVCC版本链实现的，然而MySQL对于咱们来说是一个黑盒，对于底层的实现理解的不是很多。本文次要介绍MySQL中的InnoDB引擎的MVCC的实现原理，由浅到深率领大家从根上了解MySQL InnoDB行格局InnoDB存储引擎中记录是以行的模式存储的，这就意味着数据页（page）中保留的是一行行的数据，咱们把记录在磁盘上的寄存形式被称为行格局或者记录格局。到目前为止设计了4种不同类型的行格局，别离为Compact、Redundant、Dynamic和Compressed。本文只简略的介绍Compact行格局（其余的行格局大同小异，暂不做介绍）。能够通过下列命令批改、查看行格局 ## 创立表设置行格局CREATE TABLE 表名 (列的信息) ROW_FORMAT=行格局名称## 批改行格局ALTER TABLE 表名 ROW_FORMAT=行格局名称##查看表行格局SHOW TABLE STATUS LIKE "表名"COMPACT行格局上图为compact行格局的构造示意图，其中跟事务（MVCC）有关联的是暗藏列的内容 变长字段长度列表mysql反对一些变长字段类型比方：VARCHAR、TEXT、BLOB等。变长字段中存储多少字节的数据是不固定的，所以咱们在存储实在数据的时候须要顺便把这些数据占用的字节数也存起来。 null值列表表中的某些列可能存储NULL值，如果把这些NULL值都放到记录的实在数据中存储会很占中央，所以Compact行格局把这些值为NULL的列对立治理起来，存储到NULL值列表 记录头信息 暗藏列名称形容row_id列id(如果表没有指定主键，该列为暗藏主键)trx_id事务idroll_pointer回滚指针、指向undo日志SQL规范中的四种隔离级别READ UNCOMMITTED：未提交读。READ COMMITTED：已提交读。REPEATABLE READ：可反复读。SERIALIZABLE：可串行化。事务隔离级别脏读不可反复读幻读READ UNCOMMITTED是是是READ COMMITTED否是是REPEATABLE READ否否是REPEATABLE READ否否否MVCC原理版本链下面介绍过行格局中有个暗藏的列（row_id，trx_id，roll_pointer），其中row_id不是必须的。 trx_id：每次一个事务对某条聚簇索引记录进行改变时，都会把该事务的事务id赋值给trx_id暗藏列。roll_pointer：每次对某条聚簇索引记录进行改变时，都会把旧的版本写入到undo日志中，而后这个暗藏列就相当于一个指针，能够通过它来找到该记录批改前的信息。备注：事务执行过程中，只有在第一次真正批改记录时（比方应用INSERT、DELETE、UPDATE语句），才会被调配一个独自的事务id，这个事务id是递增的以后有个hero的表，查问后果下图： 假如插入该记录的事务id为80，那么此刻该条记录的示意图如下所示 之后两个事务id别离为100、200的事务对这条记录进行UPDATE操作，操作流程如下： 事务trx_id 100事务trx_id 200begin beginUPDATE hero set name="关羽" UPDATE hero set name="张飞" commit UPDATE hero set name="赵云" UPDATE hero set name="诸葛亮" commit此时的版本链就如下图所示，能够看到记录的批改组成了一个链表，链表中每个节点都记录了以后记录的事务id（trx_id），MVCC也是基于这些链表去实现的事务级别的4种隔离级别，也就是上面介绍的ReadView。 ReadView对于应用READ UNCOMMITTED隔离级别的事务来说，因为能够读到未提交事务批改过的记录，所以间接读取记录的最新版本就好了；对于应用SERIALIZABLE隔离级别的事务来说，规定应用加锁的形式来拜访记录；对于应用READ COMMITTED和REPEATABLE READ隔离级别的事务来说，都必须保障读到曾经提交了的事务批改过的记录，也就是说如果另一个事务曾经批改了记录然而尚未提交，是不能间接读取最新版本的记录的，外围问题就是：须要判断一下版本链中的哪个版本是以后事务可见的。为此mysql设计出了ReadView的概念，ReadView中有4个比拟重要的属性： m_ids：示意在生成ReadView时以后零碎中沉闷的读写事务的事务id列表。min_trx_id：示意在生成ReadView时以后零碎中沉闷的读写事务中最小的事务id，也就是m_ids中的最小值。max_trx_id：示意生成ReadView时零碎中应该调配给下一个事务的id值。creator_trx_id：示意生成该ReadView的事务的事务id。有了这个ReadView，这样在拜访某条记录时，只须要依照下边的步骤判断记录的某个版本是否可见： 如果被拜访版本的trx_id属性值与ReadView中的creator_trx_id值雷同，意味着以后事务在拜访它本人批改过的记录，所以该版本能够被以后事务拜访。如果被拜访版本的trx_id属性值小于ReadView中的min_trx_id值，表明生成该版本的事务在以后事务生成ReadView前曾经提交，所以该版本能够被以后事务拜访。如果被拜访版本的trx_id属性值大于或等于ReadView中的max_trx_id值，表明生成该版本的事务在以后事务生成ReadView后才开启，所以该版本不能够被以后事务拜访。如果被拜访版本的trx_id属性值在ReadView的min_trx_id和max_trx_id之间，那就须要判断一下trx_id属性值是不是在m_ids列表中，如果在，阐明创立ReadView时生成该版本的事务还是沉闷的，该版本不能够被拜访；如果不在，阐明创立ReadView时生成该版本的事务曾经被提交，该版本能够被拜访。基于下面的ReadView的规定，READ COMMITTED和REPEATABLE READ有什么不同呢？ READ COMMITTED —— 每次读取数据前都生成一个ReadViewREAD COMMITTED —— 在第一次读取数据时生成一个ReadView参考资料：MySQL技术底细MySQL是怎么运行的

字符串字段误应用数字进行查问，会导致隐式类型转换，无奈命中索引的坑我置信大多数小伙伴都踩过。特地是当字段中存的大多数数据都是数字时，很容易先入为主地认为字段是 int 类型，谬误地应用相似 where file_id=123456789 执行了查问。好一点的可能当时通过 Explain 命令查看语句的执行打算，发现居然没用命中索引，从而纠正错误；杯具一点的代码公布上线后呈现大量慢查问，数据库服务器的CPU使用率和磁盘IO飙升，酿成生产事变。 而仔细的小伙伴肯定会发现，尽管 varchar 字段用数字查无奈命中索引，而 int 字段用字符串查却通常能很快查出后果。这是为什么呢？ 上面咱们通过理论测试来阐明呈现这种景象的起因。测试用 MySQL版本为 5.7.18，数据表 file 构造如下，存储引擎为 InnoDB，表数据条数为 5 百万+。 mysql> SELECT VERSION();+---------------------+| VERSION() |+---------------------+| 5.7.18-20170830-log |+---------------------+mysql> DESC `file`;+----------+---------------------+------+-----+---------+----------------+| Field | Type | Null | Key | Default | Extra |+----------+---------------------+------+-----+---------+----------------+| id | int(11) | NO | PRI | NULL | auto_increment || fs_id | varchar(20) | NO | MUL | NULL | || filename | varchar(255) | NO | | NULL | || shareid | bigint(20) unsigned | NO | MUL | NULL | || uk | bigint(20) unsigned | NO | | NULL | || pid | varchar(32) | NO | | NULL | |+----------+---------------------+------+-----+---------+----------------+mysql> SELECT COUNT(*) FROM `file`;+----------+| COUNT(*) |+----------+| 5416697 |+----------+varchar 字段用数字进行查问数据表 file 中的 fs_id 字段是 varchar 类型，并且建设了一般索引 idx_fs_id。当应用字符串进行查问时，耗时 0.07 秒。通过 EXPLAIN 命令查看执行打算，结果表明查问时应用了 fs_id 字段的索引。 ...

　一、为什么用自增列作为主键　1、如果咱们定义了主键(PRIMARY KEY)，那么InnoDB会抉择主键作为汇集索引。　如果没有显式定义主键，则InnoDB会抉择第一个不蕴含有NULL值的惟一索引作为主键索引。　如果也没有这样的惟一索引，则InnoDB会抉择内置6字节长的ROWID作为隐含的汇集索引(ROWID随着行记录的写入而主键递增，这个ROWID不像ORACLE的ROWID那样可援用，是隐含的)。　2、如果表应用自增主键，那么每次插入新的记录，记录就会程序增加到以后索引节点的后续地位(主键插入性能最高，因为是程序的)，当一页写满，就会主动开拓一个新的页　3、如果应用非自增主键（如果身份证号或学号等），因为每次插入主键的值近似于随机，因而每次新纪录都要被插到现有索引页得两头某个地位　此时MySQL不得不为了将新记录插到适合地位而挪动数据，甚至指标页面可能曾经被回写到磁盘上而从缓存中清掉，此时又要从磁盘上读回来，这减少了很多开销，同时频繁的挪动、分页操作造成了大量的碎片，失去了不够紧凑的索引构造，后续不得不通过OPTIMIZE TABLE来重建表并优化填充页面。　二、为什么在字段上增加索引能进步查问效率　1、增加索引的字段的值，是寄存在索引构建的b+tree的叶子节点上，并通过排序寄存；　2、如有相干查问进来，会通过索引创立的b+tree获取数据所在的数据页（b+tree与二分查找法配合，只需几次io耗费就能够找到对应的数据页）；　3、找到数据页后，将页加载到buffer pool中，再内存中从数据页中获取具体数据；　三、B+树索引和哈希索引的区别　B+树是一个均衡的多叉树结构，从根节点到每个叶子节点的高度差值不超过1，而且同层级的节点间有指针互相链接，是有序的，如下图：　哈希索引就是采纳肯定的哈希算法，把键值换算成新的哈希值，检索时不须要相似B+树那样从根节点到叶子节点逐级查找，只需一次哈希算法即可,是无序的，如下图所示：　四、哈希索引的劣势：　等值查问，哈希索引具备绝对优势（前提是：没有大量反复键值，如果大量反复键值时，哈希索引的效率很低，因为存在所谓的哈希碰撞问题。）；MySQL中在缓冲池中会开启自适应哈希索引。　五、说说你对MySQL汇集索引的了解　1、汇集索引的抉择：　会优先选择显示创立的主键作为汇集索引；　如果没有则抉择第一个创立的非空惟一索引作为汇集索引；　如都没有则零碎会创立一个实例级别的rowid作为汇集索引。　2、汇集索引的特点：　汇集索引的键值程序决定了表数据行的物理程序；　叶子节点上寄存的是整行数据；　一张表只能创立一个汇集索引。　六、说说MySQL如何优化一般索引的写操作　如一个一般索引的插入操作，对于非汇集索引叶子节点的插入不再是程序的了，这时就须要离散地拜访非汇集索引页，因为随机读取的存在而导致了插入操作性能降落。　MySQL通过insert buffer（插入缓冲）这个个性，来优化一般索引的写入操作。　对于非汇集索引的插入操作，不是每一次直接插入到索引页中，而是先判断插入的非汇集索引页是否在缓冲池中，若在，则直接插入；若不在，则先放入到一个Insert Buffer对象中。而后再以肯定的频率和状况进行Insert Buffer和辅助索引页子节点的merge（合并）操作，这时通常能将多个插入合并到一个操作中（因为在一个索引页中），这就大大提高了对于非汇集索引插入的性能。　七、说说前缀索引应用的注意事项　建前缀索引时，最重要的是定义好长度，把握好度，即可节俭内存应用，又能够缩小额定的查问老本；前缀索引会对笼罩索引产生影响　...

前言浏览本文后你将播种： 1.对MySql中的锁有更加全面的意识。2.理解什么是幻读，以及如何防止幻读 。3.InnoDb 引擎对于行级锁的实现形式。4.死锁产生的条件、实例及如何防止死锁。5.本文中的sql语句均可间接在MySql中执行，不便本人做试验，这点很重要，只有本人入手试验过才会记忆更加粗浅。另外，因为自己程度及工夫无限，文中若有纰漏，欢送批评指正，感激不尽，当然有任何疑难也欢送评论区留言，一起学习探讨共同进步。 置信许多同学对于MySQL锁的概念并不生疏，但又感觉了解地不是很透彻，总像蒙着一层纱。那么明天咱们就一起通过实际操作来捋一捋 Mysql 的锁，读本文之前倡议你先理解 隔离级别、以后读、快照读 等概念 。注：本文的操作均是基于 Mysql 8.0.22 版本 InnoDB 引擎进行的，在其余大版本下执行，后果可能存在差别。（留神：本文均是在（repeatable-read）隔离级别下进行的操作）接下来咱们将从 MySQL有哪些锁以及为什么要加锁展开讨论。 1.MySql 有哪些锁？MySQL 不同的存储引擎反对不同的锁机制，所有的存储引擎都以本人的形式实现锁，服务器层无需理解存储引擎锁的具体实现。依据锁的不同粒度，MySQL 的锁可分为：全局锁、表级锁、行级锁（InnoDB）及其他（自增ID锁）。本文将重点探讨行级锁。其余只做简要形容，感兴趣的可自行搜寻。 1.1 全局锁Flush tables with read lock ：顾名思义是锁整个数据库，全局锁的典型应用场景是数据库备份时，为了保持数据的一致性，会对数据库加全局锁，然而当数据库表应用的引擎为InnoDB时，个别应用mysqldump …… --single-transaction。如果应用MyISAM引擎进行数据备份时，则只能加全局锁了。 如果数据备份时不加全局锁，会产生怎么的数据不统一呢？这里举个栗子：数据库中含有： Wallet（用户钱包）表 及 stock （商品库存）表，当购买商品时须要同时扣减 用户钱包 及 商品库存。在数据库备份过程中，恰好产生了商品购买。而且恰好是在 wallet 表备份实现后 及 stock 备份前，产生了商品购买。因为wallet表曾经实现了备份，所以此次的钱包扣减操作并没有被记录到wallet的备份文件中。但扣减库时，stock表还未备份，所以此次库存扣减记录在备份文件中， 这就导致应用备份文件复原进去的数据库数据不统一了，钱包没有扣钱，然而库存扣减了。 因为InnoDB引擎反对快照读，所以如果在数据库备份时打一个快照（--single-transaction），则就算不加全局锁，也不会有数据不统一的问题。 1.2 表级锁：表锁（Lock tables read）：个别MyISAM和MEMORY存储引擎会采纳表锁解决并发（这两个引擎不反对行级锁），而InnoDB引擎则同时反对表锁与行锁，并通过行级锁来进步并发性（另外，行锁应用不过后，InnoDB的行锁也会进化成表级锁，前面会介绍）。另外BDB存储引擎应用的是页面锁，页面锁的粒度介于表级锁与行级锁之间。 MDL锁（meta data lock）：在 MySQL 5.5 版本之后引入了 MDL锁，当对一个表做增删改查操作的时候，加 MDL 读锁；当要对表做构造变更操作DDL的时候，加 MDL 写锁。以避免在数据查问或数据更新时有表构造的变更，进而导致查问或更新的后果与预期的不统一。 构想一下，如果DDL操作 与 CURD操作之间不加锁，能够同时进行，那么在查问数据时，你的查问条件列被删除了，或者你要更新的列被删除了，是不是不管从 MySql的语句执行方面 及业务查问数据的后果来看，都会怪怪的。所以MySql 引入了MDL锁的概念。 意向锁（Intention Locks）：为了容许行锁和表锁共存，实现多粒度锁机制，InnoDB 还有两种外部应用的意向锁（Intention Locks），这两种意向锁都是表级别锁： ...

作者：姚嵩 爱可生南区交付服务部经理，爱好音乐，动漫，电影，游戏，人文，美食，游览，还有其余。尽管都很菜，但毕竟是喜好。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 本文内容来源于对客户的三个问题的思考： 哪些 SQL 会产生长期表/临时文件如何查看已有的长期表如何管制长期表/临时文件的总大小阐明：以下测试都是在 MySQL 8.0.21 版本中实现，不同版本可能存在差别，可自行测试； 首先，让咱们理解下什么是长期表|临时文件？长期表和临时文件都是用于长期存放数据集的中央； 个别状况下，须要长期寄存在长期表或临时文件中的数据集应该合乎以下特点： 数据集较小(较大的长期数据集个别意味着 SQL 较烂，当然有例外项)用完就清理(因为是长期存储数据集的中央，所以生命周期和 SQL 或者会话生命周期雷同)会话隔离(因为是长期数据集，不波及到与其余会话交互)不产生 GTID 从长期表|临时文件产生的主观性来看，分为2类： 用户创立的长期表SQL 产生的长期表|临时文件用户创立长期表： 用户创立长期表(只有创立长期表的会话能力查看其创立的长期表的内容) create database if not exists db_test ;use db_test ;CREATE TEMPORARY TABLE t1 (c1 INT PRIMARY KEY) ENGINE=INNODB;select * from db_test.t1 ; 留神： 能够创立和一般表同名长期表，其余会话能够看到一般表(因为看不到其余会话创立的长期表)； 创立长期表的会话会优先看到长期表； 同名表的创立的语句如下 CREATE TABLE t1 (c1 INT PRIMARY KEY) ENGINE=INNODB;insert into t1 values(1); 当存在同名的长期表时，会话都是优先解决长期表(而不是一般表)，包含：select、update、delete、drop、alter 等操作； 查看用户创立的长期表： 任何 session 都能够执行上面的语句； ...

MySQL 的 Binlog 日志是一种二进制格局的日志，Binlog 记录所有的 DDL 和 DML 语句(除了数据查问语句SELECT、SHOW等)，以 Event 的模式记录，同时记录语句执行工夫。 Binlog 的次要作用有两个： 数据恢复 因为 Binlog 具体记录了所有批改数据的 SQL，当某一时刻的数据误操作而导致出问题，或者数据库宕机数据失落，那么能够依据 Binlog 来回放历史数据。 主从复制 想要做多机备份的业务，能够去监听以后写库的 Binlog 日志，同步写库的所有更改。 Binlog 包含两类文件： 二进制日志索引文件(.index)：记录所有的二进制文件。二进制日志文件(.00000*)：记录所有 DDL 和 DML 语句事件。Binlog 日志性能默认是开启的，线上状况下 Binlog 日志的增长速度是很快的，在 MySQL 的配置文件 my.cnf 中提供一些参数来对 Binlog 进行设置。 Copy设置此参数示意启用binlog性能，并制订二进制日志的存储目录log-bin=/home/mysql/binlog/ mysql-bin.*日志文件最大字节（单位：字节）设置最大100MBmax_binlog_size=104857600 设置了只保留7天BINLOG（单位：天）expire_logs_days = 7 binlog日志只记录指定库的更新binlog-do-db=db_namebinlog日志不记录指定库的更新binlog-ignore-db=db_name写缓冲多少次，刷一次磁盘，默认0sync_binlog=0须要留神的是： max_binlog_size ：Binlog 最大和默认值是 1G，该设置并不能严格控制 Binlog 的大小，尤其是 Binlog 比拟凑近最大值而又遇到一个比拟大事务时，为了保障事务的完整性不可能做切换日志的动作，只能将该事务的所有 SQL 都记录进以后日志直到事务完结。所以实在文件有时候会大于 max_binlog_size 设定值。expire_logs_days ：Binlog 过期删除不是服务定时执行，是须要借助事件触发才执行，事件包含： 服务器重启服务器被更新日志达到了最大日志长度 max_binlog_size日志被刷新二进制日志由配置文件的 log-bin 选项负责启用，MySQL 服务器将在数据根目录创立两个新文件mysql-bin.000001 和 mysql-bin.index，若配置选项没有给出文件名，MySQL 将应用主机名称命名这两个文件，其中 .index 文件蕴含一份整体日志文件的清单。 ...

　1、查看表　show tables; # 查看数据库全副表　select * from 表名; # 查看表所有内容　mysql装置　2、创立表　create table 表名(　列名 类型 是否能够为空，　列名 类型 是否能够为空　)ENGINE=InnoDB DEFAULT CHARSET=utf8　来一个实例好详解　CREATE TABLE tab1 (　nid int(11) NOT NULL auto_increment, # not null示意不能为空,auto_increment示意自增　name varchar(255) DEFAULT zhangyanlin, # default 示意默认值　email varchar(255),　PRIMARY KEY (nid) # 把nid列设置成主键　) ENGINE=InnoDB DEFAULT CHARSET=utf8;　注：　默认值，创立列时能够指定默认值，当插入数据时如果未被动设置，则主动增加默认值　自增，如果为某列设置自增列，插入数据时无需设置此列，默认将自增（表中只能有一个自增列）留神：1、对于自增列，必须是索引（含主键）2、对于自增能够设置步长和起始值　主键，一种非凡的惟一索引，不容许有空值，如果主键应用单个列，则它的值必须惟一，如果是多列，则其组合必须惟一。　3、删除表　drop table 表名　3、清空表内容　delete from 表名　truncate table 表名　4、批改表　复制代码　增加列： alter table 表名 add 列名 类型　删除列： alter table 表名 drop column 列名　批改列：　alter table 表名 modify column 列名 类型; -- 类型　alter table 表名 change 原列名 新列名 类型; -- 列名，类型　增加主键：　alter table 表名 add primary key(列名);　删除主键：　alter table 表名 drop primary key;　alter table 表名 modify 列名 int, drop primary key;　增加外键： alter table 从表 add constraint 外键名称（形如：FK_从表_主表） foreign key 从表(外键字段) references 主表(主键字段);　删除外键： alter table 表名 drop foreign key 外键名称　批改默认值：ALTER TABLE testalter_tbl ALTER i SET DEFAULT 1000;　删除默认值：ALTER TABLE testalter_tbl ALTER i DROP DEFAULT;　...

　1、什么是数据库 ？　数据库（Database）是依照数据结构来组织、存储和治理数据的仓库，它产生于距今六十多年前，随着信息技术和市场的倒退，特地是二十世纪九十年代当前，数据管理不再仅仅是存储和治理数据，而转变成用户所须要的各种数据管理的形式。数据库有很多种类型，从最简略的存储有各种数据的表格到可能进行海量数据存储的大型数据库系统都在各个方面失去了宽泛的利用。　支流的数据库有：sqlserver，mysql，Oracle、SQLite、Access、MS SQL Server等，本文次要讲述的是mysql　2、数据库治理是干什么用的？　a. 将数据保留到文件或内存　b. 接管特定的命令，而后对文件进行相应的操作　PS：如果有了以上管理系统，毋庸本人再去创立文件和文件夹，而是间接传递 命令 给上述软件，让其来进行文件操作，他们统称为数据库管理系统（DBMS，Database Management System）　mysql装置

1 Json 类型简介MySQL 5.7 之后提供了Json类型，是MySQL 联合结构化存储和非结构化存储设计进去的一个类型。 在某些场景下，Json 类型几乎是福音。 场景1: 用户画像，形容用户的标签等相似场景，比方互联网医院类零碎的患者衰弱档案，有很多信息不是必填项，如：身高、体重、三围等等信息，能够应用 Json 存储。 场景2: 游戏类场景； 场景3: 存储图片等从属信息，比方图片的分辨率，图片题目等。 2 让咱们看看Json怎么用的创立表，并插入数据 CREATE TABLE UserLogin ( userId BIGINT NOT NULL, loginInfo JSON, PRIMARY KEY(userId));INSERT INTO `UserLogin`(`userId`, `loginInfo`) VALUES (1, '{\"QQ\": \"82946772\", \"wxchat\": \"破产码农\", \"cellphone\": \"13918888888\"}');INSERT INTO `UserLogin`(`userId`, `loginInfo`) VALUES (2, '{\"cellphone\": \"15026888888\"}');INSERT INTO `UserLogin`(`userId`, `loginInfo`) VALUES (3, '{\"QQ\": \"82946772\", \"wxchat\": \"破产码农\", \"cellphone\": \"13918888889\"}');2.1 JSON_EXTRACT 函数，获取Json字段中特定属性的值SELECT JSON_UNQUOTE(JSON_EXTRACT(loginInfo, "$.cellphone")) from UserLogin;获取cellphone属性的值。能够应用->写法或者->>写法。 -- 带引号SELECT loginInfo->"$.cellphone" from UserLogin;-- 不带引号SELECT loginInfo->>"$.cellphone" from UserLogin;函数阐明： ...

作者：刘开洋 爱可生交付服务团队北京 DBA，对数据库及周边技术有浓重的学习趣味，喜爱看书，谋求技术。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 前段时间在客户现场发现一个奇怪的锁问题，顺便拿来和大家分享一下。 景象MySQL 版本是 8.0.18 ，在从库的线程期待连贯中观测到的景象是这样的： mysql> select * from threads;+-----------+---------------------------------------------+------------+----------------+------------------+------------------+--------------------+---------------------+------------------+---------------------------------------------+----------------------------------------------------------------------------------------------------------+------------------+------+--------------+---------+-----------------+--------------+----------------+| THREAD_ID | NAME | TYPE | PROCESSLIST_ID | PROCESSLIST_USER | PROCESSLIST_HOST | PROCESSLIST_DB | PROCESSLIST_COMMAND | PROCESSLIST_TIME | PROCESSLIST_STATE | PROCESSLIST_INFO | PARENT_THREAD_ID | ROLE | INSTRUMENTED | HISTORY | CONNECTION_TYPE | THREAD_OS_ID | RESOURCE_GROUP |+-----------+---------------------------------------------+------------+----------------+------------------+------------------+--------------------+---------------------+------------------+---------------------------------------------+----------------------------------------------------------------------------------------------------------+------------------+------+--------------+---------+-----------------+--------------+----------------+······| 58 | thread/sql/event_scheduler | FOREGROUND | 8 | NULL | NULL | NULL | Sleep | NULL | Waiting on empty queue | NULL | 1 | NULL | YES | YES | NULL | 34147 | SYS_default || 59 | thread/sql/signal_handler | BACKGROUND | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | 1 | NULL | YES | YES | NULL | 34148 | SYS_default || 60 | thread/sql/compress_gtid_table| FOREGROUND | 10 | NULL | NULL | NULL | Daemon | 33670997 | Suspending | NULL | 1 | NULL | YES | YES | NULL | 34149 | SYS_default || 61 | thread/mysqlx/acceptor_network| BACKGROUND | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | 40 | NULL | YES | YES | NULL | 34150 | SYS_default || 46627729 | thread/mysqlx/worker | BACKGROUND | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | YES | YES | NULL | 34132 | SYS_default || 57810934 | thread/sql/one_connection | FOREGROUND | 57808740 | proxy_monitor | 10.108.76.139 | NULL | Query | 718 | Waiting for commit lock | set global read_only=on | NULL | NULL | YES | YES | SSL/TLS | 76945 | USR_default || 47295992 | thread/sql/slave_io | FOREGROUND | 47294234 | root | localhost | NULL | Connect | 6285905 | Waiting for master to send event | NULL | 47294592 | NULL | YES | YES | NULL | 75880 | SYS_default || 47295993 | thread/sql/slave_sql | FOREGROUND | 47294235 | root | localhost | NULL | Query | 64768 | Waiting for dependent transaction to commit | NULL | 47294592 | NULL | YES | YES | NULL | 75881 | SYS_default || 47295994 | thread/sql/slave_worker | FOREGROUND | 47294236 | root | localhost | NULL | Query | 67415 | Waiting for global read lock | INSERT INTO `dcp_deci_acctflow_info` (······ | 47295993 | NULL | YES | YES | NULL | 75882 | SYS_default || 47295995 | thread/sql/slave_worker | FOREGROUND | 47294237 | root | localhost | NULL | Query | 67415 | Waiting for commit lock | NULL | 47295993 | NULL | YES | YES | NULL | 75883 | SYS_default || 47295996 | thread/sql/slave_worker | FOREGROUND | 47294238 | root | localhost | NULL | Query | 67415 | Waiting for preceding transaction to commit | NULL | 47295993 | NULL | YES | YES | NULL | 75884 | SYS_default || 47295997 | thread/sql/slave_worker | FOREGROUND | 47294239 | root | localhost | NULL | Query | 67415 | Waiting for global read lock | INSERT INTO `dcp_deci_acctflow_info` (······ | 47295993 | NULL | YES | YES | NULL | 75885 | SYS_default || 47295998 | thread/sql/slave_worker | FOREGROUND | 47294240 | root | localhost | NULL | Query | 67415 | Waiting for global read lock | INSERT INTO `dcp_deci_acctflow_info` (······ | 47295993 | NULL | YES | YES | NULL | 75886 | SYS_default || 47295999 | thread/sql/slave_worker | FOREGROUND | 47294241 | root | localhost | NULL | Query | 67415 | Waiting for global read lock | INSERT INTO `dcp_deci_acctflow_info` (······ | 47295993 | NULL | YES | YES | NULL | 75887 | SYS_default || 47296000 | thread/sql/slave_worker | FOREGROUND | 47294242 | root | localhost | NULL | Query | 67415 | Waiting for an event from Coordinator | NULL | 47295993 | NULL | YES | YES | NULL | 75888 | SYS_default || 47296001 | thread/sql/slave_worker | FOREGROUND | 47294243 | root | localhost | NULL | Query | 67415 | Waiting for an event from Coordinator | NULL | 47295993 | NULL | YES | YES | NULL | 75889 | SYS_default || 47296002 | thread/sql/slave_worker | FOREGROUND | 47294244 | root | localhost | NULL | Query | 67415 | Waiting for an event from Coordinator | NULL | 47295993 | NULL | YES | YES | NULL | 75890 | SYS_default || 47296003 | thread/sql/slave_worker | FOREGROUND | 47294245 | root | localhost | NULL | Query | 67415 | Waiting for an event from Coordinator | NULL | 47295993 | NULL | YES | YES | NULL | 75891 | SYS_default || 47296004 | thread/sql/slave_worker | FOREGROUND | 47294246 | root | localhost | NULL | Query | 67415 | Waiting for an event from Coordinator | NULL | 47295993 | NULL | YES | YES | NULL | 75892 | SYS_default || 47296005 | thread/sql/slave_worker | FOREGROUND | 47294247 | root | localhost | NULL | Query | 67415 | Waiting for an event from Coordinator | NULL | 47295993 | NULL | YES | YES | NULL | 75893| SYS_default || 47296006 | thread/sql/slave_worker | FOREGROUND | 47294248 | root | localhost | NULL | Query | 67415 | Waiting for an event from Coordinator | NULL | 47295993 | NULL | YES | YES | NULL | 75894 | SYS_default || 47296007 | thread/sql/slave_worker | FOREGROUND | 47294249 | root | localhost | NULL | Query | 67415 | Waiting for an event from Coordinator | NULL | 47295993 | NULL | YES | YES | NULL | 75895 | SYS_default || 47296008 | thread/sql/slave_worker | FOREGROUND | 47294250 | root | localhost | NULL | Query | 67415 | Waiting for an event from Coordinator | NULL | 47295993 | NULL | YES | YES | NULL | 75896 | SYS_default || 47296009 | thread/sql/slave_worker | FOREGROUND | 47294251 | root | localhost | NULL | Query | 67415 | Waiting for an event from Coordinator | NULL | 47295993 | NULL | YES | YES | NULL | 75897 | SYS_default || 57811108 | thread/sql/one_connection | FOREGROUND | 57808914 | proxy_monitor | 10.108.76.140 | NULL | Query | 664 | Waiting for commit lock | set global read_only=on | NULL | NULL | YES | YES | SSL/TLS | 97442 | USR_default || 57811279 | thread/sql/one_connection | FOREGROUND | 57809085 | proxy_monitor | 10.108.76.140 | NULL | Query | 610 | Waiting for commit lock | set global read_only=on | NULL | NULL | YES | YES | SSL/TLS | 98136 | USR_default || 57811110 | thread/sql/one_connection | FOREGROUND | 57808916 | proxy_monitor | 10.108.76.139 | NULL | Query | 663 | Waiting for commit lock | set global read_only=on | NULL | NULL | YES | YES | SSL/TLS | 97419 | USR_default |······ mysql> ^C// 阐明：因为连贯靠近2300条，为不便大家看起来没有那么干燥，这里进行局部省略，大多数被省略的连接线程为set global read_only的连贯剖析从下面的连贯能够观测到：这里存在着几个锁期待，有等全局读锁的，有等提交锁的，首先应该理清对应的锁期待程序，看看到底是“谁在等我，而我又在等谁”。 ...

介绍 MySQL是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发，属于 Oracle 旗下产品。MySQL 是最风行的关系型数据库管理系统之一，在 WEB 利用方面，MySQL是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件之一。MySQL是一种关系型数据库管理系统，关系数据库将数据保留在不同的表中，而不是将所有数据放在一个大仓库内，这样就减少了速度并进步了灵活性。MySQL所应用的 SQL 语言是用于拜访数据库的最罕用标准化语言。MySQL 软件采纳了双受权政策，分为社区版和商业版，因为其体积小、速度快、总体领有成本低，尤其是开放源码这一特点，个别中小型网站的开发都抉择 MySQL 作为网站数据库。 体系结构 指标 在CentOS7中配置mysql；相熟mysql的单机装置；环境 CentOS7mysql-5.7.21-linux-glibc2.12-x86_64.tar.gzVMware依赖包 yum -y install gcc-c++ ncurses-devel cmake make perl gcc autoconf automake zlib libxml libgcrypt libtool bison约定 下载目录：/mysoft装置地位：/usr/local/mysql数据库保留地位：/usr/local/fileData/mysqlData日志保留地位：/usr/local/fileLogs/logMysql用户组：mysql用 户：mysql创立用户组及用户 cat /etc/passwd //查看用户和分组信息:查看用户列表cat /etc/group //查看用户组列表查看mysql组和用户是否存在cat /etc/group | grep mysql创立用户组groupadd mysql创立用户useradd -r -g mysql -s /bin/false mysql或useradd -r -g mysql mysql装置Dmysql 解压安装包tar zxvf mysql-5.7.21-linux-glibc2.12-x86_64.tar.gz进入目录cd /mysoft/mysql-5.7.21-linux-glibc2.12-x86_64挪动并批改名称为 mysqlmv mysql-5.7.21-linux-glibc2.12-x86_64 /usr/local/mysql 配置文件 ...

1.改变数据库配置表编辑/etc/my.cnf,在配置表前方退出“skip-grant-tables”,意思是跳过跳过受权表,即不再动摇账号密码的正确性,应用service mysqld restart重启mysql,输出mysql -uroot -p,间接回车进入数据库命令行。 2.更改明码MySQL 5.7 之前的版本批改明码应用的语句是: UPDATE user SET Password=PASSWORD('yourpassword') where USER='root';5.7 之后的版本应该应用: update mysql.user set authentication_string=password('yourpassword') where user='root';或者 UPDATE user SET authentication_string=PASSWORD('yourpassword') where USER='root';3.重启除错应用service mysqld restart再次重启mysql后，输出命令，会出错。呈现的谬误：ERROR 1820 (HY000): Unknown error 1820。解决：需从新用alter从新设置下明码,然而间接设置可能会呈现ERROR 1819。起因是明码太简略,能够改变下明码默认规定。 set global validate_password_policy=0;set global validate_password_length=4;alter user user() identified by '123456';4.常识引进MySQL对设置明码进行了默认的限度（policy = 1）。即MEDIUM，所以设置的明码必须合乎长度（默认为 8 ），且必须含有数字，小写或大写字母，特殊字符。 进入MySQL下：(前提是validate_password插件必须曾经装置，从5.7版本开始默认装置)首先，批改validate_password_policy参数的值 即policy = 0 ，仅限度明码的长度set global validate_password_policy=0; 查看默认明码的长度select @@validate_password_length; 批改默认明码的长度（这里批改为4）set global validate_password_length=4; 应用零碎：centos 7.6

索引是什么？为什么要有mysql 索引，解决了什么问题，其底层的原理是什么？为什么应用B+树做为解决方案？用其余的像哈希索引或者B树不行吗？ 简略理解索引首先，索引（Index）是什么？如果我间接通知你索引是数据库管理系统中的一个有序的数据结构，你可能会有点懵逼。 为了防止这种状况，我打算举几个例子来帮忙你更容易的意识索引。 咱们查问字典的时候能够依据字的部首、笔画来查找到对应的字，这样能够疾速的找到对应的字所在页，在字典结尾那玩意就叫索引 还有一本书的目录，能够帮咱们疾速的跳到不同的章节，此时这里的目录也是索引 甚至，景区的地图，会通知你你当初在哪里，其余景点在哪儿，这个地图从某些方面来说也是索引 再联合开篇较业余的解释，你可能就可能了解索引是什么了。 为什么须要索引理解了索引的概念，咱们就须要晓得为什么咱们须要索引？从刚刚的例子能够看进去，索引的存在的目标就是： 字典中的索引帮忙咱们疾速的找到对应的字书的目录帮忙咱们疾速的跳到咱们须要看的章节景区的地图帮忙咱们疾速的找到想要去的景区的路在数据库中，索引能够帮忙咱们疾速的查问到对应的数据行，从而顺利的取出所有列的数据。这个过程必须要快，对于当初的 Web 利用来说，DB 如果响应慢，将会间接影响到整个申请的响应工夫，而这对用户体验来说是灾难性的。 对于点个按钮，等个好几秒才有返回，那么之后用户大概率是不会再应用你开发的利用了。 MySQL中的索引首先，MySQL 和索引其实没有间接的关系。索引其实是 MySQL 中应用的存储引擎 InnoDB 中的概念。在 InnoDB 中，索引分为： 聚簇索引非聚簇索引对于聚簇索引，是 InnoDB 依据主键（Primary Key）构建的索引。你能够临时了解为 key 为主键，value 则是整行数据。并且一张表只能有一个聚簇索引。 当然，你能够不定义主键。然而失常状况下咱们都会创立一个枯燥递增的主键，或者是通过对立的 ID 生成算法生成。如果没有定义任何主键，InnoDB 会有本人的兜底策略。InnoDB 会抉择咱们定义的第一个所有值的都不为空的惟一索引作为聚簇索引。 不过理论的生产环境中，确实会有这样的 Corner Case。InnoDB 还有一个究极兜底，如果连仅剩的惟一索引也不符合要求，InnoDB 会本人创立一个暗藏的6个字节的主键 RowID，而后依据这个暗藏的主键来生成聚簇索引。 而对于非聚簇索引，是依据指定的列创立的索引，也叫二级索引（Secondary Index），一张表最多能够创立64个二级索引。key 为创立二级索引的列的值，value 为主键。换句话说，如果通过非聚簇索引查问，最终只能失去索引列自身的值 + 主键的值，如果想要获取到残缺的列数据，还须要依据失去的主键去聚簇索引中再查问一次，这个过程叫回表。 这里阐明一下，当初有很多的博客说，MySQL 应用 InnoDB 时，一张表最多只能创立 16 个索引，首先这是错的，显著是从其余的中央间接抄过来的，本人没有去做任何的验证。 在 MySQL 的官网文章中，明确的阐明了，一张表最多能够创立 64 个非聚簇索引，而且创立非聚簇索引时，列的数量不能超过16个。 留神，是创立非聚簇索引的列不能超过16个！ 这也顺便提一下题外话，所谓的技术谨严，什么叫谨严？对你通过其余渠道获取到的常识，它最多叫作者的观点，咱们持一种狐疑态度，并想方法本人去求证。求证后，它才会变成事实。 而不是对某些名词死记硬背，当初的新玩意层出不穷，但当你溯其本源，你会发现就那么回事。 索引底层原理后面提到了 InnoDB 中索引的类型，简略的理解了其分类和区别，那 InnoDB 中的索引是如何做到减速查问的呢？其底层的原理是啥呢？InnoDB 中的索引的底层构造为 B+ 树，是B树的一个变种。 ...

前言： 在 MySQL 中，建表时个别都会要求有主键。若要求不标准难免会呈现几张无主键的表，本篇文章让咱们一起揪出那个无主键的表。 1.无主键表的危害以 InnoDB 表为例，咱们都晓得，在 InnoDB 中，表都是依据主键程序以索引的模式寄存的，这种存储形式的表称为索引组织表。一张 InnoDB 表必须有一个聚簇索引，当有主键时，会以主键作为聚簇索引；如果没有显式定义主键，InnoDB 会抉择一个惟一的非空索引代替。如果没有这样的索引，则 MySQL 主动为 InnoDB 表生成一个隐含字段作为主键。 也就是说，最好咱们能够显式定义主键，那么无主键表可能会产生哪些危害呢？首先没有主键就意味着无奈用到主键索引，可能影响查问效率。其次是对保护不敌对，比方想降级为 MGR 集群或应用某些开源工具时，都会要求表要有主键。还有一点，对于无主键的表批量更新或删除，极易引起很长时间的主从提早。 这里也顺便提下，当主库对于无主键表（特地是既无主键又无索引的表）大量更新或删除时，从库会产生极大的主从提早，甚至会始终卡着执行不上来，别问我怎么晓得的，前段时间遇到过。产生这种状况的景象是从库提早一直增大，且正在执行的主库 binlog pos 位点始终不变，这个时候须要去主库解析下从库卡着的 binlog pos 位点，发现是对某个无主键表的操作，这时若想从库尽快赶上，能够手动设置下疏忽该表的同步，解决 SQL 如下： # 假如查看发现是 testtb 表导致了主从提早 能够再从库疏忽该表的同步mysql> STOP SLAVE SQL_THREAD;Query OK, 0 rows affected (0.00 sec)mysql> CHANGE REPLICATION FILTER REPLICATE_IGNORE_TABLE = (db.testtb);Query OK, 0 rows affected (0.00 sec)mysql> START SLAVE SQL_THREAD;Query OK, 0 rows affected (0.01 sec)疏忽掉该表的同步后，从库很快就会追上主库了。后续能够为该表减少主键，而后再手动同步下并解除疏忽即可。 2.找到无主键的表言归正传，当咱们的数据库实例中有好多好多张表时，又应该如何查找是否有无主键的表呢？总不能一个个找吧，聪慧的你可能想到了，能够从 MySQL 自带的零碎表中查找，因为咱们的所有建表信息都存储在零碎库 information_schema 中。上面 SQL 能够查找出无主键的表： ...

问在 MySQL 8.0 中, 应用长期表时, 会发现有1G的磁盘空间"隐没"了 试验咱们先宽油做一个 MySQL 8.0.25 的实例. 此处咱们疏忽创立的步骤, 大家可参考以前的试验. 还是用咱们相熟的翻倍法, 造一张表: 不停执行最初一句 SQL , 让表中含有足够多的记录: 这里咱们设置两个长期表的配置参数, 稍后再解释其作用: 咱们还须要设置好 performance_schema , 用来察看整个过程: 还须要记录一下目前的磁盘容量: 当初咱们下一个应用长期表的 SQL , 参考试验6: 在 SQL 执行的过程中, 察看一下磁盘空间: 数据库的磁盘总量全程并没有变动, 而磁盘总量会逐步增长, 增长1G左右, 而后又会降下来 这段时间到底产生了什么呢? 咱们来梳理一下 MySQL 8.0.25 中长期表的应用过程: 在 8.0.25 中, 长期表默认的引擎为 TempTable , 会先在内存里创立内存长期表当所有内存长期表的总大小达到 temptable_max_ram 限度后, MySQL 会应用 mmap 机制, 将一部分磁盘映射作为内存应用, 这个过程中磁盘使用量会回升。(咱们在试验中将 temptable_max_ram 设置为最小值, 是为了让 MySQL 尽早应用 mmap 机制, 试验会不便一点)当所有内存长期表通过mmap调配的内存量 (理论是磁盘) 达到 temptable_max_mmap 限度后, MySQL会将 内存长期表 转换成 磁盘长期表(引擎为InnoDB或MyISAM). (咱们在试验中将 temptable_max_ram 设置为1G)SQL 完结后, 长期表会被清理, 这个过程中, 磁盘使用量会降落咱们从新做一次这个试验, 钻研一下怎么察看这个过程: ...

COMP9334 Project, Term 1, 2019:Fog/cloud ComputingVersion 1.0Due Date: 11:00pm Friday 26 April 2019.This version: 20 March 2019Updates to the project, including any corrections and clarifications, will be posted on thesubject website. Make sure that you check the course website regularly for updates.Change logNothing for Version 1.0.1 Introduction and learning objectivesThis project is inspired by the research work reported in the article FogQN: An Analytic Modelfor Fog/Cloud Computing [2] on modelling a computing system that makeg use of both fog andcloud computing. The key question studied in the paper is on how to distribute work betweentwo computing resources, namely the fog and the cloud. In this project, you will use simulationto try to answer a similar research question.In this project, you will learn: ...

数据库能够解决什么问题- 实现数据长久化- 应用残缺的管理系统对立治理，易于查问相干概念- DB 数据库(database):存储数据的仓库。它保留了一系列有组织的数据。- DBMS 数据库管理系统(Database Management System).数据库是通过DBMS创立和操作的容器 - SQL 结构化查问语句(Structure Query Language):专门用来与数据库通信的语句。SQL命令1.查看所有数据库show databases;2.查看所有表show tables;show tables from 库名;3.进入表内use 表名;4.查看目前在那个库select database();5.创立表create table stuinfo( id int, name varchar(20));6.查看表构造desc 表名; 例如:desc stuinfo;7.查问表中数据select * from stuinfo;8.查看数据库版本select version();1.DQL:次要用来查问 对于Select2.DML:次要用来操作 插入、批改、删除3.DDL:库和表的定义 操作库的4.DCL:事务管制语言 操作事务进阶1:根底查问语法:select 查问列表 from 表名;1.查问列表能够是:表中的字段、常量值、表达式、函数2.查问的后果是一个虚构的表格#1.查问表中的单个字段select last_name from employees;#2.查问表中的多个字段select last_name,salary,email from employees;#3.查问表中的所有字段select * from employees;#4.查问常量值select 100;select 'john';#5.查问表达式select 100%98; 2#6.查问函数select VERSION(); 5.7.14 #7.起别名select 100%98 AS 后果;select last_name AS 姓,first_name AS 名 from employees;#8.去重select DISTINCT(department_id) from employees;#9.+的作用/***Java中+号*1.运算符，两个操作数都为数值型*2.连接符，只有有一个操作数为字符串，后果还是字符串**mysql的+*仅仅只有一个性能：运算符*1.select 100+90;两个操作数都为数值型，则做加法运算190*2.select '123'+90;其中一方为字符串，试图将字符型数值转换成数值型，* 如果转换胜利，则持续做加法运算 213*3.select 'john'+90; 90 如果转换失败，则将字符型数值转换成0*4.select null+10; null 只有其中一方为null，则后果必定是null*/#案例：查问员工名和姓连接成一个字段，并显示为姓名select last_name+first_name as 姓名 from employees; 谬误的查问，后果为0select CONCAT(last_name,first_name) as 姓名 from employees; 正确#10.IFNULLselect IFNULL(commission_pct,0) AS 奖金率,commission_pct from employees;进阶2:条件查问/**语法： select 查问列表 from 表名 where 帅选条件; 分类： 一、按条件表达式筛选 条件运算符：> < = != <> >= <= 二、按逻辑表达式筛选 逻辑运算符：&& ｜｜ ！ and or not 三、含糊查问 like between and in is null */ #1.按条件表达式筛选#案例1:查问工资>12000的员工信息SELECT * FROM employees WHERE salary > 12000;#案例2:查问部门编号不等于90号的员工名和部门编号SELECT last_name,department_id FROM employees WHERE department_id <> 90;#案例3:查问工资在1000到2000之间的员工姓名、工资以及奖金SELECT last_name, salary, commission_pct FROM employees WHERE salary >= 10000 AND salary <= 20000;#案例4:查问部门编号不是在90到110之间，或者工资高于15000的员工信息 SELECT * FROM employees WHERE department_id < 90 OR department_id > 110 OR salary > 15000; #3.含糊查问1.%:任意多个字符，蕴含0个字符2._:任意单个字符#案例一:查问员工名中蕴含字符a的员工信息SELECT * FROM employees WHERE last_name LIKE '%a%';#案例二:查问员工名中第三个字符为e，第五个字符为a的员工名和工资SELECT last_name, salary FROM employees WHERE last_name LIKE '__e_a%';#案例三:查问员工名中第二个字符为_的员工名转译：1.符号'_':能够用'\_'来转译2.还能够用 例2办法，ESCAPE '$'指出SELECT last_name FROM employees WHERE last_name LIKE '_\_%'; 例2SELECT last_name FROM employees WHERE last_name LIKE '_$_%' ESCAPE '$';#4.between and 蕴含临界值#案例一:查问员工编号在100到200之间的员工信息SELECT * FROM employees WHERE employee_id BETWEEN 100 AND 120;#5.in #案例一:查问员工的工种编号是 IT_PROG、AD_VP、AD_PRESSELECT last_name, job_id FROM employees WHERE job_id IN ( 'IR_PROT', 'AD_VP', 'AD_PRES' ); #6.is null#案例一:查问没有奖金的员工名和奖金率SELECT last_name, commission_pct FROM employees WHERE commission_pct IS NULL;#案例二:查问有奖金的员工和奖金率SELECT last_name, commission_pct FROM employees WHERE commission_pct IS NOT NULL;#7.平安等于 <=> #案例一:查问工资为12000的员工信息SELECT last_name, salary FROM employees WHERE salary <=> 12000; IS NULL:仅仅能够判断null值<=> :既能够判断NULL值，又能够判断一般的数值#进阶三#1.排序#语法select 查问列表form 表[where 筛选条件]order by 排序列表 [asc|desc]1.asc:代表的是升序，desc代表的是降序，如果不写，默认是升序。2.order by子句中能够反对单个字段、多个字段、表达式、函数、别名3.order by子句个别是放在查问语句的最初面，limit子句除外#案例一:查问员工信息，要求工资从高到低排序SELECT * FROM employees ORDER BY salary DESC;#案例二:查问部门编号>=90的员工信息，按入职工夫的先后进行排序SELECT * FROM employees WHERE department_id >= 90 ORDER BY hiredate ASC;#案例三:按年薪的高下显示员工的信息和年薪(按表达式排序)SELECT *,salary*12*(1+IFNULL(commission_pct,0)) 年薪FROM employees ORDER BY salary*12*(1+IFNULL(commission_pct,0)) DESC;#案例四:按年薪的高下显示员工的信息和年薪(按别名排序)SELECT *,salary*12*(1+IFNULL(commission_pct,0)) 年薪FROM employees ORDER BY 年薪 DESC;#案例五:按姓名的长度显示员工的姓名和工资(按函数排序)SELECT LENGTH(last_name) 字节长度,last_name,salaryFROM employees ORDER BY LENGTH(last_name) DESC;#案例六:查问员工信息，要求先按工资排序，再按员工编号排序SELECT *FROM employees ORDER BY salary ASC,employee_id DESC;s #进阶四:常见函数分类1.单行函数：concat、length、ifnull函数2.分组函数：- 字符函数- 数学函数- 日期函数- 其余函数- 流程管制函数# 一.字符函数#lengthSELECT LENGTH-- 获取参数值的字节个数SELECT LENGTH('john'); -- 4SELECT LENGTH('张三丰hahaha'); -- 15-- 查看字符集SHOW VARIABLES LIKE '%char%';-- utf8mb4#2.cincat 拼接字符串SELECT CONCAT(last_name,'_',first_name) FROM employees;#3.uppder、LOWER(str)#4.substr substring 索引从1开始SELECT SUBSTR('李莫愁爱上了陆展元',6) out_put; -- 了陆展元SELECT SUBSTR('李莫愁爱上了陆展元',1,3) out_put; -- 李莫愁#5.instr 返回字符串第一次呈现的索引，如果找不到返回0SELECT INSTR('杨不梅爱上了殷六侠','殷六侠') AS out_put; -- 7#6.TRIMSELECT LENGTH(TRIM(' 张翠山 ')) AS out_put;-- 9# 去掉前后的aSELECT TRIM('a' FROM 'aaaaaaaaaaaaaa牛aaaaaaaaaaniuzzzaa') AS out_put;-- 牛aaaaaaaaaaniuzzz#7.LPAD 左填充指定字符长度SELECT LPAD('牛牛牛',10,'*') AS out_put;-- *******牛牛牛#8.RPAD 右填充指定字符长度SELECT RPAD('牛牛牛',10,'*') AS out_put;-- 牛牛牛*******#9.replace替换SELECT REPLACE('张无忌爱上了周芷若','周芷若','赵敏') AS out_put;-- 张无忌爱上了赵敏# 二.数学函数# 1.round 四舍五入SELECT ROUND(-1.55);-- -2# 小数点前面保留两位SELECT ROUND(1.567,2);-- 1.57# 2.CEIL(X) 向上取整，返回>=该参数的最小整数SELECT CEIL(1.00);-- 1# 3.FLOOR(X) 向下取整，返回<=该参数的最大整数SELECT FLOOR(9.99);-- 9SELECT FLOOR(-9.99); -- -10# TRUNCATE(X,D)截断SELECT TRUNCATE(1.666666,1); -- 1.6# MOD(N,M)去余数 a-a/b*bSELECT MOD(10,-3); -- 1# 三.日期函数# NOW()返回以后零碎日期+工夫SELECT NOW();-- 2021-07-07 22:41:14# CURDATE()返回以后零碎日期，不蕴含工夫SELECT CURDATE();-- 2021-07-07# CURTIME()返回以后工夫，不蕴含日期SELECT CURTIME();-- 22:43:20# 能够获取指定的局部，年、月、日、小时、分钟、秒SELECT YEAR(NOW()) 年; -- 2021SELECT YEAR('1998-1-1') 年; -- 1998SELECT YEAR(hiredate) 年 FROM employees;# 月SELECT MONTH(NOW()) 月;-- 7SELECT MONTHNAME(NOW()) 月; -- July#STR_TO_DATE(str,format)将字符通过指定的格局转换成日期SELECT STR_TO_DATE( '4-3 1992', '%c-%d %Y' );-- 1992-04-03SELECT * FROM employees WHERE hiredate = STR_TO_DATE( '4-3 1992', '%c-%d %Y' ); #DATE_FORMAT(date,format) 将日期转换成字符SELECT DATE_FORMAT(NOW(),'%y年%m月%d日') AS out_put; -- 21年07月07日#四.其余函数SELECT VERSION(); -- 5.7.14SELECT DATABASE(); -- myemployeesSELECT USER(); -- root@localhost#五.流程管制函数#1.if函数：if else的函数SELECT IF(10>5,'大','小');-- 大SELECT last_name, commission_pct,IF ( commission_pct IS NULL, '没有奖金，呵呵', '有奖金，哈哈' ) 备注 FROM employees; 2.case函数的应用一：switch case的成果switch(变量或表达式){ case 常量1:语句1;break； ... default:语句n;break;}mysql中case 要判断的字段或表达式when 常量1 then 要显示的值1或语句1;when 常量2 then 要显示的值1或语句2;...else 要显示的值n或语句nend-- 部门号=30，显示的工资为1.3倍-- 部门号=40，显示的工资为1.2倍-- 部门号=50，显示的工资为1.3倍-- 其余部门，显示的工资为原工资SELECT salary, department_id,CASE department_id WHEN 30 THEN salary * 1.1 WHEN 40 THEN salary * 1.2 WHEN 50 THEN salary * 1.3 ELSE salary END AS 新工资 FROM employees;3.case函数的应用二 多重ifcasewhen 条件1 then 要显示的值1或语句1when 条件2 then 要显示的值2或语句2...else 要显示的值n或语句nend-- 案例：查问员工的工资的状况-- 如果工资>20000，显示A级别-- 如果工资>15000，显示B级别-- 如果工资>10000，显示C级别-- 否则，显示D级别SELECT salary ,CASE WHEN salary>20000 THEN 'A'WHEN salary>15000 THEN 'B'WHEN salary>10000 THEN 'C'ELSE 'D'END AS 工资级别FROM employees; ...

本文基于 MySQL 8在后面的两篇文章，咱们剖析了 MySQL InnoDB 引擎的两种行记录存储格局： Compact 格局Redundant 格局在这里简略总结下： Compact 格局构造： 变长字段长度表：包含数据不为NULL的每个可变长度字段的长度，并依照列的程序逆序排列NULL 值列表：针对能够为 NULL 的字段，用一个 BitMap 来标识哪些字段为 NULL记录头信息：固定 5 字节，包含： 无用位：2 bits，目前没用deleted_flag：1 bits，标识记录是否被删除min_rec_flag：1 bits，是否是 B+ 树中非叶子节点最小记录标记n_owned：4 bits，记录对应的 slot 中领有的记录数量heap_no：13 bits，该记录在堆中的序号，也能够了解为在堆中的地位信息record_type：3 bits，记录类型，一般数据记录为000，节点指针类型为 001，伪记录首记录 infimum 行为 010，伪记录最初一个记录 supremum 行为 011，1xx 的为保留的next_record 指针：16 bits，页中下一条记录的绝对地位暗藏列： DB_ROW_ID：6 字节，这个列不肯定会生成。优先应用用户自定义主键作为主键，如果用户没有定义主键，则选取一个 Unique 键作为主键，如果表中连 Unique 键都没有定义的话，则会为表默认增加一个名为 DB_ROW_ID 的暗藏列作为主键DB_TRX_ID：6 字节，产生以后记录项的事务 id，每开始一个新的事务时，零碎版本号会主动递增，而事务开始时刻的零碎版本号会作为事务 id，事务 commit 的话，就会更新这里的 DB_TRX_IDDB_ROLL_PTR：7 字节，undo log 指针，指向以后记录项的 undo log，找之前版本的数据需通过此指针。如果事务回滚的话，则从 undo Log 中把原始值读取进去再放到记录中去数据列： bigint：如果不为 NULL，则占用8字节，首位为符号位，残余位存储数字，数字范畴是 -2^63 ~ 2^63 - 1 = -9223372036854775808 ~ 9223372036854775807。如果为 NULL，则不占用任何存储空间double：非 NULL 的列，合乎 IEEE 754 floating-point "double format" bit layout 这个统一标准，如果为 NULL，则不占用任何存储空间对于定长字段，不须要存长度信息间接存储数据即可，如果有余设定的长度则补充。例如 char 类型，补充 0x20， 对应的就是空格。varchar 存储：因为数据结尾有可变长度字段长度列表，所以 varchar 只须要保留理论的数据即可，不须要填充额定的数据。然而咱们还没有思考存储特地长数据的状况Redundant 格局构造与 Compact 格局的区别： ...

前言：在索引优化时，常常会看到的一句话：如果索引字段呈现隐式字符集转换的话，那么索引将生效，进而转为全表扫描，查问效率将大大降低，要避免出现隐式字符集转换；在此我想问问同学们：大家晓得为什么隐式字符集转换会导致索引生效吗？理论场景中有没有遇到过隐式字符集转换导致索引生效的场景，具体排查的过程；本文主线：由下面的两个问题牵引出了本文的主线； 简略形容下隐式字符集转换导致索引生效的起因而后模仿理论场景排查隐式字符集转换导致索引生效的过程隐式字符集转换导致索引生效的起因MySQL索引的数据结构是 B+Tree，想要走索引查问必须要满足其 最左前缀准则 ，否则无奈通过索引树进行查找，只能进行全表扫描； 例如：上面的这个SQL因为在 索引字段 上应用函数进行运算，导致索引生效 select * from t_user where SUBSTR(name, 1, 2) = '李彤'下面的这个SQL怎么革新能力使索引失效呢？如下所示： select * from t_user where name like '李彤%'通过下面的小例子能够晓得，如果在索引字段上应用函数运算，则会导致索引生效，而索引字段的 隐式字符集转换 因为MySQL会主动的在索引字段上加上 转换函数 ，进而会导致索引生效； 那接下来咱们就通过模仿的理论场景来具体看看是不是因为MySQL主动给加上了转换函数而导致索引生效的； 模仿场景 + 问题排查因为导致索引生效的起因有很多，如果本人写的SQL怎么看都没问题，然而通过查看执行打算发现就是没有走索引查问，此时就会让很多人陷入困境，这到底是怎么导致的呢？此时本文重点将要讲述的工具就要闪亮退场啦： explain extended + show warnings ； 应用这个工具能够将执行的SQL语句的一些扩大信息展现进去，这些扩大信息就包含：MySQL优化时可能会增加上字符集转换函数，使得字符集不匹配的SQL能够正确执行上来； 上面就来具体聊聊 explain extended + show warnings 的应用； 模仿隐式字符集转换的场景：首先创立两个字符集不一样的表： CREATE TABLE `t_department` ( `id` int(11) NOT NULL AUTO_INCREMENT, `de_no` varchar(32) NOT NULL, `info` varchar(200) DEFAULT NULL, `de_name` varchar(200) DEFAULT NULL, PRIMARY KEY (`id`), KEY `index_de_no` (`de_no`) USING BTREE) ENGINE=InnoDB AUTO_INCREMENT=12 DEFAULT CHARSET=utf8mb4;CREATE TABLE `t_employees` ( `id` int(11) NOT NULL AUTO_INCREMENT, `em_no` varchar(32) NOT NULL, `de_no` varchar(32) NOT NULL, `age` int(11) DEFAULT NULL, `info` varchar(200) DEFAULT NULL, `em_name` varchar(200) DEFAULT NULL, PRIMARY KEY (`id`), KEY `index_em_no` (`de_no`) USING BTREE) ENGINE=InnoDB AUTO_INCREMENT=12 DEFAULT CHARSET=utf8;而后应用存储过程结构数据： ...

　查看所有的数据库　show databases;　进入数据库　use 数据库名；　创立数据库　create database 数据库名 default charset utf8;　查看以后应用的数据库　select database();　删除数据库　drop database 数据库名;　装置mysql：http://anzhuang.cuohei.com/　查看数据库的表　show tables();

　创立表　create table 表名 (列名1 数据类型，列名2 数据类型) engine=innodb default charset=utf8;　实例：　#创立表t1，id列为int类型，不能为空。且自增；name列为char类型，不超过10个字符　create table t1(id int not null auto_increment primary key,name char(10));　查看表的构造　desc 表名;　向表中增加内容(增)　insert into 表名(列名1，列名2) values('内容1'，'内容2') ;　删除表　drop table 表名;　删除内容（删）　delete from 表名 where 条件;　实例：　#删除表t1中id小于6的　delete from t1 where id<6;　清空表　#如果表中有自增，清空表之后，从新创立新表时，自增数据会接着之前的　delete from 表名;　装置mysql：http://shujuku.cuohei.com/　#如果表中有自增，清空表之后，从新创立新表时，自增数据不会接着之前的　truncate table 表名;　批改表中内容（改）　updata 表名 set 条件 where 条件;　实例：#把表t1中年龄为17的改为18　updata t1 set age=18 where age=17;　查看表的内容（查）　#查问所有列　select * from 表名;　#查问指定列　select 列1，列2 from 表名;　as 关键字　应用as给字段起别名　select id as 序号,name as 名字 from 表名; ...

　mysql的数据类型：数值型、日期/工夫、字符串类型　装置mysql：http://down.cuohei.com/　tinyint:小整数，数据类型用于保留一些范畴的整数数值范畴，MySQL中无布尔值，应用tinyint(1)结构　int：整数　varint：大整数　float：单精度浮点数，数值越大越不精确　double:双精度浮点数，数值越大月不精确　char:用于示意固定长度的字符串，能够蕴含最多达255个字符　varchar：用于变长的字符串，能够蕴含最多达255个字符。　尽管varchar应用起来较为灵便，然而从整个零碎的性能角度来说，char数据类型的处理速度更快。　text:用于保留变长的大字符串　date:YYYY-MM-DD(2021-06-09)　timer:HH:MM:SS(“20:30:25”)　year:YYYY(2021)　datetime:YYYY-MM-DD HH:MM:SS(2021-02-27 00:00:00)　timestamp:YYYYMMDD HHMMSS(2019-08-09 00:00:00)

　1、like "xx"　2、应用函数　3、or　当or条件中有未建设索引的列时才生效　一下状况还是会走索引(id和email是索引)：　select * from tb1 where id =1 or name = "kkk" and email = "123456";　装置mysql：http://fix.cuohei.com/　4、类型不统一　如果是字符串类型，传入条件时必须用括号括起来　5、！=　如果是主键，还是会走索引　6、>　主键或索引类型是整数类型还是会走索引　7、order by　当依据索引排序时，抉择的映射如果不是索引，，则不走索引；如果是对主键排序，还是会走索引　select email from tb1 oreder by email　8、组合索引最前缀　如果组合索引为（name、email）　name and email 应用索引　name 应用索引　email 不应用索引

　（1）字段：表中的一列，（也叫属性）；　（2）记录：表中的一行，（也叫元组）；　（3）关键字：一组能够惟一标识记录的字段，（能依据它疾速分类，检索到目标数据的关键词）；　（4）域：字段的取值范畴，（即某一列的取值限度）；　（5）关系：就是数据库的表，（即数据库的表名）；　（6）关系模式：定义关系的形容叫关系模式，通常示意为：表名（字段1，字段2，……），（也叫表构造）；　（7）事务：是作为单个逻辑单元执行的一系列操作，（也就是一组不可分割的sql语句）；　（8）ACID：事务必须具备ACID个性，　A ——>Atomic（原子性），事务必须是原子工作单位，对于数据的批改，要么全副执行，要么全副不执行。　C ——>Consistency（一致性），事务在实现时，必须使所用的数据都保持一致状态。　I ——>Isolation（隔离性），由并发事务所作的批改必须与任何其余并发事务所作的批改隔离。事务查看数据时数据所处的状态，要么是另一并发事务批改它之前的状态，要么是另一事务批改它之后的状态。　D ——>Durability（持久性），事务实现后，对系统的影响是永恒的。　（数据库采纳日志的形式来保障原子性，一致性，持久性，用锁机制来保障隔离性）；　mysql装置：http://install.cuohei.com/　（9）索引：索引是对数据库表中一列或多列的值进行排序的一种构造

　登录　mysql -uroot -p明码;　查看数据库　show databases;　创立数据库　create database 数据库名;　应用某个数据库　use 数据库名;　查看以后数据库的表　show tables; 装置mysql：http://mysql.cuohei.com/　初始化数据　source sql脚本门路;　当一个文件的扩大名为.sql，并且该文件中编写了大量的sql语句，咱们称这样的文件为sql脚本　当sql脚本中的数据量太大的时候无奈关上，应用source命令实现初始化。　删除数据库　drop databases 数据库名;　查看表构造　desc 表名;　\t命令是完结一条语句;　exit命令，退出mysql；　查看创立表的语句　show create table 表名;　留神：　任何一条sql语句以“;”结尾。　sql语句不辨别大小写。　示例　查问员工的年薪　select sal*12 as sal_count from emp; //as是用于给查问后果的列改名　select ename,sal*12 as sal_count from emp; //查问每个人的年薪水 ...