Mysql

在工作中遇到一个状况: 日志零碎的表中,工夫字段存储的是13位工夫戳timestamp而不是日期数据,而在业务中,咱们须要通过工夫和ip来进行分组查问给定日期的数据. 当然你能够抉择在业务层先将传入的日期转为工夫戳,再去进行查问,然而既然mysql既然能够间接进行转换,那么省去在业务层的操作何乐而不为呢? 1.首先介绍一下mysql中将工夫戳和日期相互转换的函数:工夫戳转换成日期FROM_UNIXTIME():FROM_UNIXTIME(1429063399,'%Y-%m-%d %H:%i:%s')如果不须要时分秒,'%Y-%m-%d'就好下面例子中应用的是10位工夫戳,若是13位工夫戳须要/1000,如下:FROM_UNIXTIME(1429063399123/1000,'%Y-%m-%d %H:%i:%s') 日期转换为工夫戳UNIX_TIMESTAMP():UNIX_TIMESTAMP('2015-04-15') %Y年、%m月、%d日、%H时、%i分、%s秒最为罕用 2.理论应用在我理论应用中,我还将DATE_FORMAT()函数(DATE_FORMAT(data,format) 函数用于以不同的格局显示日期/工夫数据)和FROM_UNIXTIME()来进行转换:DATE_FORMAT(FROM_UNIXTIME(DateTime/1000),'%Y-%m-%d') SELECT ip,DATE_FORMAT(FROM_UNIXTIME(timestamp/1000),'%Y-%m-%d') as date,count(*)FROM s_pagewhere DATE_FORMAT(FROM_UNIXTIME(timestamp/1000),'%Y-%m-%d') = ?GROUP BY ip,DATE_FORMAT(FROM_UNIXTIME(timestamp/1000),'%Y-%m-%d')?为占位符

前言对于Web来说，用户量和访问量增肯定水平上推动我的项目技术和架构的更迭和提高。可能会有以下的一些情况： 页面并发量和访问量并不多，MySQL足以撑持本人逻辑业务的倒退。那么其实能够不加缓存。最多对动态页面进行缓存即可。页面的并发量显著增多，数据库有些压力，并且有些数据更新频率较低重复被查问或者查问速度较慢。那么就能够思考应用缓存技术优化。对高命中的对象存到key-value模式的Redis中，那么，如果数据被命中，那么能够不通过效率很低的db。从高效的redis中查找到数据。当然，可能还会遇到其余问题，你还通过动态页面缓存页面、cdn减速、甚至负载平衡这些办法进步零碎并发量。这里就不做介绍。 缓存思维无处不在咱们从一个算法问题开始理解缓存的意义。 问题1： 输出一个数n(n<20),求n！；剖析1： 单单思考算法，不思考数值越界问题。 当然咱们晓得n!=n * (n-1) * (n-2) * ... * 1= n * (n-1)!; 那么咱们能够用一个递归函数解决问题。static long jiecheng(int n) { if(n==1||n==0)return 1; else { return n*jiecheng(n-1); }}复制代码这样每输出求一次须要执行n次。 问题2： 输出t组数据(可能成千盈百)，每组一个xi(xi<20),求xi！；剖析2： 如果应用递归,输出t组数据，每次输出为xi，那么每次都要执行次数为： 当每次输出的Xi过大或者t过大都会造成不小的累赘！工夫复杂度为O(n2)那么是否换个思维的。没错、是打表。打表罕用于ACM算法中，罕用于解决多组输入输出、图论搜寻后果、门路贮存问题。那么，对于这个求阶乘。咱们只须要申请一个数组，依照编号从前往后将在需要的数存到数组中，前面再获得时候间接输入数组值就能够，思维很明确吧:import java.util.Scanner;public class test {public static void main(String[] args) { // TODO Auto-generated method stub Scanner sc=new Scanner(System.in); int t=sc.nextInt(); long jiecheng[]=new long[21]; jiecheng[0]=1; for(int i=1;i<21;i++) { jiecheng[i]=jiecheng[i-1]*i; } for(int i=0;i<t;i++) { int x=sc.nextInt(); System.out.println(jiecheng[x]); }} }复制代码工夫复杂度才O(n)。这里的思维就和缓存思维差不多。先将数据在jiecheng[21]数组中贮存。执行一次计算。当前面持续拜访的时候就相当于当问动态数组值。每次都为O(1的操作)。缓存的利用场景缓存实用于高并发的场景，晋升服务容量。次要是将从常常被拜访的数据或者查问老本较高从慢的介质中存到比拟快的介质中，比方从硬盘—>内存。咱们晓得大多数关系数据库是基于硬盘读写的，其效率和资源无限，而redis是基于内存的，其读写速度差异差异很大。当并发过高关系数据库性能达到瓶颈时候，就能够策略性将常拜访数据放到Redis进步零碎吞吐和并发量。 ...

一. 基础知识本文应用的Mysql版本: 8.0.12-debug本文用到的Linux命令: xxd本文须要应用到的知识点: Mysql 数据页存储, 能够参见 https://segmentfault.com/a/11900000374368031.1 问题Data Dictironary是什么?Data Dictironary(DD, 数据字典)是无关数据库对象的合集, 例如表、视图、索引等, 能够看做是数据库的元信息。换句话说, 数据字典存储了无关表构造的信息, 每个表具备的列, 表的索引等。2.零碎表是什么? 跟本人创立的表有何不同? 零碎表有很多, 常见的有mysql.schemata,mysql.tables, mysql.indexes咱们创立的表的元信息是放到零碎表中的在内存中, 这些元信息以对象的形式提供给内部应用, 比如说, 创立一个表, 内存中会创立这个表的数据字典对象, 零碎表以及咱们创立的表都会有本人的数据字典对象能够认为零碎表的元信息就存储在本人的数据字典对象中, 这些信息会被序列化到磁盘的mysql.ibd文件中3.DD存储在哪些地方? 这里是针对Mysql 8的数据字典, 数据字典信息须要长久化, 存储在mysql.ibd文件中, 应用专门的表空间id在每个独立的表空间中, 也备份了一份这个表空间相干的dd对象序列化信息零碎表空间, 也就是ibdata1文件中, 并没有存储dd对象的相干信息1.2 DD存储Mysql 8之前, 数据字典存储构造如下图, 从图中能够看出, DD信息存储在多个中央, 局部数据存储在文件中局部数据存储在mysql零碎表中InnoDB零碎表也存储了局部数据这种存储形式存在以下问题: 数据存储在多个中央, 难以保护治理MyISAM零碎表容易损坏不反对原子操作Mysql 8 对数据字典进行了从新设计, 并且应用InnoDB存储, 将原来存储数据字典的文件全副删除, 对立放到数据字典表空间中对于原来应用MyISAM存储的零碎表, 全副替换为InnoDB存储, 为实现原子DDL提供了可能性1.3 如何查看数据字典通过命令行连贯Mysql服务器查看SET SESSION debug='+d,skip_dd_table_access_check';SELECT name, schema_id, hidden, type FROM mysql.tables where schema_id=1 AND hidden='System';能够看到DD中存储了很多零碎表, +------------------------------+-----------+--------+------------+| name | schema_id | hidden | type |+------------------------------+-----------+--------+------------+| catalogs | 1 | System | BASE TABLE || character_sets | 1 | System | BASE TABLE || collations | 1 | System | BASE TABLE || columns | 1 | System | BASE TABLE || dd_properties | 1 | System | BASE TABLE || events | 1 | System | BASE TABLE || index_stats | 1 | System | BASE TABLE || indexes | 1 | System | BASE TABLE || schemata | 1 | System | BASE TABLE || tables | 1 | System | BASE TABLE || tablespace_files | 1 | System | BASE TABLE || tablespaces | 1 | System | BASE TABLE |+------------------------------+-----------+--------+------------+这里咱们仅列出了一部分, InnoDB还存储了很多其余的零碎表这些零碎表存储了各种元数据, columns存储了表的列信息, indexes则存储了表的索引信息, schemata存储了数据库的信息。2.通过 ibd2sdi 工具查看 ...

当业务规模达到肯定规模之后，像淘宝日订单量在5000万单以上，美团3000万单以上。数据库面对海量的数据压力，分库分表就是必须进行的操作了。而分库分表之后一些惯例的查问可能都会产生问题，最常见的就是比方分页查问的问题。个别咱们把分表的字段称作shardingkey，比方订单表依照用户ID作为shardingkey，那么如果查问条件中不带用户ID查问怎么做分页？又比方更多的多维度的查问都没有shardingkey又怎么查问？ 惟一主键个别咱们数据库的主键都是自增的，那么分表之后主键抵触的问题就是一个无奈防止的问题，最简略的方法就是以一个惟一的业务字段作为惟一的主键，比方订单表的订单号必定是全局惟一的。 常见的分布式生成惟一ID的形式很多，最常见的雪花算法Snowflake、滴滴Tinyid、美团Leaf。以雪花算法举例来说，一毫秒能够生成4194304多个ID。 第一位不应用，默认都是0，41位工夫戳准确到毫秒，能够包容69年的工夫，10位工作机器ID高5位是数据中心ID，低5位是节点ID，12位序列号每个节点每毫秒累加，累计能够达到2^12 4096个ID。 分表第一步，分表后要怎么保障订单号的惟一搞定了，当初思考下分表的问题。首先依据本身的业务量和增量来思考分表的大小。 举个例子，当初咱们日单量是10万单，预估一年后能够达到日100万单，依据业务属性，个别咱们就反对查问半年内的订单，超过半年的订单须要做归档解决。 那么以日订单100万半年的数量级来看，不分表的话咱们订单量将达到100万X180=1.8亿，以这个数据量级局部表的话必定单表是扛不住的，就算你能扛RT的工夫你也根本无法承受吧。依据教训单表几百万的数量对于数据库是没什么压力的，那么只有分256张表就足够了，1.8亿/256≈70万，如果为了保险起见，也能够分到512张表。那么考虑一下，如果业务量再增长10倍达到1000万单每天，分表1024就是比拟适合的抉择。 通过分表加上超过半年的数据归档之后，单表70万的数据就足以应答大部分场景了。接下来对订单号hash，而后对256取模的就能够落到具体的哪张表了。 那么，因为惟一主键都是以订单号作为根据，以前你写的那些依据主键ID做查问的就不能用了，这就波及到了历史一些查问性能的批改。不过这都不是事儿对吧，都改成以订单号来查就行了。这都不是问题，问题在咱们的题目说的点上。 C端查问说了半天，总算到了正题了，那么分表之后查问和分页查问的问题怎么解决？ 首先说带shardingkey的查问，比方就通过订单号查问，不论你分页还是怎么样都是能间接定位到具体的表来查问的，显然查问是不会有什么问题的。 如果不是shardingkey的话，下面举例说的以订单号作为shardingkey的话，像APP、小程序这种个别都是通过用户ID查问，那这时候咱们通过订单号做的sharding怎么办？很多公司订单表间接用用户ID做shardingkey，那么很简略，间接查就完了。那么订单号怎么办，一个很简略的方法就是在订单号上带上用户ID的属性。举个很简略的例子，本来41位的工夫戳你感觉用不完，用户ID是10位的，订单号的生成规定带上用户ID，落具体表的时候依据订单号中10位用户ID hash取模，这样无论依据订单号还是用户ID查问成果都是一样的。 当然，这种形式只是举例，具体的订单号生成的规定，多少位，蕴含哪些因素依据本人的业务和实现机制来决定。 好，那么无论你是订单号还是用户ID作为shardingkey，依照以上的两种形式都能够解决问题了。那么还有一个问题就是如果既不是订单号又不是用户ID查问怎么办？最直观的例子就是来自商户端或者后盾的查问，商户端都是以商户或者说卖家的ID作为查问条件来查的，后盾的查问条件可能就更简单了，像我碰到的有些后盾查问条件能有几十个，这怎么查？？？别急，接下来离开说B端和后盾的简单查问。 事实中真正的流量大头都是来自于用户端C端，所以实质上解决了用户端的问题，这个问题就解了大半，剩下来自商户卖家端B端、后盾反对经营业务的查问流量并不会很大，这个问题就好解。 其余端查问针对B端的非shardingkey的查问有两个方法解决。 双写，双写就是下单的数据落两份，C端和B端的各自保留一份，C端用你能够用单号、用户ID做shardingkey都行，B端就用商家卖家的ID作为shardingkey就好了。有些同学会说了，你双写不影响性能吗？因为对于B端来说轻微的提早是能够承受的，所以能够采取异步的形式去落B端订单。你想想你去淘宝买个货色下单了，卖家略微提早个一两秒收到这个订单的音讯有什么关系吗？你点个外卖商户晚一两秒收到这个订单有什么太大影响吗？ 这是一个解决方案，另外一个计划就是走离线数仓或者ES查问，订单数据落库之后，不论你通过binlog还是MQ音讯的都模式，把数据同步到数仓或者ES，他们反对的数量级对于这种查问条件来说就很简略了。同样这种形式必定是略微有提早的，然而这种可控范畴的提早是能够承受的。 而针对治理后盾的查问，比方经营、业务、产品须要看数据，他们人造须要简单的查问条件，同样走ES或者数仓都能够做失去。如果不必这个计划，又要不带shardingkey的分页查问，兄弟，这就只能扫全表查问聚合数据，而后手动做分页了，然而这样查出来的后果是有限度的。 比方你256个片，查问的时候循环扫描所有的分片，每个片取20条数据，最初聚合数据手工分页，那必然是不可能查到全量的数据的。 总结分库分表后的查问问题，对于有教训的同学来说其实这个问题都晓得，然而我置信其实大部分同学做的业务可能都没来到这个数量级，分库分表可能都停留在概念阶段，面试被问到后就不知所措了，因为没有教训不晓得怎么办。 分库分表首先是基于现有的业务量和将来的增量做出判断，比方拼多多这种日单量5000万的，半年数据得有百亿级别了，那都得分到4096张表了对吧，然而理论的操作是一样的，对于你们的业务分4096那就没有必要了，依据业务做出正当的抉择。 对于基于shardingkey的查问咱们能够很简略的解决，对于非shardingkey的查问能够通过落双份数据和数仓、ES的计划来解决，当然，如果分表后数据量很小的话，建好索引，扫全表查问其实也不是什么问题。

作者：姚远专一于 Oracle、MySQL 数据库多年，Oracle 10G 和 12C OCM，MySQL 5.6，5.7，8.0 OCP。当初鼎甲科技任技术顾问，为共事和客户提供数据库培训和技术支持服务。本文起源：原创投稿*爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。MySQL 启动失败的最常见的起因有两类，别离是无法访问系统资源和参数设置谬误造成的，上面别离剖析如下。 一、无法访问系统资源MySQL 不能拜访启动须要的资源是造成而 MySQL 无奈启动的一个常见起因，如：文件，端口等。因为 linux 中用于启动 mysqld 过程的 mysql 用户通常是不能登陆的，能够应用相似上面的命令查看文件的拜访权限。 sudo -u mysql touch /var/lib/mysql/b找出问题后，批改对应文件或目录的权限或属主后通常能够解决问题。但有时 mysql 用户有拜访文件和目录的权限，但依然会被回绝拜访，例如上面这个例子： mysql> system sudo -u mysql touch /home/mysql/data/amysql> create table t1 ( id int primary key,n varchar(10 ) data directoryERROR 1030 (HY000): Got error 168 from storage engine测试阐明 mysql 用户有这个目录的拜访权限，但创立文件还是失败，这种状况让很多人困惑，这个时候通常是 mysqld 过程的拜访被 linux 的 selinux 或 apparmor 给阻止了，大家能够看到创立的表不是在 mysql 的默认目录上面，因而 selinux 或 apparmor 的 policy 外面没有蕴含这个目录的拜访权限，此时只有对应的批改 policy 就行了，当然把 selinux 或 apparmor 停了也行。 ...

1.对于tomcat服务器脚本1.1 问题阐明如果通过命令: java -jar xxx.war 的形式启动服务器时,如果近程的终端敞开之后,那么tomcat服务器也会随之敞开.影响用户的应用. 上述的命令 示意前台运行. 1.2 线上部署的命令阐明: 个别在Linux零碎中部署服务器 个别采纳后端运行的形式 启动tomcat服务器.并且指定日志文件输入.命令: nohup java -jar 8081.war -> 8081.log & 1.3 对于文件查看的阐明cat 输入文件所有的内容more 输入文档所有的内容，分页输入，空格浏览下一屏，q退出less 用法和more雷同，只是通过PgUp、PgOn键来管制 q退出tail 用于显示文件后几号，应用频繁tail -10 nginx.conf 查看nginx.conf的最初10行tail –f nginx.conf 动静查看日志，不便查看日志新增的信息ctrl+c 完结查看 1.4 Linux 脚本阐明阐明: Linux中的"脚本"(外挂-荒野口头)的后缀为.sh创立文件: vim start.sh执行脚本: 2 数据库代理阐明2.1 数据库构造的优化阐明:因为须要用户同时链接2台甚至多台数据库时须要引入代理,所以有如下的部署.注意事项: 用户链接代理服务器 端口号个别:8066端口 2.2 Mycat介绍 2.3 Mycat部署2.3.1 上传Mycat安装包解压Mycat压缩包: `tar -zxvf Mycat-server-1.7.0-DEV-20170416134921-linux.tar.gz` 2.3.2 查看JDK是否装置 2.4 对于Mycat配置文件阐明2.4.1 server.xml配置文件阐明阐明:在server.xml配置文件中定义用户名和明码及操作的数据库信息,必须与YML配置文件统一.2).批改YML配置文件 2.4.2 schemas配置文件阐明阐明:schemas文件次要的作用就是配置数据库读写的策略. `<writeHost host="hostM1" url="192.168.126.129:3306" user="root" password="root"> <!--读数据库1--> <readHost host="hostS1" url="192.168.126.130:3306" user="root" password="root" /> <!--读数据库2--> <readHost host="hostS2" url="192.168.126.129:3306" user="root" password="root" /></writeHost>` ...

MySQL简介MySQL是一个小型的开源的关系型数据库管理系统，与其余大型数据库管理系统例如Oracle、DB2、SQL Server等相比，MySQL规模小，性能无限，然而它体积小、速度快、成本低，且它提供的性能对略微简单的利用曾经够用，这些个性使得MySQL成为世界上最受欢迎的凋谢源代码数据库。 MySQL的劣势： MySQL是凋谢源代码的数据库，任何人都能够取得该数据库的源代码。MySQL可能实现跨平台操作，能够在Windows、UNIX、Linux和Mac OS等操作系统上运行。MySQL数据库是一款自由软件，大部分利用场景下都是收费应用。什么是数据库数据库是一个以某种有组织的形式存储的数据汇合，它是一个按数据结构来存储和治理数据的计算机软件系统。了解数据库的一种最简略的方法是将其设想为一个文件柜，这个文件柜只是一个存储数据的空间，而数据库就是这么一个空间。 数据库管理系统（Database Management System, DBMS）是用于创立、治理、和保护数据库时所应用的软件，用以治理数据库，肯定水平上，用户都是在操作DBMS，所以日常的数据库概念个别就是指DBMS。 常见的数据库软件DBMS有甲骨文的Oracle、微软的Access、MongoDB等，还有MySQL。 什么是MySQLMySQL是一种DBMS，而且是一种一个小型的开源的关系型数据库管理系统。2008年1月16日MySQL AB被Sun公司收买。而2009年，SUN又被Oracle收买。就这样如同一个轮回，MySQL成为了Oracle公司的另一个数据库我的项目。[MySQL]是一种[凋谢源代码]的关系型[数据库治理]零碎（RDBMS），应用最罕用的数据库治理语言--[结构化查询语言]（SQL）进行数据库治理。 MySQL是凋谢源代码的，因而任何人都能够在General Public License的许可下下载并依据个性化的[须要]对其进行批改。 MySQL因为其速度、可靠性和适应性而备受关注。大多数人都认为在不须要[事务]化解决的状况下，MySQL是治理内容最好的抉择。 MySQL装置下载MySQLMySQL的官网下载地址为：(https://dev.mysql.com/downloa...[MySQL下载] Windows下装置MySQL将下载文件装置到电脑中，关上安装程序，顺次点击下一步。留神：1）Choosing a setup type：抉择装置类型，装置类型共有5种，抉择“Developer Default”即可。2）Type and Networking：抉择运行形式，共有2种，抉择规范类型“Standalone…”即可，第二种是沙盒运行。3）Type and Networking：抉择服务器配置，“Developer Machine”选项代表典型集体桌面工作站，在3种类型中，占用起码的内存，个别抉择此选项。4）Accounts and Roles：设置账户，在这里设置root明码。5）一路Next，即可装置胜利。 Linux下装置MySQL参考：Liunx装置MySQL MySQL管理工具MySQL的规范装置版本中没有图形化管理工具，尽管MySQL简直所有的工作都能够用命令提示符下的mysqladmin和mysql命令来实现，也会对MySQL留下“界面不敌对”的坏印象，为解决这个问题，MySQL开发了多种图形化的管理工具。上面介绍2个应用比拟宽泛的MySQL图形化管理工具。 Navicat for MySQLNavicat for MySQL基于Windows平台，为MySQL量身定做，提供相似于MySQL的用户治理界面工具。此解决方案的呈现，将解放PHP、J2EE等程序员以及数据库设计者、管理者的大脑，升高开发成本，为用户带来更高的开发效率。Navicat for MySQL应用了极好的图形用户界面（GUI），能够用一种平安和更为容易的形式疾速和容易地创立、组织、存取和共享信息。用户可齐全管制MySQL数据库和显示不同的治理材料，包含治理用户和管制拜访权限，可不便的将数据从一个数据库转移到另一个数据库中（Local to Remote、Remote to Remote、Remote to Local）进行数据备份。Navicat for MySQL反对Unicode，以及本地或近程MySQL服务器多连贯，用户可浏览数据库、建设和删除数据库、编辑数据、建设或执行SQL queries、治理用户权限（平安设定）、将数据库备份/还原、导入/导出数据（反对CSV、TXT、DBF和XML数据格式）等。 MySQL AdministratorMySQL Administrator是泛滥MySQL图形化管理工具中利用最宽泛的一种，是用来执行数据库治理操作的程序，以及用来监督和治理MySQL实例的数据库、用户的权限和数据的实用程序，比方MySQL服务的配置、管制、开启和敞开，还可用于治理用户和连贯数据库，执行数据备份和其余的一些治理工作。它有这几个长处：（1）它的图形化的用户界面为用户提供了十分直观的接口。（2）它提供了较好的全局设置，这对于MySQL服务器的可执行性、可信度和安全性是相当重要的。（3）它提供了图形化的性能显示，使停止服务器和更改服务器的设置更加简略。 MySQL的罕用语法创立库其中“jt_name”是将要创立的数据库名称，该名称不能与曾经存在的数据库重名。 CREAT DATABASE jt_name;查看库SHOW DATABASES;删除库其中“jt_name”是要删除的数据库名称，如果指定数据库名不存在，则删除出错。 DROP DATABASE jt_name;抉择数据库use 库名； use jt_name;MySQL的数据类型数值类型MySQL中反对多种整型，其实很大水平上是雷同的，只是存储值的大小范畴不同而已。tinyint：占用1个字节，绝对于java中的byte； smallint：占用2个字节，绝对于java中的short； int：占用4个字节，绝对于java中的int；bigint：占用8个字节，绝对于java中的long；其次是浮点类型即：float和double类型：float：4字节单精度浮点类型，绝对于java中的float；double：8字节双精度浮点类型，绝对于java中的double； 字符串类型1、char(n) 定长字符串，最长255个字符。n示意字符数，例如：-- 创立user表，指定用户名为char类型，字符长度不超过10 ...

你好，有幸相见。 从九月开始，我决定发动「每周一博」的指标：每周至多公布一篇博客，能够是各种源码剖析研读，也能够是记录工作中遇到的难题。 在通过了一段时间漫无目的的学习之后，我发现那样用途如同不大，看过的货色过段时间就忘了，而且也没有做什么笔记。 “凡所学，必有所输入。”我认为这才是最适宜我的学习形式，这也是「每周一博」流动的来由，敌人们，如果你也感觉常常会遗记以前看过的货色，一起退出这个流动吧。 本来应该是九月的第五篇博客，最终实现于十月的第一周，同时这也是 MySQL 系列的第二篇。 本文首发于集体博客: javageekers.club本文收录于集体语雀知识库: 我所了解的后端技术MySQL 系列的第二篇，次要探讨 MySQL 中对于索引的一些问题，包含索引品种、数据模型、索引执行流程、最左前缀准则、索引生效状况以及索引下推等内容。 最早晓得索引应该是在大二的数据库原理这门课中，当一个查问语句十分慢时，能够通过为某些字段增加索引来进步查问效率。 还有一个十分经典的例子：咱们能够把数据库设想成字典，把索引设想成目录，当咱们借助字典的目录来查问一个字的时候，就能体现出索引的作用了。 1. 索引品种在 MySQL 中，从索引的逻辑或者说字段个性来辨别，索引大抵分为以下几个品种：一般索引、惟一索引、主键索引、联结索引和前缀索引。 一般索引：最根底的索引，没有任何限度。惟一索引：索引列的值必须惟一。主键索引：非凡的惟一索引，作为主键它的值不能为空。联结索引：联结索引就是索引列为多个字段的一般索引，须要思考最左前缀准则。前缀索引：对字符类型的前几个字符或二进制类型的前几个字节建设索引。还有另外一种从物理存储上来辨别的索引分类：聚簇索引和非聚簇索引。 聚簇索引：索引程序与数据存储程序统一，其叶子节点存储的是数据行。非聚簇索引：非聚簇索引的叶子节点存储的是聚簇索引的值，同时它是基于聚簇索引创立的。简略来说，所谓的聚簇索引就是索引 key 与数据行在一起，而非聚簇索引的索引 key 对应的值是聚簇索引的值。 2. 索引的数据结构常见的用于实现索引的数据结构有哈希表、有序数组和搜寻树。 2.1 哈希索引哈希表是一个以 key-value 模式来存储数据的容器，和 HashMap 一样，哈希索引也会将 key 通过特定的哈希函数计算失去索引值，而后在数组的相应地位寄存 key 对应的 value，如果有两个 key 通过哈希函数计算失去的索引值雷同（产生哈希抵触），那么数组的这个地位就会变成一个链表，寄存所有哈希值雷同的 value。 所以在个别状况下，哈希表进行等值查问的工夫复杂度能够达到 O(1)，然而在产生哈希抵触的状况下，还须要额定遍历链表中的所有值，才可能找到符合条件的数据。 另外，思考到通过哈希函数计算失去的索引是不法则的——哈希表心愿所有的 key 可能失去充沛散列，这样能力让 key 均匀分布，不节约空间——即哈希表的 key 是非程序的，所以应用哈希表来进行区间查问时很慢的，排序也是同样的情理。 所以，哈希表仅实用于等值查问。 2.2 有序数组有序数组顾名思义是一个依照 key 的程序进行排列的数组，它进行等值查问的工夫复杂度应用二分查问能够达到O(logN)，这与哈希表相比逊色不少。 然而通过有序数组进行范畴查问的效率较高：首先通过二分查问找到最小值（或最大值），而后反向遍历，直到另一个边界。 至于排序，有序数组原本就是有序的，人造曾经排好序了，当然排序字段不是索引字段就另说了。 然而有序数组有一个毛病，因为数组元素是间断且有序的，如果此时插入新的数据行，为了维持有序数组的有序性，须要将比此元素 key 大的元素都往后挪动一个单位，给他腾出一个中央插入。而这种保护索引的形式的代价是很大的。 所以，有序数组适宜存储衣服初始化过后就不再更新的数据。 2.3 搜寻树理解过数据结构的人应该会晓得，搜寻树是一个查问工夫复杂度为O(logN)，更新的工夫复杂度也是O(logN)的数据结构。所以搜寻树相较于哈希表和有序数组来说兼顾查问与更新两方面。也正是因为这个起因，在 MySQL 中最罕用的数据模型就是搜寻树。 而思考到索引是寄存在磁盘中的，如果搜寻树是一棵二叉树，那么它的子节点只能有左右两个，在数据比价多的状况下，这棵二叉树的树高可能会十分高，当 MySQL 进行查问的时候，可能因为树高导致磁盘I/O次数过多，查问效率变慢。 ...

数据库实现高可用高可用：保障服务器尽可能的不宕机，保障用户能失常应用。 数据库的双机热备阐明：个别在公司中配置双机热备的模式，配置为互为主从。配置阐明：1.主库：192.168.126.1302.从库：192.168.126.129 /*实现主从的挂载*/CHANGE MASTER TO MASTER_HOST="192.168.126.130",MASTER_PORT=3306,MASTER_USER="root",MASTER_PASSWORD="root",MASTER_LOG_FILE="mysql-bin.000001",MASTER_LOG_POS=482/*启动主从服务*/START SLAVE /*查看主从状态*/SHOW SLAVE STATUS;实现数据库高可用配置阐明：批改实现数据库之后， 将配置文件上传即可 <?xml version="1.0"?><!DOCTYPE mycat:schema SYSTEM "schema.dtd"><mycat:schema xmlns:mycat="http://io.mycat/"> <!--name属性是自定义的 dataNode示意数据库的节点信息 jtdb示意逻辑库--> <schema name="jtdb" checkSQLschema="false" sqlMaxLimit="100" dataNode="jtdb"/> <!--定义节点名称/节点主机/数据名称--> <dataNode name="jtdb" dataHost="localhost1" database="jtdb" /> <!--参数介绍 UTF-8 中文报错--> <!--balance 0示意所有的读操作都会发往writeHost主机 --> <!--1示意所有的读操作发往readHost和闲置的主节点中--> <!--writeType=0 所有的写操作都发往第一个writeHost主机--> <!--writeType=1 所有的写操作随机发往writeHost中--> <!--dbType 示意数据库类型 mysql/oracle--> <!--dbDriver="native" 固定参数 不变--> <!--switchType=-1 示意不主动切换, 主机宕机后不会主动切换从节点--> <!--switchType=1 示意会主动切换(默认值)如果第一个主节点宕机后,Mycat会进行3次心跳检测,如果3次都没有响应,则会主动切换到第二个主节点--> <!--并且会更新/conf/dnindex.properties文件的主节点信息 localhost1=0 示意第一个节点.该文件不要随便批改否则会呈现大问题--> <dataHost name="localhost1" maxCon="1000" minCon="10" balance="1" writeType="0" dbType="mysql" dbDriver="native" switchType="1" slaveThreshold="100"> <heartbeat>select 1</heartbeat> <!--配置第一台主机次要进行写库操作,在默认的条件下Mycat次要操作第一台主机在第一台主机中曾经实现了读写拆散.因为默认写操作会发往137的数据库.读的操作默认发往141.如果从节点比较忙,则主节点分担局部压力. --> <writeHost host="hostM1" url="192.168.126.129:3306" user="root" password="root"> <!--读数据库1--> <readHost host="hostS1" url="192.168.126.130:3306" user="root" password="root" /> <!--读数据库2--> <readHost host="hostS2" url="192.168.126.129:3306" user="root" password="root" /> </writeHost> <!--定义第二台主机 因为数据库外部曾经实现了双机热备.--> <!--Mycat实现高可用.当第一个主机137宕机后.mycat会主动收回心跳检测.检测3次.--> <!--如果主机137没有给Mycat响应则判断主机死亡.则回启东第二台主机持续为用户提供服务.--> <!--如果137主机复原之后则处于期待状态.如果141宕机则137再次继续为用户提供服务.--> <!--前提:实现双机热备.--> <writeHost host="hostM2" url="192.168.126.130:3306" user="root" password="root"> <readHost host="hostS1" url="192.168.126.130:3306" user="root" password="root" /> <readHost host="hostS2" url="192.168.126.129:3306" user="root" password="root" /> </writeHost> </dataHost></mycat:schema>实现数据库高可用测试测试步骤：1.敞开主数据库,之后检索数据,检查用户的拜访是否受限.2.批改数据库记录,检查用户的操作是否失常. (操作的是从库).3.重启主数据库 之后查看从库的数据是否同步. ...

问题在 09 问中，咱们开启了 coredump 性能，在 MySQL 解体时取得了有用的 coredump 信息。 那如果没开启 coredump，仅有 error log 中的堆栈信息，咱们如何剖析无效的信息？ 试验咱们沿用 09 问中的 MySQL 解体的场景，此处疏忽复现解体的步骤，大家参看 09 问查看 error log： 咱们拿到了解体地位 0xee36f1，如何找到与之绝对的代码地位呢？找台测试机，获取对应版本的安装包： 解压： 而后用 GDB 关上 mysqld： 在 0xee36f1 地位打一个断点： 咱们能够看到，gdb 将解体地位的文件名和行号都打印进去，剩下的事件，就能够交给开发工程师，依照这个解体堆栈来进行问题排查。 赠送章节 红框内的这串信息是什么？咱们来解开看一下，这段信息分为两段，"+0x71" 是一个偏移量，后面是一串文字，咱们将文字解析进去： 能够看到后面这串文字是一个函数签名的编码，用 c++filt 还原编码当前，能够看到残缺的函数签名。红框内的这串信息的意思就是解体地位是 一个函数起始地位 + 偏移量。咱们大略能够猜到，这个 MySQL 的缺点是在为 binlog 产生新的文件名时产生的。 小贴士：函数起始地位 + 偏移量 是一种内存地位的示意办法，但该地位不肯定是这个函数内的代码。以本例来说，0xee36f1 这个地位，程序找到了就近的函数 generate_new_name 的起始地位，计算出有 0x71 这么多偏移，就示意成了 generate_new_name+0x71 这种模式。但 0xee36f1 这个地位的代码，大概率是，但，不肯定是 generate_new_name 这个函数外部的一段代码。 ...

前言： 对于数据库范式，时常有据说过，始终没有具体去理解。个别数据库书籍或数据库课程会介绍范式相干内容，范式也经常出现在数据库考试题目中。不分明你是否对范式有比拟清晰的理解呢？本篇文章咱们一起来学习下数据库范式吧。 1.数据库范式简介为了建设冗余较小、结构合理的数据库，设计数据库时必须遵循肯定的规定。在关系型数据库中这种规定就称为范式。范式是合乎某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足肯定的范式。 范式的英文名称是 Normal Form ，简称 NF 。它是英国人 E.F.Codd 在上个世纪70年代提出关系数据库模型后总结进去的。范式是关系数据库实践的根底，也是咱们在设计数据库构造过程中所要遵循的规定和领导办法。 目前关系型数据库有六种常见范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完满范式）。满足最低要求的范式是第一范式（1NF）。在第一范式的根底上进一步满足更多标准要求的称为第二范式（2NF），其余范式以次类推。 2.罕用范式详解在设计数据库时，会参考范式要求来做，然而并不是说遵循的范式等级越高越好，范式过高尽管具备对数据关系有更好的约束性，然而也会导致表之间的关系更加繁琐，从而导致每次操作的表会变多，数据库性能降落。通常，在关系型数据库设计中，最高也就遵循到 BCNF ，广泛还是 3NF 。即个别状况下，咱们应用前三个范式曾经够用了。上面咱们来具体理解下罕用的前三个范式。 第一范式（1NF） 第一范式是最根本的范式。如果数据库表中的所有字段值都是不可合成的原子值，就阐明该数据库表满足了第一范式。简略的讲第一范式就是每一行的各个数据都是不可分割的，同一列中不能有多个值，如果呈现反复的属性就须要定义一个新的实体。 示例：假如一家公司要存储其员工的姓名和联系方式。它创立一个如下表： 两名员工（Jon＆Lester）领有两个手机号码，因而公司将他们存储在同一表格中，如上表所示。那么该表不合乎 1NF ，因为规定说“表的每个属性必须具备原子（单个）值”，Jon＆Lester员工的 emp_mobile 值违反了该规定。为了使表合乎 1NF ，咱们应该有如下表数据： 第二范式（2NF） 第二范式在第一范式的根底之上更进一层。第二范式须要确保数据库表中的每一列都和主键相干，而不能只与主键的某一部分相干（次要针对联结主键而言）。也就是说在一个数据库表中，一个表中只能保留一种数据，不能够把多种数据保留在同一张数据库表中。 +----------+-------------+-------+| employee | department | head |+----------+-------------+-------+| Jones | Accountint | Jones || Smith | Engineering | Smith || Brown | Accounting | Jones || Green | Engineering | Smith |+----------+-------------+-------+上表形容了被雇佣者，工作部门和领导的关系。咱们把可能惟一示意数据库中表的一行的数据成为这个表的主键。表中 head 列不和主键相干。 因而，该表是不合乎第二范式的，为了使下面的表合乎第二范式，须要将它拆分为两个表： -- employee 为主键+----------+-------------+| employee | department |+----------+-------------+| Brown | Accounting || Green | Engineering || Jones | Accounting || Smith | Engineering |+----------+-------------+-- department 为主键+-------------+-------+| department | head |+-------------+-------+| Accounting | Jones || Engineering | Smith |+-------------+-------+第三范式（3NF） ...

1. sql查找一列中呈现次数大于8的记录select `POID` from `orderDetail` group by `POID` having count(*) >8;2. SQL查找汇合中的记录select `OID`from `orderHead`where `OID` in ( select `POID` from `orderDetail` group by `POID` having count(*) > 8);

mysql装置在指定目录1、版本：mysql-5.7.20-1.el7.x86_64.rpm-bundle.tar 装置依赖\# yum remove mariadb-libs //删除 mariadb相干内容\# yum install perl \# yum install numactl \# yum install libaio \# yum install net-tools 解压mysql安装包\# tar -xvf mysql-5.7.20-1.el7.x86_64.rpm-bundle.tar装置\# rpm -ivh commom ---- lib ------- client-------server按程序逐个装置实现 批改数据地址\# vim /etc/my.cnf SELINUX设置\# vim /etc/selinux/config把SELINUX的参数批改成disabled即可： 创立数据寄存目录\# mkdir /opt/mysqldata目录受权\# chown -R mysql:mysq /opt/mysqldata启动数据库\# systemctl start mysqld.service查看长期明码\# grep 'temporary password' /var/log/mysqld.log登录批改明码\# mysql -uroot -p alter user root@localhost identified by ‘root123’use mysql create user 'root'@'%' identified by 'root123'; ...

JNPF是一款优良的软件平台产品，可视化开发环境，新增的零代码开发，操作相当简略，流程化的表单开发让业务人员也能参加其中，做到所见即所得，大大提高开发效率，能帮忙公司大幅节俭人力老本和工夫老本，同时又不失灵活性。实用于搭建 OA、ERP、CRM、HR、HIS等所有的企业信息管理系统（且实用于集团公司部署）。 创立web表单 表单设计是配置大量可复用控件，通过拖拽的控件主动生成可视化利用 列表设计是配置页面显示列、查问条件、列表分页、 按钮配置等设置 对WEB设计进行删除、编辑、查问、复制、刷新和状态管制等性能操作 在菜单治理外面增加这个web表单性能菜单，而后就能够间接看到本人设计的表单页面

Explain 命令中的 type 列，显示MySQL查问所应用的 关联类型（Join Types） 或者 拜访类型，它表明 MySQL决定如何查找表中符合条件的行。常见拜访类型性能由最差到最优顺次为：ALL < index < range < index_subquery < unique_subquery < index_merge < ref_or_null < fulltext < ref < eq_ref < const < system。 0、测试环境简述本文 MySQL 实例版本为 5.7，表存储引擎为 InnoDB数据库 t 中有两张表 user、user_captcha，每张表中有2W+条数据，上面是两张表的建表语句（表构造只为满足试验要求，没有理论业务逻辑参考价值）： user 表id 字段是主键email 字段建设了惟一索引phone 与 country_code 字段组成联结惟一索引birth_year 与 gender 字段组成联结一般索引nickname 字段前10个字符建设了一般索引CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `nickname` varchar(255) DEFAULT NULL, `country_code` smallint(6) unsigned NOT NULL DEFAULT '0', `phone` varchar(12) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL DEFAULT '', `email` varchar(255) CHARACTER SET latin1 COLLATE latin1_bin DEFAULT NULL, `gender` tinyint(4) DEFAULT NULL, `birth_year` smallint(11) unsigned DEFAULT NULL, `created_at` int(11) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `unq_phone_country_code` (`phone`,`country_code`) USING BTREE, UNIQUE KEY `unq_email` (`email`), KEY `idx_birth_year_gender` (`birth_year`,`gender`) USING BTREE, KEY `idx_nickname` (`nickname`(10))) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4user_captcha 表id 字段是主键user_id 字段建设了惟一索引，能够为空receiver 字段建设了惟一索引CREATE TABLE `user_captcha` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_id` int(11) unsigned DEFAULT NULL, `code` char(6) COLLATE utf8_unicode_ci NOT NULL COMMENT '验证码', `retry_times` int(11) NOT NULL COMMENT '重试次数', `last_request_at` int(11) unsigned DEFAULT NULL COMMENT '最初申请工夫', `receiver` varchar(255) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL COMMENT '接收者（手机号或邮箱）', `created_at` int(11) NOT NULL, `expired_at` int(11) NOT NULL COMMENT '过期工夫', PRIMARY KEY (`id`), UNIQUE KEY `unq_receiver` (`receiver`) USING BTREE, UNIQUE KEY `unique_user` (`user_id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb41. ALL全表扫描，通常意味着MySQL必须从头到尾扫描整张表，去查找匹配的行的行，性能极差。然而，如果在查问里应用了 LIMIT n，尽管 type 仍然是 ALL，然而MySQL只须要扫描到符合条件的前 n 行数据，就会进行持续扫描。 ...

docker简介Docker提供了轻量级的虚拟化，它简直没有任何额定开销，这十分的cool，相比于虚拟机，你能够在同一台机器上创立更多容器，而且启动docker容器只须要几秒钟，这是传统的虚拟机无法比拟的，这也是docker一经公布，就火爆互联网的起因，其利用场景十分宽泛。 docker运行用户很多刚刚接触docker的敌人，根本都是用root进行治理docker容器，如下所示 [root@localhost ~]# docker ps -aCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESff668e421d59 mysql:5.7.28 "docker-entrypoint.s…" 38 hours ago Exited (137) 10 hours ago mysql5.7.28_3307423e39a1c866 mysql:5.7.28 "docker-entrypoint.s…" 38 hours ago Exited (137) 10 hours ago mysql5.7.28_330630482d5580fa mysql:5.7.28 "docker-entrypoint.s…" 7 months ago Exited (0) 46 hours ago mysql_dns_5.7.28669d7e9b8d4c phensley/docker-dns "./dockerdns --domai…" 7 months ago Exited (2) 46 hours ago dnsb4f8d09ddf11 mysql:8.0.18 "docker-entrypoint.s…" 8 months ago Exited (0) 10 days ago mysql8.0.18c8bc897479a9 mysql:5.7.28 "docker-entrypoint.s…" 8 months ago Exited (0) 45 hours ago mysql5.7.28[root@localhost ~]# [root@localhost ~]# docker start ff668e421d59ff668e421d59[root@localhost ~]# [root@localhost ~]# docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESff668e421d59 mysql:5.7.28 "docker-entrypoint.s…" 38 hours ago Up 8 seconds 33060/tcp, 0.0.0.0:3307->3306/tcp mysql5.7.28_3307[root@localhost ~]# 用root治理容器，的确十分的不便，快捷，不过存在平安危险，因为root是操作系统的最高权限，docker容器运维人员用root权限，如果其账号失落或者泄露，或者docker运维人员用root删除系统文件，就会造成严重后果，所以必须要做权限隔离。 ...

在Mysql 中删除数据以及数据表十分的容易，然而须要特地小心，因为一旦删除所有数据都会隐没。 删除数据删除表内数据，应用delete关键字。 删除指定条件的数据删除用户表内id 为1 的用户： delete from User where id = 1;删除表内所有数据删除表中的全副数据，表构造不变。 对于 MyISAM 会立即开释磁盘空间，InnoDB 不会开释磁盘空间。 delete from User;开释磁盘空间 optimize table User; 删除数据表删除数据表分为两种形式： 删除数据表内数据以及表构造只删除表内数据，保留表构造drop应用drop关键词会删除整张表，啥都没有了。 drop table User;truncatetruncate 关键字则只删除表内数据，会保留表构造。 truncate table User;思考题：如何批量删除前缀雷同的表？想要实现 drop table like 'wp_%'，没有间接可用的命令，不过能够通过Mysql 的语法来拼接。 -- 删除”wp_”结尾的表：SELECT CONCAT( 'drop table ', table_name, ';' ) AS statementFROM information_schema.tablesWHERE table_schema = 'database_name' AND table_name LIKE 'wp_%';其中database_name换成数据库的名称，wp_换成须要批量删除的表前缀。 留神只有drop命令能力这样用：drop table if exists tablename`;truncate只能这样应用：truncate table `tp_trade`.`setids`;总结当你不再须要该表时， 用drop;当你仍要保留该表，但要删除所有记录时， 用truncate;当你要删除局部记录时， 用delete。

本文次要是帮忙了解相干常识，没有具体的操作和代码。 事务事务就是一组操作，这组操作要么全副胜利，要么全副失败。 最经典的例子就是银行转账： 张三给李四转账100，对用户来说，就是一个操作。但对应到数据库中，至多须要三步： //查看张三账户余额是否大于等于100//张三账户-100//李四账户+100这三个操作能够没有程序，然而必须全副胜利或者全副失败。否则就可能导致张三损失100李四没收到，或者李四收到100然而张三没扣款胜利（银行损失100）。 MySQL默认引擎InnoDB，反对事务；MyISAM引擎不反对事务。事务的个性后面说的其实都是事务的概念，具体怎么实现或者有什么要求呢？ 一个运行良好的事务处理零碎，必须根本满足四个个性(ACID)，即原子性（atomicity）、一致性（consistency）、隔离性（isolation）和持久性（durability）。 原子性（atomicity）一个事务必须被视为一个不可分割的最小工作单元，整个事务中的所有操作要么全副提交胜利，要么全副失败回滚，对于一个事务来说，不可能只执行其中的一部分操作。（这个个性基本上等同于事务的定义，所以必须满足）。 一致性（consistency）数据库总是从一个一致性的状态转换到另外一个一致性的状态。在转账的例子中，若转账胜利，张三和李四的账户总额和转账前也是统一。 隔离性（isolation）一般来说，一个事务所做的批改在最终提交以前，对其余事务是不可见的。（这是本文的探讨的次要内容，因为在理论状况下，并不一定能保障隔离性。） 持久性（durability）一旦事务提交，则其所做的批改就会永恒保留到数据库中。此时即便零碎解体，批改的数据也不会失落。 事务的隔离级别事务间的隔离事务的四个个性中，原子性，一致性，持久性少数状况下都能保障。略微简单的是隔离性，因为咱们在学习的过程中很多时候都是单用户，单连贯，也就是一个事务执行实现再去执行另一个，很难领会到隔离性的外延。 无妨想一下春运时候的12306零碎，每个用户要实现的操作： //假如某一线路总票数100张//1.查问余票//2.买票即总票数-1//3.付款这三个操作组成一个事务，在高并发的状况下，一个用户甲执行到第二步，票数减到99，此时第二个用户乙查问余票，票数应该是100还是99 ？ 针对相似的疑难，SQL标准提出了四种情景，或者说用四种级别实现了不同的需要，不同级别决定了用户乙看到的是100还是99。 这四种级别别离是： READ UNCOMMITTED（未提交读）在READ UNCOMMITTED级别，事务中的批改，即便没有提交，对其余事务也都是可见的。 回到后面的例子，如果设置为这个级别，用户乙看到的将是99。这导致的问题是如果甲付款或者其余起因失败，乙读到其实是假数据，称为脏读。 脏读（Dirty Read）事务读取到未提交的数据。 READ COMMITTED（提交读）在READ COMMITTED级别，一个事务开始时，只能“看见”曾经提交的事务所做的批改。换句话说，一个事务从开始直到提交之前，所做的任何批改对其余事务都是不可见的。 这是少数数据库系统的默认隔离级别（但MySQL不是）。在后面的例子中，设置这个级别，乙看到的将是100。同样可能导致的问题是，乙在一次事务中，查问胜利后，甲付款胜利，票数变为99，乙再次查问，后果由100变成99。一次事务中两次查问后果不统一，也叫不可反复读。 不可反复读（nonrepeatable read）两次执行同样的查问，失去了不一样的后果。 REPEATABLE READ（可反复读）可反复读是MySQL的默认事务隔离级别。REPEATABLE READ解决了脏读的问题。保障了在同一个事务中屡次读取同样记录的后果是统一的（意思是对同样的数据批改不影响）。然而可反复读隔离级别无奈解决幻读的问题。 幻读（Phantom Read）所谓幻读，指的是当某个事务在读取某个范畴内的记录时，另外一个事务又在该范畴内插入了新的记录，当之前的事务再次读取该范畴的记录时，会产生幻行（Phantom Row）。 MySQL对于幻读的解决InnoDB和XtraDB存储引擎通过多版本并发管制（MVCC，Multiversion Concurrency Control）解决了幻读的问题。 InnoDB的MVCC是通过每一行加两个暗藏列来实现，一列记录行的创立工夫，一列记录行的过期工夫（或删除工夫），理论记录的是版本号而非具体工夫。 相当于行级锁，然而比加锁开销更低，也体现了一种用空间换工夫的思维。具体内容参考文档或者相干书籍。 对于这个级别到底是否齐全解决幻读问题，MySQL（8.0）文档是这样说的： This is the default isolation level for InnoDB. Consistent reads within the same transaction read the snapshot established by the first read. This means that if you issue several plain (nonlocking) SELECT statements within the same transaction, these SELECT statements are consistent also with respect to each other. ...

MySQL 是咱们作为后盾开发中十分重要的软件。前段时间作为面试官，面试了几位后盾开发的候选人——MySQL 的常识由浅入深一路问上来，并没有人可能残缺地答复进去。 于是我突发灵感，决定整顿一下 MySQL 的利用中须要理解的常识，做一个概要性的介绍，供后盾开发的读者参阅。 首先是第一篇：MySQL 简介和操作 本篇内容十分根底，可能很多读者都曾经理解了，因而能够间接跳过 SQL 和 MySQL 是什么？SQLSQL 的全称是 "Structured Query Language"，即 “结构化查询语言”，简称的读音在中文程序员圈子中常常被读作 "[s: kwl]"，不过实际上，应该读作 "[si: kwl]"。 SQL 定义了一系列数据查问的语法、函数定义等，形成了一套残缺的数据库操作交互语法。SQL 在1986年成为 ANSI 的一项规范，并于次年成为 ISO 的规范。在这之后，开始呈现大量基于 SQL 语法实现的数据库。 目前支流的几大 SQL 数据库有： MySQL、MariadDB、Percona Server: 最经典、应用最宽泛的开源分布式数据库PostgreSQL（读作 "post-gress-Q-L"，中文开发者喜爱简称 PG）: 集体认为是第二驰名的开源数据库，已经在地理信息系统数据存储中独领风骚Oracle Database: 甲骨文公司推出的关系型数据库，在晚期政府我的项目中简直是惟一指定洽购的数据库软件。集体倡议：互联网从业者就不必学了，当初至多国内都在去IOE化，而这其中的 O 指的就是 Oracle。Windows SQL Server: 一看到 Windows 打头的，后盾开发同学也能够不必学了。Wikipedia 说得很夸大：尽管有这一规范的存在，但大部分的SQL代码在不同的数据库系统中并不具备齐全的跨平台性。应该说规范的 SQL 标准和各家 SQL 数据库的实现均不完全一致，因而如果应用到了某一数据库略微进阶一点的 SQL，就无奈迁徙到另一个数据库上了。这一点须要注意。 MySQLMySQL 最早是在 1995 年由瑞典 MySQL AB 公司开发的开源的关系型数据库系统。当初 MySQL 及其分支者 MariaDB 曾经是互联网中应用最为宽泛的分布式关系型数据库系统，没有之一。 ...

聚簇，其实是绝对于InnoDB这个数据库引擎来说的，因而在将聚簇索引的时候，咱们通过InnoDB和MyISAM这两个MySQL的数据库引擎开展。 InnoDB和MyISAM的数据分布比照CREATE TABLE test (col1 int NOT NULL, col2 int NOT NULL, PRIMARY KEY(col1), KEY(col2));首先通过以上SQL语句创立出一个表格，其中col1是主键，两列数据均创立了索引。而后咱们数据的主键取值为1-10000，依照随机的程序插入数据库中。 MyISAM的数据分布MyISAM的数据存储逻辑比较简单，就是依照数据插入的程序创立出一个数据表格。直观上来看如下图：能够看出，数据就是依照插入的程序“一行一行”生成的。后面还会有一个行号的字段，用途就是在查找到索引的时候可能疾速地定位到该行索引的地位。咱们再来看一下具体的细节：上图展现的状况就是在MyISAM引擎下，依照主键建设的索引的具体实现。能够看出在主键依照顺序排列在叶子结点上的同时，节点中还存储着这个主键在数据库表格中存在的具体的行号，正如咱们下面所说的，这个行号能够帮忙咱们疾速地定位到表中数据的地位，也能够把这个行号了解为一个指针，指向了这个主键所在的具体数据行。那么如果咱们依照col2建设索引呢？会有什么不同吗？答案是不会的：所以失去的论断就是在MyISAM中建设索引是否是主键索引其实是没有区别的，惟一不同的就是这是一个“主键的索引”。 InnoDB的数据分布因为InnoDB反对聚簇索引，所以会与MyISAM上的索引实现形式有所区别。咱们先看看基于主键的聚簇索引在InnoDB上的实现形式：首先，和MyISAM上的主键索引一样，这里的索引的叶子结点上同样也是包含了主键的值，并且主键的值是依照顺序排列的。不同的是，每一个叶子结点还包含了事务id，回滚指针和其余非主键列的值（这里指的col2）。所以咱们能够了解为InnoDB上的聚簇索引，是将原来表格中的所有的行数据依照主键进行排列而后放在了索引的叶子节点上。这就是一个与MyISAM在主键索引上的一个不同。MyISAM的主键索引在查找到对应的主键值之后须要通过指针（行号）再去表中找到绝对应的数据行，而InnoDB的主键索引，将数据信息全副放在了索引外面，能够间接在索引中查找拿到。再来看看InnoDB中的二级索引的状况：能够看到，和InnoDB中的主键索引不同，二级索引并没有在叶子结点存储所有的行数据信息，而是除了索引列的值外，只存储了这个数据行所对应的主键的信息。咱们晓得在MyISAM中，二级索引和主键索引一样，除了索引列的值外，只存储了一个指针（行号）的信息。比照一下两个引擎上的二级索引。即存储指针和存储主键值的优劣。首先存储主键值会比只存储一个指针带来的空间开销更大。然而当咱们数据表在进行决裂或者其余扭转构造的操作的时候，存储主键值的索引并不会收到影响，而存储指针的索引，可能就要从新进行更新保护。 用一个图对两个引擎中的两种索引进行比照：

背景mysql 呈现 ERROR 1205: Lock wait timeout exceeded阐明有另外一个事务锁定了记录，该如何排查是哪个事务呢？ 过程INNODB_LOCK_WAITS 表再次执行SQL，让其试图获取锁。 SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;能够看出本次SQL的锁期待信息，拿到 blocking_lock_id，即是以后正在占用的lock_id, blocking_trx_id即是对应的事务 INNODB_LOCK 表 SELECT * FROM information_schema.INNODB_LOCK;能够查出具体的锁信息 INNODB_TRX 表 SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX where trx_id = "xxx";能够查出具体的事务信息，trx_mysql_thread_id即是对应的线程ID PROCESSLIST 表 select * from information_schema.`PROCESSLIST` where ID = "xxx"能够查到线程的详细信息，能够通过 kill xxx来终止过程从而强行开释锁

一、mySql罕用语句1、新增数据库 CREATE TABLE sys_list ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键ID，主动递增', title varchar(32) NOT NULL COMMENT '题目',content varchar(200) NOT NULL COMMENT '内容', photo varchar(32) NOT NULL COMMENT '图片',author varchar(32) NOT NULL COMMENT '作者',type enum('1','2') NOT NULL COMMENT '类型',createTime TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,updateTime TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,PRIMARY KEY (id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 2、新增一条数据insert into sys_list values(1,'题目1','内容1','','2020-10-07','2020-10-07') 3、查问一条数据select * from sys_brand d where d.id=1 //通过id查问select * from sys_brand d where d.title like '%标%' //通过title含糊查问 ...

当数据库性能呈现瓶颈时就须要通过扩大来晋升性能，对于扩展性来说要么增强机器自身的性能，要么把工作散发到不同的机器上。对于数据库来说通过强悍的机器解决老本是很大的，如Oracle。通过多个便宜的机器实现程度扩大是古代的支流解决方案，如Mysql。 数据库程度扩大的外围是把数据拆分成不同的单元并放在不同的独立的实例上，这样就做到了负载平衡。拆分分为逻辑和物理拆分，逻辑拆分是对物理上不可分割的实例进行逻辑上的宰割，物理拆分是拆分成多个独立的实例： 逻辑拆分 分区（Partition）分表物理拆分 读写拆散垂直拆分（分库）程度拆分（分表）1.逻辑拆分1.1 分区我了解的逻辑分区：举个例子，操作系统中的分区，是将硬盘依据大小进行逻辑分区，就是咱们看到的C、D、E、F盘，逻辑分区还是在同一个操作系统中。数据库产品的Partition分区也是一样的情理，将数据进行逻辑分区，对数据划分界线。 MySql 反对Range，List，Hash，Key。最罕用的是Range。_留神不同的版本对分区类型的反对有些不同！_ Range：范畴 CREATE TABLE employees ( id INT NOT NULL, fname VARCHAR(30), lname VARCHAR(30), hired DATE NOT NULL DEFAULT '1970-01-01', separated DATE NOT NULL DEFAULT '9999-12-31', job_code INT NOT NULL, store_id INT NOT NULL)PARTITION BY RANGE (store_id) ( PARTITION p0 VALUES LESS THAN (6), PARTITION p1 VALUES LESS THAN (11), PARTITION p2 VALUES LESS THAN (16), PARTITION p3 VALUES LESS THAN (21));LIST：列表 ...

索引是检索图书资料的一种工具，把书刊中的内容或我的项目分类摘录，注明页数，按肯定秩序排列。针对不同的数据存储构造有不同的数据查找形式。 1. 数据结构1.1 B树B树又名均衡多路查找树，次要用于文件系统中，在B树中，每个结点的大小为一个磁盘页，结点中所蕴含的关键字及其孩子的数目取决于页的大小。 对于一颗度为m的B树，须要满足： 根结点或叶子结点，至多有2颗子树，至少有m颗。非叶子结点至多有 m/2颗子树，至少有m颗。所有叶子结点都在同一层。每个结点都要蕴含（n，Ao，K1，A1，K2，A2，K3，A3，Kn，An） n是结点中关键字的个数，且 (m/2)-1 ≤ n ≤m-1，n+1为子树的棵数Ai(i=0，1，…，n)为指向孩子结点的指针，且Ai-1所指向的子树中所有结点的关键字都小于Ki ，Ai所指向的子树中所有结点的关键字都大于KiKi(1≤i≤n)是关键字，且Ki<Ki+1 (1≤i≤n-1)B树应用二分查找，蕴含两个基本操作： 在B树上查找结点：遍历整个树。在结点中查找关键字：每个结点中蕴含m个关键字，通过二分查找查问指标关键字。B树上关键字的减少和删除通过均衡算法达到均衡。 1.2 B+树B+树是B树的变体，在理论的文件系统中基本上不应用B树。B+树和B树的差别点： 若一个结点有n棵子树，则必含有n个关键字；所有叶子结点中蕴含了全副记录的关键字信息以及这些关键字记录的指针，而且叶子结点按关键字的大小从小到大程序链接；所有的非叶子结点能够看成是索引的局部，结点中只含有其子树的根结点中的最大(或最小)关键字。 B+树的非叶子结点不保留数据记录的指针信息，这意味着深度雷同时B+树比B树的关键字更多。 2.InnoDB索引类型2.1 B+树索引InnoDB中的主键索引和辅助索引都是采纳B+树。 B树的每个结点大小和磁盘页统一，磁盘每个页有4k，依据这个咱们就能够计算出索引的深度。假如是一颗齐全的m阶B+树，m的大小取决于非叶子结点存储关键字的数量，主键个别都是BIGINT 占8个字节，那么m=4*1024/8=512。 辅助索引的关键字按索引创立时定义列的程序来的，如：status + create_time，10 2020-8-1 B+树结点中的关键字都是按程序组织的，所以关键字的长度和类型决定了索引的性能： 关键字越短，B+树的结点就越多，树的深度也会在预期内。关键字值散布的越平均（反复少），B+树就越均衡。数字比字符串要快，因为字符串须要先做转换再做排序：字符串排序算法。在某些非凡场景关键字的值不须要平均，如：status字段有 1、2这两个值，1 -> 100条数据，2 -> 100万条数据，业务上只须要查问status为1的记录就会十分快，否则须要扫全表。 理解InnoDB索引的查找办法有助于咱们创立高效的索引： 全值匹配：比拟残缺的关键字。匹配最左前缀：只和索引定义的第一列进行匹配。匹配列前缀：只匹配第一列并且匹配关键字的前缀而非全值匹配。匹配范畴值：匹配两个关键字之间的值。（在B树中关键字是程序组织的，只有查问到以后关键字的父结点就能间接确认范畴）只拜访索引：不会查问数据行，像count这种操作就不须要再去查具体的行。2.2 哈希索引InnoDB中的哈希函数应用除留余数法，抵触采纳链地址法。 2.3 自适应哈希索引哈希是一种十分快的查找办法，工夫复杂度为O(1)，即只须要查问一次就能定位数据，而B+树的查找次数取决于树的高度。InnoDB存储引擎会监控对表上各索引页的查问。如果察看到建设哈希 索引能够带来速度晋升，则建设哈希索引，称之为自适应哈希索引 (Adaptive Hash Index，AHI)。AHI是通过缓冲池的B+树页结构而来，因而建设的速度很快，而且不须要对整张表构建哈希索引。InnoDB存储引擎会主动依据拜访的频率和模式来主动地为某些热点页 建设哈希索引。 AHI有一个要求，即对这个页的间断拜访模式必须是一样的。例如对 于(a，b)这样的联结索引页，其拜访模式能够是以下状况。 模式： WHERE a=xxxWHERE a=xxx and b=xxx条件： 以该模式拜访了100次页通过该模式拜访了N次，其中N=页中记录*1/16自适应hash索引是mysql的性能，开发者并不能管制，尽管如此还是要尽可能的利用，如果性能无奈满足再抉择缓存中间件。 参考： Mysql官网文档《Mysql及时底细 InnoDB存储引擎》https://blog.csdn.net/voidccc/article/details/40077329Jeremy Cole The physical structure of InnoDB index pagesJeremy Cole B+Tree index structures in InnoDBJeremy Cole The physical structure of records in InnoDB

1. ACID模型事务是一种操作数据的形式，一个事务能够是一条SQL语句，一组SQL语句或整个程序，满足以下特色： Atomic（原子性）：事务中蕴含的操作被看做一个逻辑单元，要么都胜利，要么都失败Consistency（一致性）：一致性指事务将数据库从统一状态转变为下一种统一的状态。在事务开始之前和事务完结当前，数据库的完整性束缚没有被毁坏。Isolation（隔离性）：隔离不同事务，防止相互烦扰，保障所见即所得Durability（持久性）：事务一旦提交就是永久性的。产生宕机等故障，数据库也能复原2. InnoDB的实现InnoDB和ACID模型：https://dev.mysql.com/doc/refman/5.6/en/mysql-acid.html 2.1 redo & undoredo log称为重做日志，是物理日志，记录的是磁盘页的批改操作。redo log包含两局部：一是内存中的日志缓冲(redo log buffer)，该局部日志是易失性的；二是磁盘上的重做日志文件(redo log file)，该局部日志是长久的。undo log是逻辑日志，记录的是数据行记录。undo log也蕴含两局部：undo log buffer、undo log。 2.2 持久性事务一旦提交操作胜利，该事务所做的更改就不会受到电源故障、零碎解体等问题影响。持久性通常波及到对磁盘存储的写入，并具备肯定数量的冗余，以避免写入操作期间呈现电源故障或软件解体。InnoDB通过Force Log at Commit机制实现事务的持久性，即当事务提交时，必须先将该事务的所有日志写入到重做日志文件进行长久化，待事务的commit操作实现才算实现。在InnoDB存储引擎中，由两局部组 成，即redo log和undo log。redo log用来保障事务的持久性，undo log用来帮忙事务回滚及MVCC的性能。redo log基本上都是程序写的，在数据库运行时不须要对redo log的文件进行读取操作。而undo log是须要进行随机读写的。 刷数到磁盘是在commit时产生的，有3中不同到策略，通过innodb_flush_log_at_trx_commit参数管制： master thread会每秒把redo log buffer和undo log buffer刷新到磁盘中，即便没有commit，这就是为什么即便是长事务，commit操作也很快的起因。所以设置为0时，理论是没有额定操作。2比1要平安，因为1是把数据写入用户空间，mysql服务挂了数据就丢了，2会把数据写入零碎空间，只会在服务器宕机是产生数据失落。 尽管用户能够通过设置参数innodb_flush_log_at_trx_commit为0或2来提 高事务提交的性能，然而须要牢记的是，这种设置办法丢失了事务的ACID个性。 2.3 隔离性隔离性要解决的几个问题： 1.脏读 事务A对缓冲池中的数据做了批改并且还没有被提交（commit），这时被另外一个事务B读取到了数据，因为查问是优先走缓存的。2.不可反复读 事务A中对同一行数据屡次读取，如果在这期间事务B对数据进行了批改，那么事务A会读取到提交过的数据，造成了不统一。3.幻读 可反复读要求对雷同数据屡次查问后果要统一，显然幻读并不属于不可反复读，对幻读的解决是在serializable级别中，然而InnoDB在RR级别就解决了幻读问题，心愿不要把这两个概念搞混。 事务A查问orderid=1 and status=1的记录，发现记录不存在操作insert事务B插入orderid=1 and status=1的记录，commit事务A commit数据反复插入4.失落更新 失落更新体现逻辑上，事务A的更新操作会被事务B笼罩，如： 事务A把状态改为2，未commit事务B把状态改为3，commit事务A commit，应用程序继续执行后续操作这时就产生了逻辑谬误，即：以后状态没有改为2，不合乎逻辑预期。 ANSI/ISO SQL规范定义了4中事务隔离级别 上面解读一下RC和RR级别 2.3.1 RC 解决脏读RC级别次要为了解决脏读，即：不能读取到未提交的数据。通过MVCC来实现，MVCC多版本并发管制指的是 “维持一个数据的多个版本，使得读写操作没有抵触” 这么一个概念。 ...

背景测试mysql5.7和mysql8.0 别离在读写、只读、只写模式下不同并发时的性能（tps，qps） 前提测试应用版本为mysql5.7.22和mysql8.0.15sysbench测试前先重启mysql服务，并清空os的cache（防止屡次测试时命中缓存）每次进行测试都是新生成测试数据后再进行mysql5.7和mysql8.0的测试每次测试时保障mysql5.7和mysql8.0的配置参数统一环境机器 cat /etc/redhat-release | xargs echo '版本 ' && dmidecode -s system-product-name | xargs echo '是否虚拟化 ' && cat /proc/cpuinfo |grep "processor"|wc -l | xargs echo 'cpu核数 ' 版本 CentOS Linux release 7.5.1804 (Core)  是否虚拟化 KVM  cpu核数 4myql5.7.22 5.7.22-loginnodb_buffer_pool_size 128Minnodb_log_buffer_size  64Minnodb_log_file_size    48Mbinlog_format   ROWlog_bin ONtransaction_isolation   REPEATABLE-READmysql8.0.15 8.0.15innodb_buffer_pool_size 128Minnodb_log_buffer_size  64Minnodb_log_file_size    48Mbinlog_format   ROWlog_bin ONtransaction_isolation   REPEATABLE-READsysbench sysbench -Vsysbench 1.1.0 (using bundled LuaJIT 2.1.0-beta3)测试在不同的长久化策略下（binlog, redo log长久化）mysql5.7和mysql8.0 在读写模式、只读模式、只写模式（oltp_read_write，oltp_read_only，oltp_write_only）下的性能体现sysbench 测试工夫为60s，测试的表数量为20测试别离在双1模式（安全性）和0 2模式（高性能）下进行双1模式下SHOW GLOBAL  VARIABLES WHERE Variable_name IN('sync_binlog','innodb_flush_log_at_trx_commit');+--------------------------------+-------+| Variable_name                  | Value |+--------------------------------+-------+| innodb_flush_log_at_trx_commit | 1     || sync_binlog                    | 1   |+--------------------------------+-------+mysql5.7和mysql8.0 在读写模式下的体现 双1 配置，读写模式下，mysql5.7.22 和mysql8.0.15 tps 、qps 性能差不多，mysql8.0.15 在120 线程并发时，性能呈现了降落抖动：mysql5.7和mysql8.0 在只读模式下的体现 双1 配置，只读模式下，mysql5.7.22 的tps、qps比mysql8.0.15 好1/3 左右；并发线程数减少后，tps、qps并没有随着减少，反而呈现了降落的趋势。mysql5.7和mysql8.0 在只写模式下的体现 双1 配置，只写模式下，随着并发数的回升，mysql5.7.22 的性能比mysql8.0.15 好1/4左右。0 2 模式下 SHOW GLOBAL  VARIABLES WHERE Variable_name IN('sync_binlog','innodb_flush_log_at_trx_commit');+--------------------------------+-------+| Variable_name                  | Value |+--------------------------------+-------+| innodb_flush_log_at_trx_commit | 2     || sync_binlog                    | 0   |+--------------------------------+-------+mysql5.7和mysql8.0 在读写模式下的体现 0 2配置，读写模式下，并发数低时，mysql5.7.22性能好于mysql8.0.15; 并发数比拟高时，mysql8.0.15 性能好于mysql5.7.22；在80 线程的并发以上时，性能开始降落。mysql5.7和mysql8.0 在只读模式下的体现 0 2配置，只读模式下，mysql5.7.22性能比mysql8.0.15 好1/3左右；随着并发数的回升，性能也没有回升，反而有降落的趋势.mysql5.7和mysql8.0 在只写模式下的体现 0 2 配置，只写模式下，mysql5.7.22的tps 抖动比拟大；mysql5.7.22 的qps比mysql8.0.15好1/3左右论断整体来看，mysql5.7.22在读写模式、只读模式、只写模式下的体现是优于mysql8.0.15的随着并行数的减少，性能体现不会也跟着减少，还会呈现降落本次测试后果是在配置很低的状况下进行的，不代表相对留神sysbench 须要设置--db-ps-mode=disable 禁用预编译语句，不然并发测试线程多时会报上面的谬误 FATAL: mysql_stmt_prepare() failedFATAL: MySQL error: 1461 "Can't create more than max_prepared_stmt_count statements (current value: 16382)"FATAL: mysql_stmt_prepare() failedFATAL: MySQL error: 1461 "Can't create more than max_prepared_stmt_count statements (current value: 16382)"FATAL: thread_init' function failed: /usr/local/share/sysbench/oltp_common.lua:288: SQL API error FATAL: mysql_stmt_prepare() failed FATAL: MySQL error: 1461 "Can't create more than max_prepared_stmt_count statements (current value: 16382)" FATAL:thread_init' function failed: /usr/local/share/sysbench/oltp_common.lua:288: SQL API errorFATAL: mysql_stmt_prepare() failed应用脚本 cat sysbench_test_mysql5.7_8.0_tps_qps.sh#!/bin/bash#用于sysbench 测试在读写模式、只读模式、只写模式下 mysql5.7和mysql8.0 的tps,qps#nohup bash $0 >/tmp/sysbench_test 2>& 1 &#user=adminpasswd=adminports="8015 57222"host=127.0.0.1sysbench_test_mode="oltp_read_write oltp_read_only oltp_write_only"sysbench_test_info_path=/tmp/sysbench-testfunction red_echo () {        local what="$*"        echo -e "$(date +%F-%T) e[1;31m ${what} e[0m"}function check_las_comm(){    if [ $1 -ne 0 ];then        red_echo $2        exit 1    fi}function  restart_mysqld(){  service mysqld${1} restart  sleep 2}function  purge_binlog(){port=$1mysql -u$user -p$passwd -P$port -h$host<<EOFpurge binary logs before now();EOF}function clean_os_cache(){  echo 3 > /proc/sys/vm/drop_caches}function  sysbench_with_diff_thread(){thread_num=$1port=$2order=$3test_mode=$4sysbench /usr/local/share/sysbench/${test_mode}.lua --mysql_storage_engine=innodb  --table-size=100000 --tables=20 --mysql-db=test_1 --mysql-user=$user --mysql-password=$passwd --mysql-port=$port  --mysql-host=$host --threads=$thread_num  --time=60 --report-interval=2 --db-ps-mode=disable --events=0 --db-driver=mysql $order}function  main(){for test_mode in $sysbench_test_mode;do  for port in $ports;do    for thread_num in {5,10,20,30,40,80,120,200};do      restart_mysqld "$port"      check_las_comm  "$?" "restart mysqld${port} failed "      clean_os_cache      purge_binlog "$port"      red_echo "sysbench $thread_num  threads cleanup mysqld${port}"      sysbench_with_diff_thread "$thread_num" "$port" "cleanup" "$test_mode">/dev/null      red_echo "sysbench $thread_num  threads prepare mysqld${port}"      sysbench_with_diff_thread "$thread_num" "$port" "prepare" "$test_mode">/dev/null      mkdir -p $sysbench_test_info_path      red_echo "sysbench $thread_num  threads run mysqld${port} $test_mode"      sysbench_with_diff_thread "$thread_num" "$port" "run" "$test_mode" > $sysbench_test_info_path/${test_mode}_${thread_num}_$port      # service mysqld{port} stop    done  donedone}main作者：jiaxin出处：https://www.cnblogs.com/YangJ...

这是我最近新接触到的一个函数, 我在我的项目中的应用场景是这样的: 有一个利用类型表,表中有parentId字段和parentIds字段,前者为父级id,后者为多级父级id,在库中都是varchar类型,parentIds由多个父级id拼接而成由","分隔. 组长告知我能够应用该函数,就去进行了理解与应用. 语法FIND_IN_SET(str,strlist) 定义如果字符串str在由多个子链组成的字符串列表strlist中，则返回值的范畴在1到N之间。一个字符串列表就是一个由一些被‘,’符号离开的自链组成的字符串。如果第一个参数是一个常数字符串，而第二个是typeSET列，则FIND_IN_SET()函数被优化，应用比特计算。如果str不在strlist或strlist为空字符串，则返回值为0。如任意一个参数为NULL，则返回值为NULL。这个函数在第一个参数蕴含一个逗号(‘,’)时将无奈失常运行。strlist：一个由英文逗号“,”链接的字符串，例如："a,b,c,d"，该字符串模式上相似于SET类型的值被逗号给链接起来。 示例：SELECT FIND_IN_SET('b','a,b,c,d'); //返回值为2，即第2个值 例子有个文章表外面有个type字段，它存储的是文章类型，有 1头条、2举荐、3热点、4图文等等 。当初有篇文章他既是头条，又是热点，还是图文，type中以 1,3,4 的格局存储。那咱们如何用sql查找所有type中有4的图文类型的文章呢？这就能够应用 find_in_set 了。以下为援用的内容：select * from article where FIND_IN_SET('4',type)

摘要：Mysql 和Oracle，别再傻傻分不清。mysql 和Oracle 在开发中的应用是随处可见的，那就简略去理解一下这俩款火的不行的数据库。 本质区别：Oracle数据库是一个对象关系数据库管理系统（免费）MySQL是一个开源的关系数据库管理系统（收费）数据库的安全性：mysql应用三个参数来验证用户，即用户名，明码和地位Oracle应用了更多的平安性能，如用户名，明码，配置文件，本地身份验证，内部身份验证，高级平安加强性能等权限MySQL的权限零碎是通过继承造成的分层构造。权限授于高层时，其余低层隐式继承被授于的权限，当然低层也可改写这些权限。 按受权范畴不同，MySQL有以下种受权形式： 1、全局； 2、基于每个主机； 3、基于表； 4、基于表列。 每一级在数据库中都有一个受权表。当进行权限查看时，MySQL从高到低查看每一张表，低范畴受权优先于高范畴受权。 与Oracle不同，MySQL没有角色的概念。也就是说，如果对一组用户授于同样的权限，须要对每一个用户别离受权。 模式迁徙模式蕴含表、视图、索引、用户、束缚、存储过程、触发器和其余数据库相干的概念。少数关系型数据库都有类似的概念。 蕴含内容如下： 模式对象的相似性；模式对象的名称；表设计时的关注点；多数据库整合；MySQL模式整合的关注点。模式对象的相似性就模式对象，Oracle和MySQL存储诸多的类似，但也有一些不同 模式对象的名称Oracle是大小写不敏感的，并且模式对象是以在写时行存储。在Oracle的世界中，列、索引、存储过程、触发器以及列别名都是大小写不敏感，并且在所有平台都是如此。MySQL是大小写敏感的，如数据库绝对的存储门路、表对应的文件都是如此 当把关键字用引号引起来时，Oracle和MySQL都容许把这些关键字用于模式对象。但MySQL对于一些关键字，不加引号也行。 表设计的关注点1、字符数据的类型； 2、列默认值。 3.2.3.1 字符数据类型 (1) Oracle反对4种字体类型：CHAR、NCHAR、NVARCHAR2和VARCHAR2。CHAR和NCHAR的最大长度为2000字节， NVARCHAR2和VARCHAR2最大长度为4000字节。 (2)MySQL和Oracle在字符型数据保留和读取上存在一些不同。MySQL的字符类型，如CHAR和VARCHAR的长度小于65535字节。Oracle反对4种字体类型：C HAR、NCHAR、NVARCHAR2和VARCHAR2。CHAR和NCHAR的最大长度为2000字节，NVARCHAR2和VARCHAR2最大长度为4000字节。 （3.2.3.2 列默认值） MySQL会解决列默认值，不容许他为空，这点和Oracle不同。在Oracle中如果向表插入数据，须要对有所有不容许为NULL列的值。 多数据库迁徙如果多个MySQL数据库位于同一个数据库服务上，反对迁徙。 数据存储概念MySQL的数据库对应于服务器上数据目录内的了目录，这一数据存储形式与多数据数据库不同，也包含Oracle。数据库中的表对应一个或者多个数据库目录下的文件，并取表存储时的存储引擎。 一个Oracle数据库蕴含一个或者多个表空间。表空间对应数据在磁盘上的物理存储。表空间是从一个或者多个数据文件开始构建的。数据文件是文件系统中的文件或者原始存储的一块空间。 语法上的区别：主键：mysql个别应用主动增长类型，在创立表的时候指定表的主键为auto increment，主键就会主动增长。Oracle中没有主动增长，主键个别应用序列，插值时顺次赋值即可引号问题：Oracle不应用双引号，会报错mysql则对引号没有限度分页查问：mysql分页查问应用关键字limit来实现Oracle没有实现分页查问的关键字，实现起来较简单，在每个后果集中只有一个rownum字段表明它的地位，并且只能用rownum<=某个数，不能用rownum>=某个数，因为ROWNUM是伪列，在应用时所以须要为ROWNUM取一个别名，变成逻辑列，而后来操作数据类型：mysql中的整型：int（），字符串类型：varchar（）Oracle中的整形：number（），字符串类型：varchar2（）点击关注，第一工夫理解华为云陈腐技术~

集体公众号：月伴飞鱼，欢送关注 先看看具体有哪些字段： mysql> EXPLAIN SELECT 1; 其实除了以SELECT结尾的查问语句，其余的DELETE、INSERT、REPLACE以及UPDATE语句前边都能够加上EXPLAIN这个词儿，用来查看这些语句的执行打算 建两张测试表： CREATE TABLE t1 ( id INT NOT NULL AUTO_INCREMENT, key1 VARCHAR(100), key2 VARCHAR(100), key3 VARCHAR(100), name VARCHAR(100), PRIMARY KEY (id), KEY idx_key1 (key1), KEY idx_key2_key3(key2, key3)) Engine=InnoDB CHARSET=utf8;CREATE TABLE t2 ( id INT NOT NULL AUTO_INCREMENT, key1 VARCHAR(100), key2 VARCHAR(100), key3 VARCHAR(100), name VARCHAR(100), PRIMARY KEY (id), KEY idx_key1 (key1), KEY idx_key2_key3(key2, key3)) Engine=InnoDB CHARSET=utf8;两个变种explain extended会在 explain 的根底上额定提供一些查问优化的信息。紧随其后通过 show warnings 命令能够 失去优化后的查问语句，从而看出优化器优化了什么 ...

MySQL 有多种存储引擎，每种存储引擎有各自的优缺点，能够择优抉择应用： MyISAM、InnoDB、MERGE、MEMORY(HEAP)、BDB(BerkeleyDB)、EXAMPLE、FEDERATED、ARCHIVE、CSV、BLACKHOLE。 MySQL反对数个存储引擎作为对不同表的类型的处理器。MySQL存储引擎包含处理事务平安表的引擎和解决非事务平安表的引擎： MyISAM治理非事务表。它提供高速存储和检索，以及全文搜寻能力。MyISAM在所有MySQL配置里被反对，它是默认的存储引擎，除非你配置MySQL默认应用另外一个引擎。MEMORY存储引擎提供"内存中"表。MERGE存储引擎容许汇合将被解决同样的MyISAM表作为一个独自的表。就像MyISAM一样，MEMORY和MERGE存储引擎解决非事务表，这两个引擎也都被默认蕴含在MySQL中。正文：MEMORY存储引擎正式地被确定为HEAP引擎。 InnoDB和BDB存储引擎提供事务平安表。BDB被蕴含在为反对它的操作系统公布的MySQL-Max二进制散发版里。InnoDB也默认被包含在所 有MySQL 5.1二进制散发版里，你能够依照爱好通过配置MySQL来容许或禁止任一引擎。EXAMPLE存储引擎是一个"存根"引擎，它不做什么。你能够用这个引擎创立表，但没有数据被存储于其中或从其中检索。这个引擎的目标是服务，在 MySQL源代码中的一个例子，它演示阐明如何开始编写新存储引擎。同样，它的次要趣味是对开发者。NDB Cluster是被MySQL Cluster用来实现宰割到多台计算机上的表的存储引擎。它在MySQL-Max 5.1二进制散发版里提供。这个存储引擎以后只被Linux, Solaris, 和Mac OS X 反对。在将来的MySQL散发版中，咱们想要增加其它平台对这个引擎的反对，包含Windows。ARCHIVE存储引擎被用来无索引地，十分小地笼罩存储的大量数据。CSV存储引擎把数据以逗号分隔的格局存储在文本文件中。BLACKHOLE存储引擎承受但不存储数据，并且检索总是返回一个空集。FEDERATED存储引擎把数据存在近程数据库中。在MySQL 5.1中，它只和MySQL一起工作，应用MySQL C Client API。在将来的散发版中，咱们想要让它应用其它驱动器或客户端连贯办法连贯到另外的数据源。比拟罕用的是 MyISAM 和 InnoBD

目录： 用一个守业公司的倒退作为背景引入用多台服务器来分库撑持高并发读写大量分表来保障海量数据下查问性能读写拆散来撑持按需扩容及性能晋升高并发下的数据库架构设计总结“ 这篇文章，咱们来聊一下对于一个撑持日活百万用户的高并零碎，他的数据库架构应该如何设计？ 看到这个题目，很多人第一反馈就是：分库分表啊！ 然而实际上，数据库层面的分库分表到底是用来干什么的，他的不同的作用如何应答不同的场景，我感觉很多同学可能都没搞清楚。 （1）用一个守业公司的倒退作为背景引入 如果咱们当初是一个小守业公司，注册用户就20万，每天沉闷用户就1万，每天单表数据量就1000，而后高峰期每秒钟并发申请最多就10。 天哪！就这种零碎，轻易找一个有几年工作教训的高级工程师，而后带几个年老工程师，轻易干干都能够做进去。 因为这样的零碎，实际上次要就是在后期疾速的进行业务性能的开发，搞一个单块零碎部署在一台服务器上，而后连贯一个数据库就能够了。 接着大家就是不停的在一个工程里填充进去各种业务代码，尽快把公司的业务撑持起来，如下图所示。 后果呢，没想到咱们运气这么好，碰上个优良的CEO带着咱们走上了坎坷不平！ 公司业务倒退迅猛，过了几个月，注册用户数达到了2000万！每天沉闷用户数100万！每天单表新增数据量达到50万条！高峰期每秒申请量达到1万！ 同时公司还顺带着融资了两轮，估值达到了惊人的几亿美金！一只暮气沉沉的幼年独角兽的节奏！ 好吧，当初大家感觉压力曾经有点大了，为啥呢？ 因为每天单表新增50万条数据，一个月就多1500万条数据，一年下来单表会达到上亿条数据。 通过一段时间的运行，当初咱们单表曾经两三千万条数据了，勉强还能撑持着。 然而，眼见着零碎拜访数据库的性能怎么越来越差呢，单表数据量越来越大，拖垮了一些简单查问SQL的性能啊！ 而后高峰期申请当初是每秒1万，咱们的零碎在线上部署了20台机器，均匀每台机器每秒撑持500申请，这个还能抗住，没啥大问题。然而数据库层面呢？ 如果说此时你还是一台数据库服务器在撑持每秒上万的申请，负责任的通知你，每次高峰期会呈现下述问题： 你的数据库服务器的磁盘IO、网络带宽、CPU负载、内存耗费，都会达到十分高的状况，数据库所在服务器的整体负载会十分重，甚至都快不堪重负了高峰期时，原本你单表数据量就很大，SQL性能就不太好，这时加上你的数据库服务器负载太高导致性能降落，就会发现你的SQL性能更差了最显著的一个感觉，就是你的零碎在高峰期各个性能都运行的很慢，用户体验很差，点一个按钮可能要几十秒才进去后果如果你运气不太好，数据库服务器的配置不是特地的高的话，弄不好你还会经验数据库宕机的状况，因为负载太高对数据库压力太大了（2）多台服务器分库撑持高并发读写 首先咱们先思考第一个问题，数据库每秒上万的并发申请应该如何来撑持呢？要搞清楚这个问题，先得明确个别数据库部署在什么配置的服务器上。 通常来说，如果你用一般配置的服务器来部署数据库，那也起码是16核32G的机器配置。 这种十分一般的机器配置部署的数据库，个别线上的教训是：不要让其每秒申请撑持超过2000，个别管制在2000左右。 管制在这个水平，个别数据库负载绝对正当，不会带来太大的压力，没有太大的宕机危险。 所以首先第一步，就是在上万并发申请的场景下，部署个5台服务器，每台服务器上都部署一个数据库实例。 而后每个数据库实例里，都创立一个一样的库，比如说订单库。此时在5台服务器上都有一个订单库，名字能够相似为：db_order_01，db_order_02，等等。 而后每个订单库里，都有一个雷同的表，比如说订单库里有订单信息表，那么此时5个订单库里都有一个订单信息表。 比方db_order_01库里就有一个tb_order_01表，db_order_02库里就有一个tb_order_02表。 这就实现了一个根本的分库分表的思路，原来的一台数据库服务器变成了5台数据库服务器，原来的一个库变成了5个库，原来的一张表变成了5个表。 而后你在写入数据的时候，须要借助数据库中间件，比方sharding-jdbc，或者是mycat，都能够。 你能够依据比方订单id来hash后按5取模，比方每天订单表新增50万数据，此时其中10万条数据会落入db_order_01库的tb_order_01表，另外10万条数据会落入db_order_02库的tb_order_02表，以此类推。 这样就能够把数据平均扩散在5台服务器上了，查问的时候，也能够通过订单id来hash取模，去对应的服务器上的数据库里，从对应的表里查问那条数据进去即可。 根据这个思路画出的图如下所示，大家能够看看。 做这一步有什么益处呢？第一个益处，原来比方订单表就一张表，这个时候不就成了5张表了么，那么每个表的数据就变成1/5了。 假如订单表一年有1亿条数据，此时5张表里每张表一年就2000万数据了。那么假如以后订单表里曾经有2000万数据了，此时做了上述拆分，每个表里就只有400万数据了。 而且每天新增50万数据的话，那么每个表才新增10万数据，这样是不是初步缓解了单表数据量过大影响零碎性能的问题？ 另外就是每秒1万申请到5台数据库上，每台数据库就承载每秒2000的申请，是不是一下子把每台数据库服务器的并发申请升高到了平安范畴内？这样，升高了数据库的高峰期负载，同时还保障了高峰期的性能。 （3）大量分表来保障海量数据下的查问性能 然而上述的数据库架构还有一个问题，那就是单表数据量还是过大，当初订单表才分为了5张表，那么如果订单一年有1亿条，每个表就有2000万条，这也还是太大了。所以还应该持续分表，大量分表。 比方能够把订单表一共拆分为1024张表，这样1亿数据量的话，扩散到每个表里也就才10万量级的数据量，而后这上千张表扩散在5台数据库里就能够了。 在写入数据的时候，须要做两次路由，先对订单id hash后对数据库的数量取模，能够路由到一台数据库上，而后再对那台数据库上的表数量取模，就能够路由到数据库上的一个表里了。 通过这个步骤，就能够让每个表里的数据量十分小，每年1亿数据增长，然而到每个表里才10万条数据增长，这个零碎运行10年，每个表里可能才百万级的数据量。 这样能够一次性为零碎将来的运行做好短缺的筹备，看上面的图，一起来感受一下： （4）读写拆散来撑持按需扩容以及性能晋升 这个时候整体成果曾经挺不错了，大量分表的策略保障可能将来10年，每个表的数据量都不会太大，这能够保障单表内的SQL执行效率和性能。 而后多台数据库的拆分形式，能够保障每台数据库服务器承载一部分的读写申请，升高每台服务器的负载。 然而此时还有一个问题，如果说每台数据库服务器承载每秒2000的申请，而后其中400申请是写入，1600申请是查问。也就是说，增删改的SQL才占到了20%的比例，80%的申请是查问。 此时如果说随着用户量越来越大，如果又变成每台服务器承载4000申请了。那么其中800申请是写入，3200申请是查问，如果说你依照目前的状况来扩容，就须要减少一台数据库服务器. 然而此时可能就会波及到表的迁徙，因为须要迁徙一部分表到新的数据库服务器下来，是不是很麻烦？ 其实齐全没必要，数据库个别都反对读写拆散，也就是做主从架构。写入的时候写入主数据库服务器，查问的时候读取从数据库服务器，就能够让一个表的读写申请离开落地到不同的数据库下来执行。 这样的话，如果写入主库的申请是每秒400，查问从库的申请是每秒1600，那么图大略如下所示。 写入主库的时候，会主动同步数据到从库下来，保障主库和从库数据统一。而后查问的时候都是走从库去查问的，这就通过数据库的主从架构实现了读写拆散的成果了。 当初的益处就是，如果说当初主库写申请减少到800，这个无所谓，不须要扩容。而后从库的读申请减少到了3200，须要扩容了。 这时，你间接给主库再挂载一个新的从库就能够了，两个从库，每个从库撑持1600的读申请，不须要因为读申请增长来扩容主库。 实际上线上生产你会发现，读申请的增长速度远远高于写申请，所以读写拆散之后，大部分时候就是扩容从库撑持更高的读申请就能够了。 而且另外一点，对同一个表，如果你既写入数据（波及加锁），还从该表查问数据，可能会牵扯到锁抵触等问题，无论是写性能还是读性能，都会有影响。 所以一旦读写拆散之后，对主库的表就仅仅是写入，没任何查问会影响他，对从库的表就仅仅是查问。 （5）高并发下的数据库架构设计总结 其实从大的一个简化的角度来说，高并发的场景下，数据库层面的架构必定是须要通过精心的设计的。 尤其是波及到分库来撑持高并发的申请，大量分表保障每个表的数据量别太大，读写拆散实现主库和从库按需扩容以及性能保障。 这篇文章就是从一个大的角度来梳理了一下思路，各位同学能够联合本人公司的业务和我的项目来思考本人的零碎如何做分库分表应该怎么做。 另外就是，具体的分库分表落地的时候，须要借助数据库中间件来实现分库分表和读写拆散，大家能够本人参考 sharding-jdbc 或者 mycat 的官网即可，外面的文档都有具体的应用形容。 ...

文章目录法令一：只返回须要的后果法令二：确保查问应用了正确的索引法令三：尽量避免应用子查问法令四：不要应用 OFFSET 实现分页法令五：理解 SQL 子句的逻辑执行程序总结SQL 作为关系型数据库的规范语言，是 IT 从业人员必不可少的技能之一。SQL 自身并不难学，编写查问语句也很容易，然而想要编写出可能高效运行的查问语句却有肯定的难度。 查问优化是一个简单的工程，波及从硬件到参数配置、不同数据库的解析器、优化器实现、SQL 语句的执行程序、索引以及统计信息的采集等，甚至应用程序和零碎的整体架构。本文介绍几个要害法令，能够帮忙咱们编写高效的 SQL 查问；尤其是对于初学者而言，这些法令至多能够防止咱们写出性能很差的查问语句。 法令一：只返回须要的后果肯定要为查问语句指定 WHERE 条件，过滤掉不须要的数据行。通常来说，OLTP 零碎每次只须要从大量数据中返回很少的几条记录；指定查问条件能够帮忙咱们通过索引返回后果，而不是全表扫描。绝大多数状况下应用索引时的性能更好，因为索引（B-树、B+树、B\*树）执行的是二进制搜寻，具备对数工夫复杂度，而不是线性工夫复杂度。以下是 MySQL 聚簇索引的示意图：Clustered index 举例来说，假如每个索引分支节点能够存储 100 个记录，100 万（1003）条记录只须要 3 层 B-树即可实现索引。通过索引查找数据时须要读取 3 次索引数据（每次磁盘 IO 读取整个分支节点），加上 1 次磁盘 IO 读取数据即可失去查问后果。 相同，如果采纳全表扫描，须要执行的磁盘 IO 次数可能高出几个数量级。当数据量减少到 1 亿（1004）时，B-树索引只须要再减少 1 次索引 IO 即可；而全表扫描则须要再减少几个数量级的 IO。 同理，咱们应该防止应用 SELECT \* FROM， 因为它示意查问表中的所有字段。这种写法通常导致数据库须要读取更多的数据，同时网络也须要传输更多的数据，从而导致性能的降落。 ????对于B-树索引的原理以及利用索引优化各种查问条件、连贯查问、排序和分组以及 DML 语句的介绍，能够参考：https://tonydong.blog.csdn.ne...法令二：确保查问应用了正确的索引如果短少适合的索引，即便指定了查问条件也不会通过索引查找数据。因而，咱们首先须要确保创立了相应的索引。一般来说，以下字段须要创立索引： 经常出现在 WHERE 条件中的字段建设索引能够防止全表扫描；将 ORDER BY 排序的字段退出到索引中，能够防止额定的排序操作；多表连贯查问的关联字段建设索引，能够进步连贯查问的性能；将 GROUP BY 分组操作字段退出到索引中，能够利用索引实现分组。即便创立了适合的索引，如果 SQL 语句写的有问题，数据库也不会应用索引。导致索引生效的常见问题包含： 在 WHERE 子句中对索引字段进行表达式运算或者应用函数都会导致索引生效，这种状况还包含字段的数据类型不匹配，例如字符串和整数进行比拟；应用 LIKE 匹配时，如果通配符呈现在左侧无奈应用索引。对于大型文本数据的含糊匹配，应该思考数据库提供的全文检索性能，甚至专门的全文搜索引擎（Elasticsearch 等）；如果 WHERE 条件中的字段上创立了索引，尽量设置为 NOT NULL；不是所有数据库应用 IS \[NOT\] NULL 判断时都能够利用索引。执行打算（execution plan，也叫查问打算或者解释打算）是数据库执行 SQL 语句的具体步骤，例如通过索引还是全表扫描拜访表中的数据，连贯查问的实现形式和连贯的程序等。如果 SQL 语句性能不够现实，咱们首先应该查看它的执行打算，通过执行打算（EXPLAIN）确保查问应用了正确的索引。 ...

前言说到数据库事务，大家脑子里肯定很容易蹦出一堆事务的相干常识，如事务的ACID个性，隔离级别，解决的问题（脏读，不可反复读，幻读）等等，然而可能很少有人真正的分明事务的这些个性又是怎么实现的，为什么要有四个隔离级别。 在之前的文章咱们曾经理解了MySQL中事务的隔离性的实现原理，明天就持续来聊一聊MySQL持久性的实现原理。 当然MySQL博大精深，文章疏漏之处在劫难逃，欢送批评指正。 阐明 MySQL的事务实现逻辑是位于引擎层的，并且不是所有的引擎都反对事务的，上面的阐明都是以InnoDB引擎为基准。 InnoDB读写数据原理在往下学习之前，咱们须要先来理解下InnoDB是怎么来读写数据的。咱们晓得数据库的数据都是寄存在磁盘中的，而后咱们也晓得磁盘I/O的老本是很大的，如果每次读写数据都要拜访磁盘，数据库的效率就会非常低。为了解决这个问题，InnoDB提供了 Buffer Pool 作为拜访数据库数据的缓冲。 Buffer Pool 是位于内存的，蕴含了磁盘中局部数据页的映射。当须要读取数据时，InnoDB会首先尝试从Buffer Pool中读取，读取不到的话就会从磁盘读取后放入Buffer Pool；当写入数据时，会先写入Buffer Pool的页面，并把这样的页面标记为dirty，并放到专门的flush list上，这些批改的数据页会在后续某个时刻被刷新到磁盘中（这一过程称为刷脏，由其余后盾线程负责） 。如下图所示： 这样设计的益处是能够把大量的磁盘I/O转成内存读写，并且把对一个页面的屡次批改merge成一次I/O操作（刷脏一次刷入整个页面），防止每次读写操作都拜访磁盘，从而大大晋升了数据库的性能。 持久性定义持久性是指事务一旦提交，它对数据库的扭转就应该是永久性的，接下来的其余操作或故障不应该对本次事务的批改有任何影响。 通过后面的介绍，咱们晓得InnoDB应用 Buffer Pool 来进步读写的性能。然而 Buffer Pool 是在内存的，是易失性的，如果一个事务提交了事务后，MySQL忽然宕机，且此时Buffer Pool中批改的数据还没有刷新到磁盘中的话，就会导致数据的失落，事务的持久性就无奈保障。 为了解决这个问题，InnoDB引入了 redo log来实现数据批改的长久化。当数据批改时，InnoDB除了批改Buffer Pool中的数据，还会在redo log 记录这次操作，并保障redo log早于对应的页面落盘（个别在事务提交的时候），也就是常说的WAL。若MySQL忽然宕机了且还没有把数据刷回磁盘，重启后，MySQL会通过曾经写入磁盘的redo log来复原没有被刷新到磁盘的数据页。 实现原理：redo log为了进步性能，和数据页相似，redo log 也包含两局部：一是内存中的日志缓冲(redo log buffer)，该局部日志是易失性的；二是磁盘上的重做日志文件(redo log file)，该局部日志是长久的。redo log是物理日志，记录的是数据库中物理页的状况 。 当数据产生批改时，InnoDB不仅会批改Buffer Pool中的数据，也会在redo log buffer记录这次操作；当事务提交时，会对redo log buffer进行刷盘，记录到redo log file中。如果MySQL宕机，重启时能够读取redo log file中的数据，对数据库进行复原。这样就不须要每次提交事务都实时进行刷脏了。 写入过程 留神点： 先批改Buffer Pool，后写 redo log buffer。redo日志比数据页先写回磁盘：事务提交的时候，会把redo log buffer写入redo log file，写入胜利才算提交胜利（也有其余场景触发写入，这里就不开展了），而Buffer Pool的数据由后盾线程在后续某个时刻写入磁盘。刷脏的时候肯定会保障对应的redo log曾经落盘了，也即是所谓的WAL（预写式日志），否则会有数据失落的可能性。益处事务提交的时候，写入redo log 相比于间接刷脏的益处次要有三点： ...

mysql锁机制1）.mysql锁根底锁期待景象表级锁：锁住一张表的数据 =》myisam下的， innodb也可能有页级锁：锁住一页的数据 行级锁：锁住一行的数据 =》 innodb下的越往上，资源开销越小，然而越往上加锁速度越慢锁抵触，表越往下的概率约低并法度：行级锁并法度的概率最低 重点：innodb下的行级锁 2）.排它锁与共享锁-重点：innodb下的行级锁 排它锁加锁语法： select * from user where id=1 for update;for update示意对要查问的语句加排它锁 共享锁：select * from user where id=1 lock in share mode;lock in share mode示意加共享锁 set autocommit=0; 敞开事务主动提交配置1为主动提交，0为勾销主动提交 排它锁：左边锁期待景象（排它锁与排它锁不能一起应用）只有右边commit后能力查问进去 共享锁：就没有锁期待景象，两把共享锁能够同时应用 锁与锁之间的影响事务与事务之间会不会有什么影响 排它锁与共享锁不能一起应用事务1加排它锁，事务2加共享锁，事务2会进行锁期待 事务1加共享锁，事务2加排它锁，事务2会进行锁期待 对于update, insert，alter等写操作，mysql在事务中会主动加上排它锁select * from user where id=1;对于一般查问，对锁没有影响，它仍然能够获取加锁后的数据以后读取：加锁的select的查问快照读取：没加锁的一般查问 写操作的一般mysql语句，其实在对于innodb会自带事务的开启以及提交（自带begin,commit)update user set username=‘111’ where id=1; 锁机制：使咱们的业务强制进入串行化 3）.乐观锁与乐观锁的解释乐观锁：不论是加什么锁，只有是上了锁都属于乐观锁（共享锁和排它锁都属于乐观锁）乐观锁：乐观，不会加任何锁，比如说MVCC MVCC - 多版本的并发管制软删除的意思同例子：秒杀操作  以下哪些不是mysql的锁机制？排它锁共享锁表级锁页级锁行级锁乐观锁乐观锁 答案：乐观锁和乐观锁不是，他们属于概念，乐观锁是真的加锁，乐观锁是通过其余伎俩达到加锁的成果 4）.死锁的产生和解决：属于一个景象，两个事务都进入了锁期待景象产生于两个或两个以上的过程当中例子：事务2间接报错Deadlock退出，事务1批改胜利 还有一种景象：不会报错，然而会产生期待，事务1在期待事务2，事务2在期待事务1，锁等待时间超时还会报出异样锁期待的工夫：wait_timeout=120 #设置的是锁期待的工夫锁等待时间完结之后，事务会有一个失败和一个胜利失败和胜利的mysql的抉择与事务的大小无关：select比拟小，update比拟大个别准则：舍小保大个别呈现死锁的范畴的：含糊查问，范畴查问 5）.间隙锁与行锁降级为表锁 间隙锁：当咱们应用的是范畴查问而不是等式查问，并申请或者排它锁的时候危害：如果在查问中通过范畴去查问，锁住的范畴会是所有索引的键值。即便这个数据不存在  ...

1.下载地址https://dev.mysql.com/doc/ind... 例如下载employee data 2.导入数据库linux执行 mysql < employees.sqlwindows批改emplopees.sql中将source中dump的门路写成绝对路径，留神用反斜杠/ 而后执行上面语句，留神emplopees.sql要带上文件的绝对路径 mysql -uroot -p < emplopees.sql3.导入胜利

世界上最快的捷径，就是好高鹜远，本文已收录【架构技术专栏】关注这个喜爱分享的中央。InnoDB引擎有几个重点个性，为其带来了更好的性能和可靠性： 插入缓冲（Insert Buffer）两次写（Double Write）自适应哈希索引（Adaptive Hash Index）异步IO（Async IO）刷新邻接页（Flush Neighbor Page）明天咱们的主题就是 插入缓冲（Insert Buffer）,因为InnoDB引擎底层数据存储结构式B+树，而对于索引咱们又有汇集索引和非汇集索引。 在进行数据插入时必然会引起索引的变动，汇集索引不用说，个别都是递增有序的。而非汇集索引就不肯定是什么数据了，其离散性导致了在插入时构造的一直变动，从而导致插入性能升高。 所以为了解决非汇集索引插入性能的问题，InnoDB引擎 发明了Insert Buffer。 Insert Buffer 的存储 看到上图，可能大家会认为Insert Buffer 就是InnoDB 缓冲池的一个组成部分。 重点：其实对也不对，InnoDB 缓冲池的确蕴含了Insert Buffer的信息，但Insert Buffer 其实和数据页一样，也是物理存在的（以B+树的模式存在共享表空间中）。 Insert Buffer 的作用先说几个点： 一张表只能有一个主键索引，那是因为其物理存储是一个B+树。（别忘了汇集索引叶子节点存储的数据，而数据只有一份）非汇集索引叶子节点存的是汇集索引的主键 汇集索引的插入首先咱们晓得在InnoDB存储引擎中，主键是行惟一的标识符（也就是咱们常叨叨的汇集索引）。咱们平时插入数据个别都是依照主键递增插入，因而汇集索引都是程序的，不须要磁盘的随机读取。 比方表： CREATE TABLE test( id INT AUTO_INCREMENT, name VARCHAR(30), PRIMARY KEY(id));如上我创立了一个主键 id,它有以下的个性： Id列是自增长的Id列插入NULL值时，因为AUTO_INCREMENT的起因，其值会递增同时数据页中的行记录按id的值进行程序寄存个别状况下因为汇集索引的有序性，不须要随机读取页中的数据，因为此类的程序插入速度是十分快的。 但如果你把列 Id 插入UUID这种数据，那你插入就是和非汇集索引一样都是随机的了。会导致你的B+ tree构造不停地变动，那性能必然会受到影响。 非汇集索引的插入很多时候咱们的表还会有很多非汇集索引，比方我依照b字段查问，且b字段不是惟一的。如下表： CREATE TABLE test( id INT AUTO_INCREMENT, name VARCHAR(30), PRIMARY KEY(id), KEY(name));这里我创立了一个x表，它有以下特点： 有一个汇集索引 id有一个不惟一的非汇集索引 name在插入数据时数据页是依照主键id进行程序寄存辅助索引 name的数据插入不是程序的非汇集索引也是一颗B+树，只是叶子节点存的是汇集索引的主键和name 的值。 ...

errorlog日志记录mysql运行过程中Error、Warning、Note等信息 sql语句查看日志存储地位 mysql> show variables like "log_error";+---------------+---------------------------------+| Variable_name | Value |+---------------+---------------------------------+| log_error | /var/log/mysqld.log |+---------------+---------------------------------+1 row in set (0.00 sec)error配置项 [mysqld]log-error=/data/log/mysql/mysql_error.logGeneral Query Log日志记录mysql的日常日志，包含查问、批改、更新等。 sql语句查看是否开启以存储地位 mysql> show global variables like "%genera%";+----------------------------------------+--------------------+| Variable_name | Value |+----------------------------------------+--------------------+| auto_generate_certs | ON || general_log | OFF || general_log_file | /data/mysql/JD.log || sha256_password_auto_generate_rsa_keys | ON |+----------------------------------------+--------------------+4 rows in set (0.01 sec)Query配置项 [mysqld] general_log = 1 general_log_file = /data/log/mysql/mysql_query.logmysql开启/敞开 mysql> set global general_log = on;mysql> set global general_log = off;Slow Query Log记录Mysql 慢查问的日志 ...

一、索引列必须独自让咱们先看看上面的这段MySQL代码： mysql> SELECT id FROM user WHERE id + 1 = 2;咱们会发现，在下面这段SQL查问语句中，咱们给的条件是一个有变量的表达式，如果咱们此时的id列上是存在索引的，那下面的语句能不能应用到索引呢？答案是不能的，因为MySQL无奈主动的解析 id + 1 = 2 这个条件语句，只管咱们能够一眼的看进去此时等价于 id = 1，然而这种做法是无奈应用到索引的，因而咱们在查问的时候，应该使得索引列不能是表达式的一部分，也不能是函数的参数。 二、前缀索引和索引选择性如果咱们须要在某一列，例如寄存url的一列数据上增加索引来放慢查问的速度，咱们先看看url数据的特点，长，相似的还有TEXT类型的数据等，这些都是一些很长，占据很大空间的数据，而且会使得对应的索引大且慢。这时候咱们能够应用一些优化的索引策略，例如前缀索引。前缀索引与个别的索引不同，他在查问的时候并不会比对该列数据的所有值，而只是比对它的后面的一部分数据。这样会使得索引变得更加灵便有效率，然而却升高了索引选择性。什么是索引选择性呢？咱们给定一个公示：索引选择性 = 不同的索引值 / 数据表的记录总数首先思考，为什么会有所谓的不同索引值和雷同的索引值？这都要建设在咱们是应用前缀索引这种形式建设索引的根底上。例如有两个数据，“abcalkjsdhgasdfasdf”和“abcalaasdasdqwe”。很显然这两个数据是截然不同的，然而如果咱们规定前缀索引的长度是数据的前五个字符，那么会发现这两个数据的索引值都是“abcal”，即这两个数据的索引值是一样的。因而也就升高了索引选择性。简略来说，索引选择性越高，咱们通过索引值能查找到惟一的数据的可能性就越大，索引选择性越低，咱们通过索引值能查找到的惟一的数据的可能性就越小。那么这是否就意味着前缀索引是一个很差的抉择呢？并不，因为个别状况下应用失当的前缀索引，也是能够精确的进行数据的查问，并且可能节俭空间的，而且对于BLOB，TEXT或者很长的VARCHAR类型的列，必须应用前缀索引，因为MySQL不容许索引这些列的残缺长度。 三、多列索引首先，如果一个数据表有3个列，那么咱们为每一个列都独自的创立一个索引，是不是就可能使得在查问的时候，无论进行怎么的查找，咱们都能取得最快的效率呢？进行上面的表格建设语句： mysql> CREATE TABLE temp (c1 INTEGER,c2 INTEGER,KEY (c1),KEY (c2));事实证明，在理论的操作中，这种为每一个列都建设一个索引的“单纯”的想法，对查找的效率晋升十分的无限，与最佳的索引计划往往效率差距了几个量级。在MySQL5.0之后的版本多出了“索引合并”的策略，肯定水平上是帮程序员优化了这种在一个数据表上创立许多单列索引的操作，然而还是不倡议应用这种索引策略。在MySQL5.0之前的版本，如果咱们为表film_actor的字段film_id和actor_id别离创立一个单列索引，而后执行以下的查问操作： mysql> SELECT film_id, actor_id FROM film_actor WHERE film_id = 1 OR actor_id = 1;事实上，在这个查问语句中，咱们所定义的两个单列索引都无奈帮忙提高效率，甚至于在老版本的MySQL中，将会应用全表扫描来实现这个查问，这就使得这个索引策略变得齐全没有意义。除非将下面的语句改写成以下的模式： mysql> SELECT actor_id, film_id FROM film_actor WHERE actor_id = 1 UNION ALL SELECT actor_id, film_id FROM film_actor WHERE film_id = 1行将查问改写成两个查问的交加，即每个查问都只是用一个列作为判断的条件，拿着整MySQL就会很天然的使用这个列的索引。 ...

记录一次mysql8的装置过程，不便当前查找，下文中xxx可依据理论状况调整。1.零碎和软件。依据操作系统版本，到官网下载对应的mysql安装文件，我下载的是mysql-8.0.21-linux-glibc2.12-x86_64.tar。解压文件放到/user/local下。 [root@bogon ~]# cat /proc/version Linux version 3.10.0-514.el7.x86_64 (builder@kbuilder.dev.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Tue Nov 22 16:42:41 UTC 2016[root@bogon ~]# tar zxvf mysql-8.0.21-linux-glibc2.12-x86_64.tar[root@bogon ~]# mv mysql-8.0.21-linux-glibc2.12-x86_64 /usr/local/mysql2.增加零碎用户，并受权。[root@bogon ~]# groupadd mysql[root@bogon ~]# useradd -g mysql mysql[root@bogon ~]# chown -R mysql:mysql /usr/local/mysql3.数据库初始化。初始化数据库后，须要记录初始化明码，以便登录mysql。数据存储目录：/var/lib/mysql日志文件目录：/var/log/mysql配置文件目录：/etc/my.cnf [root@bogon ~]# cd /usr/local/mysql[root@bogon mysql]# ./bin/mysqld --initialize --lower-case-table-names=1 --user=mysql --basedir=/usr/local/mysql --datadir=/var/lib/mysql[root@bogon ~]# cd /usr/local/mysql留神：--lower-case-table-names=1 示意表名疏忽大小写。如果须要配置，必须启动的时候配置；否则当前不能批改，要删除mysql从新初始化才行。4.增加到零碎服务。# 将服务文件拷贝到init.d下[root@bogon mysql]# cp /usr/local/mysql/support-files/mysql.server /etc/init.d/mysqld# 赋予可执行权限[root@bogon mysql]# chmod +x /etc/init.d/mysqld# 增加服务[root@bogon mysql]# chkconfig --add mysqld# 显示服务列表[root@bogon mysql]# chkconfig --list# 启动mysql服务[root@bogon mysql]# systemctl start mysql5.批改初始密码，开启账号近程拜访。[root@bogon mysql]# ./bin/mysql -uroot -pEnter password:mysql> alter user 'root'@'localhost' identified by 'xxx';mysql> create user 'root'@'%' identified by 'root';mysql> grant all privileges on *.* to 'root'@'%' with grant option;mysql> alter user 'root'@'%' identified with mysql_native_password by 'xxx';mysql> flush privileges;mysql> exit;6.数据库配置。[root@bogon ~]# cat /etc/my.cnf [mysql]default-character-set = utf8mb4[mysqld]port=3306socket=/tmp/mysql.sock# 装置目录basedir=/usr/local/mysql# 数据目录datadir=/var/lib/mysql# 容许的最大连接数max_connections=100# 服务器端的字符集character-set-server=utf8mb4# 创立表时默认的存储引擎default-storage-engine=INNODB# 疏忽大小写lower_case_table_names=1# 自定更新工夫 实时刷新表状态，如自增idinformation_schema_stats_expiry=0max_allowed_packet=16Mdefault-authentication-plugin=mysql_native_password##bin log 设置server-id=1log-bin=mysql-bin#文件大小max-binlog-size=200M#日志格局binlog_format=MIXED# 文件大小max_binlog_size = 1G#过期工夫,单位天expire_logs_days = 7##logslow-query-log-file=/var/log/mysql/slow.logslow_query_log = onlong_query_time = 1[root@bogon ~]# systemctl restart mysql 7.开发外网端口（生产环境不倡议开启）#凋谢3306端口[root@bogon mysql]# firewall-cmd --permanent --add-port=3306/tcp#重启防火墙(批改配置后要重启防火墙)[root@bogon mysql]# firewall-cmd --reload

概述在晚期的 MySQL 版本中，DDL 操作（如创立索引等）通常都须要对数据表加锁，操作过程中 DML 操作都会被阻塞，影响失常业务。MySQL 5.6 和 MariaDB 10.0 开始反对 Online DDL，能够在执行 DDL 操作的同时，不影响 DML 的失常执行，线上间接执行 DDL 操作对用户根本无感知（局部操作对性能有影响）。 不同版本的数据库对各种 DDL 语句的反对存在肯定的差别，本文将会针对 MySQL 和 MariaDB 对 Online DDL 的反对状况做一个汇总，在须要执行 DDL 操作时，能够参考本文的 Online DDL 反对状况 局部。 本文将会继续修改和更新，最新内容请参考我的 GITHUB 上的 程序猿成长打算 我的项目，欢送 Star，更多精彩内容请 follow me。 在 ALTER TABLE 语句中，反对通过 ALGORITHM 和 LOCK 语句来实现 Online DDL： ALGORITHM - 管制 DDL 操作如何执行，应用哪个算法LOCK - 管制在执行 DDL 时容许对表加锁的级别ALTER TABLE tab ADD COLUMN c varchar(50), ALGORITHM=INPLACE, LOCK=NONE;ALGORITHM 反对的算法ALGORITHM阐明DEFAULT默认算法，主动应用可用的最高效的算法COPY最原始的形式，所有的存储引擎都反对，不应用 Online DDL，操作时会创立长期表，执行全表拷贝和重建，过程中会写入 Redo Log 和大量的 Undo Log，须要增加读锁，十分低效INPLACE尽可能防止表拷贝和重建，更确切的名字应该是 ENGINE 算法，由存储引擎决定如何实现，有些操作是能够立刻失效的（比方重命名列，扭转列的默认值等），但有些操作仍然须要全表或者局部表的拷贝和重建（比方增加删除列、增加主键、扭转列为 NULL 等）NOCOPY该算法是 INPLACE 算法的子集，用于防止聚簇索引（主键索引）的重建造成全表重建，也就说用该算法会禁止任何引起聚簇索引重建的操作INSTANT用于防止 INPLACE 算法在须要批改数据文件时异样低效的问题，所有波及到表拷贝和重建的操作都会被禁止NOCOPY 算法反对：MariaDB 10.3.2+，MySQL 不反对该算法。 INSTANT 算法反对：MariaDB 10.3.2+，MySQL 8.0.12+。 ...

代欠缺

前言 通过对《【Mysql源码剖析】基于行的复制实现之“主从关系建设”》理解了主从复制的一些原理，本章内容会深刻对binlog、relaylog做解说。并对流程做深刻理解。 在开始交接之前，咱们带着几个问题切入： 如何查看binlog和relaylog事件？relaylog是如何写入？binlog是如何同步？binlog格局如何解析？1.如何查看binlog和relaylog 在mysql中能够通过如下命令能够查看都有哪些binlog日志，如图1-1： mysql> show binary logs; <center>图1-1 查看binlog日志</center> Log_name 日志文件名称。File_size 文件大小。Encrypted 是否加密“No”代表未加密。 在查看binlog时、主有本人的binlog、从也有本人的binlog。 如果要查看最新的binlog，能够通过如下命令查看，如图1-2 mysql> show master status; <center>图1-2 查看最新binlog</center> 通过如下命令能够查看以后binlog事件，如图1-3: mysql> show binlog events;<center>图1-3 查看binlog事件</center> Log_name 日志文件名称。Pos 代表文件开始的地位。Event_type 代表事件的类型。Server_id 是创立事件的服务器ID。End_log_pos 代表事件在文件中的完结地位，以下面为例，第一次查问的完结地位是125，第二次insert之后文件的开始地位就是从125开始。Info 代表事件信息，是一段可读的文本内容。 除了查看binlog事件以外，咱们还能够查看relaylog的事件如图1-4所示，查看事件命令如下： mysql> show relaylog events;<center>图1-4 查看relaylog事件</center>relaylog事件的参数含意和binlog的统一，可参考binlog。 除了查看relaylog事件外，还能够查看relaylog参数，如图1-5所示。通过如下命令能够查看： mysql> show variables like '%relay%';<center>图1-5 relaylog参数 </center> max_relay_log_size：标记relay log 容许的最大值，如果该值为0，则默认值为max_binlog_size(1G)；如果不为0，则max_relay_log_size则为最大的relay_log文件大小；relay_log：定义relay_log的地位和名称，如果值为空，则默认地位在数据文件的目录，文件名为host_name-relay-bin.nnnnnn；relay_log_index：同relay_log，定义relay_log的地位和名称；relay_log_info_file：设置relay-log.info的地位和名称（relay-log.info记录MASTER的binary_log的复原地位和relay_log的地位）relay_log_purge：是否主动清空不再须要中继日志时。默认值为1(启用)。relay_log_recovery：当slave从库宕机后，如果relay-log损坏了，导致一部分中继日志没有解决，则主动放弃所有未执行的relay-log，并且从新从master上获取日志，这样就保障了relay-log的完整性。默认状况下该性能是敞开的，将relay_log_recovery的值设置为 1时，可在slave从库上开启该性能，倡议开启。relay_log_space_limit：避免中继日志写满磁盘，这里设置中继日志最大限额。但此设置存在主库解体，从库中继日志不全的状况，不到万不得已，不举荐应用；sync_relay_log：这个参数和sync_binlog是一样的，当设置为1时，slave的I/O线程每次接管到master发送过去的binlog日志都要写入零碎缓冲区，而后刷入relay log中继日志里，这样是最平安的，因为在解体的时候，你最多会失落一个事务，但会造成磁盘的大量I/O。当设置为0时，并不是马上就刷入中继日志里，而是由操作系统决定何时来写入，尽管安全性升高了，但缩小了大量的磁盘I/O操作。这个值默认是0，可动静批改，倡议采纳默认值。sync_relay_log_info：这个参数和sync_relay_log参数一样，当设置为1时，slave的I/O线程每次接管到master发送过去的binlog日志都要写入零碎缓冲区，而后刷入relay-log.info里，这样是最平安的，因为在解体的时候，你最多会失落一个事务，但会造成磁盘的大量I/O。当设置为0时，并不是马上就刷入relay-log.info里，而是由操作系统决定何时来写入，尽管安全性升高了，但缩小了大量的磁盘I/O操作。这个值默认是0，可动静批改，倡议采纳默认值。2.slave_relay_log_info与slave_master_info slave_relay_log_info和slave_master_info别离为relaylog-info和master-info信息。relaylog-info和master-info信息能够应用FILE或这TABLE存储。relaylog-info有三种模式，分为为FILE、TABLE、DUMMY。 <center>图2-1 查看relaylog-info和master-info </center> 通过relay_log_info_repository和master_info_repository能够得悉relaylog-info和master-info是用什么模式存储，如图2-1所示。 3.binlog文件格式解析 想理解binlog的格局，能够通过十六进制的模式去查看,如图3-1所示。<center>图3-1 binlog十六进制格局 </center> 查看十六进制格局能够应用hexdump命令，命令格局如下： ...

为什么要进行mysql集群搭建如果我的项目中应用单台数据库,如果因为不可抗因素导致设施损坏,数据失落,将间接影响用户的应用.须要须要进行优化.数据库备份形式数据库冷备份阐明:定期将数据库中的文件通过sql的形式进行转储.保证数据在肯定工夫之内失去备份.毛病: 因为是定期备份,所以可能会导致数据的失落.数据库的冷备份 是复原数据的最初无效的伎俩.所以始终连续应用. 数据库热备份阐明: 因为数据库的同步的操作在工作中特地的频繁,所以作为数据库的开发人员,也设计了数据库如何进行同步.同步的步骤:1、数据库主库如果须要启动同步策略,则必须开启二进制日志文件.(默认条件下是敞开的.)2、当用户"更新"数据库时,主库会将更新信息写入二进制日志文件中. (主库工作完结)从库会利用IO线程读取主库中更新的二进制日志文件.3、IO线程会将读取到的信息采纳异步的形式先保留到中继日志中.(中继长期存储数据的媒介)4、SQL线程会读取中继日志中的信息,之后将sql语句同步到从数据库中.至此实现了主从的同步… 实现数据库主从搭建首先要筹备两台虚拟机，别离装置Mariadb，两台虚拟机的mac网络地址要不一样，而后批改为本人想要的ip地址。 1、批改虚拟机ip地址顺次执行如下命令，批改ip地址： cd /etc/sysconfig/network-scripts/vim ifcfg-ens33重启网卡，检测ip地址是否正确 server network restart 2、别离下载安装mariadb数据库（详见另一篇《Linux下mariadb的装置》）3、开启主库二进制文件命令: vim /etc/my.cnf 4、重启主数据库命令：cd /var/lib/mysql/systemctl restart mariadb 5、配置从数据库 5、重启从数据库6、实现主从挂载在Navicat中执行如下命令：主库: 192.168.126.129 master从库: 192.168.126.130 slave 7、查看主库状态命令：show master status 8、实现主从挂载从库中执行如下代码： CHANGE MASTER TO MASTER_HOST="xxx.xxx.xxx.xxx"#主库的ip地址MASTER_PORT=3306#主库的端口MASTER_USER="xxxx"#主库账号MASTER_PASSWORD="xxxx"#主库明码MASTER_LOG_FILE="mysql-bin.000001"#主库的二进制日志名称MASTER_LOG_POS=245#主库的Position如果因为数据库屡次重启导致生成了多个二进制日志文件，能够将多余文件删除后，重启数据库，再次执行挂载命令即可

MySQL反对的整数类型有TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT。 每种整数类型所需的存储空间和范畴如下： 类型字节最小值(有符号)最大值(有符号)最小值(无符号)最大值(无符号)TINYINT1-1281270255SMALLINT2-3276832767065535MEDIUMINT3-83886088388607016777215INT4-2147483648214748364704294967295BIGINT8-9223372036854775808(9223372036854775807018446744073709551615有无限度的区别在创立数据表时，通常会看见 int(11)和int这样的写法，这两者有什么区别，各自又代表什么意思呢？ 对应Integer 类型而言，仅示意字段的显示宽度。对于DECIMAL类型，示意数字的总数。对于字符字段，这是能够存储的最大字符数，例如VARCHAR（20）能够存储20个字符。显示宽度并不影响能够存储在该列中的最大值。int(3)和int(11) 所能存储的最大范畴是一样的。 将某个字段设置成INT(20)并不意味着将可能存储20位数字，这个字段最终能存储的最大范畴还是 INT 的范畴。 示例创立一张长期表： CREATE TABLE tmp_table_a ( id INT(3) NOT NULL AUTO_INCREMENT, name varchar(16) DEFAULT '' NOT NULL, PRIMARY KEY (`id`));查看表构造： mysql> desc tmp_table_a;+-------+-------------+------+-----+---------+----------------+| Field | Type | Null | Key | Default | Extra |+-------+-------------+------+-----+---------+----------------+| id | int(3) | NO | PRI | NULL | auto_increment || name | varchar(16) | NO | | | |+-------+-------------+------+-----+---------+----------------+插入超过"长度"的数字： INSERT INTO tmp_table_a(id, name) VALUES(123456, "boo");查看后果，发现数字并没有插入失败： ...

场景介绍本文为您介绍如何基于ECS搭建云上博客。 背景常识本场景次要波及以下云产品和服务： 云服务器ECS云服务器（Elastic Compute Service，简称ECS）是阿里云提供的性能卓越、稳固牢靠、弹性扩大的IaaS（Infrastructure as a Service）级别云计算服务。云服务器ECS免去了您洽购IT硬件的后期筹备，让您像应用水、电、天然气等公共资源一样便捷、高效地应用服务器，实现计算资源的即开即用和弹性伸缩。阿里云ECS继续提供创新型服务器，解决多种业务需要，助力您的业务倒退。 WordpressWordPress是应用PHP语言开发的博客平台，用户能够在反对PHP和MySQL数据库的服务器上架设属于本人的网站。也能够把WordPress当作一个内容管理系统（CMS）来应用。 场景体验本场景将提供一台根底环境为CentOS 的ECS（云服务器）实例。咱们将会在这台服务器上安装和部署LAMP环境，而后装置 WordPress，帮忙您疾速搭建本人的云上博客。首先您须要登录到已创立的ECS虚构服务器上，而后在云服务器上安装一个MySQL数据库来存储博客内容。 步骤一：连贯ECS服务器具体操作可见阿里云体验实验室连贯步骤 如尚未购买及操作ECS，可在此处收费体验阿里云ECS服务器。资源地址：https://developer.aliyun.com/adc/scenario/fdecd528be6145dcbe747f0206e361f3 步骤二：装置Apache服务（连贯ECS后）Apache是世界应用排名第一的Web服务器软件。它能够运行在简直所有宽泛应用的计算机平台上，因为其跨平台和安全性被宽泛应用，是最风行的Web服务器端软件之一。 1.执行如下命令，装置Apache服务及其扩大包。 yum –y install httpd httpd-manual mod_ssl mod_perl mod_auth_mysql2.返回相似如下图后果则示意装置胜利。 执行如下命令，启动Apache服务。 systemctl start httpd.service3.测试Apache服务是否装置并启动胜利。 Apache默认监听80端口，所以只需在浏览器拜访ECS调配的IP地址http://&lt;ECS公网IP>，如下图： 步骤三：装置MySQL数据库因为应用wordpress搭建云上博客，须要应用MySQL数据库存储数据，所以这一步咱们装置一下MySQL。1.执行如下命令，下载并装置MySQL。 wget http://dev.mysql.com/get/mysql57-community-release-el7-10.noarch.rpmyum -y install mysql57-community-release-el7-10.noarch.rpmyum -y install mysql-community-server2.执行如下命令，启动 MySQL 数据库。 systemctl start mysqld.service3.执行如下命令，查看MySQL运行状态。 systemctl status mysqld.service4.执行如下命令，查看MySQL初始密码。 grep "password" /var/log/mysqld.log5.执行如下命令，登录数据库。 mysql -uroot -p 6.执行如下命令，批改MySQL默认明码。阐明:新密码设置的时候如果设置的过于简略会报错，必须同时蕴含大小写英文字母、数字和特殊符号中的三类字符。 ALTER USER 'root'@'localhost' IDENTIFIED BY 'NewPassWord1.';7.执行如下命令，创立wordpress库。 create database wordpress; 8.执行如下命令，查看是否创立胜利。 show databases;9.输出exit退出数据库。 ...

ECS装置MySQL总的来说是从 检测是否曾经装置 ->下载并装置mysql -> 设置启动 -> 设置明码 -> 开启远程登陆 检测本人的服务器是否曾经装置了MySQLrpm -qa | grep mysql yum list installed | grep mysql 两个命令选一个即可(我选了第一个) 如果装置了先删除原来的 例：能够依照上面的语句依据本人的版本状况进行删除( 对于删除最初还会有具体解说 ) rpm -e --nodeps       mysql-libs-5.1.73-5.e16_6.i686 下载MySQL安装包rpm -ivh http://dev.mysql.com/get/mysq... 装置MySQLyum install -y mysql-server 装置之后如果显示信息的最初呈现 Complete! 即为装置胜利 ( 如果装置谬误个别会提醒错误信息 ) 设置开机启动MySQLsystemctl enable mysqld.service 检测是否曾经装置了开机主动启动systemctl list-unit-files | grep mysqld 会显示两行信息 第一行是 mysqld.service enabled 这样就是装置胜利了 设置开启服务systemctl start mysqld.service 查看MySQL默认明码grep 'temporary password' /var/log/mysqld.log 这个意思就是在对应的门路下进行查找 在该门路下可能找不到这个文件 因为是在MySQL文件夹下，能够用Xftp关上服务器在这个mysqld.log文件中查看初始密码（我的明码一开始显示为empty） ...

依据如下语句，查问对应数据； select count(a.table_name),b.table_name from information_schema.COLUMNS a, ( select table_namefrom information_schema.`TABLES`where table_schema='hdtb_pilot') bwhere a.table_name = b.table_namegroup by a.table_name

MySQL的多版本并发管制(MVCC)一、什么是多版本并发管制多版本并发管制技术的英文全称是 Multiversion Concurrency Control，简称 MVCC。 多版本并发管制（MVCC） 是通过保留数据在某个工夫点的快照来实现并发管制的。也就是说，不论事务执行多长时间，事务外部看到的数据是不受其它事务影响的，依据事务开始的工夫不同，每个事务对同一张表，同一时刻看到的数据可能是不一样的。 简略来说，多版本并发管制 的思维就是保留数据的历史版本，通过对数据行的多个版本治理来实现数据库的并发管制。这样咱们就能够通过比拟版本号决定数据是否显示进去，读取数据的时候不须要加锁也能够保障事务的隔离成果。 能够认为 多版本并发管制（MVCC） 是行级锁的一个变种，然而它在很多状况下防止了加锁操作，因而开销更低。尽管实现机制有所不同，但大都实现了非阻塞的读操作，写操作也只锁定必要的行。 MySQL的大多数事务型存储引擎实现的都不是简略的行级锁。基于晋升并发性能的思考，它们个别都同时实现了多版本并发管制（MVCC）。不仅是MySQL，包含Oracle、PostgreSQL等其余数据库系统也都实现了MVCC，但各自的实现机制不尽相同，因为MVCC没有一个对立的实现规范，典型的有乐观（optimistic）并发管制和乐观（pessimistic）并发管制。 二、多版本并发管制解决了哪些问题1. 读写之间阻塞的问题通过 MVCC 能够让读写相互不阻塞，即读不阻塞写，写不阻塞读，这样就能够晋升事务并发解决能力。 进步并发的演进思路： 一般锁，只能串行执行；读写锁，能够实现读读并发；数据多版本并发管制，能够实现读写并发。2. 升高了死锁的概率因为 InnoDB 的 MVCC 采纳了乐观锁的形式，读取数据时并不需要加锁，对于写操作，也只锁定必要的行。 3. 解决一致性读的问题一致性读也被称为快照读，当咱们查询数据库在某个工夫点的快照时，只能看到这个工夫点之前事务提交更新的后果，而不能看到这个工夫点之后事务提交的更新后果。 三、快照读与以后读快照读（SnapShot Read） 是一种一致性不加锁的读，是InnoDB并发如此之高的外围起因之一。 这里的一致性是指，事务读取到的数据，要么是事务开始前就曾经存在的数据，要么是事务本身插入或者批改过的数据。不加锁的简略的 SELECT 都属于快照读，例如： `SELECT * FROM t WHERE id=1`与 快照读 绝对应的则是 以后读，以后读就是读取最新数据，而不是历史版本的数据。加锁的 SELECT 就属于以后读，例如： SELECT * FROM t WHERE id=1 LOCK IN SHARE MODE;SELECT * FROM t WHERE id=1 FOR UPDATE;四、InnoDB 的 MVCC 是如何工作的1. InnoDB 是如何存储记录的多个版本的事务版本号每开启一个事务，咱们都会从数据库中取得一个事务 ID（也就是事务版本号），这个事务 ID 是自增长的，通过 ID 大小，咱们就能够判断事务的工夫程序。 ...

首先，什么是索引？咱们假如上面一个场景，当你拿到一本很厚的工具书进行有目标的查找内容的时候，你会怎么做？你必定不会对着这本书从头到尾地去找你想要找的内容（尽管这肯定也能够找到），因为这太消耗工夫了。你会做的必定是先查找书本的目录，找到你想要浏览的章节的页码，而后再到对应的页码去查找你想要的具体的内容，这显然是一种快得多的计划，特地是在书本的页数十分多的状况下。同理，数据库的索引表演的就是一种相似与目录的角色，它通过应用一些非凡的数据结构对数据库的数据进行一些非凡的排列，使得当咱们在依照肯定的要求查找数据的时候可能取得更快的相应。 一、索引的类型B-Tree索引B-Tree索引是以后应用最宽泛的一种索引的模式，他的底层实现其实是一种叫B+Tree的数据结构，这是一种非凡的树型数据结构。首先咱们看看B+Tree在索引中是怎么样进行实现的：能够看到是一种相似于排列树的状况，即每一个节点都会保留一个数据，而这个节点的左子树保留的数据都要比以后的节点的值要小，右子树保留的数据都要比以后的节点的值要大。其实就是通过树形构造对数据进行了依照肯定规定的排列。指的留神的是，所有的叶子结点之间都有指针相互连接，不便数据的查找。这样对数据进行解决的益处在于当咱们进行数据的查找时，不须要再对全表进行扫描了，只须要对索引的这棵树从根节点开始进行若干次的比拟，达到叶子结点再依据指针指向，找到咱们所要查找的数据。留神此时，咱们进行比照判断的是索引树中的数据，而不是表中的数据。咱们举一个例子来看看具体的实现。 mysql> CREATE TABLE People( last_name varchar(50) not null, first_name varchar(50) not null, dob date not null, gender enum('m','f') not null, key(last_name,first_name,dob));下面的sql语句创立了一个表，并且对表中的last_name,first_name和dob列生成了索引：咱们能够看到这个索引中的数据就会依照咱们给定的要求，对last_name,first_name和dob三列进行排序存储，值得注意的是，咱们察看途中最右下角的两个数据节点，会发现他们的last_name,first_name列的内容都是一样的，便依照dob进行排序，即对于一个多列的索引，排序也是有优先级的，这个优先级就是咱们在定义索引的时候的程序。而如果在一个应用了B-Tree索引，咱们应用怎么的查问形式可能反对呢？ 能够应用B-Tree索引的查问类型： 全值匹配全值匹配指的是和索引中的所有列进行匹配，如上述条件中，查找一个姓名为Cuba Allen，出生于1960-01-01的人。 匹配最左前缀即对索引的第一列进行查找，下面例子的索引的第一列是last_name，比方咱们要查找一个姓为Allen的人。 匹配列前缀也能够只匹配某一列的结尾局部，如查找一个姓结尾为J的人，这里也应用了索引的第一列。 匹配范畴值例如咱们能够查找，姓为Allen和Barrymore之间的人，这里也应用了索引的第一列。 准确匹配某一列，范畴匹配另外一列咱们能够查找姓为Allen，名是K结尾的人，即索引第一列全匹配，第二列范畴匹配。 B-Tree索引的一些限度： 如果不是依照最左列进行查找，则无奈应用索引例如，上述索引无奈用于匹配名字为Bill的人，这种状况下会进化为全表扫描。 不能跳过索引中的列例如，上述索引无奈用于匹配一个姓为Allen且生日在1960-01-01的人，即必须依照从左到右的程序对索引的列进行匹配，不能两头跳过。 如果对索引中的一个列进行范畴查找，则它左边的列都无奈利用索引进行匹配如后面例子中咱们匹配一个查找姓为Allen，名是K结尾的人，因为first_name曾经是范畴匹配了，因而它左边的dob列就无奈利用索引了。 咱们从上述的限度能够看出，对于B-Tree索引，索引的程序会对这个索引的作用的施展和咱们查问语句的书写有着十分大的影响。 哈希索引哈希索引蕴含两个数据，一个是哈希值，一个是指向数据行的指针。哈希值是通过数据的每一列进行哈希计算得出的。因而每一行的数据都有一个举世无双的哈希值。因为哈希索引只存储哈希值，因而构造能够存储得比拟紧凑，也因而进步了哈希索引的速度。然而哈希索引也有它的限度： 哈希索引的数据是依照哈希值排列的而并不是依照数据自身排列的，因而不能用于排序。哈希索引不反对局部索引列的匹配。因为哈希值是依据数据的每一列计算得出的，要失去哈希值就必须要有全副索引列的数据，因而如果一个数据有A,B两列，此时只有一个数据A是无奈通过哈希索引匹配到相干的数据的。哈希索引只反对等值比拟，不反对范畴查问。当呈现哈希抵触（即多个数据计算出来的哈希值雷同）的时候，这些数据以链表的模式存储在对应的哈希值下。哈希抵触很多的时候，会对哈希索引的效率造成比拟大的影响，特地是在要删除一行数据的时候。二、索引的长处索引能够让服务器疾速定位到咱们须要的表的地位。但这并不是索引带来的惟一的益处。总结下来索引的长处次要有以下三个： 索引大大减少了服务器须要扫描的数据量索引能够帮忙服务器防止排序和长期表索引能够将随机I/O变为程序I/O

作者：杨涛涛资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。本文起源：原创投稿*爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。这篇咱们来简略介绍下 MySQL 8.0.21 附带的增强版逻辑备份工具。 在介绍这个工具之前，先来回顾下 MySQL 的逻辑备份工具历史。1. mysqldump： 最早，也是最成熟的逻辑备份工具，是 MySQL 原生的用来备份整个数据库实例、单个数据库、单张表的逻辑备份工具， 上手简略，学习老本简直为 0。备份简略，复原也简略。 比方导出单个数据库 ytt: mysqldump ytt > /tmp/ytt.sql； 复原也非常简单：mysql < /tmp/ytt.sql 毛病是备份速度慢。在整个备份过程中，是单线程运行；备份进去的数据集要复原的话同样也是单线程运行，复原速度也慢。除非对同一时刻的所有表独自备份进去，本人写额定脚本进行多线程复原。 2. mysqlpump：MySQL 5.7 GA 后推出的 mysqldump工具的增强版。能够对同一个数据集多个线程并发备份，备份速度很快。 其余毛病和 mysqldump 一样。 3. MySQL Shell UTIL 对象附带的备份工具：随 MySQL 8.0.21 最新版本捆绑公布，自带多线程备份以及多线程复原性能， 能够间接代替 mysqldump/mysqlpump。 dump_instance/dumpInstance 用来多线程备份 MySQL 整个单机实例dump_schemas/dumpSchemas 用来多线程备份 MySQL 单个数据库load_dump/loadDump 用来多线程复原之前两个工具导出的数据集文件MySQL Shell UTIL 备份复原工具具备如下个性： 1. 压缩导出（默认压缩算法 zstd） 2. 数据集分块导出，每块 32M 3. 默认导出存储过程、存储函数、触发器、事件、用户、视图 4. 默认 4 个线程导出 5. 默认进度展现 6. 默认字符集 utf8mb4 ...

一、范式范式的英文名称是Normal Form，它是英国人E.F.Codd（关系数据库的老祖宗）在上个世纪70年代提出关系数据库模型后总结进去的。范式是关系数据库实践的根底，也是咱们在设计数据库构造过程中所要遵循的规定和领导办法。目前有迹可寻的共有8种范式，顺次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。通常所用到的只是前三个范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。 第一范式（1NF）第一范式其实是关系型数据库的根底，即任何关系型数据库都是合乎第一范式的。简略的将第一范式就是每一行的各个数据都是不可分割的，同一列中不能有多个值，如果呈现反复的属性就须要定义一个新的尸实体。上面数据库便不合乎第一范式： +------------+-------------------+| workername | company |+------------+-------------------+| John | ByteDance,Tencent || Mike | Tencent |+------------+-------------------+下面形容的数据所表白的意思是，Mike在Tencent工作，而John同时在ByteDance和Tencent工作（假如这是可能的）。然而这种表达方式并不合乎第一范式，即列的数据必须是不可分的，要满足第一范式，必须是上面的这种模式： +------------+-----------+| workername | company |+------------+-----------+| Mike | Tencent || John | ByteDance || John | Tencent |+------------+-----------+第二范式（2NF）首先，一个数据库要满足第二范式必须要先满足第一范式。咱们先看一个表格： +----------+-------------+-------+| employee | department | head |+----------+-------------+-------+| Jones | Accountint | Jones || Smith | Engineering | Smith || Brown | Accounting | Jones || Green | Engineering | Smith |+----------+-------------+-------+这个表形容了被雇佣者，工作部门和领导的关系。这个表所示意的关系在现实生活中是齐全可能存在的，当初让咱们思考一个问题，如果Brown接任Accounting部门的领导，咱们须要怎么对表进行批改？这个问题将会变得十分麻烦，因为咱们会发现数据都耦合在一起了，你很难找到一个很好的能惟一确定每一行的判断条件来执行你的UPDATE语句。而咱们把可能惟一示意数据库中表的一行的数据成为这个表的主键。 因而，没有主键的表是不合乎第二范式的，也就是说合乎第二范式的表须要规定主键。因而咱们为了使下面的表合乎第二范式，须要将它拆分为两个表： +----------+-------------+| employee | department |+----------+-------------+| Brown | Accounting || Green | Engineering || Jones | Accounting || Smith | Engineering |+----------+-------------++-------------+-------+| department | head |+-------------+-------+| Accounting | Jones || Engineering | Smith |+-------------+-------+在这两个表中，第一个表的主键为employee，第二个表的主键为department。在这种状况下，实现下面的问题就显得非常简单了。 ...

链接: MySQL 5.6 Reference Manual / UPDATE Statement 针对以下相似sqlUPDATE t1 SET col1 = col1 + 1, col2 = col1 - 1;执行后果和从左往右, col1原值加1, col2 = 更新后的col1减1(与col1原值雷同) 原文If you access a column from the table to be updated in an expression, UPDATE uses the current value of the column. For example, the following statement sets col1 to one more than its current value: UPDATE t1 SET col1 = col1 + 1;The second assignment in the following statement sets col2 to the current (updated) col1 value, not the original col1 value. The result is that col1 and col2 have the same value. This behavior differs from standard SQL. ...

在装置完 MySQL 或者是在应用 MySQL 时，最难堪的就是遗记明码了，墨菲定律也通知咱们，如果一件事有可能出错，那么它肯定会出错。那如果咱们不小心遗记了 MySQL 的明码，该如何解决呢？别着急，本文教你一招搞定。 1.批改 MySQL 配置文件首先咱们须要关上 MySQL 的配置文件，如果是 Windows 零碎的话，MySQL 的配置文件是 my.ini，它在 MySQL 的默认装置目录下；如果是 MacOS 零碎的话，配置文件名是 my.cnf，它的门路是 /etc/my.cnf。 以 MacOS 为例，咱们须要在配置文件的 [mysqld] 前面增加“skip-grant-tables”，意思是设置跳过权限验证，如下图所示： MacOS 能够间接应用“sudo vim /etc/my.cnf”命令进行配置文件的编辑。注意事项在 MacOS 中如果找不到 MySQL 的配置文件，能够间接在 /etc 目录下创立 my.cnf，增加如下内容： [client]default-character-set=utf8 [mysqld] bind-address = 127.0.0.1 character-set-server=utf8 skip-grant-tables 当然如果有其余配置项的话，也能够自行批改。 2.重启 MySQL在批改完配置文件之后，咱们须要重启 MySQL 服务能力让配置失效。 如果是 Windows 零碎，咱们能够先敞开再启动 MySQL，执行命令如下： net stop mysqlnet start mysql 如果是 Linux 零碎，能够间接应用命令重启： service mysql restart如果是 Mac 零碎，可通过界面进行重启操作，如下图所示： ...

在 MacOS 上装置最新版的 MySQL 有三种办法： 应用 Docker 装置；应用 Homebrew 运行 brew install mysql 装置；应用安装包装置。咱们本文将采纳最惯例的形式，也就是安装包的形式进行装置，这也是我举荐给老手的装置形式，因为这种装置形式更直观更可控一些，比方对 MySQL 版本的抉择和明码配置等，那接下来咱们就间接开始吧。 1.下载安装包首先咱们要去 Oracle 的官网去下载 MySQL 的安装包，下载地址：https://dev.mysql.com/downloads/mysql/ 点击下载按钮即可下载。 注意事项咱们刚下载的是 MySQL Community 版本，也就是 MySQL 社区版，此版本是收费开源的能够放心使用，其余相干的产品还有： MySQL Enterprise Edition 企业版本，需付费，能够试用 30 天；MySQL Cluster 集群版，开源收费。可将几个 MySQL Server 封装成一个Server；MySQL Cluster CGE 高级集群版，需付费；MySQL Workbench（GUI TOOL）一款专为 MySQL 设计的 ER 数据库建模工具。它是驰名的数据库设计工具 DBDesigner4 的继任者。MySQL Workbench 又分为两个版本，别离是社区版（MySQL Workbench OSS）、商用版（MySQL Workbench SE）。2.装置 MySQL待下载实现之后，咱们就能够双击进行装置了，如下图所示： 之前的步骤没有须要留神的中央，始终点击“持续”按钮进行装置即可。等呈现以下界面咱们就须要进行明码的设置了，你能够抉择 MySQL 8 的加密形式或 MySQL 5.x 的加密形式而后再进行明码的设定，咱们这里抉择 MySQL 5.x 的加密形式： ...

一、VARCHAR与CHAR这两者都是用来示意字符串的数据类型。 VARCHARVARCHAR属于可变长的字符串，绝对于定长的字符串会更加节俭存储空间。在存储数据的时候VARCHAR变量须要在原有的数据大小的根底上额定应用1或2个字节记录字符串的长度（当列的最大长度小于等于255时，应用1个字节记录，否则应用2个字节记录）。因为长度可变的个性，使得VARHCHAR类型的数据在UPDATE的时候耗时会更久。且在存储时会在VARCHAR类型数据的最初增加一个空格（能够了解成为长度扭转所做的筹备）。上面状况应用VARCHAR类型是适合的：字符串列的最大长度比均匀长度大很多（即字符串长度都比拟短）；列的更新比拟少。 CHARCHAR是定长的字符串，MySQL会依据字符串的长度调配足够的空间，且会在存储数据的时候剔除数据最初的空格。CHAR类型适宜存储长度较短且列的数据长度基本一致的数据；对于常常变更的数据也适宜采纳CHAR值，因为不会像VARCHAR的可变个性一样产生存储碎片的问题。创立一个存储char字符串的表格： mysql> CREATE TABLE char_test(char_col CHAR(10));插入几条数据： mysql> INSERT INTO char_test(char_col) VALUES ('string1'),(' string2'),('string3 ');留神此时第二个数据的结尾与第三个数据的结尾存在空格。查看后果： mysql> SELECT * FROM char_test;+----------+| char_col |+----------+| string1 || string2 || string3 |+----------+3 rows in set (0.00 sec)会发现第二个数据结尾的空格得以保留，而第三个数据结尾的空格被移除了，这也就验证了咱们下面所说的CHAR类型在存储数据的时候会主动剔除结尾的空格。为了比照咱们再做一个VARCHAR类型的数据，增加雷同的数据失去的后果是： mysql> SELECT * FROM varchar_test;+-------------+| varchar_col |+-------------+| string1 || string2 || string3 |+-------------+3 rows in set (0.00 sec)第三个数据结尾的空格得以保留。 二、枚举（ENUM）类型枚举类型其实和字符串类型十分类似，不同的是枚举类型在创立的时候就规定了这个字段所能应用的字符串的一个汇合，之后该字段呈现的字符串只能是枚举汇合中存在的。这种状况尽管看似使得数据的操作变得不灵便，然而却因为这种先规定的个性使得数据在存储的时候可能被压缩的十分紧凑，节俭了存储空间。在一个表中创立一个枚举类型的字段： mysql> CREATE TABLE enum_test(e ENUM('fish','apple','dog'));下面的语句为表格创立了一个名为e的枚举字段，该字段所能呈现的值就只有'fish'、'apple'和'dog'，其余内容都不能呈现在这个字段中。然而MySQL在存储ENUM类型的数据的时候并不是依照'fish'，'apple'，'dog'这样的内容来存储的，而是存储他们的索引，即存储的内容是一个证整数。 mysql> INSERT INTO enum_test VALUES ('fish'),('apple'),('dog');Query OK, 3 rows affected (0.00 sec)Records: 3 Duplicates: 0 Warnings: 0mysql> SELECT * FROM enum_test;+-------+| e |+-------+| fish || apple || dog |+-------+3 rows in set (0.00 sec)mysql> SELECT e+0 FROM enum_test;+------+| e+0 |+------+| 1 || 2 || 3 |+------+3 rows in set (0.00 sec)从第二个查问的后果能够看出在MySQL外部，'fish'存储的其实是0，'apple'存储的其实是1，'dog'存储的其实是2，即依据枚举定义的时候的定义程序的一个编号。让咱们再看看另一个景象： ...

咱们都晓得，当多个事务并发运行的时候，很容易会产生各种各样的数据问题。如脏读，脏写，不可反复读，幻读等。 那么，mysql是如何解决多个事务并发运行时数据的查问与更新问题的呢？ 这其实就是通过Mysql的MVCC机制，而MVCC机制就是通过版本链与ReadView实现的。 事务的几种隔离级别首先，要理解MVCC机制必须得晓得mysql事务里的几种隔离级别。 读未提交读已提交可反复读串行化读未提交: 在以后事务里，能读取到其余未提交的事务批改后的值。会产生脏读、不可反复读、幻读。 读已提交: 在以后事务中，只能读到已提交后的事务的值。会产生不可反复读、幻读。 可反复读: 当事务开启后，在运行过程中所查问到的值是不会产生扭转的。(不会在运行过程中，因为某个值被其余事务批改并提交就读取进来)。也就是事务一旦开启，屡次查问同一个值，无论那个值在运行过程中有没有被其余事务批改并提交，你查问进去的值都是一样的。会产生幻读问题(在mysql中此事务隔离级别中通过mvcc+锁的机制把幻读也解决了) 串行化: 就是间接加锁排队串行化运行。不容许多个事务并发执行。 篇幅无限，如果对脏读，脏写，不可反复读和幻读有点不理解的能够搜搜其余文章看看版本链咱们都晓得，事务是能够回滚的。那么必然就要保留每次事务批改前的数据，不然到时候回滚是依据什么回滚呢？ 而当你一个值被批改屡次的时候，就须要有个版本链，记录每次的值，从而才可晓得回滚到哪个对应的版本上。 而在innodb存储引擎上，汇集索引中都会蕴含两个暗藏列。一个是trx_id，用于记录事务id，一个是roll_pointer，回滚指针。 那么其实undo log 版本链看上去就大略是这个样子。 那么能够试想下以下场景： 一开始事务A(id为10)对某张表id为1的某个字段更改，把值改为A： 而后又有事务B(id为20)对那条数据进行批改，把值改成B: 最初事务C(id为30)把那条数据的值改成C: 不难看出，每次更新，都会将旧的值保存起来，放到undo log的版本链中，造成一个链表。链表的头节点就是记录最新的值。 那么此时咱们能够看到，尽管每次批改每个版本的值我都保留记录下来了，但这么多版本，我又怎么晓得我应该获取的是版本链上哪个版本的值呢？？？ 这个时候就须要咱们的 ReadView 退场了。 ReadViewreadview 你能够简略的了解为是一个视图。通过它，咱们能够晓得在版本链上哪个版本对于以后事务以及以后事务的隔离级别是可见的。 首先咱们要晓得readView是由什么组成的，为什么通过它咱们能够判断版本链上哪个版本是咱们应该获取的值，哪些又是不可获取的值。 那么readView的组成次要能够分为四局部： m_ids: 是一个数组，记录的是以后沉闷的事务id(就是还没提交的)min_trx_id: m_ids数组外面的最小值max_trx_id: 示意下一个事务生成时调配给它的id。(不是m_ids外面的最大值)creator_trx_id: 以后事务id好了，在咱们晓得readview的组成后，咱们接下来能够看看在mysql中不同事务隔离级别下是怎么实现的。 如何实现不难看出，在读未提交和串行化这两种隔离级别下，都是间接获取最新的值即可，不存在那种多版本并发管制的问题。 因而，咱们次要钻研的是在读已提交和可反复读条件下是如何通过版本链与readview获取到对应的正确版本的值。 MVCC机制首先，咱们要晓得MVCC机制是如何通过readview和版本链就可决定对应版本链上的数据是否被读取。也就是要晓得MVCC外面外部的大抵规定是怎么的。 其实，有了这个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时生成该版本的事务曾经被提交，该版本能够被拜访。 读已提交读已提交隔离级别下就是只能读取到其余事务曾经提交过的值，若某个值被其余事务批改了，但那个事务还未提交的时候是无奈被其余事务读取到的。 那么，这个时候咱们能够试下想以下场景： 此时，版本链上存在一条被事务id为5的插入进去的数据。且有两个沉闷事务A和B 这时候，事务B对数据进行批改，把值改成B, 那么在此时的trx_id就会变为20，同时生成一个undolog，由roll_pointer来指向。 接下来，事务A就要开始查问。这时候就要生成一个readview，不难看出，readview的m_ids为[10，20]，min_trx_id：10，max_trx_id:21（按递增为1算）,creator_trx_id:10。 那么此时，事务A去查问的时候就会发现，版本链上第一个时trx_id为20的数据，在[min_trx_id,max_trx_id)中，且也在m_ids外面。 这就证实此版本号所对应数据的事务还在沉闷状态中(还未被提交)。因而就不读取，持续顺着roll_pointer找下一条数据。 而后接下来，找到下一条数据发现trx_id=5。发现小于min_trx_id。这阐明这条数据所对应的事务在很早之前就被提交了，因而能够读取。 这个时候，事务B提交了。那依照读已提交的个性，当事务B提交的时候，事务A就应该能够读取到事务B的值，那怎么能让事务A依据MVCC机制能读取到呢？ 很简略，只须要从新生成一个readview即可。从新生成readview后，这个时候readview外面的值就有:m_ids:[10],min_trx_id：10，max_trx_id:21（按递增为1算）,creator_trx_id:10。 那事务A开始查问的时候，依据MVCC机制，发现版本链上的头节点数据trx_id=20,在[min_trx_id,max_trx_id)范畴外面，且不在m_ids数组外面，因而能够读取。 ...

格局: create database 数据库名 charset utf8; create table 表名(字段名1 字段类型 [字段属性], 字段名2 字段类型 [字段属性], ....); insert into 表名(字段名1, 字段名2, ...)values(值1, 值2, ...);例如1: create database demo1 charset utf8; create table info(id int auto_increment primary key, title varchar(50), email varchar(20), content text); insert into info( id, title, email, content)values(null, '明天咱们能够不上自习吗？', '1871151400@qq.com', '不能够');

1.前言以前每次新环境装置都是百度，以至于装置形式每次可能都不一样，可能不能一次性胜利，为了当前能节省时间，所以明天记录一下CentOs装置MySQL办法。这里以CentOs 7为例。 2.增加yml源目前我的项目支流的MySQL还是5.7所以这里也是装置5.7下载源安装包 wget http://dev.mysql.com/get/mysql57-community-release-el7-11.noarch.rpm装置： yum localinstall mysql57-community-release-el7-11.noarch.rpm3.装置并启动服务装置： yum -y install mysql-community-server下载略微有点慢，就算切换源也差不多,喝杯咖啡或者干点其余事就下好了。启动服务： systemctl start mysqld 设置开机自启动 systemctl enable mysqld4.批改默认明码查看默认明码： grep 'temporary password' /var/log/mysqld.log 登录： mysql -u root -p明码批改默认明码： ALTER USER 'root'@'localhost' IDENTIFIED BY 'youPassword';5.开启近程连贯容许某个用户近程连贯并刷新权限 GRANT ALL PRIVILEGES ON *.* TO 'username'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION;flush privileges;开启防火墙并凋谢3306端口 systemctl start firewalld.servicefirewall-cmd --permanent --remove-port=3306/tcp防火墙其余相干命令： - `systemctl start firewalld`：开启防火墙- `firewall-cmd --add-port=8080/tcp --permanent`：凋谢8080端口- `firewall-cmd --reload`：从新加载- `firewall-cmd --query-port=123/tcp`：查问指定端口是否开启胜利- `firewall-cmd --permanent --remove-port=123/tcp`：敞开指定端口- `firewall-cmd --zone=public --list-ports`:查看凋谢的所有端口参考：https://segmentfault.com/a/11... ...

MySQL的中的全局锁、表级锁、行锁 学习极客工夫-林晓彬老师-MySQL实战45讲 学习整顿????全局锁对整个数据库实例加锁。通过应用Flush tables with read lock (FTWRL)办法，让整个数据库处于只读的状态，尔后的数据库的更新语句（增删改）、数据定义语句（建表、批改表构造）和更新类事务的提交语句会被阻塞 锁定整个数据库，那么全局锁的一个显著的应用场景就是做全库逻辑备份；还有另外一个形式应用set global readonly=true 让全库进入只读的状态，这两种形式有个最大的区别是： 异样解决上，如果客户端产生异样断开，MySQL会主动开释全局锁，让整个库回到失常的状态；将整个库设置为readonly之后，异样断开后，数据库还是会始终放弃readonly状态，导致数据库长时间处于不可写状态。 ????表级锁MySQL有两种表级锁：表锁和元数据锁（meta data lock (MDL)） 表锁语法lock tables ...read/write，解锁unlock talbes。在客户端断开的时候会主动开释。表锁除了会限度别的线程读写外，也限定了本线程接下来的操作对象，例如：线程A执行lock tables t1 read,t2 write,其余线程写t1读t2写都会被阻塞，在unlock tables之前，A线程也只能读t1,写t2 元数据锁在拜访一个表的时候回主动加上，保障在拜访数据的时候，表的构造不能批改 ????行锁MySQL的行锁是在各个存储引擎中本人实现，InnoDB中就反对行锁，MyISAM引擎就不反对行锁 行锁就是锁住表中一行记录的锁，当A在对这行数据进行解决，B也想解决这条数据，就须要等到A处理完毕之后，B能力持续 两阶段锁协定 在InnoDB事务中，行锁是在须要的时候才被加上，但并不是不须要了就会立即开释，而是要期待以后事务完结后才会开释。 所以在如果事务中须要锁住多个行，把最可能造成并发的行尽量往后放。 举个????： 一个购票的零碎的买票业务大略是： 顾客A购票，A余额扣除票价影院B账户余额减少电影票价记录交易日志这条业务下，并发的点在于影院B增加收入，如果每个客户依照1、2、3的业务程序去购票，那么并发的点2持有锁的工夫会很长；如果批改为3、1、2解决完并发的点之后，就会开释行级锁，缩小了事物之间的锁的等待时间。 死锁和死锁检测 不同线程之间相互持有对方的锁，A等B开释锁，B等A开释锁，那么就会造成死锁 解决死锁的策略： 一种策略是，间接进入期待，直到超时。这个超时工夫能够通过参数 innodb_lock_wait_timeout 来设置发动死锁检测，发现死锁后，被动回滚死锁链条中的某一个事务，让其余事务得以继续执行。将参数 innodb_deadlock_detect 设置为 on，示意开启这个逻辑，这里须要留神： （1）拜访的行上有行锁才会去做死锁检测 （2）并不是每次死锁检测都都要扫所有事务。比方某个时刻，事务期待状态是这样的： B在等A，D在等C，当初来了一个E，发现E须要等D，那么E就判断跟D、C是否会造成死锁，这个检测不必管B和A

一、Mysql 锁类型和加锁剖析1、锁类型介绍：MySQL有三种锁的级别：页级、表级、行级。 表级锁：开销小，加锁快；不会呈现死锁；锁定粒度大，产生锁抵触的概率最高,并发度最低。行级锁：开销大，加锁慢；会呈现死锁；锁定粒度最小，产生锁抵触的概率最低,并发度也最高。页面锁：开销和加锁工夫界于表锁和行锁之间；会呈现死锁；锁定粒度界于表锁和行锁之间，并发度个别算法： next KeyLocks锁，同时锁住记录(数据)，并且锁住记录后面的GapGap锁，不锁记录，仅仅记录后面的GapRecordlock锁（锁数据，不锁Gap）所以其实 Next-KeyLocks=Gap锁+ Recordlock锁 二、死锁产生起因和示例1、产生起因：所谓死锁：是指两个或两个以上的过程在执行过程中,因抢夺资源而造成的一种相互期待的景象,若无外力作用，它们都将无奈推动上来.此时称零碎处于死锁状态或零碎产生了死锁，这些永远在相互期待的过程称为死锁过程。表级锁不会产生死锁.所以解决死锁次要还是针对于最罕用的InnoDB。 死锁的关键在于：两个(或以上)的Session加锁的程序不统一。那么对应的解决死锁问题的要害就是：让不同的session加锁有秩序2、产生示例：案例一 需要：将投资的钱拆成几份随机调配给借款人。 起初业务程序思路是这样的： 投资人投资后，将金额随机分为几份，而后随机从借款人表外面选几个，而后通过一条条select for update 去更新借款人表外面的余额等。 例如两个用户同时投资，A用户金额随机分为2份，分给借款人1，2 B用户金额随机分为2份，分给借款人2，1 因为加锁的程序不一样，死锁当然很快就呈现了。 对于这个问题的改良很简略，间接把所有调配到的借款人间接一次锁住就行了。 Select * from xxx where id in (xx,xx,xx) for update在in外面的列表值mysql是会主动从小到大排序，加锁也是一条条从小到大加的锁 例如（以下会话id为主键）： Session1: mysql> select * from t3 where id in (8,9) for update;+----+--------+------+---------------------+| id | course | name | ctime               |+----+--------+------+---------------------+|  8 | WA     | f    | 2016-03-02 11:36:30 ||  9 | JX     | f    | 2016-03-01 11:36:30 |+----+--------+------+---------------------+rows in set (0.04 sec)Session2: select * from t3 where id in (10,8,5) for update;锁期待中…… 其实这个时候id=10这条记录没有被锁住的，但id=5的记录曾经被锁住了，锁的期待在id=8的这里，不信请看。 Session3: mysql> select * from t3 where id=5 for update;锁期待中 Session4: mysql> select * from t3 where id=10 for update;+----+--------+------+---------------------+| id | course | name | ctime               |+----+--------+------+---------------------+| 10 | JB     | g    | 2016-03-10 11:45:05 |+----+--------+------+---------------------+row in set (0.00 sec)在其它session中id=5是加不了锁的，然而id=10是能够加上锁的。 案例二 在开发中，常常会做这类的判断需要：依据字段值查问（有索引），如果不存在，则插入；否则更新。 以id为主键为例，目前还没有id=22的行 Session1: select * from t3 where id=22 for update;Empty set (0.00 sec)session2: select * from t3 where id=23  for update;Empty set (0.00 sec)Session1: insert into t3 values(22,'ac','a',now());锁期待中…… Session2: insert into t3 values(23,'bc','b',now());ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction当对存在的行进行锁的时候(主键)，mysql就只有行锁。 当对未存在的行进行锁的时候(即便条件为主键)，mysql是会锁住一段范畴（有gap锁） 锁住的范畴为： (无穷小或小于表中锁住id的最大值，无穷大或大于表中锁住id的最小值) 如：如果表中目前有已有的id为（11 ， 12） 那么就锁住（12，无穷大） 如果表中目前已有的id为（11 ， 30） 那么就锁住（11，30） 对于这种死锁的解决办法是： insert into t3(xx,xx) on duplicate key update `xx`='XX';用mysql特有的语法来解决此问题。因为insert语句对于主键来说，插入的行不论有没有存在，都会只有行锁 案例三 mysql> select * from t3 where id=9 for update;+----+--------+------+---------------------+| id | course | name | ctime               |+----+--------+------+---------------------+|  9 | JX     | f    | 2016-03-01 11:36:30 |+----+--------+------+---------------------+ row in set (0.00 sec)Session2: mysql> select * from t3 where id<20 for update;锁期待中 Session1: mysql> insert into t3 values(7,'ae','a',now());ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction这个跟案例一其它是差不多的状况，只是session1不按常理出牌了， Session2在期待Session1的id=9的锁，session2又持了1到8的锁（留神9到19的范畴并没有被session2锁住），最初，session1在插入新行时又得期待session2,故死锁产生了。 这种个别是在业务需要中根本不会呈现，因为你锁住了id=9，却又想插入id=7的行，这就有点跳了，当然必定也有解决的办法，那就是重理业务需要，防止这样的写法。 案例四 个别的状况，两个session别离通过一个sql持有一把锁，而后相互拜访对方加锁的数据产生死锁。 案例五 两个单条的sql语句波及到的加锁数据雷同，然而加锁程序不同，导致了死锁。 死锁场景如下：表构造： ...

我是少侠露飞。学习塑造人生，技术扭转世界。引言我在之前一篇博客专门介绍了MySQL聚簇索引和非聚簇索引，附传送门：【享学MySQL】系列：MySQL索引的数据结构，索引品种及聚簇索引和非聚簇索引简略来说，就是咱们设计表的时候，根本都会人为设定一个主键，这就是聚簇索引（如果没有设定主键，MySQL会抉择非空不惟一的字段作为聚簇索引，如果仍然没有，则MySQL会抉择本人暗藏列row_id作为聚簇索引）。MySQL主键分为自增主键和UUID两种模式。明天咱们就针对这个主键的生成深刻探索一下。 自增主键和UUID比拟首先须要明确一点，自增主键是整数，UUID是字符串类型（个别为36位）。 所以UUID相比自增主键一个首要的毛病就是UUID主键索引占据空间更大。其次咱们再来别离来看看两种主键生成形式插入数据时产生的状况。 自增主键的插入：如上图所示，InnoDB把每条记录都保留在前一条记录的前面，因为主键的值是程序的。当达到页面最大的填充因子（Fill Factor）（InnoDB初始的填充因子是15/16），后一条记录就会写入新页面。 UUID主键的插入因为新行的主键不肯定比前一个大，因而InnoDB不能总是把新行插入到索引的最初。它不得不为新行寻找适合的地位：通常在已有数据的中段，并且为它调配空间。这会导致大量的额定工作并且导致不优化的数据布局。次要毛病如下： 指标页面兴许会被刷写到磁盘上并且从缓存中移走，无论哪种状况，InnoDB都不得不在插入新行之前从磁盘上找到并读取它，这导致了大量的随机I/O。InnoDB有时不得不进行分页，为新行开拓空间。这会导致挪动大量数据。页面会因为分页而变得稠密和不规则地被填充，因而最终的数据会有碎片。因而通过UUID的形式插入数据破费的工夫也更长。MySQL自增主键的实现自增锁的值保留地位InnoDB引擎的自增值，在MySQL5.7及之前的版本，自增值保留在内存里，并没有长久化。每次重启后，第一次关上表的时候，都会去找自增值的最大值max(id)，而后将max(id)+步长作为这个表以后的自增值 select max(id) from table_name for update;在MySQL8.0版本，将自增值的变更记录在了redo log中，重启的时候依附redo log复原重启之前的值。 自增锁的实现自增id锁并不是一个事务锁，而是每次申请完就马上开释，以便容许别的事务再申请。 但在MySQL5.0版本的时候，自增锁的范畴是语句级别。也就是说，如果一个语句申请了一个表自增锁，这个锁会等语句执行完结当前才开释 MySQL5.1.22版本引入了一个新策略，新增参数innodb_autoinc_lock_mode，默认值是1 1.这个参数设置为0，示意采纳之前MySQL5.0版本的策略，即语句执行完结后才开释锁。 2.这个参数设置为1。 一般insert语句，自增锁在申请之后就马上开释 。相似insert … select这样的批量插入数据的语句，自增锁还是要等语句完结后才被开释。3.这个参数设置为2，所有的申请自增主键的动作都是申请后就开释锁。 所以当产生主键抵触和事务回滚都会导致自增主键id不间断的状况。思考事实上开发中根本采纳自增主键的形式。然而主键程序肯定是不会造成坏的后果么？答案当然是否定的。自增主键为了避免多个线程返回同样的主键，生成主键的过程必然是要加自增锁的，然而在高并发的场景下，抵触的概率就大大提高了，并发插入很可能会竞争下一个自增锁，即会带来InnoDB外部单点竞争。

1 概述本文讲述了如何利用Docker去装置MySQL，以及MySQL自定义配置文件的相干设置。 2 装置Docker首先装置Docker并开启服务： systemctl start docker如果没有增加国内源的话倡议增加一下，新增/批改/etc/docker/daemon.json，增加如下内容： { "registry-mirrors": ["http://hub-mirror.c.163.com"]}这里用的是网易的源，其余源如下： Docker中国区官网镜像：https://registry.docker-cn.comustc：https://docker.mirrors.ustc.edu.cn中科大：https://docker.mirrors.ustc.edu.cn阿里云：每个人不同，须要到阿里云容器服务创立，具体请查看文档3 拉取MySQL镜像docker pull mysql:latest权限不够请加sudo，另外这一步须要一点工夫，请急躁期待。 拉取实现后能够查看镜像： docker images 4 运行容器docker run -itd -p 3306:3306 -e MYSQL_ROOT_PASSWORD=123456 --name mysql-latest mysql参数阐明： -i：以交互模式运行，通常配合-t-t：为容器重新分配一个伪输出终端，通常配合-i-d：后盾运行容器-p：端口映射，格局为主机端口:容器端口-e：设置环境变量，这里设置的是root明码--name：设置容器别名 运行之后会返回一个容器ID。 5 测试先查看运行状态： docker ps 接着连贯到容器的伪终端上： docker exec -it mysql-latest /bin/bash其中mysql-latest是执行运行命令时创立的别名，同时应用mysql测试连贯： mysql -u root -p输出环境变量传递的root明码后就能够连贯上MySQL了： 也能够在IDEA中增加MySQL数据源并测试连贯： 6 配置文件一般来说仅仅装置完MySQL是不够的，还须要自定义一些配置文件，自定义配置文件有两种办法，一种是进入容器并批改外面的my.cnf，另一种是容器启动的时候应用-v参数挂载配置文件的目录。 6.1 容器内批改首先进入容器： docker exec -it mysql-latest /bin/bash请把mysql-latest批改为对应的容器别名，进入后能够通过 mysql --help | grep my.cnf查看配置文件的地位： 这几个文件存在读取程序，能够应用 mysqld --verbose --help --pid-file=/var/run/mysqld/mysqld.pid | grep -A 1 "Default options"查看： ...

前言产生死锁了，如何排查和解决呢？本文将跟你一起探讨这个问题 筹备好数据环境模仿死锁案发剖析死锁日志剖析死锁后果环境筹备数据库隔离级别： mysql> select @@tx_isolation;+-----------------+| @@tx_isolation |+-----------------+| REPEATABLE-READ |+-----------------+1 row in set, 1 warning (0.00 sec)主动提交敞开： mysql> set autocommit=0;Query OK, 0 rows affected (0.00 sec)mysql> select @@autocommit;+--------------+| @@autocommit |+--------------+| 0 |+--------------+1 row in set (0.00 sec)表构造: //id是自增主键，name是非惟一索引，balance一般字段CREATE TABLE `account` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) DEFAULT NULL, `balance` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_name` (`name`) USING BTREE) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;表中的数据： 模仿并发开启两个终端模仿事务并发状况，执行程序以及试验景象如下： ...

前言 常常听到他人说Mysql的SBR、RBR、MBR，如果不分明，那么能够跟着文章一起来学习。因为波及到主从的内容比拟多，须要拆分成多篇内容来概述，这章先从基础知识和主从关系建设开始讲起。还会出一篇文章具体解说从主同步。 1.理解什么是SBR、RBR、MBR？ 2.理解下主从配置该如何配置？ 3.理解主从关系如何建设? 1.配置Mysql主从 在本文中，分为一主一从。主监听的端口为3306，从监听的端口为3309。 1.1主服务配置master配置，配置文件my.cnf： [mysqld]port=3306basedir=/usr/local/mysql8.0.20datadir=/usr/local/mysql8.0.20/datasocket=/tmp/mysql.sock#explicit_defaults_for_timestamp=truelower_case_table_names=2 #表名存储为给定的大小写然而比拟的时候是小写的log_bin=mysql-binserver_id =10主服务启动Mysql命令： # sudo bin/mysqld --defaults-file=/usr/local/mysql8.0.20/etc/my.cnf --user=root客户端连贯master端 # mysql --socket=/tmp/mysql.sock -u root启动master后，须要创立一个用户，用于主从同步： mysql> GRANT REPLICATION SLAVE ON *.* TO repl@'localhost' IDENTIFIED BY '123456';查看主服务状态 mysql> show master status \G;1.2 从服务配置slave配置,配置文件salve.conf： [mysqld]port=3309basedir=/usr/local/mysql8.0.20datadir=/usr/local/mysql8.0.20/data1socket=/tmp/mysqlslave.sock#explicit_defaults_for_timestamp=truelower_case_table_names=2 #表名存储为给定的大小写然而比拟的时候是小写的log_bin=mysql-binserver_id=2relay_log=/usr/local/mysql8.0.20/mysql-relay-binread_only=1 #执行模式从服务启动Mysql命令： # sudo bin/mysqld --defaults-file=/usr/local/mysql8.0.20/etc/salve.conf --user=root连贯Slave端： # mysql --socket=/tmp/mysqlslave.sock -u rootSlave端主从同步配置： mysql>change master to master_host='localhost', master_user='repl',master_password='123456',master_log_file='mysql-bin.000001',master_log_pos=0;Slave/Master #查看binlog事件mysql> SHOW BINLOG EVENTS; 如果发现主从没有同步，能够应用如下命令查看相应的状态： #查看slave状态mysql> show slave status; 如果遇到从库报这个谬误：Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file' ...

MySQL 是一个跨世纪的平凡产品，它最早诞生于 1979 年，距今曾经有 40 多年的历史了，而现在比拟支流的 Java 语言也只是 1991 年才诞生的，也就是说 MySQL 要比 Java 的诞生还早十几年，不得不惊叹二者弱小的生命力。 MySQL 的利用非常宽泛，像 Google、Taobao、Facebook、Twitter、Baidu、Tencent 等公司以及绝大多数互联网公司都能见到它的身影，MySQL 也一度是（目前也是）“数据库”的代名词。 MySQL 之所以风行和它开源以及收费的个性是分不开的，因为收费所有很多公司在用，因为被宽泛应用所以会有一群狂热的爱好者为它提供技术支持，这样良性的循环将 MySQL 推向了巅峰。 以国内的状况来说，现在的互联网巨头阿里巴巴，当年当倒退到肯定规模之后就提出了“去 IOE”的口号，所谓的 I 就是 IBM，O 就是 Oracle，而 E 就是 EMC 存储设备，为什么要去 IOE？无非是出于老本的思考，最初阿里以 MySQL 为基石逐步去掉了对 Oracle 的依赖，MySQL 在巨头的应用下也在进行着疾速的迭代，那么国内的其余小弟看大哥都用 MySQL 了，也就纷纷投入了 MySQL 的怀抱，于是 MySQL 缓缓就成为了各种互联网公司数据库的首选计划。 当然阿里在应用 MySQL 的同时也在研发本人的数据库 OceanBase，并且 OceanBase 在 2019 年的 TPC-C 中也战败了已经的老大哥 Oracle 一举成名，让世界看到了中国的实力，这也是咱们每个国人的自豪。TPC-C 是寰球最具公信力的联机交易解决数据库的性能与性能联合的测试规范。艰深来讲 TPC-C 测试是对于商业数据库想要证实本身实力的一个硬性门槛。 MySQL 被卖扯远了，说回 MySQL。对于 MySQL 来说 2008 年是一个重要的一年，因为这一年 MySQL 被原来的 Sun 公司以 10 亿美金给收买了，第二年 Sun 公司又以 74 亿美元将本人和所有的产品打包卖给了 Oracle，从此 Oracle DB 和 MySQL 两家并一家都归属于 Oracle 公司了。 ...

https://www.jianshu.com/p/b7e...

阐明： MySQL Workbench是一个对立的数据库架构师、开发人员和DBA的可视化工具。MySQL Workbench提供了数据建模、SQL开发、服务器配置、用户治理、备份等全面的管理工具。MySQL Workbench可在Windows、Linux和Mac OS X上应用。 本系列教程将从以下几个方面来介绍 设计 MySQL Workbench使DBA、开发人员或数据架构师可能直观地设计、建模、生成和治理数据库。它包含了数据建模人员创立简单的ER模型、正向和反向工程所须要的所有，还提供了执行艰难的变更治理和文档工作的要害性能，这些工作通常须要大量的工夫和精力。 开发 MySQL Workbench提供了创立、执行和优化SQL查问的可视化工具。SQL编辑器提供了黑白语法高亮显示、主动实现、SQL片段的重用以及SQL的执行历史记录等性能。数据库连贯面板使开发人员可能轻松治理规范数据库连贯，包含MySQL Fabric。对象浏览器提供了对数据库模式和对象的即时拜访。 数据库管理者 MySQL Workbench提供了一个可视化的控制台，能够轻松治理MySQL环境，并取得更好的数据库可视性。开发人员和DBA能够应用可视化工具来配置服务器、治理用户、执行备份和复原、查看审计数据和查看数据库健康状况。 可视化仪表板 MySQL Workbench提供了一套工具来进步MySQL应用程序的性能。DBA能够使用性能仪表板疾速查看要害性能指标。性能报告能够轻松辨认和拜访IO热点、高老本SQL语句等。此外，通过1次点击，开发人员能够通过改良后的、易于应用的Visual Explain Plan看到须要优化查问的中央。 数据库迁徙 MySQL Workbench当初提供了一个残缺的、易于应用的解决方案，能够将Microsoft SQL Server、Microsoft Access、Sybase ASE、PostreSQL和其余RDBMS表、对象和数据迁徙到MySQL。开发人员和DBA能够疾速、轻松地将现有的利用程序转换为在Windows和其余平台上运行的MySQL。迁徙还反对从晚期版本的MySQL迁徙到最新版本的MySQL。 下载 下载地址： https://dev.mysql.com/downloads/workbench/ 找到本人对应的操作系统平台和版本地址。 装置 以windows为例子，一路next就能够。

数据库相干基础知识常见的概念数据库存储数据的一些特点window中装置mysqlmysql罕用的一些命令mysql启动2种形式mysql登录命令其余常见命令mysql语法标准SQL的语言分类数据库相干基础知识常见的概念DB：数据库，存储数据的容器。 DBMS：数据库管理系统，又称为数据库软件或数据库产品，用于创立或治理DB。 SQL：结构化查询语言，用于和数据库通信的语言，不是某个数据库软件持有的，而是简直所有的支流数据库软件通用的语言。中国人之间交换须要说汉语，和美国人之间交换须要说英语，和数据库沟通须要说SQL语言。 数据库存储数据的一些特点数据寄存在表中，而后表寄存在数据库中一个库中能够有多张表，每张表具备惟一的名称（表名）来标识本人表中有一个或多个列，列又称为“字段”，相当于java中的“属性”表中每一行数据，相当于java中的“对象”mysql登录命令`mysql -u 用户名 -p` 其余常见命令查看数据库版本 mysql --version：用于在未登录状况下，查看本机mysql版本： select version()：登录状况下，查看链接的库版本：显示所有数据库：show databases;进入指定的库：use 库名;显示以后库中所有的表：show tables;查看其余库中所有的表：show tables from 库名;查看表的创立语句：show create table 表名;查看表构造：desc 表名;mysql语法标准不辨别大小写，但倡议关键字大写，表名、列名小写每条命令最好用英文分号结尾每条命令依据须要，能够进行缩进或换行正文单行正文：#正文文字 单行正文：-- 正文文字 ，留神， 这里须要加空格 多行正文：/ 正文文字 / SQL的语言分类DQL（Data Query Language）：数据查询语言select 相干语句DML（Data Manipulate Language）：数据操作语言insert 、update、delete 语句DDL（Data Define Languge）：数据定义语言create、drop、alter 语句TCL（Transaction Control Language）：事务管制语言set autocommit=0、start transaction、savepoint、commit、rollback

越致力，越侥幸， 本文已珍藏在GitHub中JavaCommunity, 外面有面试分享、源码剖析系列文章，欢送珍藏，点赞 https://github.com/Ccww-lx/Ja...前言在面试中，基本上都会问到对于数据库的事务问题，如果啥都不会或者只答复到外表的上知识点的话，那面试基本上是没戏了，为了能顺利通过面试，那MySql的事务问题就须要理解，所以就依据网上的材料总结一版Mysql事务的知识点，坚固一下事务的常识。 事务事务是指逻辑上的一组操作，要么都执行，要么都不执行, 事务的个性（ACID）原子性(Atomicity)：事务是不可分割的工作单元，要么都胜利，要么都失败， 如果事务中一个sql语句执行失败，则已执行的语句也必须回滚，数据库退回到事务前的状态。一致性(Consistency)：事务不能毁坏数据的完整性和业务的一致性 。例如在银行转账时，不论事务胜利还是失败，单方钱的总额不变隔离性(Isolation)：一个事务所操作的数据在提交之前，对其余事务的可见性设定（个别是不可见）持久性(Durability)：事务提交之后，所做的批改就会永恒保留，不会因为系统故障导致数据失落严格来说，只有同时满足数据库的事务ACID个性能力算一个残缺的事务，但事实中实现可能真正满足的残缺的事务个性少之又少，然而在实现中也必须尽量达到事务要求的个性。 那么事务ACID个性具体怎么实现的呢？咱们来剖析看看，首先先看看事务的个性。 原子性(Atomicity)首先咱们来看看事务的原子性个性，看看其如何实现的？ 原子性(Atomicity)：事务是不可分割的工作单元，要么都胜利，要么都失败， 如果事务中一个sql语句执行失败，则已执行的语句也必须回滚，数据库退回到事务前的状态 原子性(Atomicity)的实现离不开 MySQL的事务日志 undo log日志类型，当事务须要回滚的时候须要将数据库状态回滚到事务开始前，即须要撤销所有曾经胜利执行的sql语句。那么undo log起了关键性作用： <font color='red'>当事务对数据库进行批改时，InnoDB会生成对应的undo log；如果事务执行失败或调用了rollback，导致事务须要回滚，便能够利用undo log中的信息将数据回滚到批改之前的样子。</font> 那么undo log是什么呢？每个数据变更操作是怎么被记录下来的呢？ undo log（ 回滚日志 ）undo log (回滚日志)：是采纳段(segment)的形式来记录的，每个undo操作在记录的时候占用一个undo log segment。为什么会在数据更改操作的时候，记录了绝对应的undo log呢？其目标在于： 为了保证数据的原子性，记录事务产生之前的一个版本，用于回滚，通过mvcc+undo log实现innodb事务可反复读和读取已提交隔离级别。其中，undo log分为： insert undo log ： insert操作中产生的undo log，update undo log： 对delete 和update操作产生的undo log数据更改的undo log怎么记录的呢？ 因为insert操作的记录，只对事务自身可见，对其余事务不可见。故该undo log能够在事务提交后间接删除，不须要进行purge操作， 而Delete操作在事务中实际上并不是真正的删除掉数据行，而是一种Delete Mark操作，在记录上标识Delete_Bit，而不删除记录。是一种"假删除",只是做了个标记，真正的删除工作须要后盾purge线程去实现。 update分为两种状况：update的列是否是主键列。 如果不是主键列，在undo log中间接反向记录是如何update的。即update是间接进行的。如果是主键列，update分两部执行：先删除该行，再插入一行指标行。与insert undo log 不同的，update undo log日志，当事务提交的时候，innodb不会立刻删除undo log， 会将该事务对应的undo log放入到删除列表中，将来通过purge线程来删除。 因为后续还可能会用到undo log，如隔离级别为repeatable read时，事务读取的都是开启事务时的最新提交行版本，只有该事务不完结，该行版本就不能删除（即undo log不能删除）,且undo log调配的页可重用缩小存储空间和晋升性能。 ...

1.备份1.1 冷备份定期对数据库中的数据通过sql的模式转存,保证数据在肯定工夫内失去备份,效率快. 毛病:可能会造成数据肯定的失落,冷备份只能在数据库敞开条件下备份. 1.2 热备份实时对数据库的数据同步进行备份,所以效率较冷备份慢,但不会造成数据的失落. 原理(两个文件,两个线程) : 数据库的主库要开启同步策略,则必须关上二进制日志文件(默认敞开),当用户进行"更新"操作时,主库会将更新信息写入二进制日志文件(主库工作完结).从库通过IO线程从二进制日志文件中读取更新信息,而后通过异步形式写入中继文件,SQL线程再从中继文件中读取更新信息,将sql语句写入从库,从而实现主从的同步. 主从挂载配置进入 /etc/my.cnf 文件,编辑server-id=1和log-bin=mysql-bin,主从的id须要不统一,则开启了二进制日志文件.其余则需在数据库中配置. 2.数据库代理当存在多台数据库时,须要引入数据库代理.以Mycat中间件为例.Mycat是java编写的程序,只须要java环境就能够运行.Mycat次要能够使数据库读写拆散和分库分表,来达到负载平衡.Mycat默认端口个别是8066. 读写拆散通过server.xml和schemas.xml(配置数据库读写的策略)文件来进行配置,理论我的项目中读的操作更多,所以主机个别执行写,从机执行读. 分库分表分库分表有垂直切分和程度切分两种策略. 垂直切分: 依据性能和字段(列)来进行切分,比方将同一业务下的字段或罕用到的字段分出一个库或一个表,来晋升效率. 程度切分: 依据数据(行)来进行切分,比方海量数据时,将罕用的数据分进去,能够晋升解决效率. 3.双机热备(高可用性)当存在主从时,就须要思考当主机宕机后,从机的数据量比主机多而导致主机不工作.所以咱们须要配置双机热备,互为主从.当主机宕机复原后,从机会将数据又写入主机. 4.缓存应用缓存机制能够无效缩小用户对数据库的拜访,疾速的从缓存中返回数据给用户(缓存运行在内存中,效率快).以Redis为例

对运行一段时间的数据库做主从复制序言：前几天对运行一段时间且未开启bin-log的MySQL数据库做了主从同复制，特此将具体操作步骤与阐明记录下来。留神本次同步未应用GTID进行主从复制，配置中应用通配符，做到了只同步特定名称的表，主从数据库版本：二者都是 MySQL5.7 1.主数据库配置，开启bin-log，并重启数据库先编辑主数据库的配置文件，我的数据库配置文件门路是：/etc/my.cnf。不要遗记先备份，以防配置出错。 cp /etc/my.cnf /etc/my.cnf.bakvim /etc/my.cnf次要配置内容如下，我已做了具体阐明： server-id=234 # 主从集群中惟一，不要反复，我应用的ip地址后4位binlog-do-db=master_slave_test # 须要同步的数据库binlog-ignore-db=mysql # 无需开启bin-log的数据库log_bin=mysql-bin # 启用bin-log master_info_repository=TABLE # 在从库中创立表，记录master的状态relay_log_info_repository=TABLE # 在从库中创立表，记录同步的地位信息relay_log_recovery=ON # 从库意外宕机重启，能够立刻复原到未执行的sql语句的地位重启主数据库 systemctl restart mysqld2.从数据库配置，指定要同步的数据库，并重启数据库server-id=167slave-skip-errors=all # 跳过主从同步中遇到的所有谬误号，继续执行前面的sqlreplicate_do_db=master_slave_test # 须要复制的数据库replicate_wild_do_table=master_slave_test.%table% # 须要复制的数据库中的表，应用通配符匹配含有‘table’字样的表slave-parallel-type=LOGICAL_CLOCK # 并行复制slave-parallel-workers=4 # slave线程数master_info_repository=TABLE # 在从库中创立表，记录master的状态relay_log_info_repository=TABLE # 在从库中创立表，记录同步的地位信息relay_log_recovery=ON # 从库意外宕机重启，能够立刻复原到未执行的sql语句的地位重启从数据库 systemctl restart mysqld3.主库导出数据在主库中，应用mysqldump工具将未开启bin-log之前的数据导出并压缩。 mysqldump -uroot -P3317 -p --single-transaction --master-data=2 --databases 数据库1 --tables table表名1 table表名2 >master_slave_test.sqlgzip master_slave_test.sql其中： --single-transaction：不锁表，同时保障dump的数据的一致性。--master-data：指定=1时，会在导出的sql文件中减少一句CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=1565461;，当在从库导入时，会执行那句sql。咱们在从库开启主从时，须要手动写具体的change语句，所以不心愿在从库执行那句sql，然而又须要获取bin-log的地位信息，所以指定=2，即在导出的sql文件中将其正文。当数据量十分大时，能够应用nohup工具，在后盾执行mysqldump，具体操作如下： nohup mysqldump -uroot -P3317 -p --single-transaction --master-data=2 --databases 数据库1 --tables table表名1 table表名2 >master_slave_test.sql(回车输出数据库明码)ctrl+z中断输出bg命令后盾运行4.从库导入数据登录从库所在服务器，将.sql文件拷贝过去，并且解压缩。 ...

在现在互联网业务中应用范畴最广的数据库无疑还是关系型数据库MySQL，之所以用"还是"这个词，是因为最近几年国内数据库畛域也获得了一些长足进步，例如以TIDB、OceanBase等为代表的分布式数据库，但它们临时还没有造成相对的覆盖面，所以现阶段还得持续学习MySQL数据库以应答工作中遇到的一些问题，以及面试过程中对于数据库局部的考查。 明天的内容就和大家聊一聊MySQL数据库中对于并发管制、事务以及存储引擎这几个最外围的问题。本内容波及的常识图谱如下图所示： 并发管制并发管制是一个内容宏大的话题，在计算机软件系统中只有在同一时刻存在多个申请同时批改数据的状况，就都会产生并发管制的问题，例如Java中的多线程平安问题等。在MySQL中的并发管制，次要是探讨数据库如何管制表数据的并发读写。 例如有一张表useraccount，其构造如下： 此时如果有如下两条SQL语句同一时刻向数据库发动申请： SQL-A: update useraccount t set t.account=t.account+100 where username='wudimanong';SQL-B: update useraccount t set t.account=t.account-100 where username='wudimanong'当上述语句都执行实现，正确后果应该是account=100，但在并发状况下，却有可能产生这样的状况： 那么在MySQL中是如何进行并发管制的呢？实际上与大多数并发管制形式一样，在MySQL中也是利用锁机制来实现并发管制的。 1.MySQL锁类型 在MySQL中次要是通过"读写锁"来实现并发管制。 读锁(read lock)：也叫共享锁(share lock)，多个读申请能够同时共享一把锁来读取数据，而不会造成阻塞。 写锁(write lock)：也叫排他锁(exclusive lock)，写锁会排挤其余所有获取锁的申请，始终阻塞，直到实现写入并开释锁。 读写锁能够做到读读并行，然而无奈做到写读、写写并行。前面会讲到的事务隔离性就是依据读写锁来实现的！ 2.MySQL锁粒度 下面提及的读写锁是依据MySQL的锁类型来划分的，而读写锁可能施加的粒度在数据库中次要体现为表和行，也称为表锁(table lock)、行锁(row lock)。 表锁(table lock)：是MySQL中最根本的锁策略，它会锁定整张表，这样保护锁的开销最小，然而会升高表的读写效率。如果一个用户通过表锁来实现对表的写操作(插入、删除、更新)，那么先须要取得锁定该表的写锁，那么在这种状况下，其余用户对该表的读写都会被阻塞。个别状况下"alter table"之类的语句才会应用表锁。 行锁(row lock)：行锁能够最大水平地反对并发读写，但数据库保护锁的开销会比拟大。行锁是咱们日常应用最多的锁策略，个别状况下MySQL中的行级锁由具体的存储引擎实现，而不是MySQL服务器层面去实现(表锁MySQL服务器层面会实现)。 3.多版本并发管制(MVCC) MVCC(MultiVersion Concurrency Control)，多版本并发管制。在MySQL的大多数事务引擎(如InnoDB)中，都不只是简略地实现了行级锁，否则会呈现这样的状况："数据A被某个用户更新期间(获取行级写锁),其余用户读取该条数据(获取读锁)都会被阻塞“。但现实情况显然不是这样，这是因为MySQL的存储引擎基于晋升并发性能的思考，通过MVCC数据多版本控制，做到了读写拆散，从而实现不加锁读取数据进而做到了读写并行。 以InnoDB存储引擎的MVCC实现为例： InnoDB的MVCC，是通过在每行记录前面保留两个暗藏的列来实现的。这两个列，一个保留了行的创立工夫，一个保留了行的过期工夫。当然它们存储的并不是理论的工夫值，而是零碎版本号。每开启一个新的事务，零碎版本号都会主动递增；事务开始时刻的零碎版本号会作为事务的版本号，用来和查问到的每行记录的版本号进行比拟。MVCC在MySQL中实现所依赖的伎俩次要是:"undo log和read view"。 undo log :undo log 用于记录某行数据的多个版本的数据。read view :用来判断以后版本数据的可见性undo log在前面讲述事务还会介绍到。对于MVCC的读写原理示意图如下： 上图演示了MySQL InnoDB存储引擎，在REPEATABLE READ(可反复读)事务隔离级别下，通过额定保留两个零碎版本号(行创立版本号、行删除版本号)实现MVCC，从而使得大多数读操作都能够不必再加读锁。这样的设计使得数据读取操作更加简略、性能更好。 那么在MVCC模式下数据读取操作是如何保证数据读取正确的呢？以InnoDB为例，Select时会依据以下两个条件查看每行记录： 只查找版本号小于或等于以后事务版本的数据行，这样能够确保事务读取的行要么是在事务开始前曾经存在，要么是事务本身插入或者修过的。行的删除版本号要么未定义，要么大于以后事务版本号。这样能够确保事务读取到的行，在事务开始之前未被删除。只有合乎上述两个条件的记录，能力返回作为查问的后果！以图中示范的逻辑为例，写申请将account变更为200的过程中，InnoDB会再插入一行新记录(account=200），并将以后零碎版本号作为行创立版本号(createVersion=2)，同时将以后零碎版本号作为原来行的行删除版本号(deleteVersion=2)，那么此时对于这条数据有两个版本的数据正本，具体如下： 如果当初写操作还未完结，事务对其余用户暂不可见，依照Select查看条件只有accout=100的记录才符合条件，因而查问后果会返回account=100的记录！ 上述过程就是InnoDB存储引擎对于MVCC实现的基本原理，然而前面须要留神MVCC多版本并发管制的逻辑只能工作在“REPEATABLE READ(可反复读)和READ COMMITED(提交读)”两种事务隔离级别下。其余两个隔离级别都与MVCC不兼容，因为READ UNCOMMITED(未提交读)总是读取最新的数据行，而不是合乎以后事务版本的数据行；而SERIALIZABLE则会对所有读取的行都加锁，也不合乎MVCC的思维。 MySQL事务后面在解说了对于MySQL并发管制的过程中，也提到了事务相干的内容，接下来咱们来更全面的梳理下对于事务的外围常识。 置信大家在日常的开发过程中，都应用过数据库事务，对事务的特点也都能张口就来——ACID。那么事务外部到底是怎么实现的呢？在接下来的内容中，就来和大家具体聊一聊这个问题！ 1.事务概述 数据库事务自身所要达成的成果次要体现在："可靠性"以及"并发解决"这两个方面。 可靠性：数据库要保障当insert或update操作抛出异样，或者数据库crash的时候要保障数据操作的前后一致。并发解决：说的是当多个并发申请过去，并且其中有一个申请是对数据进行批改操作，为了防止其余申请读到脏数据，须要对事务之间的读写进行隔离。实现MySQL数据库事务性能次要有三个技术，别离是日志文件（redo log和undo log）、锁技术及MVCC。 ...

在理论开发过程中，应用例如 DDD领 域模型充血计划或者为了数据模型更加的便于之后的拓展和解释，不便于也不倡议通过减少状态字段的形式解决问题，但同时下层业务有绝对比较复杂，就会存在数据模型与业务要求之间的适配问题，简单的业务可能提当初数据模型中须要用到多张表的联表查问状况，这类问题如何解决呢？ 拆分形式将本来一条SQL形式，查分为多步。多步能够是在SQL层面也能够是在程序层面。有些业务状况是容许 通过多条SQL执行 的后果，在程序中进行拼装失去最终符合要求的后果集，在这里作者举荐尽可能在程序中解决，这样做的益处是缩小数据库的压力。 也能够 借助其余缓存中间件 ，例如 redis 将一部分数据事后解决好，查问Redis性能必定比数据库要好。 合并形式（读写拆散）事后将所须要的后果集以冗余形式存储下来，程序只需查问该冗余数据汇合即可。有的人会最先想到应用视图的形式去做，但理解视图的人都晓得，每次查问视图数据，仍旧会执行联表SQL，不会起到性能晋升成果。 应用 缓存表形式 ，以MySQL为例，MySQL 有提供缓存表的实现，将指标数据先缓存到缓存表中，再查缓存表中数据。 同步数据到ElasticSearch，查问 ElasticSearch 中的冗余数据 ，阿里 Canal 产品提供 MySQL 同步到 ElasticSearch 的实现，能够参考 Sync ES · alibaba/canal Wiki · GitHub。但该种计划往往存在提早的问题，仅适宜于对实时性有容忍度的场景中。 大数据 Spark / Flink 形式 ，以实时或者离线形式（实时性要求低）对多张指标表业务解决，长久化后果集，程序只需读取后果集中的数据。Flink 提供 Joining 计划，能够参考Apache Flink 1.11 Documentation: Joining。 分库分表+主从形式 ，例如多租户的场景，租户之间数据隔离，咱们能够一主多从，一主用于写数据，多从别离依据租户拆分，各租户查问本人的从库。但该计划在程序实现方面会比较复杂，同时某个租户的数据量十分大还是会存在性能问题。 小结：该类形式往往是通过事件驱动形式实现，就会存在实时性和程序问题，在选型的时候，须要思考这方面的问题。以上提到的计划都仅仅适宜联表查问绝对简略的场景，如果存在子查问之类的简单要求，就无奈满足要求了。

拉取mysql:5.7的镜像sudo docker pull mysql:5.7 运行mysql:5.7的镜像# --name指定容器名字 -v目录挂载 -p指定端口映射 -e设置mysql参数 -d后盾运行sudo docker run -p 3306:3306 --name mysql \-v /mydata/mysql/log:/var/log/mysql \-v /mydata/mysql/data:/var/lib/mysql \-v /mydata/mysql/conf:/etc/mysql \-e MYSQL_ROOT_PASSWORD=root \-d mysql:5.7查看mysql是否运行起来docker ps配置mysqlvi /mydata/mysql/conf/my.conf [client]default-character-set=utf8[mysql]default-character-set=utf8[mysqld]init_connect='SET collation_connection = utf8_unicode_ci'init_connect='SET NAMES utf8'character-set-server=utf8collation-server=utf8_unicode_ciskip-character-set-client-handshakeskip-name-resolve#保留(留神评论区该配置不对，不是collection而是collation)重启mysqldocker restart mysql

mysql的物理文件这里次要讲：日志文件、数据库文件和配置文件 1.Mysql日志文件mysql的日志文件次要有5种：谬误日志、二进制日志、事务日志、慢查问日志、查问日志。 1.1 谬误日志(Error Log)文件名：*.err 默认状况下谬误日志大略记录以下几个方面的信息： 服务器启动和敞开过程中的信息（未必是错误信息，如mysql如何启动InnoDB的表空间文件的、如何初始化本人的存储引擎的等等。服务器运行过程中的错误信息、事件调度器运行一个事件时产生的信息、在从服务器上启动服务器过程时产生的-信息。留神：这里并不会记录sql执行谬误的日志。 # 查问谬误日志地位命令show global variables like '%log_error%';1.2 事务日志(InnoDB redo Log & undo Log)事务日志是InnoDB独有的日志。事务日志又分为：重做日志(redo Log)、回滚日志(undo Log) 应用事务日志，存储引擎在批改表的数据时只须要批改其内存拷贝，再把批改行为记录到硬盘上长久的事务日志中，而不必每次都将批改的数据自身长久到磁盘。事务日志采纳追加的形式，因而写日志的操作是磁盘上一小块区域内的程序I/O，而不像随机I/O须要在磁盘的多个中央挪动磁头，所以采纳事务日志的形式相对来说要快得多。事务日志长久当前，内存中被批改的数据在后盾能够缓缓的刷回到磁盘。目前大多数的存储引擎都是这样实现的。事务具体执行流程：https://www.cnblogs.com/maypattis/p/5628355.html 重做日志(redo Log)文件名：*.ib_logfile0redo log是指在回放日志的时候把曾经COMMIT的事务重做一遍，对于没有COMMIT的事务依照abort解决，不进行任何操作。Redo日志记录了InnoDB所做的所有物理变更和事务信息回滚日志(undo Log)文件名：*.ibdataundo log是把所有没有COMMIT的事务回滚到事务开始前的状态，零碎解体时，可能有些事务还没有COMMIT，在零碎复原时，这些没有COMMIT的事务就须要借助undo log来进行回滚。Innodb存储引擎可将所有数据寄存于ibdata*的共享表空间，也可将每张表寄存于独立的.ibd文件的独立表空间。-- 查看事务日志 ：show engine innodb statusG;-- 查看日志文件设置状态show variables like 'innodb_%';-- innodb_log_files_in_group DB中设置几组事务日志，默认是2-- innodb_log_group_home_dir 事务日志寄存目录；不设置，ib_logfile0...存在在数据文件目录下1.3 二进制日志(Binary Log)二进制日志，也就是咱们常说的binlog。二进制日志记录了MySQL所有批改数据库的操作，而后以二进制的模式记录日志在日志文件中，其中还包含没调语句所执行的工夫和耗费的资源，以及相干的事务信息。 作用： 记录sql操作(数据备份)增量数据备份及复原sql主从复制阐明： 默认状况下二进制日志是敞开的，然而在宝塔中是默认开启的。因为记录的是所有sql的执行记录，所以产生的日志文件的量会很大，这个状况下就要进行日志文件的定时挪到备份服务器或者进行定时删除。# 查问二进制日志开启等状况show global variables like '%log_bin%';1.4 慢查问日志(Show Query Log)文件名：*show.log(默认目录是data目录下) 慢查问日志中记录的是执行工夫较长的query，也就是咱们常说的slow query。 业余一点：慢查问日志是值所有SQL执行的理论超过long_query_time变量的语句和达到min_examined_row_limit条举例的语句。用户能够针对这部分语句性能调优。慢查问日志通过设置log-slow_queries[=file_name]选项开启后，将记录日志所在的路劲和名称。 留神:慢查问 对事务的执行是不记录的。如果测试的话，请应用select sleep(60);这样的语句来测试-- 查看慢查问信息show variables like "%slow%" ;-- log_slow_queries off 示意“慢查问”是“敞开的状态”-- slow_launch_time 2 示意“查问工夫超过2秒就记录到慢查问日志中”；-- slow_queries_log off 示意慢查问日志开关是关着的-- slow_query_log_file "门路" 示意慢查问日志寄存残缺门路-- 查看long_query_time(最大等待时间,或者慢查问工夫)设置工夫-- 留神和slow_launch_time的区别show variables like "%long%"-- long_query_time 就这个值 ...

依据以下语句获取解决语句； SELECT case when DATA_TYPE= 'varchar' then CONCAT('ALTER TABLE ',TABLE_NAME , ' CHANGE ' ,COLUMN_NAME,' ', REPLACE(COLUMN_NAME, '_', '') ,' ',DATA_TYPE,'(',CHARACTER_MAXIMUM_LENGTH,')' ,' ; ') elseCONCAT('ALTER TABLE ',TABLE_NAME , ' CHANGE ' ,COLUMN_NAME,' ', REPLACE(COLUMN_NAME, '_', '') ,' ',DATA_TYPE,' ; ') end as '语句',TABLE_SCHEMA AS '库名',TABLE_NAME AS '表名',COLUMN_NAME '列名',ORDINAL_POSITION AS '列的排列程序',COLUMN_DEFAULT AS '默认值',IS_NULLABLE AS '是否为空',DATA_TYPE AS '数据类型',CHARACTER_MAXIMUM_LENGTH AS '字符最大长度',NUMERIC_PRECISION AS '数值精度(最大位数)',NUMERIC_SCALE AS '小数精度',COLUMN_TYPE AS 列类型,COLUMN_KEY 'KEY',EXTRA AS '额定阐明',COLUMN_COMMENT AS '正文' FROMinformation_schema.`COLUMNS` WHERETABLE_SCHEMA = '数据库名称' and COLUMN_NAME <> REPLACE(COLUMN_NAME, '_', ''); 依据查问的语句，执行后，即可调整数据库所有字段特殊字符； ...

获取表名+触发器名称+具体执行内容：SELECT CONCAT(event_object_table,' ',trigger_name,' ',action_statement) as sqltext FROM information_schema.TRIGGERSorder by event_object_table 不便集中处理所有触发器；

Mysql构造和运行流程Mysql构造简略版本构造略微细一点的构造 MySQL = 客户端 + 服务端 客户端 = Connection(语言连接器例如：PHP-pdo，MySQLi) 服务端 = SQL层 + 存储引擎层 SQL层 = 链接/线程解决 + 查问缓存 + 分析器 + 优化器 存储引擎 = InnoDB + MariaDB + .....Connection：这一块其实次要是其余语言的连贯，并不属于MySQL自身；次要是其余语言对于MySQL的连贯操作的工具比方PHP中的：pdo，mysqli或者Navicat for MySQL SQL层：性能次要包含权限判断，SQL解析性能和查问缓存解决等。 链接/线程解决：客户端通过 连贯/线程层 来连贯MySQL数据库，连贯/线程层次要用来解决客户端的申请、身份验证和数据库安全性验证等。查问缓存和查问分析器是SQL层的外围局部，其中次要波及查问的解析、优化、缓存、以及所有内置的函数，存储过程，触发器，视图等性能。优化器次要负责存储和获取所有存储在MySQL中的数据。运行流程这里将执行流程大体分为：启动->连贯->解决->后果解决 (上面程序标号对应上图中的步骤号) 启动1）通过命令net start mysql(windows) / service mysql start(linux)启动MySQL服务2）调用初始模块；初始化模块就是在数据库启动的时候，对整个数据库做的一些初始化操作，比方各种零碎环境变量的初始化，各种缓存，存储引擎初始化设置等。连贯3）用户发送一条SQL，这个时候会被网络交互模块监听到用户的操作申请，传递给连贯治理模块4）接管到申请转发到进/线程连贯模块5）调用用户模块来进行权限检测（拜访数据库的权限），如果监测失败，间接返回，不往下走了。6）通过检测之后就会去线程连接池中查找闲暇的被缓存的线程连贯,如果找到就返回，如果没找到就从新创立一个。客户端申请对接，如果没找到，则创立一个新的线程连贯7）将线程连贯和客户端申请对接后返回给下一步解决8）在用户权限校验胜利并且取得新的连接池之后就会去命令散发器，判断命令的类型如果是select就会去拜访查问缓存，如果没有就会往下执行；9）如果是select，并且开启查问缓存之后就会去缓存中查问是否有与之相匹配的SQL,如果有就会校验用户拜访该数据的权限;通过就返回,不通过就会返回错误信息. 如果数据没有就会往下执行;10）会记录过程中的SQL操作过程到日志文件中（感觉其实记录日志应该是在查问缓存模块之前，只有有sql操作进入命令散发器，就会进行日志记录）11）在第8,9步 没有满足相应条件之后往下执行进入命令解析器,通过词法剖析,语法分析后生成解析树12）依据操作转到对应的模块解决(预处理阶段)，依据SQL抉择执行的模块13）模块收到申请后，通过访问控制模块查看所连贯的用户是否有拜访指标表和指标字段的权限（是指拜访这些数据的权限）14）有权限表治理模块先查看table cache中是否存在，有则间接对应的表和获取锁，否则从新关上表文件15）依据表的ENGINE数据，获取表的存储引擎类型等信息16）通过接口调用对应的存储引擎解决17）返回查问之后数据内容用户模块：次要性能是用于管制用户登入连贯的权限和用户受权治理。访问控制模块：次要用于监控用户的每一个操作。访问控制模块实现的性能就是依据用户模块中不同的用户受权，以及依据其数据库的各种束缚来管制用户对数据的拜访。用户模块和访问控制模块联合起来，就组成了MySQL数据库的权限治理性能。 查问优化器：这个模块次要是讲客户端发送的查问申请，在之前算法的根底上剖析，计算出一个最优的查问策略，优化之后会进步查问拜访的速度，最初依据其最优策略返回查问语句。 表变更治理模块：次要负责实现DML和DDl的查问，列如，insert，update，delete，create table，alter table等语句解决。 表保护模块：次要用于检测表的状态，剖析，优化表构造，以及修复表。 复制模块：复制模块分为Master模块和Slave模块两局部。Master模块次要负责复制环境中读取Master端的binary日志，以及Slave端的I/O线程交互等工作。 状态模块：在客户端申请零碎状态的时候，零碎状态模块次要负责将各种状态的数据返回给用户。最罕用的一些查问状态的命令包含show status，show variable是等，都是通过这个模块负责返回的。 表治理模块：次要就是保护系统生成的表文件。列如MyISAM存储引擎就生成frm，myd，myi文件，保护这些文件，江哥哥表构造的信息缓存起来，另外该模块还治理表级别的锁。 存储引擎接口模块：MySQL实现了其数据库底层存储引擎的插件师治理，将各种数据处理高度抽象画。 后果解决命令执行完了之后，将后果集返回给进/线程连贯模块(返回的也能够是相应标识，成功失败)进/线程连贯模块进行后续的清理工作，并持续期待申请或断开与客户端的连贯本文章内容来在通过六星培训的解说后依据课件进行整顿和公布的。

MySQL的数据类型次要包含以下五大类 整数类型：bit、bool、tinyint、smallint、mediumint、int、bigint浮点数类型：float、double、decimal字符串类型：char、varchar、tinyblob、blob、mediumblob、longblob、tinytext、text、mediumtext、longtext日期类型：Date、DateTime、TimeStamp、Time、Year其余数据类型：暂不介绍，用的比拟少。整数类型[]蕴含的内容是可选的，默认是有符号类型的，无符号的须要在类型前面跟上unsigned 示例1：有符号类型`mysql> create table demo1( c1 tinyint );Query OK, 0 rows affected (0.01 sec)mysql> insert into demo1 values(-pow(2,7)),(pow(2,7)-1);Query OK, 2 rows affected (0.00 sec)Records: 2 Duplicates: 0 Warnings: 0mysql> select * from demo1;+------+| c1 |+------+| -128 || 127 |+------+2 rows in set (0.00 sec)mysql> insert into demo1 values(pow(2,7));ERROR 1264 (22003): Out of range value for column 'c1' at row 1` demo1表中c1字段为tinyint有符号类型的，能够看一下下面的演示，有超出范围报错的。 对于数值对应的范畴计算形式属于计算机根底的一些常识，能够去看一下计算机的二进制示意相干的文章。 示例2：无符号类型`mysql> create table demo2( c1 tinyint unsigned );Query OK, 0 rows affected (0.01 sec)mysql> insert into demo2 values (-1);ERROR 1264 (22003): Out of range value for column 'c1' at row 1mysql> insert into demo2 values (pow(2,8)+1);ERROR 1264 (22003): Out of range value for column 'c1' at row 1mysql> insert into demo2 values (0),(pow(2,8));mysql> insert into demo2 values (0),(pow(2,8)-1);Query OK, 2 rows affected (0.00 sec)Records: 2 Duplicates: 0 Warnings: 0mysql> select * from demo2;+------+| c1 |+------+| 0 || 255 |+------+2 rows in set (0.00 sec)` c1是无符号的tinyint类型的，插入了正数会报错。 ...

尔后会针对数据库索引出一系列的文章，敬请期待 前言—学习索引几大理由高薪程序员必备常识，无论去哪里面试，数据库的索引优化是必考常识工作必备，无论任何零碎都要和数据库打交道，当数据量达到百万级以上，查问速度就会变慢，影响数据库的并发，从而影响整体的零碎并发不会数据库索引的程序员，不是一个合格的程序员，所以快来学习索引吧，哈哈索引是什么MySQL官网对索引的定义为：索引(Index)是帮忙MySQL高校获取数据的数据结构。 能够失去索引的实质：索引是数据结构，索引的目标是进步查问效率，能够类比英语新华字典，如果咱们要查问MySQL这个单词，首先咱们须要在目录（索引）定位到M，而后在定位到y，以此类推找到SQL。 如果没有索引呢，那就须要从A到Z，去遍历的查找一遍，直到找到咱们须要的，一个一个找和间接依据目录定位到数据，是不是差的天壤之别呢，这就是索引的妙用。  索引底层数据结构当数据量大的时候，索引的数据量也很大，所以索引不可能全副放到内存中，因而索引个别以文件的模式存储到硬盘上。 数据自身之外，数据库还保护着一个满足特定查找算法的数据结构，这些构造以某种形式指向数据，这样就能够基于这些数据结构实现高级查找算法。 索引算法品种 B-tree索引（重点把握，之后文章具体解说）Hash索引full-text索引R-tree索引索引的劣势相似大学图书馆书目索引，进步数据检索效率，升高数据库IO老本通过索引列对数据进行排序，升高数据排序老本，升高了CPU耗费索引的劣势实际上索引也是一张表，该表保留了主键和索引字段，并指向实体表的记录,所以索引列也是要占用空间的尽管索引大大提高了查问速度，同时却会升高更新表的速度,如果对表INSERT,UPDATE和DELETE。因为更新表时，MySQL不仅要不存数据，还要保留一下索引文件每次更新增加了索引列的字段，都会调整因为更新所带来的键值变动后的索引信息索引只是提高效率的一个因素，如果你的MySQL有大数据量的表，就须要花工夫钻研建设优良的索引，或优化查问语句索引分类单值索引：即一个索引只蕴含单个列，一个表能够有多个单列索引惟一索引：索引列的值必须惟一，但容许有空值复合索引：即一个索引蕴含多个列索引语法创立一：create [unique] index indexName on tableName (columnName (length) )。如果是CHAR,VARCHAR类型，length能够小于字段理论长度；如果是BLOB和TEXT类型，必须指定length。 创立二：alter tableName add [unique] index [indexName] on (columnName (length) )删除：DROP INDEX [indexName] ON mytable;查看：SHOW INDEX FROM table_nameG 哪些状况须要建索引主键主动建设惟一索引频繁作为查问的条件的字段应该创立索引查问中与其余表关联的字段，外键关系建设索引频繁更新的字段不适宜创立索引：因为每次更新不单单是更新了记录还会更新索引，减轻IO累赘Where条件里用不到的字段不创立索引单间/组合索引的抉择问题（在高并发下偏向创立组合索引）查问中排序的字段，若通过索引去拜访将大大提高排序的速度查问中统计或者分组字段哪些不适宜建索引表记录太少常常增删改的表数据反复且散布均匀的表字段，因而应该只为常常查问和常常排序的数据列建设索引。留神，如果某个数据列蕴含许多反复的内容，为它建设索引就没有太大的实际效果。明天索引先介绍到这来，之后文章会围绕索引优化解说 敬请期待！！！

先给大家看几个实例的谬误剖析与解决方案。 1.ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/data/mysql/mysql.sock' 问题剖析：可能是数据库没有启动或者是端口被防火墙禁止。解决办法：启动数据库或者防火墙凋谢数据库监听端口。2.ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO) 问题剖析：明码不正确或者没有权限拜访。解决办法：1）批改 my.cnf 主配置文件，在[mysqld]下增加 skip-grant-tables，重启数据库。最初批改明码命令如下： mysql> use mysql;mysql> update user set password=password("123456") where user="root";再删除刚刚增加的 skip-grant-tables 参数，再重启数据库，应用新密码即可登录。 2）从新受权，命令如下: mysql> grant all on *.* to 'root'@'mysql-server' identified by '123456';3.客户端报 Too many connections 问题剖析：连接数超出 Mysql 的最大连贯限度。解决办法：1、在 my.cnf 配置文件外面减少连接数，而后重启 MySQL 服务。max_connections = 100002、长期批改最大连接数，重启后不失效。须要在 my.cnf 外面批改配置文件，下次重启失效。set GLOBAL max_connections=10000;4.Warning: World-writable config file '/etc/my.cnf' is ignored ERROR! MySQL is running but PID file could not be found 问题剖析：MySQL 的配置文件/etc/my.cnf 权限不对。解决办法：chmod 644 /et/my.cnf5.InnoDB: Error: page 14178 log sequence number 29455369832 InnoDB: is in the future! Current system log sequence number 29455369832 ...

一. 简介Mysql是目前最为风行的关系型数据库管理系统, 具备体积小、速度快、开放源码等劣势。InnoDB是Mysql应用最宽泛的存储引擎, InnoDB进行了行锁设计, 反对MVCC, 提供一致性非锁定读。学习InnoDB数据页存储, 可能让咱们更加深刻的了解InnoDB的一些个性。程序 = 数据结构 + 算法, 对于Mysql而言也是如此。因为数据长久化的须要, Mysql的数据不仅存储在内存中, 也会长久化到文件中, 存储构造如下图, 从磁盘中, 咱们能够很容易的看到长久化的各个文件。磁盘中的文件须要加载到内存中能力被程序应用, 很显著, 不可能将所有磁盘文件都加载到内存, 当内存中的数据产生更改后, 也须要刷新到磁盘文件中, 什么时候刷新, 怎么刷新, 这些都是Mysql须要思考的问题, 然而这些内容不是本文的重点, 咱们这里稍加理解即可。本文的重点是学习数据页的存储, 这些数据页可能存在与零碎表空间, 独立表空间或者长期表空间。能够看到, 这些只是图中的一小部分。学习之前, 咱们先思考几个问题,无论是内存存储还是磁盘存储, 都离不开内存治理, InnoDB是如何划分内存以及如何治理内存的?InnoDB应用B+树存储咱们表中的数据, B+树索引节点以及叶子节点应该须要存储哪些数据? 又是怎么存储的?咱们在应用时, 创立了数据库, 数据表, 这些元数据是如何存储的, 查问某个表时, 如何依据元数据找到表的索引, 如何抉择索引, 抉择索引后, 如何定位到索引的根节点(root page)? 找到跟节点后, 又是如何一步步找到某个具体数据的?阐明Mysql版本: 8.0.12-debug存储引擎应用InnoDB咱们会用到xxd命令, 应用xxd(或者hexdump)能够以十六进制的形式查看文件。二. InnoDB存储构造InnoDB存储结构图如下所示, 咱们这里只做简要的介绍, 更多细节咱们将在后续的文章中再进行具体论述, 表空间(tablespace)能够认为是InnoDB存储引擎存储构造的最高层, 所有数据都在表空间中, 除了共享表空间外, 每个表能够创立独立表空间, 具体参数是由innodb_file_per_table参数决定, 表空间由各种段组成。常见的段(segment)有数据段, 回滚段, 索引段。innodb中数据段就是B+树的叶子节点, 索引段就是B+树中的非叶子节点。段是由区(extent)组成, 默认状况下区的大小是1MB, InnoDB默认页大小为16KB, 所以1个区是由16个间断页组成。innodb默认页(page)大小是16KB, 也能够通过innodb_page_size进行管制。innodb存储是面向行(row)的, 行的存储格局次要有compact、redundant、compressed、dynamic。三. 数据页存储3.1 独立表空间通过innodb_file_per_table参数, 咱们能够为每个表都创立一个表空间, 这个就是这个表的独立表空间, 这个表的索引段, 数据段都会存储在这个独立表空间中, 然而Redo log, Undo log依然在各自的表空间中, 表空间存储如下图, ...

数据库服务概念介绍数据库: 次要用于对大量数据信息能够进行无效的剖析解决数据库服务器: MySQL Maridb数据库: 存储数据分类 用户信息--用户信息库 商品信息---商品 交易信息---领取业务数据表: 数据表信息 数据字段: 存储具体内容信息,存储信息标准数据行: 实在每一条非法的数据信息数据库服务环境装置部署 windows零碎中部署数据库: https://dev.mysql.com/downloads/installer/ 启动PHPstudy程序--->启动MySQL5.7.26 形式一: 命令行操作 命令行中切换到MySQL所在门路 C:Users\zh>d: # 切换到文件所在盘D\>cd d:\use\phpstudy_pro\Extensions\MySQL5.7.26\bin>mysql.exe -uroot -proot # cd到具体门路后输出mysql.exe -uroot -prootmysql> 留神：也能够用其它两种办法进入命令行的路劲 1.本地文件夹进入想去的门路，而后下面鼠标左键选中，默认全选，而后输出cmd--->回车，就进去了2.后面同上，在文件夹外面shift+右键有个“在此处关上命令窗口”选项，点它就进去了。形式二: 连贯数据库(图形界面操作)装置连贯数据库程序软件: Navicat 装置部署 实现近程连贯数据库: 本地建设连贯: localhost == 127.0.0.1 留神：形式二应该不罕用，因而没有尝试去部署，具体操作步骤不熟。 Linux零碎中部署数据库: https://dev.mysql.com/downloads/mysql/ [root@oldboy72~]#yum install -y mariadb(命令包) mariadb-server(程序包) #下载数据库[root@oldboy72~]#systemctl start mariadb # 启动数据库形式一: 连贯数据库(命令行) [root@oldboy72~]#mysql -uroot# 进入数据库命令Welcome to the MariaDB monitor. Commands end with ; or \g.Your MariaDB connection id is 4Server version: 5.5.65-MariaDB MariaDB ServerCopyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.MariaDB [(none)]> # 进入胜利[root@oldboy72]#mysqladmin -uroot password "明码" # 批改默认明码，不能批改明码？形式二: 连贯数据库(图形界面)如何和虚拟主机数据路服务建设连贯???留神：Linux简直不部署图形化界面吧？所以这里不深入研究。 ...

一、批量批改字段名称为小写； 查问获取须要调整的执行语句；SELECT concat( 'alter table ', TABLE_NAME, ' change column ', COLUMN_NAME, ' ', LOWER( COLUMN_NAME ), ' ', COLUMN_TYPE, ' comment '', COLUMN_COMMENT, '';' ) AS '批改脚本' FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = '库名称'; 2.执行查问后的语句，进行字段名称批改； 3.大写，调整lower函数为upper即可；

前言本文次要受众为开发人员,所以不波及到MySQL的服务部署等操作,且内容较多,大家筹备好急躁和瓜子矿泉水. 前一阵零碎的学习了一下MySQL,也有一些实际操作教训,偶尔看到一篇和MySQL相干的面试文章,发现其中的一些问题本人也答复不好,尽管知识点大部分都晓得,然而无奈将常识串联起来. 因而决定搞一个MySQL灵魂100问,试着用答复问题的形式,让本人对知识点的了解更加深刻一点. 此文不会事无巨细的从select的用法开始解说mysql,次要针对的是开发人员须要晓得的一些MySQL的知识点,次要包含索引,事务,优化等方面,以在面试中高频的问句模式给出答案. 1. 什么是索引? 索引是一种数据结构,能够帮忙咱们疾速的进行数据的查找. 2. 索引是个什么样的数据结构呢? 索引的数据结构和具体存储引擎的实现无关, 在MySQL中应用较多的索引有Hash索引,B+树索引等,而咱们常常应用的InnoDB存储引擎的默认索引实现为:B+树索引. 3. Hash索引和B+树所有有什么区别或者说优劣呢? 首先要晓得Hash索引和B+树索引的底层实现原理: hash索引底层就是hash表,进行查找时,调用一次hash函数就能够获取到相应的键值,之后进行回表查问取得理论数据.B+树底层实现是多路均衡查找树.对于每一次的查问都是从根节点登程,查找到叶子节点方能够取得所查键值,而后依据查问判断是否须要回表查问数据. 那么能够看出他们有以下的不同: hash索引进行等值查问更快(个别状况下),然而却无奈进行范畴查问.因为在hash索引中通过hash函数建设索引之后,索引的程序与原程序无奈保持一致,不能反对范畴查问.而B+树的的所有节点皆遵循(左节点小于父节点,右节点大于父节点,多叉树也相似),人造反对范畴. hash索引不反对应用索引进行排序,原理同上.hash索引不反对含糊查问以及多列索引的最左前缀匹配.原理也是因为hash函数的不可预测.AAAA和AAAAB的索引没有相关性.hash索引任何时候都防止不了回表查问数据,而B+树在合乎某些条件(聚簇索引,笼罩索引等)的时候能够只通过索引实现查问.hash索引尽管在等值查问上较快,然而不稳固.性能不可预测,当某个键值存在大量反复的时候,产生hash碰撞,此时效率可能极差.而B+树的查问效率比较稳定,对于所有的查问都是从根节点到叶子节点,且树的高度较低.因而,在大多数状况下,间接抉择B+树索引能够取得稳固且较好的查问速度.而不须要应用hash索引. 4. 下面提到了B+树在满足聚簇索引和笼罩索引的时候不须要回表查问数据,什么是聚簇索引? 在B+树的索引中,叶子节点可能存储了以后的key值,也可能存储了以后的key值以及整行的数据,这就是聚簇索引和非聚簇索引. 在InnoDB中,只有主键索引是聚簇索引,如果没有主键,则筛选一个惟一键建设聚簇索引.如果没有惟一键,则隐式的生成一个键来建设聚簇索引. 当查问应用聚簇索引时,在对应的叶子节点,能够获取到整行数据,因而不必再次进行回表查问. 5. 非聚簇索引肯定会回表查问吗? 不肯定,这波及到查问语句所要求的字段是否全副命中了索引,如果全副命中了索引,那么就不用再进行回表查问. 举个简略的例子,假如咱们在员工表的年龄上建设了索引,那么当进行select age from employee where age < 20的查问时,在索引的叶子节点上,曾经蕴含了age信息,不会再次进行回表查问. 6. 在建设索引的时候,都有哪些须要思考的因素呢? 建设索引的时候个别要思考到字段的应用频率,常常作为条件进行查问的字段比拟适宜.如果须要建设联结索引的话,还须要思考联结索引中的程序.此外也要思考其余方面,比方避免过多的所有对表造成太大的压力.这些都和理论的表构造以及查问形式无关. 7. 联结索引是什么?为什么须要留神联结索引中的程序? MySQL能够应用多个字段同时建设一个索引,叫做联结索引.在联结索引中,如果想要命中索引,须要依照建设索引时的字段程序挨个应用,否则无奈命中索引. 具体起因为: MySQL应用索引时须要索引有序,假如当初建设了"name,age,school"的联结索引,那么索引的排序为: 先依照name排序,如果name雷同,则依照age排序,如果age的值也相等,则依照school进行排序. 当进行查问时,此时索引仅仅依照name严格有序,因而必须首先应用name字段进行等值查问,之后对于匹配到的列而言,其依照age字段严格有序,此时能够应用age字段用做索引查找,,,以此类推.因而在建设联结索引的时候应该留神索引列的程序,个别状况下,将查问需要频繁或者字段选择性高的列放在后面.此外能够依据特例的查问或者表构造进行独自的调整. 8. 创立的索引有没有被应用到?或者说怎么才能够晓得这条语句运行很慢的起因? MySQL提供了explain命令来查看语句的执行打算,MySQL在执行某个语句之前,会将该语句过一遍查问优化器,之后会拿到对语句的剖析,也就是执行打算,其中蕴含了许多信息.能够通过其中和索引无关的信息来剖析是否命中了索引,例如possilbe_key,key,key_len等字段,别离阐明了此语句可能会应用的索引,理论应用的索引以及应用的索引长度. 9. 那么在哪些状况下会产生针对该列创立了索引然而在查问的时候并没有应用呢? 应用不等于查问,列参加了数学运算或者函数在字符串like时右边是通配符.相似于'%aaa'.当mysql剖析全表扫描比应用索引快的时候不应用索引.当应用联结索引,后面一个条件为范畴查问,前面的即便合乎最左前缀准则,也无奈应用索引.以上状况,MySQL无奈应用索引. 事务相干1. 什么是事务? 了解什么是事务最经典的就是转账的栗子,置信大家也都理解,这里就不再说一边了. 事务是一系列的操作,他们要合乎ACID个性.最常见的了解就是:事务中的操作要么全副胜利,要么全副失败.然而只是这样还不够的. 2. ACID是什么?能够具体说一下吗? A=Atomicity 原子性,就是下面说的,要么全副胜利,要么全副失败.不可能只执行一部分操作. C=Consistency 零碎(数据库)总是从一个一致性的状态转移到另一个一致性的状态,不会存在中间状态. I=Isolation 隔离性: 通常来说:一个事务在齐全提交之前,对其余事务是不可见的.留神后面的通常来说加了红色,意味着有例外情况. D=Durability 持久性,一旦事务提交,那么就永远是这样子了,哪怕零碎解体也不会影响到这个事务的后果. 3. 同时有多个事务在进行会怎么样呢? ...

-- 省市区CREATE TABLE city ( id int(11) NOT NULL DEFAULT '0', pid int(11) DEFAULT NULL, cityname varchar(255) CHARACTER SET utf8 DEFAULT NULL, type int(11) DEFAULT NULL, PRIMARY KEY (id)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; INSERT INTO city VALUES ('1', '0', '中国', '0');INSERT INTO city VALUES ('2', '1', '北京', '1');INSERT INTO city VALUES ('3', '1', '安徽', '1');INSERT INTO city VALUES ('4', '1', '福建', '1');INSERT INTO city VALUES ('5', '1', '甘肃', '1');INSERT INTO city VALUES ('6', '1', '广东', '1');INSERT INTO city VALUES ('7', '1', '广西', '1');INSERT INTO city VALUES ('8', '1', '贵州', '1');INSERT INTO city VALUES ('9', '1', '海南', '1');INSERT INTO city VALUES ('10', '1', '河北', '1');INSERT INTO city VALUES ('11', '1', '河南', '1');INSERT INTO city VALUES ('12', '1', '黑龙江', '1');INSERT INTO city VALUES ('13', '1', '湖北', '1');INSERT INTO city VALUES ('14', '1', '湖南', '1');INSERT INTO city VALUES ('15', '1', '吉林', '1');INSERT INTO city VALUES ('16', '1', '江苏', '1');INSERT INTO city VALUES ('17', '1', '江西', '1');INSERT INTO city VALUES ('18', '1', '辽宁', '1');INSERT INTO city VALUES ('19', '1', '内蒙古', '1');INSERT INTO city VALUES ('20', '1', '宁夏', '1');INSERT INTO city VALUES ('21', '1', '青海', '1');INSERT INTO city VALUES ('22', '1', '山东', '1');INSERT INTO city VALUES ('23', '1', '山西', '1');INSERT INTO city VALUES ('24', '1', '陕西', '1');INSERT INTO city VALUES ('25', '1', '上海', '1');INSERT INTO city VALUES ('26', '1', '四川', '1');INSERT INTO city VALUES ('27', '1', '天津', '1');INSERT INTO city VALUES ('28', '1', '西藏', '1');INSERT INTO city VALUES ('29', '1', '新疆', '1');INSERT INTO city VALUES ('30', '1', '云南', '1');INSERT INTO city VALUES ('31', '1', '浙江', '1');INSERT INTO city VALUES ('32', '1', '重庆', '1');INSERT INTO city VALUES ('33', '1', '香港特别行政区', '1');INSERT INTO city VALUES ('34', '1', '澳门特别行政区', '1');INSERT INTO city VALUES ('35', '1', '台湾省级行政区', '1');-- 市辖区 INSERT INTO city VALUES ('52', '2', '市辖区', '2'); ...

没有区别 mysql> HELP 'LCASE';Name: 'LCASE'Description:Syntax:LCASE(str) LCASE() is a synonym for LOWER(). URL: https://dev.mysql.com/doc/ref...

场景在应用PageHelper的过程中，呈现了一个很奇怪的问题，假如在数据库中寄存有30条Country记录，咱们用上面的办法应用PageHelper进行分页查问，那么咱们心愿失去的page.size是10。 PageHelper.startPage(1, 10);List<Country> list = countryMapper.selectAll();PageInfo page = new PageInfo(list);assertEquals(10, list.size());个别状况下后果是如咱们所愿的，然而当上面的代码放到SpringBoot中表明@PostConstruct的办法下后，查问后果就是30而不是10，让咱们一起来看看其中的起因。 @Componentpublic class PageHelperProblem { @Autowired CountryMapper countryMapper; @PostConstruct public void init() { PageHelper.startPage(1, 10); List<Country> list = countryMapper.selectAll(); PageInfo page = new PageInfo(list); assertEquals(10, list.size()); }}起因debug之后发现，在执行完代码PageHelper.startPage(1, 10)之后，咱们把pageSize和pageNum设置到ThreadLocal中去了，然而在执行下一行代码之前，实践上应该进入到PageInterceptor拦截器中给sql动静的加上limit条件。然而没有进去，起因在于Bean的PostConstruct执行的时候，Pagehelper的autoconfigure还没有初始化，故而拦截器还没有创立进去，所以导致的后果就是startPage只是把分页参数设置到了ThreadLocal中去了，然而却没有被拦截器拦挡，所以导致了分页失败，没有达到预期的分页成果。 参考文章： https://www.liangzl.com/get-article-detail-132917.html https://github.com/pagehelper/pagehelper-spring-boot/issues/38 本篇文章如有帮忙到您，请给「翎野君」点个赞，感谢您的反对。

1、问题形容 mysql的开发人员常常按工夫范畴分区不晓得工夫上怎么写，笔者把总结演绎下来，能帮忙自已和分享成绩。2、解决问题 mysql对工夫范畴分区，能够是按年，按月，按天，按分，按秒，如下案例，这里留神点：范畴分区是一个开始是开区间，完结是闭区间：[0,10),[10,20),[20,30)..... 2.1、按年 CREATE TABLE sales_year ( DATE DATETIME)ENGINE = INNODB PARTITION BY RANGE(YEAR(DATE)) ( PARTITION p2020 VALUES LESS THAN (2020), PARTITION p2021 VALUES LESS THAN (2021), PARTITION p2022 VALUES LESS THAN (2022), PARTITION pmax VALUES LESS THAN (maxvalue)); 2.1、按月 CREATE TABLE sales_month( DATE DATETIME)ENGINE = INNODB PARTITION BY RANGE(MONTH(DATE)) ( PARTITION p202001 VALUES LESS THAN (202001), PARTITION p202002 VALUES LESS THAN (202002), PARTITION p202003 VALUES LESS THAN (202003), PARTITION pmax VALUES LESS THAN (maxvalue)); 2.2、按天 ...

1、行号问题 行号是指按程序为查问后果集的行调配的间断整数。Mysql数据库在行号方面的反对并不是非常敌对，没有橡其余数据库一样提供相似的row_number解决方案，因而失去行号是一个非常有技巧的问题。2.1 不反复数据分析问题 先看以下实例数据,创立sales表：CREATE TABLE sales( empid VARCHAR(10) NOT NULL, mgrid VARCHAR(10) NOT NULL, qty INT NOT NULL, PRIMARY KEY (empid)); 插入实例数据：INSERT INTO sales VALUES('A','Z',300);INSERT INTO sales VALUES('B','X',100);INSERT INTO sales VALUES('C','X',200);INSERT INTO sales VALUES('D','Y',200);INSERT INTO sales VALUES('E','Z',250);INSERT INTO sales VALUES('F','Z',300);INSERT INTO sales VALUES('G','X',100);INSERT INTO sales VALUES('H','Y',150);INSERT INTO sales VALUES('I','X',250);INSERT INTO sales VALUES('J','Z',100);INSERT INTO sales VALUES('K','Y',200); 查看sales数据：select * from sales; 剖析问题是咱们如何应用SQL语句将empid输入一个行号进去？从1开始？sales表empid是主键不会存在反复的数据，如果不是主键存在反复的数据怎么写SQL: 我是这么剖析的过程： A = A 后果为 true 计数器加1 A < B 后果为 true 计数器加1 后果为2 B < C 后果为 true 计数器加1 后果为3 C < D 后果为 trne 计数器加1 后果为4 顺次类推;empid字段自已跟自已关联，如果条件满足小于或等于时，计数据加1，写成以下SQL,在SQL语句中，称为子查问。 SELECT empid,( SELECT COUNT(*) FROM sales AS t2 WHERE t2.empid <= t1.empid) AS rownumFROM sales t1; ...

1、理论问题 间断范畴问题也是一个十分经典的SQL编程问题，在理论的开发中也常常应用，解决的办法有比拟多，然而个别采纳数字辅助表和分组。 如下例子： create table t(a int unsigned not null primary key); insert into t value(1);insert into t value(2);insert into t value(3);insert into t value(100);insert into t value(101);insert into t value(103);insert into t value(104);insert into t value(105); 下面的数据如何重到间断范畴： 2、解决办法咱们看上面的语句返回的后果：select a,@a := @a+1 rn from t,(select @a:=0) as a; 通过下面的辅助列RN阐明,如果SQL后果将a-rn值，如果是不变的，阐明是间断的， SELECT a,rn,a-rnFROM(SELECT a,@a := @a+1 rn FROM t,(SELECT @a:=0) AS a) b 认真剖析当前，再做一下分组SELECT MIN(a) start_range,MAX(a) start_range FROM(SELECT a,rn,a-rn AS diffFROM(SELECT a,@a := @a+1 rn FROM t,(SELECT @a:=0) AS a) b) cGROUP BY diff ...

装置装置 MySQL： brew install mysql启动 MySQL: mysql.server start查看 MySQL 服务状态： systemctl status mysql.service平安设置： myqsl_secure_installation, 执行后提醒安全策略： There are three levels of password validation policy:LOW Length >= 8MEDIUM Length >= 8, numeric, mixed case, and special charactersSTRONG Length >= 8, numeric, mixed case, special characters and dictionary file依据提醒抉择明码等级， 设置 Root 明码 创立用户创立用户： create user 'herbert_u'@'%' identified by 'herbert_123';受权用户： grant all privileges on retail_db.* to 'herbert_u'@'%';flush privileges;

背景在做数据荡涤工作，须要将线上的一份数据按工夫 dump 到本地，再做剖析。 通过 mysqldump 将数据导出下载后， 发现导出的数据与线上的数据条目数不统一。开始猜想是荡涤的脚本解决逻辑出了点问题， 通过一下午的调研和排查，最初发现根本原因是在导出 MySQL 备份数据时， 零碎时区和备份数据的时区不统一。 <!--more--> 问题剖析关上 mysqldump 保留下来的 binlog 文件， 在文件头能够发现以下两行配置： /*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;/*!40103 SET TIME_ZONE='+00:00' */;简略来说， 就是在备份数据的时候， 首先会将 time_zone 设置为 +00:00 但查看线上的数据库的默认配置， 会发现 time_zone 应用零碎默认时区： mysql> show variables like '%time_zone%';+--------------------------+------------+| Variable_name | Value |+--------------------------+------------+| system_time_zone | CST || time_zone | SYSTEM |+--------------------------+------------+rows in set (0.00 sec)查看零碎的默认时区： # date -RSun, 16 Jan 2019 17:10:54 +0800解决办法增加 -w 参数， 将工夫进行转换， 确保两边时区保持一致, 比方原来 start_at > 2019-01-16 00:00:00, 更新为 start_at > 2019-01-15 16:00:00, 提前8小时先在数据库更新时区配置为0时区：set time_zone='+00:00';， 备份实现后复原时区配置： set time_zone='SYSTEM';总结一旦发现 dump 下来的 数据与原来数据库数据不同时， 先确认工夫戳是否统一， 如果不统一， 有概率是时区设置有问题。 ...

1.数据库概述1.1 什么是数据库？所谓的数据库就是指存储和治理数据的仓库。 拓展内容1：数据库有哪些分类?(理解) 晚期:档次式数据库，网络型数据库当初:关系型数据库，非关系型数据库1.2 什么是关系型数据库？底层以二维表的模式保留数据的库就是关系型数据库 stu-学生表 学生编号姓名年龄1001刘培霞351002陈子枢18拓展内容2：常见的关系型数据库有哪些？（理解） SQL Server:微软提供，免费，实用于一些中型或大型的我的项目中，在JAVA中应用占比不高(.NET中应用的较多)Oracle:甲骨文公司提供，免费，实用于一些大型或者超大型的我的项目中，在JAVA中的应用占比十分高MYSQL：瑞士MYSQLAB公司提供，收费开源，实用于一些小型或者中型的我的项目中，在JAVA中的应用占比比拟高(玲珑轻量)mariadb其实是MYSQL的一个分支，用法和Mysql齐全一样 DB2：IBM公司提供，免费，在一些银行，金融等行业中应用较多。在JAVA中的应用占比也不高。Sqlite:迷你数据库，嵌入式设施中(安卓，苹果手机，pad)1.3 数据库相干概念1.3.1 什么是数据库服务器数据库服务器就是一个软件(比方mysql软件) 将数据库软件装置在电脑上，以后电脑就是一个数据库服务器。就能够对外提供存取数据的服务 在一个数据库服务器中能够创立多个数据库(databases)，每一个数据库都是一个独自的仓库。 #### 1.3.2 什么是数据库 数据库就是存储和治理数据的仓库，通常状况下，一个网站中的所有数据会寄存在一个数据库中。例如: jd.com db_jd(数据库)taobao.com db_taobao(数据库)...#### 1.3.3 什么是表 一个数据库中能够创立多张表，每张表用于存储一类信息(数据表)，例如 jd.com中的用户数据 tb_user(表)jd.com中的商品数据 tb_product(表)jd.com中的订单数据 tb_order(表)...#### 1.3.4 什么是表记录 一张表中能够蕴含多行表记录，每一行记录用于存储某一个具体的数据 学生编号姓名年龄1001刘沛霞351002陈子枢18..........1.4 什么是SQL语言？SQL是一门用于操作关系型数据库的通用的语言(应用SQL能够操作所有的关系型数据库) 应用SQL能够操作数据库，表，表记录(1) 创立数据库，删除数据库，批改数据库，查询数据库(2) 创立表，删除表，批改表，查问表(3) 新增表记录，删除表记录，批改表记录，查问表记录应用SQL也能够操作存储过程/视图/索引等。 提醒：SQL是一个规范通用的操作关系型数据库的语言(普通话)，每个数据库厂商为了加强本人数据库的性能，都提供了反对本人数据库的语言，称之为数据库的方言。方言不通用！

1. 事务1.1 事务概述 事务用来保障数据库的完整性——要么都批改，要么都不批改。事务必须满足ACID四个个性。 原子性（atomicity），指整个数据库事务是不可分割的工作单位。只有使事务中所有的数据库操作执行都胜利，才算整个事务胜利。如果事务中任何一个SQL语句执行失败，那么曾经执行胜利的SQL语句也必须撤销，数据库状态应该退回到执行事务前的状态。一致性（consistency），指事务将数据库从一种状态转变为下一种统一的状态，在事务开始之前和事务完结当前，数据库的完整性束缚没有被毁坏。隔离性（isolation），一个事务的影响在该事务提交前对其余事务都不可见——这通过锁来实现。持久性（durability），事务一旦提交，其后果就是永久性的。即便产生宕机等故障，数据库也能将数据恢复。1.2 事务隔离级别 ISO和ANIS SQL规范制订了四种事务隔离级别的规范： READ UNCOMMITEED，读未提交，会呈现脏读问题。READ COMMITTED，读已提交，会呈现幻读问题。REPEATABLE READ，可反复读（InnoDB存储引擎的默认隔离级别）SERIALIZABLE，会给每一个读操作加一个共享锁，不反对一致性的非锁定读，隔离性最高。2. 锁的粒度和类型 InnoDB既反对行级锁，也反对表级锁，默认状况下是采纳行级锁。InnoDB存储引擎实现了两种规范的行级锁： 共享锁（S Lock），容许事务读一行数据，不容许其余事务获取排他锁。排他锁（X Lock），容许事务删除或者更新一行数据，不容许其余事务取得共享锁或排他锁。 InnoDB存储引擎反对多粒度锁定，容许行级锁和表级锁同时存在。为了反对在不同粒度上进行加锁操作，InnoDB存储引擎提供了意向锁。意向锁是表级别的锁，其设计目标次要是为了在一个事务中揭示下一行将被申请的锁的类型。InnoDB存储引擎反对两种意向锁： 动向共享锁（IS Lock），事务想要取得一个表中某几行的共享锁。动向排他锁（IX Lock），事务想要取得一个表中某几行的排他锁。 意向锁不会阻塞除全表扫描以外的任何申请。 3. 一致性的非锁定读 一致性的非锁定读（consistent nonlocking read）是指InnoDB存储引擎通过多版本控制（multi versioning）的形式来读取以后执行工夫数据库中行的数据。如果读取的行正在执行DELETE、UPDATE操作，这是读取操作不会因而而期待行上锁的开释，相同，InnoDB存储引擎会去读取行的一个快照数据。如下图所示： 上图能够看出，读取的数据是一份快照数据，快照数据是指执行以后更改操作前的数据，该实现是通过undo段来实现的，所以快照数据自身是没有额定的开销的。因为快照数据是一份历史数据，是只读的，所以不须要上锁。 快照可能有多个版本，也就是说可能有多份不同的快照数据，这种技术称为行多版本技术，由此带来的并发管制称为多版本并发管制（Multi Version Concurrency Control， MVCC）。 一致性非锁定读是InnoDB存储引擎默认的读取形式，然而不同的事务隔离级别下，读取的形式不同，并不是每个事务隔离级别下读取的都是一致性读，即便都是一致性读，不同的事务隔离级别读取的快照数据也不同。例如Read Commited和Repeatable Read下，应用的都是一致性的非锁定读，但它们读取的是不同的快照数据。在Read Commited级别下，读取的总是被锁定行的最新一份快照数据，而在Repeatable Read级别下，读取的是事务开始时的第一份快照数据。 step 1. 初始化测试表mysql> create table t (id int, -> primary key (id)) -> engine innodb;Query OK, 0 rows affected (0.62 sec)mysql> insert into t values(1);mysql> select * from t;+----+| id |+----+| 1 |+----+1 row in set (0.00 sec)step 2. 开启一个会话A，并在会话A中开启一个事务，查看下测试表的数据，但不提交事务# Session Amysql> begin;Query OK, 0 rows affected (0.03 sec)mysql> select * from t;+----+| id |+----+| 1 |+----+1 row in set (0.00 sec)step 3. 开启另一个会话B，模仿并发的状况，在会话B中开启事务，批改测试表中id为1的数据，但不提交# Session Bmysql> begin ;Query OK, 0 rows affected (0.00 sec)mysql> update t set id = 3 where id = 1;Query OK, 1 row affected (0.00 sec)Rows matched: 1 Changed: 1 Warnings: 0step 4. 在会话A中查看测试表数据，发现还是批改之前的数据# Session Amysql> select * from t;+----+| id |+----+| 1 |+----+1 row in set (0.00 sec)setp 5. 在会话B中提交事务# Session Bmysql> commit;Query OK, 0 rows affected (0.04 sec)step 5. 再在会话A中查看测试数据，在Read Commited和Repeatable Read级别下失去的后果就不一样了。对于Read Committed级别，它总是读取最新版本，所以它失去的后果是一个id为3的记录（幻读）。而Repeatable Read级别下，它总是读取事务开始时的行数据，所以它失去的后果依然是一个id为1的记录。4. Select ... For Update 和 Select ... Lock In Share Mode 默认状况下，InnoDB存储引擎的Select操作应用的是一致性非锁定读，然而有些状况下，须要用户被动对读取操作进行加锁。InnoDB存储引擎对Select语句加锁有两种操作： ...

mac版mysql 装置后批改root明码步骤： 在开始上面的步骤之前必须先进行mysql服务！！！！ 关上终端 1、cd /usr/local/mysql/bin/ 2、sudo su输出之后会要求输出你的计算机明码，输出的时候是什么都不显示的，输完后回车3、 ./mysqld_safe --skip-grant-tables &这一步的作用是跨过权限验证 4、./mysql -uroot  已root身份登录，因为第三步的起因不须要明码了。这之后的命令就不须要在后面加./mysql 了； 5、use mysql; 6、(1) update mysql.user set authentication_string=password('123456'), plugin = 'mysql_native_password' where user = 'root'; 应用这一行明令将root明码批改为123456。 (2) flush privileges;利用权限。 (3)退出并重启MySQL。 这一步相对是最坑爹的！网上流传的版本全副是set password ＝‘’ ，这样写 特么始终报错说 ‘password’列不存在！！！ 最终用sql命令查出来只有authentication_string字段，并没有password字段。 上一步执行之后原本认为曾经能够登录了，可是navicat连贯测试时呈现了： ERROR 1862 (HY000): Your password has expired. To log in you mustchange it using a client that supports expired passwords. 所以还须要上面两步（我不必上面的步骤也能够用客户端登录了） 关上新的终端： 1、cd /usr/local/mysql/bin/
2、sudo su ...

前言说到数据库事务，大家脑子里肯定很容易蹦出一堆事务的相干常识，如事务的ACID个性，隔离级别，解决的问题（脏读，不可反复读，幻读）等等，然而可能很少有人真正的分明事务的这些个性又是怎么实现的，为什么要有四个隔离级别。 明天咱们就先来聊聊MySQL中事务的隔离性的实现原理，后续还会持续出文章剖析其余个性的实现原理。 当然MySQL博大精深，文章疏漏之处在劫难逃，欢送批评指正。 阐明 MySQL的事务实现逻辑是位于引擎层的，并且不是所有的引擎都反对事务的，上面的阐明都是以InnoDB引擎为基准。 定义隔离性（isolation）指的是不同事务先后提交并执行后，最终出现进去的成果是串行的，也就是说，对于事务来说，它在执行过程中，感知到的数据变动应该只有本人操作引起的，不存在其余事务引发的数据变动。 隔离性解决的是并发事务呈现的问题。 规范SQL隔离级别隔离性最简略的实现形式就是各个事务都串行执行了，如果后面的事务还没有执行结束，前面的事务就都期待。然而这样的实现形式很显著并发效率不高，并不适宜在理论环境中应用。 为了解决上述问题，实现不同水平的并发管制，SQL的规范制定者提出了不同的隔离级别：未提交读（read uncommitted）、提交读（read committed）、可反复读（repeatable read）、序列化读（serializable）。其中最高级隔离级别就是序列化读，而在其余隔离级别中，因为事务是并发执行的，所以或多或少容许呈现一些问题。见以下的矩阵表： 隔离级别（+:容许呈现，-:不容许呈现）脏读不可反复读幻读未提交读                                 +        +              +        提交读                                   -        +              +        可反复读                                 -        -              +        序列化读                                 -        -              -        留神，MySQL的InnoDB引擎在提交读级别通过MVCC解决了不可反复读的问题，在可反复读级别通过间隙锁解决了幻读问题，具体见上面的剖析。 实现原理规范SQL事务隔离级别实现原理咱们下面遇到的问题其实就是并发事务下的管制问题，解决并发事务的最常见形式就是乐观并发管制了（也就是数据库中的锁）。规范SQL事务隔离级别的实现是依赖锁的，咱们来看下具体是怎么实现的： 事务隔离级别   实现形式                                                     未提交读（RU）事务对以后被读取的数据不加锁；事务在更新某数据的霎时（就是产生更新的霎时），必须先对其加行级共享锁，直到事务完结才开释。提交读（RC）   事务对以后被读取的数据加行级共享锁（当读到时才加锁），一旦读完该行，立刻开释该行级共享锁；事务在更新某数据的霎时（就是产生更新的霎时），必须先对其加行级排他锁，直到事务完结才开释。可反复读（RR）事务在读取某数据的霎时（就是开始读取的霎时），必须先对其加行级共享锁，直到事务完结才开释；事务在更新某数据的霎时（就是产生更新的霎时），必须先对其加行级排他锁，直到事务完结才开释。序列化读（S）  事务在读取数据时，必须先对其加表级共享锁 ，直到事务完结才开释；事务在更新数据时，必须先对其加表级排他锁 ，直到事务完结才开释。能够看到，在只应用锁来实现隔离级别的管制的时候，须要频繁的加锁解锁，而且很容易产生读写的抵触（例如在RC级别下，事务A更新了数据行1，事务B则在事务A提交前读取数据行1都要期待事务A提交并开释锁）。 为了不加锁解决读写抵触的问题，MySQL引入了MVCC机制，具体可见我以前的剖析文章：一文读懂数据库中的乐观锁和乐观锁和MVCC。 InnoDB事务隔离级别实现原理在往下剖析之前，咱们有几个概念须要先理解下： 1、锁定读和一致性非锁定读 锁定读：在一个事务中，被动给读加锁，如SELECT ... LOCK IN SHARE MODE 和 SELECT ... FOR UPDATE。别离加上了行共享锁和行排他锁。锁的分类可见我以前的剖析文章：你应该理解的MySQL锁分类)。 https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html一致性非锁定读：InnoDB应用MVCC向事务的查问提供某个工夫点的数据库快照。查问会看到在该工夫点之前提交的事务所做的更改，而不会看到稍后或未提交的事务所做的更改（本事务除外）。也就是说在开始了事务之后，事务看到的数据就都是事务开启那一刻的数据了，其余事务的后续批改不会在本次事务中可见。 Consistent read是InnoDB在RC和RR隔离级别解决SELECT语句的默认模式。一致性非锁定读不会对其拜访的表设置任何锁，因而，在对表执行一致性非锁定读的同时，其它事务能够同时并发的读取或者批改它们。 https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-read.html2、以后读和快照读 以后读 读取的是最新版本，像UPDATE、DELETE、INSERT、SELECT ...  LOCK IN SHARE MODE、SELECT ... FOR UPDATE这些操作都是一种以后读，为什么叫以后读？就是它读取的是记录的最新版本，读取时还要保障其余并发事务不能批改以后记录，会对读取的记录进行加锁。 快照读 读取的是快照版本，也就是历史版本，像不加锁的SELECT操作就是快照读，即不加锁的非阻塞读；快照读的前提是隔离级别不是未提交读和序列化读级别，因为未提交读总是读取最新的数据行，而不是合乎以后事务版本的数据行，而序列化读则会对表加锁。 3、隐式锁定和显式锁定 隐式锁定 InnoDB在事务执行过程中，应用两阶段锁协定（不被动进行显示锁定的状况）： 随时都能够执行锁定，InnoDB会依据隔离级别在须要的时候主动加锁；锁只有在执行commit或者rollback的时候才会开释，并且所有的锁都是在同一时刻被开释。显式锁定 InnoDB也反对通过特定的语句进行显示锁定（存储引擎层）select ... lock in share mode //共享锁select ... for update //排他锁MySQL Server层的显示锁定：lock tableunlock table理解完下面的概念后，咱们来看下InnoDB的事务具体是怎么实现的（上面的读都指的是非被动加锁的select） 事务隔离级别   实现形式                                                     未提交读（RU）事务对以后被读取的数据不加锁，都是以后读；事务在更新某数据的霎时（就是产生更新的霎时），必须先对其加行级共享锁，直到事务完结才开释。提交读（RC）   事务对以后被读取的数据不加锁，且是快照读；事务在更新某数据的霎时（就是产生更新的霎时），必须先对其加行级排他锁（Record），直到事务完结才开释。通过快照，在这个级别MySQL就解决了不可反复读的问题可反复读（RR）事务对以后被读取的数据不加锁，且是快照读；事务在更新某数据的霎时（就是产生更新的霎时），必须先对其加行级排他锁（Record，GAP，Next-Key），直到事务完结才开释。通过间隙锁，在这个级别MySQL就解决了幻读的问题序列化读（S）  事务在读取数据时，必须先对其加表级共享锁 ，直到事务完结才开释，都是以后读；事务在更新数据时，必须先对其加表级排他锁 ，直到事务完结才开释。能够看到，InnoDB通过MVCC很好的解决了读写抵触的问题，而且提前一个级别就解决了规范级别下会呈现的幻读和不可反复读问题，大大晋升了数据库的并发能力。 ...

往年这种状况，有时候不找好下家还真不敢跳，这不，前段时间刚跳到新东家，刚办入职那天，就遇上事了，真的是吓出一身冷汗（老大始终盯着我，说要疾速解决这个问题），差点被（背）开（锅）了.... 状况如何？且听我上面缓缓道来！！！心愿对大家有所帮忙与借鉴。 问题形容线上有个重要Mysql客户的表在从5.6降级到5.7后，master上插入过程中呈现"Duplicate key"的谬误，而且是在主备及RO实例上都呈现。 以其中一个表为例，迁徙前通过“show create table” 命令查看的auto increment id为1758609， 迁徙后变成了1758598,理论对迁徙生成的新表的自增列用max求最大值为1758609。 用户采纳的是Innodb引擎，而且据运维同学介绍，之前碰到过相似问题，重启即可恢复正常。 内核问题排查因为用户反馈在5.6上拜访失常，切换到5.7后就报错。因而，首先得狐疑是5.7内核出了问题，因而第一反馈是从官网bug list中搜寻一下是否有相似问题存在，防止反复造车。通过搜寻，发现官网有1个相似的bug，这里简略介绍一下该bug。 背景常识1Innodb引擎中的auto increment 相干参数及数据结构。 主要参数包含：innodb_autoinc_lock_mode用于管制获取自增值的加锁形式，auto_increment_increment， auto_increment_offset用于管制自增列的递增的距离和起始偏移。 次要波及的构造体包含：数据字典构造体，保留整个表的以后auto increment值以及爱护锁；事务构造体，保留事务外部解决的行数；handler构造体，保留事务外部多行的循环迭代信息。 背景常识2mysql及Innodb引擎中对autoincrement拜访及批改的流程 (1) 数据字典构造体(dict_table_t)换入换出时对autoincrement值的保留和复原。换出时将autoincrement保留在全局的的映射表中，而后淘汰内存中的dict_table_t。换入时通过查找全局映射表复原到dict_table_t构造体中。相干的函数为dict_table_add_to_cache及dict_table_remove_from_cache_low。(2) row_import, table truncate过程更新autoincrement。(3) handler首次open的时候，会查问以后表中最大自增列的值，并用最大列的值加1来初始化表的data_dict_t构造体中的autoinc的值。(4) insert流程。相干对autoinc批改的堆栈如下：ha_innobase::write_row：write_row的第三步中调用handler句柄中的update_auto_increment函数更新auto increment的值。handler::update_auto_increment: 调用Innodb接口获取一个自增值，并依据以后的auto_increment相干变量的值调整获取的自增值；同时设置以后handler要解决的下一个自增列的值。ha_innobase::get_auto_increment:获取dict_tabel中的以后auto increment值，并依据全局参数更新下一个auto increment的值到数据字典中ha_innobase::dict_table_autoinc_initialize:更新auto increment的值，如果指定的值比以后的值大，则更新。handler::set_next_insert_id:设置以后事务中下一个要解决的行的自增列的值。(5) update_row。对于”INSERT INTO t (c1,c2) VALUES(x,y) ON DUPLICATE KEY UPDATE”语句，无论惟一索引列所指向的行是否存在，都须要推动auto increment的值。相干代码如下：if (error == DB_SUCCESS    && table->next_number_field    && new_row == table->record[0]    && thd_sql_command(m_user_thd) == SQLCOM_INSERT    && trx->duplicates)  {    ulonglong    auto_inc;       ……    auto_inc = table->next_number_field->val_int();    auto_inc = innobase_next_autoinc(auto_inc, 1, increment, offset, col_max_value);    error = innobase_set_max_autoinc(auto_inc);       ……}从咱们的理论业务流程来看，咱们的谬误只可能波及insert及update流程。 BUG 76872 / 88321: "InnoDB AUTO_INCREMENT produces same value twice"(1) bug概述:当autoinc_lock_mode大于0，且auto_increment_increment大于1时，零碎刚重启后多线程同时对表进行insert操作会产生“duplicate key”的谬误。(2) 起因剖析：重启后innodb会把autoincrement的值设置为max(id) + 1。此时，首次插入时，write_row流程会调用handler::update_auto_increment来设置autoinc相干的信息。首先通过ha_innobase::get_auto_increment获取以后的autoincrement的值(即max(id) + 1)，并依据autoincrement相干参数批改下一个autoincrement的值为next_id。 当auto_increment_increment大于1时，max(id) + 1 会不大于next_id。handler::update_auto_increment获取到引擎层返回的值后为了避免有可能某些引擎计算自增值时没有思考到以后auto increment参数，会从新依据参数计算一遍以后行的自增值，因为Innodb外部是思考了全局参数的，因而handle层对Innodb返回的自增id算出的自增值也为next_id，行将会插入一条自增id为next_id的行。 handler层会在write_row完结的时候依据以后行的值next_id设置下一个autoincrement值。如果在write_row尚未设置表的下一个autoincrement期间，有另外一个线程也在进行插入流程，那么它获取到的自增值将也是next_id。这样就产生了反复。 (3) 解决办法：引擎外部获取自增列时思考全局autoincrement参数，这样重启后第一个插入线程获取的自增值就不是max(id) + 1，而是next_id，而后依据next_id设置下一个autoincrement的值。因为这个过程是加锁爱护的，其余线程再获取autoincrement的时候就不会获取到反复的值。通过上述剖析，这个bug仅在autoinc_lock_mode > 0 并且auto_increment_increment > 1的状况下会产生。理论线上业务对这两个参数都设置为1，因而，能够排除这个bug造成线上问题的可能性。 现场剖析及复现验证既然官网bug未能解决咱们的问题，那就得自食其力，从谬误景象开始剖析了。 ...

MySQL DBA或开发人员，有时会误删或者误更新数据，如果是线上环境并且影响较大，就须要能疾速回滚。传统复原办法是利用备份重搭实例，再利用去除谬误sql后的binlog来复原数据。此法费时费力，甚至须要停机保护，并不适宜疾速回滚。也有团队利用LVM快照来缩短复原工夫，但快照的毛病是会影响mysql的性能。MySQL闪回(flashback)利用binlog间接进行回滚，能疾速复原且不必停机。 闪回的原理MySQL binlog以event的模式，记录了MySQL server从启用binlog以来所有的变更信息，可能帮忙重现这之间的所有变动。MySQL引入binlog次要有两个目标：一是为了主从复制；二是某些备份还原操作后须要从新利用binlog。有三种可选的binlog格局，各有优缺点： statement：基于SQL语句的模式，binlog数据量小，然而某些语句和函数在复制过程可能导致数据不统一甚至出错；row：基于行的模式，记录的是行的残缺变动。很平安，然而binlog会比其余两种模式大很多；mixed：混合模式，依据语句来选用是statement还是row模式；利用binlog闪回，须要将binlog格局设置为row。利用上面的语句能够查看以后binlog的模式。 show global variables like "%binlog_format%"; 闪回的实战实在的闪回场景中，最要害的是能疾速筛选出真正须要回滚的SQL。咱们应用开源工具binlog2sql来进行实战演练。binlog2sql由美团点评DBA团队(上海)出品，屡次在线上环境做疾速回滚。 ① 装置binlog2sql工具首先装置Python工具治理表pipyum -y install epel-releaseyum -y install python-pip装置binlog2sqlgit clone https://github.com/danfengcao/binlog2sql.git && cd binlog2sqlpip install -r requirements.txt② 闪回案例实战1、咱们应用之前的员工表数据，独自建设一个数据库 create database testflashback;use testflashback;source /root/tools/scott.sql2、误操作，执行上面的事务。 start transaction;delete from emp where sal>3000;update emp set sal=6000;delete from emp where job='CLERK';commit;3、查看目前的binlog文件 show master logs; 4、最新的binlog文件是mysql-binlog.000001。咱们的指标是筛选出须要回滚的SQL，因为误操作人只晓得大抵的误操作工夫，咱们首先依据工夫做一次过滤。只须要解析testflashback库emp表。(注：如果有多个sql误操作，则生成的binlog可能散布在多个文件，需解析多个文件) python binlog2sql/binlog2sql.py -uroot -pWelcome_1 \--start-file='mysql-binlog.000001' > /root/tools/raw.sql下面的语句将列车emp表的所有binlog日志。如果可能确定大抵的工夫范畴，能够应用参数--start-datetime和--stop-datetime进行过滤。例如： --start-datetime='2016-12-26 11:44:00' --stop-datetime='2016-12-26 11:50:00'解析解决的binlog如下： 5、依据地位信息，咱们确定了误操作sql来自同一个事务，精确地位在14956-16791之间(binlog2sql对于同一个事务会输入同样的start position)。再依据地位过滤，应用 -B 选项生成回滚sql，查看回滚sql是否正确。(注：实在场景下，生成的回滚SQL常常会须要进一步筛选。联合grep、编辑器等) ...