Mysql

数栈是云原生—站式数据中台PaaS，咱们在github和gitee上有一个乏味的开源我的项目：FlinkX，FlinkX是一个基于Flink的批流对立的数据同步工具，既能够采集动态的数据，也能够采集实时变动的数据，是全域、异构、批流一体的数据同步引擎。大家喜爱的话请给咱们点个star！star！star！ github开源我的项目：https://github.com/DTStack/fl... gitee开源我的项目：https://gitee.com/dtstack_dev... 一、客户背景 客户应用ES来进行数据存储、疾速查问业务订单记录，然而常常会呈现业务高峰期ES集群的cpu负载、内存应用均较高，查问提早大，导致前端业务拜访呈现大量超时的状况，极大影响其客户应用体验。 局部监控如下图： 1、 集群架构如下：集群节点配置：8数据节点（16C64G）；3主节点（8C32G） 2、 集群存在问题剖析 业务层面：与客户业务人员沟通，业务解决中有几个聚合查问会占用较多的内存，且这类查问对准确性要求较高，需准确统计所有匹配后果。 架构层面：存在4-5T的单个较大索引，该索引字段多达2000+，分片大小广泛60G+，最高达到130G+，是制约查问性能的一个较大瓶颈，另外集群在业务高峰期还会呈现常常的fullgc，这是呈现拜访超时的间接起因。 如图： 二、Elasticsearch集群优化 与客户开发人员沟通了解集群在业务上存在的问题，联合咱们在ES这块的服务教训，从语句参数、索引、架构等多个角度给客户提出调优倡议。 1、语句、参数调优 客户已提供4个慢查问语句，语句中聚合查问应用"execution_hint": "map"，该执行策略会把命中的记录都捞回内存中，一旦查问后果较大就会占用大量内存。倡议应用terminator_after，此办法能够管制查问后果数量，另外将不参加聚合、排序的字段设置为doc_values:false, 节俭磁盘空间晋升索引速度。 2、 集群架构优化： 在原有集群根底上增加协调节点或者扩容数据节点： 增加协调节点：长处是能够加重数据节点压力，变更较为容易，缓解fullgc频繁呈现的问题；扩容数据节点：长处是能够加重以后数据节点压力，也能够减小分片大小；然而减少索引分片须要从新创立索引，从新导入数据，且以后节点存储压力不大，同时减少数据节点对存储空间有肯定的节约。 联合客户业务个性，咱们举荐客户应用增加协调节点的形式对集群架构进行优化。 3、 集群索引优化： 能够对集群进行索引拆分和应用别名两方面进行优化调整。 拆分索引：对索引字段进行拆分并确认大小，能够解决以后索引分片过大的问题，晋升查问性能。应用别名：依据日期定期创立新的索引（倡议按月创立索引），依据业务对对立查问的索引创立对立别名，该办法能够彻底解决以后索引分片过大问题，优化查问性能。 三、集群优化成果 集群优化后整体性能有显著晋升： a. ES集群负载、内存较为安稳，业务高峰期不会有较大稳定； b. ES集群FullGC呈现频次极大升高，升高对业务的影响； c. ES聚合查问提早减小，业务数据查问性能晋升，速度达到百毫秒级别 四、写在最初 袋鼠云通过数据集成优化、任务调度优化、代码优化、全链路数据品质保障、故障紧急解决、大数据平台运维，为客户提供大数据系统运维保障服务。

01 前言小胖真的让人不省心。继上次小胖误删数据之后，这次这货间接给我把整个表锁住了。页面无响应，用户疯狂投诉，我特么脸都绿了。。。 事件是这样的，线上有个数据库几十万的数据，因为一开始没做好布局并没有给热点字段加索引。我就让小胖有空加个索引，没想到这货在用户应用高峰期加。。。 晓得起因，我还是比拟淡定的。毕竟最近都在钻研 MySQL，对于 MySQL 锁的问题解决起来还是得心应手。小胖见我三两下就解决了问题，客户也给出了卧槽，牛逼的必定，忙问我怎么解决的，我点燃手中 82 年的华子深深吸了一口，花了几个小时写了这篇文章给它。 全文 5665 字，从下午四点写到早晨九点，先上张思维导图镇楼： 1.1 往期精彩1、小胖问我：select 语句是怎么执行的？ 2、女朋友问我：MySQL 索引的原理是怎么的？ 3、小胖问我：MySQL 日志到底有啥用？ 4、老王问我：MySQL 事务与 MVCC 原理是怎么的？ 02 全局锁全局锁是对整个数据库实例加锁，让其处于只读状态。MySQL 能够通过 Flush tables with read lock (FTWRL) 实现，PS：unlock tables 能够解除只读状态。 执行该命令之后，数据更新语句（DML）数据的增删改操作以及数据操纵语句（DDL）批改表构造等操作将被阻塞。 2.1 全局锁的利用场景最典型的要数全库逻辑备份，就是把整个库的所有表都 select 进去存成文本。 假如当初我的数据库是读写拆散的：主写从读。有一种思路是应用 FTWRL 定时备份 + binlog 复原增量数据。 用 FTWRL 确保备份期间不会有其余线程对数据库做更新操作，而后整库备份。这时数据库实例会处于只读状态，就会造成两个问题： 在主库备份，备份期间不能写入，业务就会收到重大影响。在从库备份，备份期间不能执行主库同步的过去的 binlog（锁住了，不能写入），就会导致主从提早，业务也会受到影响。如果非要用这种形式，那么倡议是在一个月黑风高，零碎起码用户在应用的时候。 2.2 为什么要加锁？下面说了，利用全局锁备份会造成两个问题。那不加锁行吗？废话，必定是不行的。不加锁，你养我呀（备份出问题被开革）? 不加锁同样会呈现意想不到的问题：举个栗子，看电影买票，零碎有个余额表和用户已购票表。 当初我要备份，期间有人买票。逻辑上：余额表减掉相应金额，已购票表加上一张票。备份就会呈现两个问题： 先备份余额表，用户购买，再备份用户表。这是会怎么呢？不便了解，我画张图：从上图，咱们也大略晓得产生了啥。我来捋一捋： T1 时刻是备份前两个表的数据状态；T2 时刻开始备份，只备份了余额表；T3 时刻，因为没有加锁，用户买票；T4 时刻是买完票后的状态；T5 时刻备份到已购票表。 看最终的备份状态你发现没有？？？用户钱没少，票却多了一张（用户窃喜，程序员苦逼）。 以上就是不加锁的下场，它会导致数据前后不统一。这还是先备份余额表后备份已购票表的状况呈现的问题。 如果，备份的程序颠倒一下就会呈现：用户钱少了，票却没减少（你指定被投诉，程序员还是苦逼）。 通过下面剖析晓得，不加锁的话。备份失去的库不是同一个逻辑工夫点，才会造成这种结果。那怎么保障是同一逻辑工夫点呢？ 这时候就要引入上篇文章提到的一致性视图。 ...

前言： 不分明各位同学对数据库用户权限治理是否理解，作为一名 DBA ，用户权限治理是绕不开的一项工作内容。特地是生产库，数据库用户权限更应该标准治理。本篇文章将会介绍下 MySQL 用户权限治理相干内容。 1.用户权限简介当咱们创立过数据库用户后，还不能执行任何操作，须要为该用户调配适当的拜访权限。 对于 MySQL 用户权限简略的了解就是数据库只容许用户做你权力以内的事件，不能够越界。比方只容许你执行 select 操作，那么你就不能执行 update 操作。只容许你从某个 IP 上连贯 MySQL ，那么你就不能从除那个 IP 以外的其余机器连贯 MySQL 。 在 MySQL 中，用户权限也是分级别的，能够授予的权限有如下几组： 列级别，和表中的一个具体列相干。例如，能够应用 UPDATE 语句更新表 students 中 student_name 列的值的权限。表级别，和一个具体表中的所有数据相干。例如，能够应用 SELECT 语句查问表 students 的所有数据的权限。数据库级别，和一个具体的数据库中的所有表相干。例如，能够在已有的数据库 mytest 中创立新表的权限。全局，和 MySQL 中所有的数据库相干。例如，能够删除已有的数据库或者创立一个新的数据库的权限。权限信息存储在 mysql 零碎库的 user、db、tables_priv、columns_priv、procs_priv 这几个零碎表中。 user 表：寄存用户账户信息以及全局级别（所有数据库）权限。db 表：寄存数据库级别的权限，决定了来自哪些主机的哪些用户能够拜访此数据库。tables_priv 表：寄存表级别的权限，决定了来自哪些主机的哪些用户能够拜访数据库的这个表。columns_priv 表：寄存列级别的权限，决定了来自哪些主机的哪些用户能够拜访数据库表的这个字段。procs_priv 表：寄存存储过程和函数级别的权限。参考官网文档，可授予的权限如下表所示：看起来各种可授予的权限有很多，其实能够大抵分为数据、构造、治理三类，大略可分类如下： 2.权限治理实战咱们个别用 grant 语句为数据库用户赋权，倡议大家先用 create user 语句创立好用户之后再独自进行受权。上面通过示例来具体看下： # 创立用户create user 'test_user'@'%' identified by 'xxxxxxxx';# 全局权限GRANT super,select on *.* to 'test_user'@'%';# 库权限GRANT select,insert,update,delete,create,alter,execute on `testdb`.* to 'test_user'@'%';# 表权限GRANT select,insert on `testdb`.tb to 'test_user'@'%';# 列权限GRANT select (col1), insert (col1, col2) ON `testdb`.mytbl to 'test_user'@'%';# GRANT命令阐明：super,select 示意具体要授予的权限。ON 用来指定权限针对哪些库和表。*.* 中后面的*号用来指定数据库名，前面的*号用来指定表名。TO 示意将权限赋予某个用户。'test_user'@'%' 示意test_user用户，@前面接限度的主机，能够是IP、IP段、域名以及%，%示意任何中央。# 刷新权限flush privileges;# 查看某个用户的权限show grants for 'test_user'@'%';# 回收权限revoke delete on `testdb`.* from 'test_user'@'%';权限治理是一件不容忽视的事，咱们不能为了不便而给数据库用户很大的权限。特地是对于生产库，更应该进行权限管控，倡议程序用户只赋予增删改查等根底权限，个人用户只赋予查问权限。 ...

在我的 .NET 程序中连贯 MySql Server 8.0 数据库失败，残缺的谬误音讯是：Authentication to host 'localhost' for user 'root' using method 'mysql_native_password' failed with message: Access denied for user 'root'@'localhost' (using password: YES)。 执行以下 SQL 语句即可： ALTER USER 'username'@'localhost' IDENTIFIED WITH mysql_native_password BY '123456';FLUSH PRIVILEGES;留神下面的明码须要替换成本人的理论明码。

在这个问题上踩过坑，在 Windows 零碎中的 my.ini 文件里退出 skip-grant-tables 语句会导致谬误，所以大多数网友提供的这种办法间接就被淘汰掉了。通过一种环境的测试，行得通的做法如下： 还是须要先停用 MySql 的相干服务，而后如下 ALTER user root@'localhost' identified by '123456';把下面这段代码写入一个名为 root_newpass.txt 的文件中，寄存在 MySql Server 的装置目录下，如 X:\ProgramData\MySQL\MySQL Server 8.0，最初运行如下命令启动就行了： mysqld --defaults-file="C:\ProgramData\MySQL\MySQL Server 8.0\my.ini" --init-file="C:\ProgramData\MySQL\MySQL Server 8.0\root_newpass.txt"留神替换下面命令的相干门路。 相干环境：Windows 10，MySql Server 8.0

1.主库 /etc/my.cnf减少如下配置binlog-do-db=testbinlog-ignore-db=mysqllog-bin=mysql-binserver=1292.从库etc/my.cnf减少如下配置server-id=130replicate-do-db=testreplicate-ignore-db=mysql3.主节点创立公共用户并受权mysql -uroot -p123456create user 'test'@'%'identified with mysql_native_password by '123456';grant all privileges on . to 'root'@'%' with grant option;flush privileges; 4.查看状态，能够看以后主库以后同步日志的信息show master status;5.从节点对master的配置，依据上一步的配置mysql -uroot -p123456CHANGE MASTER TO MASTER_HOST='182.92.172.80', MASTER_USER='test', MASTER_PASSWORD='123456', MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=73;6.开启同步并显示状态start slave;show slave status\G

一. MVCC机制Multi-version Concurrency Controller 简称MVCC, 是为了进步数据库的并发读写能力，不加锁就能够让多个事物实现并发读写 Mysql会为每一行记录生成两个字段，trx_id(事物id), roll_pointer(回滚指针), 执行一个事务批改每一条数据的时候，会并将原来的数据复制一份，生成undo log, 并批改原来数据相应的属性，将数据的 roll_pointer(回滚指针) 指向undo log undo log指事务开始之前， 在操作任何数据之前,首先将需操作的数据备份到一个中央 mysql在执行查问的时候，会生成一个一致性视图 read-view,它由以下几个局部组成: 执行查问时所提交的trx_id数组数组外面最小的id（min_id）已创立的最大事务id（max_id）查问的数据后果要依据read-view做比照从而失去快照后果， 当隔离级别为可反复读的时候：在同一个事物执行查问，会沿用事物刚开始的read-view, 当隔离级别在度已提交的时候：每生成一条查问语句，会生成一个read-view mysql会沿着以后数据往undo log找， 如果trx_id 小于min_id, 则事物在查问之前就曾经提交，数据可见如果trx_id 大于max_id, 则事物在查问之前还没生成，数据不可见若数据的trx_id 在查问的未提交事物列表 如果数据的trx_id是以后事物，则数据可见如果数据的trx_id不是以后事物，则数据不可见 对于删除数据的状况，会将版本链上最新的数据复制一份，而后将trx_id 批改成删除操作的trx_id,同时在该记录的头信息（record_header ）里的delete flag 标记为写上true,示意以后记录曾经被删除，在依照上述规定查问的时候如果查到的delete flag 标记为为true的时候，不返回数据

mysql安装包下载地址https://dev.mysql.com/downloa... centos默认会装置mariadb所以要先卸载一下，防止出现抵触rpm -qa | grep mariadb卸载：rpm -e mariadb-libs-5.5.60-1.el7_5.x86_64 --nodeps2.在usr/local下创立mysql目录cd /usr/local&mkdir&&mysql3.解压文件tar -xvf mysql-8.0.23-1.el7.x86_64.rpm-bundle.tar装置rpm -ivh mysql-community-common-8.0.23-1.el7.x86_64.rpm --nodeps --forcerpm -ivh mysql-community-libs-8.0.23-1.el7.x86_64.rpm --nodeps --forcerpm -ivh mysql-community-client-8.0.23-1.el7.x86_64.rpm --nodeps --forcerpm -ivh mysql-community-server-8.0.23-1.el7.x86_64.rpm --nodeps --force5.初始化mysqld --initializechown mysql:mysql /var/lib/mysql -Rsystemctl start mysqld.servicesystemctl enable mysqld6.查看数据库明码cat /var/log/mysqld.log | grep password7.登录mysql -uroot -p而后输出查看的明码，这边我测试的话用复制过去的明码始终谬误要手动输出能力胜利！算是一个坑点。8.批改明码ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '123456'9.近程拜访受权create user 'root'@'%'identified with mysql_native_password by '123456';grant all privileges on . to 'root'@'%' with grant option; flush privileges;10.重启mysql服务service mysqld restart11.凋谢端口firewall-cmd --zone=public --add-port=3306/tcp --permanentfirewall-cmd --reload ...

数据库是什么数据库管理系统，简称为DBMS（Database Management System），是用来存储数据的管理系统。 DBMS 的重要性无奈多人共享数据无奈提供操作大量数据所需的格局实现读取自动化须要编程技术能力无奈应答突发事变DBMS 的品种层次性数据库 最古老的数据库之一，因为突出的毛病，所以很少应用了关系型数据库 采纳行列二维表构造来治理数据库，相似Excel的构造，应用专用的SQL语言对数据进行管制。关系数据库管理系统的常见品种 Oracle ==> 甲骨文SQL Servce ==> 微软DB2 ==> IBMPostgreSQL ==> 开源MySQL ==> 开源面向对象的数据库 XML数据库键值存储系统DB2RedisMongoDBSQL 语句及其品种DDL（数据定义语言） create ==> 创立数据库或者表等对象drop ==> 删除数据库或者表等对象alter ==> 批改数据库或者表等对象的构造DML（数据操作语言） select ==> 查问表中数据insert ==> 向表中插入数据update ==> 更新表中数据delete ==> 删除表中数据DCL（数据管制语言） commit ==> 决定对数据库中的数据进行变更rollback ==> 勾销对数据库中的数据进行变更grant ==> 赋予用户操作权限revoke ==> 勾销用户的操作权限SQL 的根本书写规定SQL 语句要以；结尾关键字不辨别大小写，然而表中数据辨别大小写关键字大写表名的首字母大写列明等小写常数的书写形式是固定的遇到字符串、日期等类型须要用到''单词间须要应用空格宰割命名规定数据库和表的名称能够应用英文、数据以及下划线名称必须以英文作为结尾名称不能反复 数据类型integer 数字型，然而不能寄存小数char 定长字符串类型，指定最大长度，有余应用空格填充varchar 可变长度字符串类型，指定最大长度，然而有余不填充data 存储日期，年/月/日以上内容是对通用数据库以及sql语句相干的知识点介绍，本文不做过多的赘述，本文次要针对关系型数据库：MySQL 来进行各方面的知识点总结。 MySQL 数据库简介MySQL 是最风行的关系型数据库管理系统，在 WEB 利用方面 MySQL 是最好的 RDBMS(Relational Database Management System：关系数据库管理系统)应用软件之一。 MySQL 是一个关系型数据库管理系统，由瑞典 MySQL AB 公司开发，目前属于 Oracle 公司。MySQL 是一种关联数据库管理系统，关联数据库将数据保留在不同的表中，而不是将所有数据放在一个大仓库内，这样就减少了速度并进步了灵活性。 ...

基于crudapi后端Java SDK二次开发之环境搭建（一）背景目前crudapi增删改查接口零碎的后盾Java API服务曾经全副可用，为了满足简单的场景，能够通过集成Java SDK的形式进行二次开发，以满足理论业务需要。 环境搭建装置JDK官网https://www.oracle.com/java/technologies/javase-downloads.html下载1.8版本（Java SE 8，Java SE 8u281 is the latest release for the Java SE 8 Platform.）装置即可。 java -versionjava version "1.8.0_241"装置maven官网http://maven.apache.org下载最新稳定版装置即可，教训证版本3.6是能够的。 mvn -vApache Maven 3.6.3下载demoGitHub地址https://github.com/crudapi/crudapi-example Gitee地址https://gitee.com/crudapi/crudapi-example 因为网络起因，GitHub可能速度慢，改成拜访Gitee即可，代码同步更新。 本地装置Jar包mvn install:install-file -Dfile=./lib/crudapi-core-1.0.0.jar -DgroupId=cn.crudapi -DartifactId=crudapi-core -Dversion=1.0.0 -Dpackaging=jarmvn install:install-file -Dfile=./lib/crudapi-api-1.0.0.jar -DgroupId=cn.crudapi -DartifactId=crudapi-api -Dversion=1.0.0 -Dpackaging=jar导入数据库./mysql/crudapi.sql 配置数据库信息./src/main/resources/application.properties spring.datasource.url=jdbc:mysql://localhost:3306/crudapi?serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=utf8&useSSL=false&allowPublicKeyRetrieval=truespring.datasource.username=rootspring.datasource.password=root编译mvn clean install -Dmaven.test.skip=true运行java -jar ./target/crudapi-example-1.0.0.jarswagger文档http://127.0.0.1:8888/swagger-ui.html 用户名和明码superadmin1234567890crudapi后盾治理WEBGitHub仓库https://github.com/crudapi/crudapi-admin-web Gitee仓库https://gitee.com/crudapi/crudapi-admin-web 批改配置批改quasar.conf.js文件中devServer->proxy->target devServer: { https: false, port: 8080, open: true, // opens browser window automatically proxy: { "/api/*": { target: "http://127.0.0.1:8888", changeOrigin: true } }}小结本文次要介绍了crudapi后盾Java SDK集成形式，demo运行起来后，既能够间接应用，也能够进行二次开发，后续会依据理论案例详情介绍中二次开发的应用场景。 ...

问题：InnoDB 刷脏页刷得比较慢，我的业务会受到影响么？如何进行试验验证？ 试验先宽油建个数据库： 找到这个数据库负责刷脏页的线程号： 咱们起一个 gdb，（别胆怯，本试验没有什么太深的调试技巧。） 咱们输出以下命令： 前三行命令，容许 gdb 只停下一个线程，而不是停下所有线程。 最初一行 attach，咱们让 gdb 管控咱们的 MySQL 实例。 通过一堆看不懂的输入，gdb 曾经管控了 MySQL 实例，能够输出命令了。 咱们先输出 info thread，拿到 MySQL 的线程表，找到负责刷脏页的线程在 gdb 中对应的 ID，是第 13 号线程： 而后咱们在 thread 13 上打一个断点（咱们为什么晓得要在 pc_sleep_if_needed 处打断点呢？留待晚点解释）： 紧接着就会看到 thread 13 停在了断点上，这根线程目前就停下来，不会再进行刷脏页了。 再来看一下各个线程的状态，有 1 号线程和 13 号线程停了下来： 咱们将 1 号线程放开： 而后将 gdb 放在一边，当初开始给 MySQL 上压力，还是用咱们罕用的办法： 不停执行最初一句，会发现 insert 会卡住，察看一下 innodb status， ...

⑴ 原子性（Atomicity） 原子性是指事务蕴含的所有操作要么全副胜利，要么全副失败回滚，这和后面两篇博客介绍事务的性能是一样的概念，因而事务的操作如果胜利就必须要齐全利用到数据库，如果操作失败则不能对数据库有任何影响。 ⑵ 一致性（Consistency） 一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。 拿转账来说，假如用户A和用户B两者的钱加起来一共是5000，那么不论A和B之间如何转账，转几次账，事务完结后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。 ⑶ 隔离性（Isolation） 隔离性是当多个用户并发拜访数据库时，比方操作同一张表时，数据库为每一个用户开启的事务，不能被其余事务的操作所烦扰，多个并发事务之间要互相隔离。 即要达到这么一种成果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就曾经完结，要么在T1完结之后才开始，这样每个事务都感觉不到有其余事务在并发地执行。 对于事务的隔离性数据库提供了多种隔离级别，稍后会介绍到。 ⑷ 持久性（Durability） 持久性是指一个事务一旦被提交了，那么对数据库中的数据的扭转就是永久性的，即使是在数据库系统遇到故障的状况下也不会失落提交事务的操作。 例如咱们在应用JDBC操作数据库时，在提交事务办法后，提醒用户事务操作实现，当咱们程序执行实现直到看到提醒后，就能够认定事务以及正确提交，即便这时候数据库呈现了问题，也必须要将咱们的事务齐全执行实现，否则就会造成咱们看到提醒事务处理完毕，然而数据库因为故障而没有执行事务的重大谬误。 以上介绍完事务的四大个性(简称ACID)，当初重点来阐明下事务的隔离性，当多个线程都开启事务操作数据库中的数据时，数据库系统要能进行隔离操作，以保障各个线程获取数据的准确性，在介绍数据库提供的各种隔离级别之前，咱们先看看如果不思考事务的隔离性，会产生的几种问题： 1，脏读 脏读是指在一个事务处理过程里读取了另一个未提交的事务中的数据。 当一个事务正在屡次批改某个数据，而在这个事务中这屡次的批改都还未提交，这时一个并发的事务来拜访该数据，就会造成两个事务失去的数据不统一。例如：用户A向用户B转账100元，对应SQL命令如下 updateaccountsetmoney=money+100wherename=’B’;  (此时A告诉B)     updateaccountsetmoney=money-100wherename=’A’; 当只执行第一条SQL时，A告诉B查看账户，B发现的确钱已到账（此时即产生了脏读），而之后无论第二条SQL是否执行，只有该事务不提交，则所有操作都将回滚，那么当B当前再次查看账户时就会发现钱其实并没有转。 2，不可反复读 不可反复读是指在对于数据库中的某个数据，一个事务范畴内屡次查问却返回了不同的数据值，这是因为在查问距离，被另一个事务批改并提交了。 例如事务T1在读取某一数据，而事务T2立马批改了这个数据并且提交事务给数据库，事务T1再次读取该数据就失去了不同的后果，发送了不可反复读。 不可反复读和脏读的区别是，脏读是某一事务读取了另一个事务未提交的脏数据，而不可反复读则是读取了前一事务提交的数据。 在某些状况下，不可反复读并不是问题，比方咱们屡次查问某个数据当然以最初查问失去的后果为主。但在另一些状况下就有可能产生问题，例如对于同一个数据A和B顺次查问就可能不同，A和B就可能打起来了…… 3，虚读(幻读) 幻读是事务非独立执行时产生的一种景象。例如事务T1对一个表中所有的行的某个数据项做了从“1”批改为“2”的操作，这时事务T2又对这个表中插入了一行数据项，而这个数据项的数值还是为“1”并且提交给数据库。而操作事务T1的用户如果再查看刚刚批改的数据，会发现还有一行没有批改，其实这行是从事务T2中增加的，就如同产生幻觉一样，这就是产生了幻读。 幻读和不可反复读都是读取了另一条曾经提交的事务（这点就脏读不同），所不同的是不可反复读查问的都是同一个数据项，而幻读针对的是一批数据整体（比方数据的个数）。 当初来看看MySQL数据库为咱们提供的四种隔离级别： ① Serializable (串行化)：可防止脏读、不可反复读、幻读的产生。 ② Repeatable read (可反复读)：可防止脏读、不可反复读的产生。 ③ Read committed (读已提交)：可防止脏读的产生。 ④ Read uncommitted (读未提交)：最低级别，任何状况都无奈保障。 ...

MySQL环境检测及装置1、检测本机上的mysql环境是否OK 关上cmd，输出:mysql -uroot -proot1）如果回车后显示：Welcome to the MariaDB/mysql...示意本机上曾经装置了mysql 并且也配置了环境变量。(不必再装置以及任何配置)2）如果回车后显示：mysql不是外部或外部命令，也不是可执行程序...，起因可能是： a）可能是电脑上装置了mysql，只是没有配制环境变量 （仅需配置环境变量！） b）也能够是电脑上既没有装置mysql，也没有配置环境变量 （需先装置，再配置环境变量）3）如何判断，本机是否装置了mysql？ 因为mysql默认装置地位是： C:/Program Files/MariaDB 10.3 C:/Program Files/mysql C:/Program Files/mysql5.5 C:/Program Files/mysql5.7 ... 如果有，点进去查看目录构造是否残缺4）如果曾经装置，只须要配置环境变量即可5）如果没有装置，先装置mysql，再配置环境变量2、装置mysql软件 mariadb10.37版本3、配置mysql环境变量 将mysql的装置目录下的bin目录配置到path环境变量中一、数据库概述1、什么是数据库 数据库: 存储和治理数据的仓库晚期：档次式数据库、网络型数据库当初市场上风行的是关系型数据库和非关系型数据库2、什么是关系型数据库 底层以二维表的模式来保留数据的库叫做关系型数据库常见的关系型数据库有哪些（理解）:Sql Server：微软，免费，实用于一些中型、大型的我的项目，在Java中的市场占比并不高。Oracle：甲骨文公司，免费，实用于一些大型、超大型的我的项目（功能强大、性能优异），50%MySQL：瑞典MySQLAB公司，收费开源，玲珑灵便，学习成本低，20% MySQL被甲骨文公司收买 开发成员：mariadb，永远开源收费，和mysql用法完全相同DB2：IBM，在银行、金融行业应用的较多，在Java中的市场占比不高。Sqlite：体积小，迷你数据库，用于智能家居，手机，pad等...3、数据库相干概念 数据库服务器: 比方咱们装置的mysql软件,装置在电脑上之后,能够对外提供存取数据的服务/能力 在一个数据库服务器中能够创立多个数据库. 数据库:每一个数据库都是存取数据的仓库. 通常一个网站中的所有数据会寄存在一个数据库中 比方: www.jd.com db_jd www.baidu.com db_baidu ...表:每一个数据库中能够创立多张表,每张表用于寄存一类数据,例如: 用户信息 tb_user 商品信息 tb_product 订单信息 tb_order 。。。表记录:每张表中又能够插入若干表记录,每一条表记录用于保留一个具体的事物 4、SQL语言 SQL: 是用于操作关系型数据库的通用的语言(学会了SQL语句,所有的关系型数据库都能够操作)应用SQL能够实现(数据库/表/表记录的)如下操作: 创立库、查看库、删除库、批改库 创立表、查看表、删除表、批改表 增加表记录、删除表记录、批改表记录、查问表记录 创立存储过程、视图、索引等SQL语言是通用的，但每一个数据库厂商为了加强本人数据库的能力，都提供了方言。 5、如何连贯mysql服务器（cmd） 关上cmd窗口,输出: mysql -uroot -proot关上cmd窗口,输出: mysql -uroot -p 换行之后再输出明码关上cmd窗口,输出: mysql -uroot -p -h主机名/ip地址 -P端口 换行之后再输出明码退出连贯mysql服务器: quit、exit、\q正文符号: #正文内容 -- 正文内容 /* 正文内容 */勾销以后SQL语句的执行：\c二、操作数据库、操作表（SQL） ...

置信很多人对于MySQL的索引都不生疏，索引(Index)是帮忙MySQL高效获取数据的数据结构。 因为索引是MySQL中比拟重点的常识，置信很多人都有肯定的理解，尤其是在面试中呈现的频率特地高。楼主自认为本人对MySQL的索引相干常识有很多理解，而且因为最近在找工作面试，所以独自温习了很多对于索引的常识。 然而，我还是图样图森破，直到我被阿里的面试官虐过之后我才晓得，本人在索引方面的常识，只是个小学生程度。 以下，是我总结的一次阿里面试中对于索引无关的问题以及知识点。 truncate和delete的区别DELETE是逻辑性的删除，逐行进行删除，该操作只会开释逻辑空间，能够被笼罩然而不会开释在磁盘上的物理空间属于逻辑性的删除，自增id会有缝隙，会有磁盘碎片产生。TRUNCATE table stu 对表段中的数据页进行清空，会删除表申请的数据页，开释物理磁盘空间，不会删除表定义（全表内容删除最好应用TRUNCATE，速度比DELETE快）DROP也是物理性的删除，会删除表定义和数据索引概念、索引模型 咱们是怎么聊到索引的呢，是因为我提到咱们的业务量比拟大，每天大略有几百万的新数据生成，于是有了以下对话： 面试官：你们每天这么大的数据量，都是保留在关系型数据库中吗？ 我：是的，咱们线上应用的是MySQL数据库 面试官：每天几百万数据，一个月就是几千万了，那你们有没有对于查问做一些优化呢？ 我：咱们在数据库中创立了一些索引（我当初十分悔恨我过后说了这句话）。 这里能够看到，阿里的面试官并不会像有一些公司一样拿着题库一道一道的问，而是会依据面试者做过的事件以及面试过程中的一些内容进行开展。 面试官：那你能说说什么是索引吗？ 我：（这道题必定难不住我啊）索引其实是一种数据结构，可能帮忙咱们疾速的检索数据库中的数据。 面试官：那么索引具体采纳的哪种数据结构呢？ 我：（这道题我也背过）常见的MySQL次要有两种构造：Hash索引和B+ Tree索引，咱们应用的是InnoDB引擎，默认的是B+树。 这里我耍了一个小心机，特意说了一下索引和存储引擎无关。心愿面试官能够问我一些对于存储引擎的问题。 面试官：既然你提到InnoDB应用的B+ Tree的索引模型，那么你晓得为什么采纳B+ 树吗？这和Hash索引比拟起来有什么优缺点吗？ 我：（忽然感觉这道题有点难，然而我还是凭借着本人的常识储备简略的答复上一些）因为Hash索引底层是哈希表，哈希表是一种以key-value存储数据的构造，所以多个数据在存储关系上是齐全没有任何程序关系的，所以，对于区间查问是无奈间接通过索引查问的，就须要全表扫描。所以，哈希索引只实用于等值查问的场景。而B+ Tree是一种多路均衡查问树，所以他的节点是人造有序的（左子节点小于父节点、父节点小于右子节点），所以对于范畴查问的时候不须要做全表扫描。 面试官：除了下面这个范畴查问的，你还能说出其余的一些区别吗？ 我：（这个题我答复的不好，预先百度了一下） 科普工夫：B+ Tree索引和Hash索引区别 哈希索引适宜等值查问，然而无奈进行范畴查问 哈希索引没方法利用索引实现排序 哈希索引不反对多列联结索引的最左匹配规定 如果有大量反复键值得状况下，哈希索引的效率会很低，因为存在哈希碰撞问题聚簇索引、笼罩索引 面试官：刚刚咱们聊到B+ Tree ，那你晓得B+ Tree的叶子节点都能够存哪些货色吗？ 我：InnoDB的B+ Tree可能存储的是整行数据，也有可能是主键的值。 面试官：那这两者有什么区别吗？ 我：（当他问我叶子节点的时候，其实我就猜到他可能要问我聚簇索引和非聚簇索引了）在 InnoDB 里，索引B+ Tree的叶子节点存储了整行数据的是主键索引，也被称之为聚簇索引。而索引B+ Tree的叶子节点存储了主键的值的是非主键索引，也被称之为非聚簇索引。 面试官：那么，聚簇索引和非聚簇索引，在查问数据的时候有区别吗？ 我：聚簇索引查问会更快？ 面试官：为什么呢？ 我：因为主键索引树的叶子节点间接就是咱们要查问的整行数据了。而非主键索引的叶子节点是主键的值，查到主键的值当前，还须要再通过主键的值再进行一次查问。 面试官：刚刚你提到主键索引查问只会查一次，而非主键索引须要回表查问屡次。（起初我才晓得，原来这个过程叫做回表）是所有状况都是这样的吗？非主键索引肯定会查问屡次吗？ 我：（额、这个问题我答复的不好，起初我本人查资料才晓得，通过笼罩索引也能够只查问一次） 科普工夫——笼罩索引 笼罩索引（covering index）指一个查问语句的执行只用从索引中就可能获得，不用从数据表中读取。也能够称之为实现了索引笼罩。 当一条查问语句合乎笼罩索引条件时，MySQL只须要通过索引就能够返回查问所须要的数据，这样防止了查到索引后再返回表操作，缩小I/O提高效率。 如，表covering_index_sample中有一个一般索引 idx_key1_key2(key1,key2)。当咱们通过SQL语句：select key2 from covering_index_sample where key1 = ‘keytest’;的时候，就能够通过笼罩索引查问，无需回表。联结索引、最左前缀匹配 面试官：不晓得的话没关系，想问一下，你们在创立索引的时候都会思考哪些因素呢？ 我：咱们个别对于查问概率比拟高，常常作为where条件的字段设置索引 面试官：那你们有用过联结索引吗？ 我：用过呀，咱们有对一些表中创立过联结索引。 面试官：那你们在创立联结索引的时候，须要做联结索引多个字段之间程序你们是如何抉择的呢？ ...

大抵的配置文件门路在 X:\ProgramData\MySQL\MySQL Server\my.ini，不同的 MySQL Server 版本对应的文件地位应该会不一样，配置文件旁边还有一个名字叫 Data 的文件夹，这个就是数据库寄存的文件夹，我把它挪动到了新的地位。这个配置文件外面有一行的规定是 datadir=???，这个中央就指定了数据库的寄存门路，比方我把它批改为 datadir="D:\MySQL\Data"，批改后就启动 MySQL 服务，但这个时候出了问题，启动不了 MySQL 服务： 在网上查了下，有网友说用 mysqld --initialize 命令执行初始化操作，另外还有说批改配置文件外面的 max_connect_errors 参数值，据介绍，这个参数的作用是当客户端尝试连贯但失败的次数达到这一值的时候，MySQL 会阻止此客户端的连贯，重置这一计数的形式能够是重新启动 MySQL 服务，或者是应用 FLUSH HOSTS 命令，有的说这个参数值调大了或者调小了都会导致不能启动 MySQL 服务。看到这个中央我感觉路被带偏了，我只是因为批改了配置文件的数据库门路才不能启动服务的，竟然会牵扯出这么多的可能性，过后依照呈现的谬误去找问题感觉切实太空泛。我核查了我设置的门路，甚至是分号、引号还有大小写都仔细检查过，不可能会呈现门路设置错的问题，我又试了试给 D 盘的那个文件夹设置权限，没想到真是这个问题，没想到权限不够会在启动服务的时候报错。我间接给新的数据库文件夹设置了一个 everyone 的齐全管制权限就好了。 相干环境：Windows Server 2008 R2、MySQL Server 8.0.15

MVCC顺便聊聊MVCC（多版本并发管制）。在mysql中，RC（已提交读）和RR（可反复读）隔离级别下，借助MVCC机制，能够解决查问时不同事务间的并发读写问题。 零碎版本号零碎里保护一个零碎版本号，这个版本号在每次创立一个事务时就会自增。每个事务会保护一个事务版本号transaction id（以下简称事务id），这个版本号就是取自创立事务时的零碎版本号。 版本链每行数据会保护2个虚构列，一个是版本号TRX_ID，每次事务创立或者更新某个行数据的时候，就会把事务id赋值给该行的TRX_ID，代表这个版本的行数据是我这个事务批改的;一个是回滚指针ROLL_PTR，指向前一次的版本，所有历史版本的记录都会存在undo log里（相干log的概念前面会提到）。留神，这里仅仅是事务批改行数据就会对TRX_ID赋值，而不是要提交事务才执行操作。咱们须要搞清楚一个概念，所谓的版本，就是每次对行数据进行批改，mysql都会新增一个批改后的记录版本，而后用ROLL_PTR指向上一个版本。所以，在mysql中会有多个不同版本的行数据，因为回滚指针的存在造成一个版本链。 readview一个事务在进行查问时，会创立一个快照readview（RC和RR不同，RR隔离级别会在事务第一次查问时生成一个快照，事务的后续查问都应用这个快照，RC级别则是事务每次查问都会生成快照），它会存储系统中其余所有未提交沉闷事务id的汇合m_ids 那么mysql是怎么利用上述的构件去实现MVCC呢？大略有以下四种状况：1.被拜访行数据版本的TRX_ID如果小于m_ids中最小的事务id m_up_limit_id，则创立这个版本数据的事务是在以后事务创立readview前就提交了的，所以能够被以后事务拜访2.被拜访行数据版本的TRX_ID如果大于m_ids中最大的事务id m_low_limit_id，则创立这个版本数据的事务是在以后事务创立readview后才开启，所以不能够被以后事务拜访3.被拜访行数据版本的TRX_ID如果介于m_ids中最小和最大事务id之间，判断一下是否存在于m_ids中。如果存在，则阐明创立这个版本数据的事务在以后事务创立readview时依然沉闷，所以不能够被以后事务拜访；反之，则这个版本数据的事务是在以后事务创立readview前就提交了的，所以能够被以后事务拜访。4.被拜访行数据版本的TRX_ID如果等于m_ids中最大或最小的事务id，则以后事务开启时，创立这个版本数据的事务还未提交，也不能被以后事务拜访 顺便提一下，有两点须要留神：1.事务拜访仅仅是针对单个版本而言的，行数据版本不能被以后事务拜访并不意味着行数据之前的版本不能被拜访，因为之前版本的事务id可能是满足被拜访的条件的2.以后事务id等于行数据版本的事务id的时候，必定能够被以后事务拜访，因为该版本就是以后事务创立的

迁徙阐明本篇文章从 MySQL、MongoDB 迁徙到云开发数据库，其余数据库迁徙也都大同小异。 迁徙大抵分为以下几步： 从 MySQL、MongoDB 将数据库导出为 JSON 或 CSV 格局创立一个云开发环境到云开发数据库新建一个汇合在汇合内导入 JSON 或 CSV 格式文件导出一、导出 MySQL 数据上面的流程中，咱们应用 Navicat for MySQL 进行导出。您也能够应用其它 MySQL 导出工具。 1、导出为 CSV 格局 选中表后进行导出： 类型中抉择 csv 格局： 注：在第 4 步时，咱们须要勾选蕴含列的题目 导出后的 csv 文件内容 第一行为所有键名，余下的每一行则是与首行键名绝对应的键值记录。相似这样： 2、导出为 JSON 格局 同样的咱们将选中的表进行导出为 json 格局： 残余步骤全副抉择默认即可。 导出后的样子： 咱们将数组去除，最初是这样： 二、导出 MongoDB 数据首先咱们先启动 mongod 服务： 启动后此终端不要敞开。 1、导出为 CSV 格局 新关上一个终端，输出以下命令： mongoexport -db <数据库> --collection <汇合名称> --type csv -f <字段名1[,字段名2]> -o <输入的文件门路>更具体的参数阐明，请参考 MongoDB 文档。 ...

索引笼罩在之前《大白话 mysql 之深入浅出索引原理 - 上》这篇文章中提到过，mysql 的 innodb 引擎通过搜寻树形式实现索引，索引类型分为主键索引和二级索引（非主键索引），主键索引树中，叶子结点保留着主键即对应行的全副数据；而二级索引树中，叶子结点保留着索引值和主键值，当应用二级索引进行查问时，须要进行回表操作。如果咱们当初有如下表构造。 CREATE TABLE `user_table` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `username` varchar(255) NOT NULL, `email` varchar(255) NOT NULL, `password` varchar(255) DEFAULT NULL, `age` int(11) unsigned Not NULL, PRIMARY KEY (`id`), key (`username`)) ENGINE=InnoDB DEFAULT CHARSET=utf8执行语句(A) select id from user_table where username = '张三' 时，因为 username 索引树的叶子结点上保留有 username 和 id 的值，所以通过 username 索引树查找到 id 后，咱们就曾经失去所需的数据了，这时候就不须要再去主键索引上持续查找了。执行语句(B) select password from user_table where username = '张三' 时，流程如下 ...

当咱们应用汉语字典查找某个字时，咱们会先通过拼音目录查到那个字所在的页码，而后间接翻到字典的那一页，找到咱们要查的字，通过拼音目录查找比咱们拿起字典从头一页一页翻找要快的多，数据库索引也一样，索引就像书的目录，通过索引能极大进步数据查问的效率。 索引的实现形式在数据库中，常见的索引实现形式有哈希表、有序数组、搜寻树。 哈希表哈希表是通过键值对（key-value）存储数据的索引实现形式，能够将哈希表设想成是一个数组，将索引通过哈希函数计算失去该行数据在数组中的地位，而后将数据存到数组中，容易发现一个问题，如果两个索引通过哈希函数计算后失去的数组地位雷同要怎么办？咱们能够采纳哈希链表，数组的每个 value 都是一个链表，新数据间接增加到链表尾部。 所以数据库查问过程为：索引通过哈希函数计算数据所在位置 --> 遍历指定地位的链表，找到满足条件的数据。 每次有新数据退出时，新数据时间接增加到链表尾部，所以增加数据时很不便。 哈希表不善于进行区间查问，个别都用于等值查问，因为两个相邻索引通过 hash 函数后计算失去的数组地位不肯定还放弃相邻，须要哈希屡次能力把区间的数据全查出来。 有序数组顾名思义，有序数组是按索引大小将数据保留在一个数组上，因为该数组是有序的，能够通过二分法很容易查到地位，找到第一个地位后，通过向左或者向右遍历很容易失去所求区间的数据。因而，无论是等值查问还是区间查问，效率都极高。 但缺点也是不言而喻的，当向数组两头 n 地位插入一条数据时，需将 n 前面的数据全副往后挪动，所以，这种索引个别用于动态存储引擎。 搜寻树二叉搜寻树：一棵空树，或者是具备下列性质的二叉树：若它的左子树不空，则左子树上所有结点的值均小于它的根结点的值；若它的右子树不空，则右子树上所有结点的值均大于它的根结点的值；二叉搜寻树的左、右子树也别离为二叉搜寻树。 均衡二叉树：均衡二叉树是在二叉搜寻树的根底上引入的，指的是结点的左子树和右子树的深度差不超过 1。 多叉树：每个结点能够有多个子结点，子节点的大小从左到右顺次递增。 数据库个别应用均衡树来当索引的存储数据结构，当应用均衡二叉实现索引时，构造如下图。 从图中可发现，每次查问最多须要拜访 4 个节点必能失去所要数据。例如查问 user2 时，查问过程为：userA-->userC-->userF-->user2。所以查问速度很高，复杂度为 O (log (n))；均衡二叉树的更新复杂度也为 O (log (n))。 区间查问时，因为搜寻树的个性（左子树小于右子树），能够很快的排除掉不满足条件的节点，查起来速度也是很快的。 思考下为什么用均衡搜寻树呢？ 因为一般的二叉树可能因为插入的数据最初变成一个很长的链表，查问复杂度进化成 O (n)。 如果搜寻树存于内存中，与多叉树相比，二叉树的搜寻速率是最高的，但实际上数据库应用的是 n 叉树而不是二叉树。 索引不仅存于内存，还是写到磁盘上，搜寻树上的每个结点在磁盘上体现为一个数据块。多叉树每个结点下能够有多个子节点，所以存储雷同数据量时多叉树的树高比二叉树小，查问一个数据须要拜访的结点数更少，即查问过程拜访更少的数据块。查问速度较高。在 mysql 的 innodb 引擎中，应用 B + 树来存储数据，B + 树是一种多叉均衡查找树。 innodb 的索引模型在 B + 树中，咱们将节点分为叶子结点和非叶子结点，非叶子结点上保留的是索引，而且一个节点能够保留多个索引；数据全副存于叶子结点上，并且叶子结点之间通过指针连接起来。 依据叶子结点的内容不同，innodb 索引分为主键索引和非主键索引。非主键索引也称为二级索引。主键索引的叶子结点中保留的数据为整行数据，而非主键索引叶子节点保留的是主键的值。 通过主键索引查问数据时，咱们只需查找主键索引树便能够获取数据；通过非主键索引查问数据时，咱们先通过非主键索引树查找到主键值，而后再在主键索引树搜寻一次，这个过程称为回表，也就是说非主键索引查问会比主键查问多搜寻一棵树。所以咱们应尽可能应用主键查问。 B + 树是一颗 N 叉树，N 是由什么决定的？是否调整？ 通过批改 page 的大小来间接调整 N 的大小。一个节点上的所有数据都在一个 page 中，页越大，每页寄存的索引就越多，N 就越大。数据页调整后，如果数据页太小层数会太深，数据页太大，加载到内存的工夫和单个数据页查问工夫会进步，须要达到均衡才行。批改索引的大小。每个索引包含固定字节数的 Point 指针和索引字段内容，索引字段越小，每页能存的索引就越多，N 就越大。索引保护增加新行时，将会在索引表上增加一条记录，如果是索引递增插入时，数据都是追加在以后最大索引之后，不会对树中其余数据造成影响；如果新退出的数据的索引值位于节点的两头，须要移动局部节点的地位，从而放弃索引树的有序性。 ...

MySQL 死锁是面试常问问题，金三银四，所以最近面试相干的文章比拟多，本文章是总结的一波死锁问题，和大家分享一下。 Mysql 锁类型和加锁剖析MySQL有三种锁的级别：页级、表级、行级。表级锁：开销小，加锁快；不会呈现死锁；锁定粒度大，产生锁抵触的概率最高,并发度最低。行级锁：开销大，加锁慢；会呈现死锁；锁定粒度最小，产生锁抵触的概率最低,并发度也最高。页面锁：开销和加锁工夫界于表锁和行锁之间；会呈现死锁；锁定粒度界于表锁和行锁之间，并发度算法： next KeyLocks锁，同时锁住记录(数据)，并且锁住记录后面的Gap  Gap锁，不锁记录，仅仅记录后面的GapRecordlock锁（锁数据，不锁Gap）所以其实 Next-KeyLocks=Gap锁+ Recordlock锁完整版的MySQL学习笔记点击支付 死锁产生起因和示例产生起因所谓死锁<DeadLock>：是指两个或两个以上的过程在执行过程中,因抢夺资源而造成的一种相互期待的景象,若无外力作用，它们都将无奈推动上来.此时称零碎处于死锁状态或零碎产生了死锁，这些永远在相互期待的过程称为死锁过程。表级锁不会产生死锁.所以解决死锁次要还是针对于最罕用的InnoDB。死锁的关键在于：两个(或以上)的Session加锁的程序不统一。那么对应的解决死锁问题的要害就是：让不同的session加锁有秩序 产生示例案例一需要：将投资的钱拆成几份随机调配给借款人。起初业务程序思路是这样的：投资人投资后，将金额随机分为几份，而后随机从借款人表外面选几个，而后通过一条条 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的这里不信请看: ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 * 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 前言我之前有一篇介绍在 MySQL SHELL 环境中如何对文档类数据进行操作，然而 MySQL SHELL 性能很多，除了能够操作文档类数据，也能够对关系表进行各种 DDL,DML 等操作。这里我就用几个简略例子来示范下如何用 MySQL SHELL 操作关系表。 此处援用的数据库示例基于官网的 SAMPLE DATABASE：WORLD，表构造以及数据能够自行下载。 MySQL SHELL 对关系型数据库的操作波及到三个组件：MySQL：传统 mysql，操作比较简单，除了写法有些差别外，基本上等同于 SQL 操作。MySQL X：基于 X DEV 协定操作 mysql，其中蕴含很多类，除了能够操作文档数据，也能够操作关系表。SHELL：蕴含了以上两个组件，能够随便切换，重点在于如何抉择连贯协定。咱们来顺次看看各个组件对关系表的罕用检索形式。 第一：mysql 组件连贯数据库：mysql.get_session 或者 mysql.get_classic_session 能够用如下传统拼串形式连贯数据库： MySQL Py > connection_url="mysql://root:root@localhost/world?socket=(/var/lib/mysql/official/mysql.sock)"MySQL Py > ytt_cn1 = mysql.get_session(connection_url);MySQL Py > ytt_cn1<ClassicSession:root@localhost>也能够用字典的形式连贯数据库： MySQL Py > connection_url={"schema":"world","user":"root","password":"root","socket":"/var/lib/mysql/official/mysql.sock"}MySQL Py > ytt_cn1=mysql.get_session(connection_url);MySQL Py > ytt_cn1<ClassicSession:root@/var%2Flib%2Fmysql%2Fofficial%2Fmysql.sock>接下来能够用 ClassicSession 类提供的各种办法来对关系表进行相干操作，所有的操作都能够间接用函数 run_sql 来执行： ...

本文首发于《.NET 5/.NET Core应用EF Core 5(Entity Framework Core)连贯MySQL数据库写入/读取数据示例教程》 前言在.NET Core/.NET 5的利用程序开发，与其常常搭配的数据库可能是SQL Server。而将.NET Core/.NET 5应用程序与SQL Server数据库的ORM组件有微软官网提供的EF Core(Entity Framework Core)，也有像SqlSugar这样的第三方ORM组件。EF Core连贯SQL Server数据库微软官网就有比拟具体的应用教程和文档。 本文将为大家分享的是在.NET Core/.NET 5应用程序中应用EF Core 5连贯MySQL数据库的办法和示例。 本示例《.NET 5/.NET Core应用EF Core 5(Entity Framework Core)连贯MySQL数据库写入/读取数据示例教程》源码托管地址： https://gitee.com/codedefault/efcore-my-sqlsample创立示例我的项目应用Visual Studio 2019(当然，如果你喜爱应用VS Code也是没有问题的，笔者还是更喜爱在Visual Studio编辑器中编写.NET代码)创立一个基于.NET 5的Web API示例我的项目,这里取名为MySQLSample： 我的项目创立好后，删除其中主动生成的多余的文件，最终的构造如下： 装置依赖包关上程序包管理工具，装置如下对于EF Core的依赖包： Microsoft.EntityFrameworkCorePomelo.EntityFrameworkCore.MySql (5.0.0-alpha.2)Microsoft.Bcl.AsyncInterfaces 请留神Pomelo.EntityFrameworkCore.MySql包的版本，安装包时请开启蕴含预览，如：创立实体和数据库上下文创立实体创立一个实体Person.cs，并定义一些用于测试的属性，如下： using System;using System.ComponentModel.DataAnnotations;using System.ComponentModel.DataAnnotations.Schema;namespace MySQLSample.Models{ [Table("people")] public class Person { [Key] public int Id { get; set; } public string FirstName { get; set; } public string LastName { get; set; } public DateTime CreatedAt { get; set; } }}创立数据库上下文创立一个数据库上下文MyDbContext.cs，如下： ...

后面探索了mysql的数据结构和索引，本文咱们来学习一下mysql中事务和锁方面的常识。总结了一些点，不便温故知新 事务1. ACID四大个性 Atomicity：原子性事务中的操作要么全副胜利要么全副失败Consistency：一致性一个事务在执行前后，数据库都必须放弃一致性，数据库只蕴含胜利提交事务的后果Isolation：隔离性事务的执行是互相隔离的，不被烦扰的Durability：持久性事务提交后，对数据的批改必须是永恒保留的 2. 隔离级别 未提交读（READ UNCOMMITTED）事务能够读取其余未提交事务中批改的数据，会产生脏读，不可反复读，幻读已提交读（READ COMMITTED）事务只能读取其余已提交事务批改的数据，能够解决脏读（读取的数据是别的未提交事务批改的数据）可反复读（REPEATABLE READ）在事务开启时，不再容许批改操作，一个事务屡次读取同一数据失去的后果是统一的，能够解决不可反复读（一个事务进行2次查问，两头有别的事务进行了批改操作，导致两次查问的后果不同）可串行化（SERIALIZABLE）事务串行执行，不能并发执行，能够解决幻读（一个事务进行2次查问，两头有别的事务进行了新增或删除操作，导致失去了不同条数的数据） 锁共享锁（读锁） 容许多个事务共享一把锁，然而对于加锁的数据只能读取，不能进行UPDATE DETELE等操作lock in share mode能够增加共享锁 排他锁（写锁） 只有一个事务能拿到排他锁，其余事务不能获取到锁，会阻塞直到持有锁的事务开释锁或者期待超时，不能与其余锁共存InnoDB会对update，insert，delete语句主动加排它锁select ... for update也会增加排他锁其余事务能够失常执行select语句，因为select不波及加锁（有些文章含糊了这块的概念，强调排他锁事务未提交时，其余事务不能对锁住的数据进行任何操作，我在试验过后发现不加for update的查问操作是能够执行的） 动向共享锁/动向排他锁在事务获取共享锁或排他锁之前，会对整张表先加锁，意向锁存在的意义是反对行锁和表锁共存 锁算法Record Lock（记录锁）对记录上的索引加锁，能够了解为行锁 Gap Lock（间隙锁）间隙锁，只对索引的间隙加锁，然而不包含索引自身，只有RR隔离级别以上才反对间隙锁 Next-Key Lock（临键锁）Record Lock+Gap Lock，不仅对索引加锁，也对索引的间隙加锁（左开右闭），InnoDB利用Next-Key Lock来解决幻读问题 加锁规定1. next-key lock 是前开后闭区间((x,y])。2. 查找过程中拜访到的对象才会加锁。3. 索引上的等值查问，给惟一索引加锁的时候，next-key lock 进化为行锁。4. 索引上的等值查问，向右遍历时且最初一个值不满足等值条件的时候，next-key lock 进化为间隙锁。5. 惟一索引上的范畴查问会拜访到不满足条件的第一个值为止 举例：假如咱们有张只有主键id的表，表的数据为1,2,3,4,5,6,9,11，咱们看看不同的sql下，加锁的后果是什么 select * from user where id =8 for update8介于索引6 9之间，next-key lock前开后闭(6,9]，又因为左边最初一个值9不等于8，所以next-key lock进化成间隙锁(6,9) select * from user where id =9 for update 因为是惟一索引等值查问，进化成行锁 select * from user where id >6 依据第五条规定，next-key lock范畴(6,+MAXVALUE] ...

最新版本请查看原文：https://blog.haohtml.com/arch... 在介绍InnoDB中的页的时候，很有必要先让大家理解一下InnoDB中的存储构造 从InnoDB存储引擎的逻辑构造看，所有数据都被逻辑地寄存在一个空间内，称为表空间(tablespace)，而表空间由段（sengment）、区（extent）、页（page）组成。 在一些文档中extend又称块（block）。 一、表空间（table space） 表空间（Tablespace）是一个逻辑容器，表空间存储的对象是段，在一个表空间中能够有一个或多个段，然而一个段只能属于一个表空间。数据库由一个或多个表空间组成，表空间从治理上能够划分为零碎表空间、用户表空间、撤销表空间、长期表空间等。 在 InnoDB 中存在两种表空间的类型：共享表空间和独立表空间。如果是共享表空间就意味着多张表共用一个表空间。如果是独立表空间，就意味着每张表有一个独立的表空间，也就是数据和索引信息都会保留在本人的表空间中。独立的表空间能够在不同的数据库之间进行迁徙。可通过命令 mysql > show variables like 'innodb_file_per_table'; 查看以后零碎启用的表空间类型。目前最新版本曾经默认启用独立表空间。 InnoDB把数据保留在表空间内，表空间能够看作是InnoDB存储引擎逻辑构造的最高层。实质上是一个由一个或多个磁盘文件组成的虚构文件系统。InnoDB用表空间并不只是存储表和索引，还保留了回滚段、双写缓冲区等。 二、段（segment） 段（Segment）由一个或多个区组成，区在文件系统是一个间断调配的空间（在 InnoDB 中是间断的 64 个页），不过在段中不要求区与区之间是相邻的。段是数据库中的调配单位，不同类型的数据库对象以不同的段模式存在。当咱们创立数据表、索引的时候，就会相应创立对应的段，比方创立一张表时会创立一个表段，创立一个索引时会创立一个索引段。 三、区（extent） 在 InnoDB 存储引擎中，一个区会调配 64 个间断的页。因为 InnoDB 中的页大小默认是 16KB，所以一个区的大小是 64*16KB=1MB。在任何状况下每个区大小都为1MB，为了保障页的连续性，InnoDB存储引擎每次从磁盘一次申请4-5个区。默认状况下，InnoDB存储引擎的页大小为16KB，即一个区中有64个间断的页。 四、页（Page） 页是InnoDB存储引擎磁盘治理的最小单位，每个页默认16KB；InnoDB存储引擎从1.2.x版本碍事，能够通过参数innodb_page_size将页的大小设置为4K、8K、16K。若设置实现，则所有表中页的大小都为innodb_page_size，不能够再次对其进行批改，除非通过mysqldump导入和导出操作来产生新的库。 innoDB存储引擎中，常见的页类型有： 1. 数据页（B-tree Node) 2. undo页（undo Log Page） 3. 零碎页 （System Page） 4. 事物数据页 （Transaction System Page） 5. 插入缓冲位图页（Insert Buffer Bitmap） 6. 插入缓冲闲暇列表页（Insert Buffer Free List） 7. 未压缩的二进制大对象页（Uncompressed BLOB Page） 8. 压缩的二进制大对象页 （compressed BLOB Page） ...

阐明：以下内容均不思考数据库之外的解决方案为什么要分表mysql单表数据量下限影响 Mysql 单表的最优最大数量的一个重要因素其实是索引。存储引擎 InnoDB 采纳 B+树结构索引。Mysql 的 B+树索引存储在磁盘上，Mysql 每次读取磁盘 Page 的大小是 16KB，为了保障每次查问的效率，须要保障每次查问拜访磁盘的次数，个别设计为 2-3 次磁盘拜访，再多性能将严重不足。Mysql B+树索引的每个节点须要存储一个指针（8Byte）和一个键值（8Byte）。因而计算16KB/(8B+8B)=1K 16KB 能够存储 1K 个节点，3 次磁盘拜访(即 B+树 3 的深度)能够存储 1K 1K 1K 即 10 亿数据（是不是感觉不堪设想？）。 理论业务中，业务查问会依赖非主键索引，波及二级索引（回表查问），这样最大数据量将指数级减小，但反对个千万数据还是问题不大的，当然，查问中最好防止大宽表查问，以及防止索引重建过程。既然mysql单表反对千万级的数据，那还须要分表么？答案是要看业务，通过简略计算就能够得出结论。例如，咱们须要存储车辆的gps定位信息，单辆车5秒上报一个点位，一天产生 246060/5 = 17280条数据，1000台车一天就产生1700万数据（理论业务对这类数据个别不会应用mysql存储）。此时就须要采纳分表策略，升高单表数据量。如果数据量的增长一年都达不到千万级别，就别折腾了，我的项目能不能活够一年都不肯定。。。分表的准则分表的次要根据还是看业务。个别看业务的查问需要，是以工夫为纬度还是业务主体的纬度。例如，咱们次要查问一段时间范畴内的订单信息，就是按工夫纬度查问的业务需要，在这种业务需要下，按工夫进行表拆分是适合的。遇到跨表查问，咱们也可能依据查问工夫来确定关联的表，个别关联两张表就差不多满足业务需要了。如果咱们是查问车辆的轨迹，此时应该以车辆id（vin）来进行分表，防止查问过程中过多的关联表，升高查问效率。有时候咱们既要查一段时间范畴内的订单，又要查某个用户的全副订单，怎么办？能够思考冗余数据做双写解决，毕竟磁盘比内存便宜。分表的工具箱ShardingSphere-JDBC（sharding-jdbc）官网文档 https://shardingsphere.apache...逻辑表 ⽔平拆分的数据库（表）的雷同逻辑和数据结构表的总称。例：订单数据依据主键尾数拆分为10张表，别离是t_order_0到t_order_9，他们的逻辑表名为t_order。实在表在分⽚的数据库中实在存在的物理表。即上个示例中的t_order_0到t_order_9 。数据节点数据分⽚的最⼩单元。由数据源名称和数据表组成，例：ds_0.t_order_0 绑定表指分⽚规定⼀致的主表和⼦表。例如： t_order 表和 t_order_item 表，均依照 order_id 分⽚，则 此两张表互为绑定表关系。绑定表之间的多表关联查问不会呈现笛卡尔积关联，关联查问效率将⼤⼤提 升。举例说明，如果SQL为： SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_i d WHERE o.order_id in (10, 11);在不配置绑定表关系时，假如分⽚键 order_id 将数值10路由⾄第0⽚，将数值11路由⾄第1⽚，那么路由后的SQL应该为4条，它们出现为笛卡尔积： SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.ord er_id WHERE o.order_id in (10, 11); SELECT i.* FROM t_order_0 o JOIN t_order_item_1 i ON o.order_id=i.ord er_id WHERE o.order_id in (10, 11); SELECT i.* FROM t_order_1 o JOIN t_order_item_0 i ON o.order_id=i.ord er_id WHERE o.order_id in (10, 11); SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.ord er_id WHERE o.order_id in (10, 11);在配置绑定表关系后，路由的SQL应该为2条:SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.ord er_id WHERE o.order_id in (10, 11);SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.ord er_id WHERE o.order_id in (10, 11);其中 t_order 在FROM的最左侧，ShardingSphere将会以它作为整个绑定表的主表。 所有路由计算将会只使⽤主表的策略，那么t_order_item表的分⽚计算将会使⽤t_order的条件。故绑定表之间的分区键要完全相同。如果存在多个关联查问，须要为每个关联查问设置绑定关系 例如 有4张表 a,b,c,d，b、c、d别离和a表还有关联查问须要配置sharding: ...

 大家好，我是为宽广程序员兄弟操碎了心的小编，每天举荐一个小工具/源码，装满你的收藏夹，每天分享一个小技巧，让你轻松节俭开发效率，实现不加班不熬夜不掉头发，是我的指标！ 明天小编举荐一套前后端不拆散的开源社区零碎，基于目前支流 Java Web 技术栈，并提供具体的开发文档和配套教程。蕴含帖子、评论、私信、零碎告诉、点赞、关注、搜寻、用户设置、数据统计等模块。 开源协定 应用 MIT 开源许可协定 链接地址 蕴含具体文档和大量图例, 帮忙读者疾速把握本我的项目，配套敌对教程, 率领读者从零开始实现本我的项目 公众号【Github导航站】回复关键词【ech】获取git地址 技术栈前端 ThymeleafBootstrap 4.xJqueryAjax后端 SpringSpring Boot 2.1.5 RELEASESpring MVCORM：MyBatis数据库：MySQL 5.7分布式缓存：Redis本地缓存：Caffeine音讯队列：Kafka 2.13-2.7.0搜索引擎：Elasticsearch 6.4.3平安：Spring Security邮件工作：Spring Mail分布式定时工作：Spring Quartz日志：SLF4J（日志接口） + Logback（日志实现）性能列表注册登录 | 登出：动静生成验证码记住我账号设置：批改头像批改明码过滤敏感词：前缀树帖子模块：公布帖子（过滤敏感词）分页显示所有的帖子反对依照 “发帖工夫” 显示反对依照 “热度排行” 显示（Spring Quartz）查看帖子详情权限治理（Spring Security + Thymeleaf Security）未登录用户无奈发帖“版主” 能够看到帖子的置顶和加精按钮并执行相应操作“管理员” 能够看到帖子的删除按钮并执行相应操作“普通用户” 无奈看到帖子的置顶、加精、删除按钮，也无奈执行相应操作评论模块：公布对帖子的评论（过滤敏感词）分页显示评论公布对评论的回复（过滤敏感词）权限治理（Spring Security）未登录用户无奈应用评论性能私信模块：发送私信（过滤敏感词）私信列表查问以后用户的会话列表每个会话只显示一条最新的私信反对分页显示私信详情查问某个会话所蕴含的所有私信拜访私信详情时，将显示的私信设为已读状态反对分页显示权限治理（Spring Security）未登录用户无奈应用私信性能对立解决 404 / 500 异样：一般申请异样异步申请异样对立记录日志点赞模块：反对对帖子、评论/回复点赞第 1 次点赞，第 2 次勾销点赞首页统计帖子的点赞数量详情页统计帖子和评论/回复的点赞数量详情页显示以后登录用户的点赞状态（赞过了则显示已赞）统计我的获赞数量权限治理（Spring Security）未登录用户无奈应用点赞相干性能关注模块：关注性能勾销关注性能统计用户的关注数和粉丝数我的关注列表（查问某个用户关注的人），反对分页我的粉丝列表（查问某个用户的粉丝），反对分页权限治理（Spring Security）未登录用户无奈应用关注相干性能零碎告诉模块：告诉列表显示评论、点赞、关注三种类型的告诉告诉详情分页显示某一类主题所蕴含的告诉进入某种类型的零碎告诉详情，则将该页的所有未读的零碎告诉状态设置为已读未读数量别离显示每种类型的零碎告诉的未读数量显示所有零碎告诉的未读数量导航栏显示所有音讯的未读数量（未读私信 + 未读零碎告诉）权限治理（Spring Security）未登录用户无奈应用零碎告诉性能搜寻模块网站数据统计：（管理员专属）独立访客 UV反对单日查问和区间日期查问日沉闷用户 DAU反对单日查问和区间日期查问权限治理（Spring Security）只有管理员能够查看网站数据统计优化网站性能：解决每次申请时，都要通过拦截器依据登录凭证查问用户信息，拜访的频率十分高。因而将已胜利登录的用户信息在缓存 Redis 中保留一段时间，查问用户信息的时候优先从缓存中取值；若缓存中没有该用户信息，则将其存入缓存；用户信息变更时革除对应的缓存数据；引入本地缓存 Caffeine，缓存热帖列表和帖子的总数，防止缓存雪崩（这外面还能再加一层二级缓存 Redis）。局部演示截图首页 ...

题目形容1. 给定一个字符串，要求把字符串后面的若干个字符挪动到字符串的尾部，如把字符串“abcdef”后面的2个字符’a’和’b’挪动到字符串的尾部，使得原字符串变成字符串“cdefab”。请写一个函数实现此性能，要求对长度为n的字符串操作的工夫复杂度为 O(n)，空间复杂度为 O(1)。剖析与解法计划一：暴力位移（工夫复杂度不符合要求）思路 逻辑思路： 1. 把须要挪动的字符一个一个的挪动到字符串的尾部 代码实现思路： 1. 实现一个函数，能够实现挪动一个字符到字符串尾部的性能 2. 循环m次调用上述函数，实现挪动m个字符到字符串尾部代码实现(GO语言)package mainfunc LeftShiftOne(chars []byte,n int) { c:=chars[0] // 获取第一个字符 for i:=1;i<n;i++{ chars[i-1]=chars[i] } chars[n-1]=c}func LeftRotateString(s string,m int) string { chars:=[]byte(s) n:=len(chars) for m>0{ LeftShiftOne(chars,n) m-- } return string(chars)}func main() { res:=LeftRotateString("abcdef",2) println(res)}工夫复杂度和空间复杂度剖析 针对长度为n的字符串来说，假如须要挪动m个字符到字符串的尾部，那么总共须要 mn 次操作，同时设立一个变量保留第一个字符，如此，工夫复杂度为O(m*n)，空间复杂度为O(1)，空间复杂度合乎题目要求，但工夫复杂度不合乎，所以，咱们得须要寻找其余更好的方法来升高工夫复杂度。反转法(利用一点点数学知识)思路 逻辑思路 1. 将一个字符串分成A和B两局部，而后定义一个字符串的反串操作，A^T，示意把A的所有字符反转(如，A=”abc“,那么A^T="cba"),在数学上有个对于矩阵运算的公式：(A*B)^T=B^T*A^T，套用一下能够得出一个论断:(A^T*B^T)^T=B*A,这样就解决了字符串反转的问题 代码实现思路：以反转abcdef为例 1. 实现一个反转字符串的函数 2. 将原字符串分为两个局部，即A:abc,B:def，注在本题中就是分为0-m和m-n的两个子串 2. 将A反转，A->A^T,即：abc->cba，将B反转,B->B^T，即：def-fed 3. 反转A^T*B^T,即反转cbafed，失去defabc,即为最初后果代码实现(GO语言)package mainfunc ReverseString(chars []byte,from,to int) { for from<to{ temp:=chars[from] chars[from]=chars[to] chars[to]=temp from++ to-- }}func LeftRotateString(s string,m int) string { chars:=[]byte(s) n:=len(chars) m%=n // 如果挪动的大于n位，那么和挪动%n位是一样的 ReverseString(chars,0,m-1) // 反转A，失去A^T m是挪动位数，m-1是下标 ReverseString(chars,m,n-1) // 反转B，失去B^T // 此时 chars为 A^T*B^T ReverseString(chars,0,n-1) // 反转A^T*B^T，失去B*A return string(chars)}func main() { res:=LeftRotateString("abcdef",2) println(res)}相干高频变种题 一样的结题思路，不再一个个的解释了，能够本人尝试解决，如果有问题，欢送在公众号”韩哥有话说“上给我留言，我会及时回复的1. 链表反转 给出一个链表和一个数k，比方，链表为1→2→3→4→5→6，k=2，则翻转后2→1→6→5→4→3，若k=3，翻转后3→2→1→6→5→4，若k=4，翻转后4→3→2→1→6→5，用程序实现。2. 尾部字符串挪动到头部 编写程序，在原字符串中把字符串尾部的m个字符挪动到字符串的头部，要求：长度为n的字符串操作工夫复杂度为O(n)，空间复杂度为O(1)。3. 单词反转(谷歌真题) 输出一个英文句子，翻转句子中单词的程序，但单词内字符的程序不变，句子中单词以空格符隔开。为简略起见，标点符号和一般字母一样解决。例如，输出“I am a student.”，则输入“student. a am I”。更多内容欢送关注我的集体公众号“韩哥有话说”，100G人工智能学习材料，大量后端学习材料等你来拿。 ...

一、前言最近常常碰到开发误删除误更新数据，这不，他们又给我找了个麻烦，咱们来看下整个过程。 二、过程因为开发须要在生产环节中修复数据，须要执行120条SQL语句，须要将数据进行更新 于是开发连上了生产数据库，首先执行了第一条SQL update tablename set source_name = "bj1062-北京市朝阳区常营北辰福第" where source_name = "-北京市朝阳区常营北辰福第"咱们认真看了下，这个SQL，确实没有什么问题，where条件也是失常的，粗心就是将这个地址的后面加字符串bj1062，是真的没有谬误么？是的没有谬误。开发执行实现后，后果确实是合乎预期。 而后开发执行了剩下的SQL，都是和下面的SQL一样，将地址进行更新。执行实现后，开发懵逼了，发现source_name都变成了0，开发连忙给我打电话说: Harvey，我执行了update，where条件都是对的，set的值也是对的，然而set后的字段全副都变成了0，你连忙帮我看看，看看能不能复原数据。我连忙登上服务器，查看了这段时间的binlog，发现了大量的update tablename set source_name=0的语句，利用binlog2sql进行了解析，我的项目地址：binlog2sql 连忙和开发确定了操作的工夫点，生成flashback的SQL，进行了数据恢复，同时保留现场证据。 而后对开发执行的SQL进行了check，发现了几条很诡异的SQL： 这几条SQL的引号地位跑到了where 字段名字前面，简化后的SQL变成了： update tbl_name set str_col="xxx" = "yyy"那么这个SQL在MySQL他是如何进行语义转化的呢？可能是上面这样的么？ update tbl_name set (str_col="xxx" )= "yyy"这样就语法错误了，那么只会是上面这样的模式， update tbl_name set str_col=("xxx" = "yyy")而 select "xxx" = "yyy" 的值是0，所以 update tbl_name set str_col="xxx" = "yyy"等价于 update tbl_name set str_col=0所以就导致了source_name字段全副更新成了0. 咱们再钻研下select模式这种语句会怎么样。 mysql [localhost] {msandbox} (test) > select id,str_col from tbl_name where str_col="xxx" = "yyy";+----+---------+| id | str_col |+----+---------+| 1 | aaa || 2 | aaa || 3 | aaa || 4 | aaa |+----+---------+咱们发现，这个SQL将str_col='aaa'的记录也查找进去了，为什么呢？ mysql [localhost] {msandbox} (test) > warningsShow warnings enabled.mysql [localhost] {msandbox} (test) > explain extended select id,str_col from tbl_name where str_col="xxx" = "yyy"\G*************************** 1. row *************************** id: 1 select_type: SIMPLE table: tbl_name type: indexpossible_keys: NULL key: idx_str key_len: 33 ref: NULL rows: 4 filtered: 100.00 Extra: Using where; Using index1 row in set, 1 warning (0.00 sec)Note (Code 1003): /* select#1 */ select `test`.`tbl_name`.`id` AS `id`,`test`.`tbl_name`.`str_col` AS `str_col` from `test`.`tbl_name` where ((`test`.`tbl_name`.`str_col` = 'xxx') = 'yyy')这里他把where条件转化成了 ...

01 什么是事务？数据库事务指的是一组数据操作，事务内的操作要么就是全副胜利，要么就是全副失败，什么都不做，其实不是没做，是可能做了一部分然而只有有一步失败，就要回滚所有操作，有点一不做二不休的意思。 在 MySQL 中，事务反对是在引擎层实现的。MySQL 是一个反对多引擎的零碎，但并不是所有的引擎都反对事务。比方 MySQL 原生的 MyISAM 引擎就不反对事务，这也是 MyISAM 被 InnoDB 取代的重要起因之一。 1.1 四大个性原子性（Atomicity）：事务开始后所有操作，要么全副做完，要么全副不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有产生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质形成的根本单位。一致性（Consistency）：事务开始前和完结后，数据库的完整性束缚没有被毁坏 。比方 A 向 B 转账，不可能 A 扣了钱，B 却没收到。隔离性（Isolation）：同一时间，只容许一个事务申请同一数据，不同的事务之间彼此没有任何烦扰。比方 A 正在从一张银行卡中取钱，在 A 取钱的过程完结前，B 不能向这张卡转账。持久性（Durability）：事务实现后，事务对数据库的所有更新将被保留到数据库，不能回滚。1.2 隔离级别SQL 事务的四大个性中原子性、一致性、持久性都比拟好了解。但事务的隔离级别的确比拟难的，明天次要聊聊 MySQL 事务的隔离性。 SQL 规范的事务隔离从低到高级别顺次是：读未提交（read uncommitted）、读提交（read committed）、可反复读（repeatable read）和串行化（serializable ）。级别越高，效率越低。 读未提交：一个事务还没提交时，它做的变更就能被别的事务看到。读提交：一个事务提交之后，它做的变更才会被其余事务看到。可反复读：一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是统一的。当然在可反复读隔离级别下，未提交变更对其余事务也是不可见的。串行化：顾名思义是对于同一行记录，“写” 会加 “写锁”，“读” 会加 “读锁”。当呈现读写锁抵触的时候，后拜访的事务必须等前一个事务执行实现，能力继续执行。所以种隔离级别下所有的数据是最稳固的，然而性能也是最差的。1.3 解决的并发问题SQL 事务隔离级别的设计就是为了能最大限度的解决并发问题： 脏读：事务 A 读取了事务 B 更新的数据，而后 B 回滚操作，那么 A 读取到的数据是脏数据不可反复读：事务 A 屡次读取同一数据，事务 B 在事务 A 屡次读取的过程中，对数据作了更新并提交，导致事务 A 屡次读取同一数据时，后果不统一。幻读：系统管理员 A 将数据库中所有学生的问题从具体分数改为 ABCDE 等级，然而系统管理员 B 就在这个时候插入了一条具体分数的记录，当系统管理员 A 改完结后发现还有一条记录没有改过来，就如同产生了幻觉一样，这就叫幻读。SQL 不同的事务隔离级别能解决的并发问题也不一样，如下表所示：只有串行化的隔离级别解决了全副这 3 个问题，其余的 3 个隔离级别都有缺点。 ...

前言读书真是一件十分神奇的事件，本篇文章的大部分内容起源《数据密集型利用零碎设计》的第七章事务，过后看的时候很是含糊，尤其是弱隔离级别一块，感觉本人仿佛都能看得懂，但就是不明确作者在表白什么，像是没有一根清晰的主线串起来，找不到宗旨。但过了一段时间学习其余的常识的时候，有种忽然买通了任督二脉的感觉，特地冲动，故写下本文以做总结。 实质从实质上来说，事务的隔离级别是为并发管制服务的。在应用程序的开发中咱们常常用锁进行并发管制，确保临界区的资源不会呈现被多个线程同时读写的状况，这其实对应的就是数据库的可串行化级别。那为什么应用层能够提供可串行化的隔离级别而数据库不能提供呢？在我的了解中，这是因为应用层对临界资源的拜访都是内存操作，而数据库要保障持久性它须要把临界区的数据flush到磁盘中，这个IO操作是要比内存操作慢好几个数量级的，这导致临界区持有锁的工夫变得不可承受、锁抵触的频率变大，数据库的性能会大大降低。 隔离级别第一个误区：可反复读级别不担保解决失落更新问题维基百科上的数据库隔离级别)我认为是有误的！ 这里的问题在于事实上Repeatable Read可反复读级别并不担保不呈现失落更新问题，它只担保解决不可反复读问题。 反例证实如下(MySQL RR级别)：事务A、B同时进行卖出item A的过程，事务A售出4件，事务B售出1件，实践上库存记录应该为原始的10减去4减去1失去5才对，但最初库存的记录显示为9。这是典型的失落更新问题，即2个事务同时开启read-modify-write操作序列，呈现了一个事务笼罩了另外一个事务的写入，但这个过程中没有利用/蕴含/读取/获取到对方更新后的最新值(这表明事务A曾经commit过了，有别于脏写)，换句话说也就是事务B没有利用到事务A的更新后果，好像事务A的更新被失落了一样。 下图是数据库隔离级别和可能呈现的问题表格，“?”表明这个级别是否产生对应问题取决于数据库的具体实现下图是MySQL的隔离级别，咱们在后面的例子中曾经解释过了MySQL RR不解决失落更新问题，咱们随后会解释为什么它也没有解决幻读问题。 异常情况脏写形容事务A笼罩了其余事务未提交的写入 解决通过行级锁即可解决，在任何隔离级别下都不会产生 脏读形容事务A读取了其余事务未提交的写入 解决提供读已提交隔离级别以上的数据库都能够避免，MySQL中是通过RC级别下的MVCC解决的 读歪斜/不可反复读形容事务A在执行过程中，对同一个数据行在不同的工夫点前后读取的后果不统一 解决提供读可反复读隔离级别以上的数据库都能够避免，MySQL中是通过RR级别下的MVCC解决的 失落更新形容两个事务同时执行read-modify-write的过程，呈现了事务A笼罩了事务B的写入，但并没有蕴含事务B批改后的最新值(已commit)，导致事务B的更新如同失落了一样的后果。 解决原子写操作如果数据库提供了原子写操作，那就应用它以实现read-modify-write操作，这是举荐的最佳计划。例如在少数关系型数据库中UPDATE counters SET value=value+1 WHERE key='test'语句是平安的 显式加锁如果数据库不反对内置原子操作，能够通过对查问后果显式加锁来解决。对于mysql来说，就是 select for update，通过for update通知数据库，查问进去的数据行稍后是须要更新的，须要加锁避免其余的事务也来读取更新导致更新失落。 自动检测更新失落数据库先让事务都并发执行，如果事务管理器检测到有更新失落的危险，间接停止以后事务，而后强制回退到平安的read-modify-write形式。 原子比拟和设置在上次读取到的数据没有发生变化时才容许更新，如果发生变化了则回退到平安的read-modify-write形式。例如：update table set value＝newvalue where id＝＊ and value＝oldvalue。然而该形式有一个问题，如果where条件的判断是基于某一个旧快照来执行的，那么where的判断是没有意义的。所以如果要采纳原子比拟和设置来防止更新失落，那么肯定要确认数据库比拟－设置操作的平安运行条件。 补充阐明举例假如有一个文章计数器变量x，事务A、B同时拜访它并筹备给文章访问量进行加1操作；当x=20时，如果呈现事务A读取到了x=20并筹备执行+1操作的这个两头过程(也就是说还没有+1并commit的过程)中，事务B曾经实现了对x的批改并且把x=21的后果提交了。这个时候咱们说事务A的x=20须要作废的，否则B的更新就如同被失落了，但实际上A还是会执行他本人的x=x+1=20+1=21并且提交x=21更新；失落更新在写锁机制下(只在写操作上上锁，而不是整个read-modify-write过程)以及MySQL的RR级别下都没方法解决这个问题！ 脏写&失落更新 比照失落更新强调read-modify-write过程，这往往是个有状态的过程脏写笼罩的是其余事务未提交的更新，失落更新笼罩了其余事务已提交的更新，导致其余事务的更新看起来像是失落了一样图例： 幻读形容事务A先查问了某些符合条件的语句，事务B随后执行了写入扭转了事务A在雷同条件下的查问后果(通常体现为A select进去的数据行数多/少了） 解决MySQL RR级别下通过MVCC快照读能够防止查问时的幻读 写歪斜形容事务A依据条件查询数据库，并依据所查问初的后果做出相应的某些动作，而后批改数据库。但当事务A提交的时候，反对它做出相应批改的条件曾经不成立了(之前Select出的后果不统一)；写歪斜是幻读的一种状况；写歪斜也能够了解为狭义的更新失落问题，如果事务A、B读取同一组对象，而后更新其中的一部分； 不同事务更新不同的对象-->可能产生写歪斜不同事务更新同一个对象-->可能产生脏写/更新失落解决方案显式加锁可串行化隔离级别第二个误区：MySQL RR级别到底有没有解决幻读问题？在这里我认为问题的关键在于幻读这个概念是否限定于只读事务的语境下，或者说写歪斜属不属于幻读的领域内:如果你认为写歪斜属于幻读的领域内，那么仅依附MySQL RR级别下仅依附MVCC(实现原理和乐观锁有类似之处)的模式是无奈防止幻读问题的，须要额定显示地加上next-key lock(乐观锁)去防止；如果你认为写歪斜不属于幻读的领域内，那么RR级别曾经解决了幻读(限定在只读事务语境下)问题，RR级别下保障了同一事务前后的快照读后果都是统一的。总得而言，RR级别解决了快照读的幻读问题，但无奈防止以后读的幻读问题，这种状况下须要next-key lock配合解决。但因为这是须要使用者显式加锁同HashMap通过Synchronize润饰各办法实现线程平安)，我认为仅依附RR级别并没有解决幻读问题 在下面这个例子中，咱们能够看到在事务B新增了一行数据当前，事务A还是只能读取到5行数据而没有事务B插入的"Frank"的材料，并没有产生幻读问题；但假如当初事务A须要为分数最高的前三名玩家减少1个credit，按照上图能够看到前三名的玩家别离是Alice、Carol和Bob，其中Bob的分数最低为740，所以你能够通过UPDATE gamer SET credit=credit+1 WHERE score>=740的原子语句进行更新，在这种状况下事务A的更新是否只影响他目前所能看到的5个玩家的材料呢？试验后果如下图:能够看到事务A执行更新语句后再次select查问能够看到Frank也查问进去了，产生幻读问题。不仅如此，咱们本来预期事务A只为前三名的玩家减少credit，而当初咱们为4个玩家减少了credit，比原定的3个还多，这种状况属于写歪斜。 进一步解释实际上RR级别下 MVCC快照读的概念大略能够了解为，当一个事务开启时对数据库的状态做一个snapshot，而后事务内只能看到这个snapshot的内容以及本人所做的更改，而无奈读取到其余事务对数据库所做的更新，这决定了不会呈现不可反复读的景象；但在MySQL InnoDB实际中能够发现这个规定只限定于SELECT(DQL)指令，而INSERT、UPDATE、DELETE等DML指令看到的不是以后事务创立时的snapshot，而是具体指令执行时数据库被commit过的最新状态。所以在下面的例子中事务A在执行第一次SELECT的时候看到的是snapshot(快照读防止幻读景象)，而当它执行UPDATE的时候就看到了数据库最新的状态，获取到了玩家Frank并为他减少credit(MySQL RR级别的以后读 无奈解决幻读问题） 同样是基于快照隔离实现的RR隔离级别的PostgreSQL，因为它的snapshot不仅作用于DQL指令，也作用于DML指令，所以幻读问题在PostgreSQL的RR级别不会产生； 解决办法基于后面给出的写歪斜解决方案，咱们在这里能够显式的加锁，例如用MySQL的 Share Lock或是Exclusive Lock指令或者先进行一次SELECT FOR UPDATE，阻塞其它想更改材料的事务即可防止幻读。 例如将事务A批改为 即可解决问题(select for update显式上锁，在事务A commit/rollback之前 事务B会始终阻塞，解决幻读) ...

前言： 在 MySQL 中，基本上每个表都会有索引，有时候也须要依据不同的业务场景增加不同的索引。索引的建设对于数据库高效运行是很重要的，本篇文章将介绍下创立索引相干常识及注意事项。 1.创立索引办法创立索引能够在建表时指定，也能够建表后应用 alter table 或 create index 语句创立索引。上面展现下几种常见的创立索引场景。 # 建表时指定索引CREATE TABLE `t_index` ( `increment_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增主键', `col1` int(11) NOT NULL, `col2` varchar(20) NOT NULL, `col3` varchar(50) NOT NULL, `col4` int(11) NOT NULL, `col5` varchar(50) NOT NULL, PRIMARY KEY (`increment_id`), UNIQUE KEY `uk_col1` (`col1`), KEY `idx_col2` (`col2`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='测试索引';# 创立索引(两种办法)# 一般索引alter table `t_index` add index idx_col3 (col3); create index idx_col3 on t_index(col3);# 惟一索引alter table `t_index` add unique index uk_col4 (col4);create unique index uk_col4 on t_index(col4);# 联结索引alter table `t_index` add index idx_col3_col4 (col3,col4);create index idx_col3_col4 on t_index(col3,col4);# 前缀索引alter table `t_index` add index idx_col5 (col5(20)); create index idx_col5 on t_index(col5(20));# 查看表索引mysql> show index from t_index;+---------+------------+----------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |+---------+------------+----------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+| t_index | 0 | PRIMARY | 1 | increment_id | A | 0 | NULL | NULL | | BTREE | | || t_index | 0 | uk_col1 | 1 | col1 | A | 0 | NULL | NULL | | BTREE | | || t_index | 1 | idx_col2 | 1 | col2 | A | 0 | NULL | NULL | | BTREE | | || t_index | 1 | idx_col3 | 1 | col3 | A | 0 | NULL | NULL | | BTREE | | |+---------+------------+----------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+2.创立索引所需权限如果你用的不是 root 账号，那创立索引就要思考权限问题了，是不是须要 create、alter 权限就行了呢？上面咱们来具体看下。 ...

哈喽哈喽大家猴，我是把代码写成bug的大头菜。公众号：大头菜技术(bigheadit)。原创不易，但欢送转载。最近这个星期。次要两件事儿： 工作遇到的bug和总结从新梳理JVM的基础知识工作遇到的bug和总结最近这两周，因为做了4个需要，都是对于黑白名单的。 于是我就打算，把这些黑白名单的需要，比方有对于C端用户的白名单，C端用户的黑名单，B端用户的白名单，B端用户的黑名单，我打算间接形象一点，把4个需要形象整合为一个需要。每个黑白名单需要：都有减少黑白名单，删除黑白名单，查问黑白名单三种不同的接口。 因为之前，曾经有C端用户的白名单了。然而对应的表的设计没有思考好拓展性，没法兼容C端用户的黑名单等需要。因而须要从新设计表。 新表的设计关键字段： role:角色 1:C端用户2:B端用户type:黑白名单 1:白名单2:黑名单status:数据状态 1:失效2:生效businessCode:业务线 1:电商业务线2:外卖业务线3:物流业务线从新设计后，表的可拓展性大大提高。但业务的复杂度和开发复杂度也大大提高。鱼和熊掌不可兼得嘛。失常！ 其实，把4个需要，形象合并为一个需要，是升高了开发成本的，也对业务做了比拟好的形象，能够为当前其余相似的需要，比方：新增一条业务线D的白名单。 这样子，其实就是，在枚举上减少多一个枚举。在接口入参上，扭转一下参数值即可。外围代码，简直不必变。 如果思考某些须要定制化的黑白名单。咱们采纳策略工厂模式即可。这样子，代码的可读性大大提高，同时也满足开闭准则。 bug的潜在因为波及到表的从新设计，因而旧表的数据，也须要做同步迁徙。数据迁徙，这种写一下SQL语句就好。没什么特地的。 关键点：我忘了谁在应用旧表。 就是哪些接口调用了获取旧表的数据。过后，确实忘了这茬，也没做兼容。因而，bug就来了。 这次，也真算是，把代码写成bug了哈哈哈哈。 影响的范畴：调用了拜访旧表数据的接口。 对于这次bug的影响，我做了一些总结点波及到表数据迁徙时，须要思考兼容性，包含读和写，只有漏掉其中一个，bug必定就会有如果真的实现，没法兼容原来的接口，这个时候，最好在大群里，播送告诉一下各个调用方，好让他们尽快切换接口。在分布式我的项目中，其实有一个痛点：就是接口不晓得被哪个微服务调用了。比方：服务A的A接口，被服务B的B接口调用了。然而因为这是2个不同微服务，没法找对应的调用链。我目前也没找到好的方法来解决微服务的调用链问题。从新梳理JVM的基础知识最近从新梳理了一下JVM的基础知识。相干笔记如下： Q:咱们平时写的JAVA代码是怎么运行起来的A： 1、把.java代码编译为.class代码2、类加载器把.class代码加载到jvm中，是字节码执行引擎按需加载的，不是一次性加载全副.class代码3、字节码执行引擎执行.class代码Q:既然.java代码能编译成.class代码后运行，那么必定也能够把.class代码反编译为.java代码。如果这样子的话，黑客拿到.class代码后，就能够通过反编译拿到外围.java代码。对于这个问题，应该怎么解决。A： 1、代码混同工具2、能够自定义类加载器。而后用公钥和私钥做加密。Q：JVM是什么？A：JVM实质上也是一个程序，负责运行java编译好的class代码Q:JVM跟咱们平时运行的机器上的零碎有什么区别？A：JVM具备跨平台。零碎不具备跨平台。Q:类加载器的概念A：把编译好的class文件按需加载到JVMzhongQ:什么是字节码执行引擎A：针对加载进内存的class代码进行运行Q:类加载的流程A： 1、JVM个别会在应用到具体某个类时，才会去加载对应的类。按需加载2、加载到JVM后，须要对class代码进行语法验证操作3、验证通过后，须要对类调配空间，对类变量调配空间，并且赋予默认值。4、解析，就是符号援用替换为间接援用，说了等于没说。这个阶段，对咱们java开发没多大用处。跳过吧Q：什么时候会初始化一个类？A：new 类()的实例化的对象的时候，就会触发从加载到初始化的全过程。如果是蕴含main办法的类，必须启动时，就立马对类进行初始化。如果这个类还有父类，且父类还没被加载和初始化，这时候，须要先加载和初始化其父类，实现父类的初始化后，再回去初始化本人。Q：为什么不把lib/ext的jar一起放在启动类加载器中一起加载？A： 1、为了辨别同名类2、容许你再一个jvm里运行不同的应用程序3、对不同的类库进行增强。Q：线程、java虚拟机栈、栈帧、局部变量、办法的关系A： 一个线程，有一个java虚拟机栈。一个线程，有一个程序计数器一个java虚拟机栈，有多个栈帧一个线程，每拜访一个办法，就创立一个栈帧。一个栈帧，有多个局部变量。Q:spring boot中怎么设置JVM参数？A：启动的时候设置Q:tomcat 中怎么设置JVM参数？A：catalina.sh 文件配置参数Q：零碎并发量大时，零碎会变慢，进而导致什么？A：零碎并发量大的时候，会有一些申请特地慢，进而援用着新生代的对象，然而GC时无奈回收，因为还被援用着。屡次minor gc后，特地慢的申请对应的对象，会进入老年代。进而很快把老年代填满，进而导致频繁的Full GC。Q：什么状况JVM内存中的一个对象会被回收？A：GC Root。比方局部变量和动态变量。此外，还分强援用，软援用。虚援用。 强援用，只有被GC Root援用，就肯定不会被回收。软援用，是在垃圾回收后，依然不够内存空间，才会被回收，不论是否被援用。虚援用，垃圾回收，就会被回收，不论是否被援用。Q:对象在新生代的调配?A:优先在eden区调配Q:什么时候会触发Minor GCA：eden区满了。Q:触发minor gc的状况有：A： 1、新生代现有对象小于老年代残余内存，即老年代空间足以撑持可能降职的对象2、状况1不成立，查看设置了空间担保且担保胜利什么状况下Minor GC之前会提前触发Full GC？A： 1、新生代的全副对象大小如果大于老年代的残余空间2、没有空间担保机制3、担保失败Q:什么状况下会间接触发Minor GCA：eden区满了Q:Minor GC之后有哪几种状况对象会进入老年代A： 1、survivor区不能包容eden区的存活对象2、动静年龄判断：survivor区的同一年龄对象超过survivior空间的一半Q:优化零碎性能的思路？A 外围思路：尽可能让对象不要过快进入老年代。缩小老年代的full gc。尽可能让对象在新生代就被GC回收。Q:如何让对象不要过快进入老年代？A:survivor要有足够的空间。试想一下，如果survivor区，空间不够，对象就会间接进入老年代。即便够，然而超过survivor区的一半，也会因为动静年龄判断，而间接进入老年代。

快照读比方咱们新建一个表，而后新建两行数据，当初表的内容是这样的咱们新建一个事务，称为Query1。 begin; select * from test1; ## 第一次查问 select * from test1; ## 第二次查问commit;而后执行第一次查问的语句，查问内容跟表内容一样，失常。而后咱们新建一个事务，执行update操作，咱们称为Query2 begin;update test1 set `name` = 'yunzhi' where id = 1;select * from test1;commit;执行他Query2,不提交，此时查问后果为而后再执行Query1的第二次查问咱们发现Query1的查问和Query2的查问的后果是不同的。 这就波及到mysql的多版本并发控制技术, 简称MVCC(Multi-Version Concurrency Control)。基于上边的例子，咱们能够了解为当开启一个事务的时候，会对事务设置一个版本号，且版本号一一递增，同时对每行数据进行新增，更新，删除也会同步更新版本号同以后事务版本号。当在事务内进行查问操作且不提交的时候，默认执行快照读操作，快照读只能查问到小于等于以后版本的数据。让咱们复盘一下方才的操作。咱们认为新增数据时version = 1;所以每行数据版本号为1。咱们在新建Query1事务的时候，version = 2; begin; ## version = 2; select * from test1; ## 第一次查问 select * from test1; ## 第二次查问commit;咱们再新建Query2事务的时候，version = 3; begin; ## version = 3;update test1 set `name` = 'yunzhi' where id = 1;select * from test1;commit;再执行Query1的第二次查问时， ...

简述大体来说，MySQL 能够分为 Server 层和存储引擎层两局部。 Server 层包含连接器、查问缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数外围服务性能，以及所有的内置函数（如日期、工夫函数等），所有跨存储引擎的性能都在这一层实现，比方存储过程、触发器、视图等。而存储引擎层负责数据的存储和提取。 其架构模式是插件式的，反对 InnoDB、MyISAM、Memory 等多个存储引擎。最罕用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始成为了默认存储引擎。也就是说，你执行 create table 建表的时候，如果不指定引擎类型，默认应用的就是 InnoDB。 也就是说，你执行 create table 建表的时候，如果不指定引擎类型，默认应用的就是 InnoDB。不过，你也能够通过指定存储引擎的类型来抉择别的引擎，比方在 create table 语句中应用 engine=myisam, 来指定引擎创立表。不同存储引擎的表数据存取形式不同，反对的性能也不同。 连接器第一步，连贯到这个数据库上，这时候接待你的就是连接器。连接器负责跟客户端建设连贯、获取权限、维持和治理连贯。一般来说命令的写法 mysql -h $ip -P $port -u $user -p 输出完命令后，须要输出完明码后即可连贯胜利。-p 前面是明码，一般来说不倡议间接在命令下面输出明码，这样可能导致明码透露。 连贯中的mysql是客户端工具，用来和服务器建设连贯。在实现TCP握手后，服务器的连接器开始认证你的身份。包含用户、明码、权限、等等： 如果用户名或明码谬误，会报出"Access denied for user"的谬误，而后完结执行如果认证都通过，连接器会在权限表里查问该账号的所有权限。之后的权限判断都基于此权限判断也就是说，一旦连贯胜利后，在断开连接的状况下，即便批改了权限，权限也不会产生变动。除非断开从新连贯。所以通常，不倡议长连贯。 查问缓存连贯建设实现后，你就能够执行 select 语句了。执行逻辑就会来到第二步：查问缓存。 MySQL 拿到一个查问申请后，会先到查问缓存看看，之前是不是执行过这条语句。之前执行过的语句及其后果可能会以 k-v 对的模式，被间接缓存在内存中。k 是查问的语句，v 是查问的后果。如果你的查问可能间接在这个缓存中找到 k，那么这个 v 就会被间接返回给客户端。 如果语句不在查问缓存中，就会持续前面的执行阶段。执行实现后，执行后果会被存入查问缓存中。你能够看到，如果查问命中缓存，MySQL 不须要执行前面的简单操作，就能够间接返回后果，这个效率会很高。 然而大多数状况下不倡议应用查问缓存。因为查问缓存往往弊大于利。 查问缓存的生效十分频繁，只有有对一个表的更新，这个表上所有的查问缓存都会被清空。因而很可能你吃力地把后果存起来，还没应用呢，就被一个更新全清空了。对于更新压力大的数据库来说，查问缓存的命中率会非常低。除非你的业务就是有一张动态表，很长时间才会更新一次。比方，一个系统配置表，那这张表上的查问才适宜应用查问缓存。 然而留神，改性能在MySQL在8.0版本之后删除了 分析器首先，MySQL须要晓得你要做什么，因而须要对sql语句做解析。 分析器会先做词法剖析，明确你的sql语句具体是做什么。 比方上面的SQLmysql> elect * from t where ID=1;如：MySQL 从你输出的"select"这个关键字辨认进去，这是一个查问语句。 ...

背景在后期的我的项目交付过程中，须要开发人员筹备很多文档给甲方，例如：零碎设计文档、部署文档、数据库文档等，其中数据库在交付阶段曾经稳固，筹备文档更多是复制、黏贴的事件。随即便有了这个想法，开发一个工具不便前面的应用。目前该工具只反对MySQL数据库，后续会缓缓补充。如果在应用过程中呈现任何报错或者有更好的倡议，请在Issues中提出 体验下载在releases界面下载最新版程序，如果是Windows零碎下载exe利用，其余平台请下载jar文件，应用java -jar dbDoc.jar命令启动程序 应用 输出各项信息，后点击确定 实现文档导出，目前导出的文件格式为doc。以MySQL自带的information_schema为例，输入了每张表的要害信息 也能够调整文档格局为己所用。 我的项目地址：https://github.com/haiCheng-7...

写在后面过后的我在里面玩的正起劲，忽然一个电话打来：“冰河，你在哪？服务器忽然不能拜访了！”。我：“又有什么状况啊？”。“我不小心踩到服务器电源连贯的插线板了，服务器断电了，重启时提醒无奈启动”。我心里一万个无语，问：”是哪台服务器断电了“。“我不小心踩到那个小插线板的开关了，连贯到这个插线板的服务器都断电了”。我：尼玛，那是数据库啊，我去。。。 于是我连忙飞奔回公司，开始了苦逼的数据恢复过程。。。 文章已收录到： https://github.com/sunshinelyz/technology-binghe https://gitee.com/binghe001/technology-binghe 解决主库问题主库问题重现回到公司一看，断电的是公司的音讯服务子系统数据库，数据库共3台，一种两从，并采纳了分库分表的形式存储数据。我首先把三台服务器启动好，发现主数据库的过程无奈启动，两台从数据库同步主库数据的状态异样。依照程序，我先看主数据库的日志信息，发现MySQL的谬误日志中输入了如下信息。 -----------------------------------------161108 23:36:45 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/var2021-02-28 23:36:46 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).2021-02-28 23:36:46 5497 [Note] Plugin 'FEDERATED' is disabled.2021-02-28 23:36:46 7f11c48e1720 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.2021-02-28 23:36:46 5497 [Note] InnoDB: Using atomics to ref count buffer pool pages2021-02-28 23:36:46 5497 [Note] InnoDB: The InnoDB memory heap is disabled2021-02-28 23:36:46 5497 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins2021-02-28 23:36:46 5497 [Note] InnoDB: Memory barrier is not used2021-02-28 23:36:46 5497 [Note] InnoDB: Compressed tables use zlib 1.2.32021-02-28 23:36:46 5497 [Note] InnoDB: Using CPU crc32 instructions2021-02-28 23:36:46 5497 [Note] InnoDB: Initializing buffer pool, size = 16.0M2021-02-28 23:36:46 5497 [Note] InnoDB: Completed initialization of buffer poolInnoDB: Database page corruption on disk or a failedInnoDB: file read of page 5.InnoDB: You may have to recover from a backup.2021-02-28 23:36:46 7f11c48e1720 InnoDB: Page dump in ascii and hex (16384 bytes): len 16384; hex 7478d078000000050000000000000000000000000f271f4d000700000000000000000000000000000000001b4000000000000000000200f20000000000000006000000000000002d000000000000002e000000000000002f0000000000000030000000000（省略很多相似代码）InnoDB: End of page dump2021-02-28 23:36:46 7f11c48e1720 InnoDB: uncompressed page, stored checksum in field1 1954074744, calculated checksums for field1: crc32 993334256, innodb 2046145943, none 3735928559, stored checksum in field2 1139795846, calculated checksums for field2: crc32 993334256, innodb 1606613742, none 3735928559, page LSN 0 254222157, low 4 bytes of LSN at page end 254221236, page number (if stored to page already) 5, space id (if created with >= MySQL-4.1.1 and stored already) 0InnoDB: Page may be a transaction system pageInnoDB: Database page corruption on disk or a failedInnoDB: file read of page 5.InnoDB: You may have to recover from a backup.InnoDB: It is also possible that your operatingInnoDB: system has corrupted its own file cacheInnoDB: and rebooting your computer removes theInnoDB: error.InnoDB: If the corrupt page is an index pageInnoDB: you can also try to fix the corruptionInnoDB: by dumping, dropping, and reimportingInnoDB: the corrupt table. You can use CHECKInnoDB: TABLE to scan your table for corruption.InnoDB: See also http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.htmlInnoDB: about forcing recovery.InnoDB: Ending processing because of a corrupt database page.2021-02-28 23:36:46 7f11c48e1720 InnoDB: Assertion failure in thread 139714288817952 in file buf0buf.cc line 4201InnoDB: We intentionally generate a memory trap.InnoDB: Submit a detailed bug report to http://bugs.mysql.com.InnoDB: If you get repeated assertion failures or crashes, evenInnoDB: immediately after the mysqld startup, there may beInnoDB: corruption in the InnoDB tablespace. Please refer toInnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.htmlInnoDB: about forcing recovery.03:36:46 UTC - mysqld got signal 6 ;This could be because you hit a bug. It is also possible that this binaryor one of the libraries it was linked against is corrupt, improperly built,or misconfigured. This error can also be caused by malfunctioning hardware.We will try our best to scrape up some info that will hopefully helpdiagnose the problem, but since we have already crashed,something is definitely wrong and this may fail.key_buffer_size=16777216read_buffer_size=262144max_used_connections=0max_threads=1000thread_count=0connection_count=0It is possible that mysqld could use up tokey_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 798063 K bytes of memoryHope that's ok; if not, decrease some variables in the equation.Thread pointer: 0x0Attempting backtrace. You can use the following information to find outwhere mysqld died. If you see no messages after this, something wentterribly wrong...stack_bottom = 0 thread_stack 0x40000/usr/local/mysql/bin/mysqld(my_print_stacktrace+0x35)[0x8e64b5]/usr/local/mysql/bin/mysqld(handle_fatal_signal+0x41b)[0x652fbb]/lib64/libpthread.so.0(+0xf7e0)[0x7f11c44c77e0]/lib64/libc.so.6(gsignal+0x35)[0x7f11c315d625]/lib64/libc.so.6(abort+0x175)[0x7f11c315ee05]/usr/local/mysql/bin/mysqld[0xa585c5]/usr/local/mysql/bin/mysqld[0xa6c7b4]/usr/local/mysql/bin/mysqld[0xa6cbc7]/usr/local/mysql/bin/mysqld[0xa5bce2]/usr/local/mysql/bin/mysqld[0xa1e2ba]/usr/local/mysql/bin/mysqld[0xa0bf60]/usr/local/mysql/bin/mysqld[0x95a427]/usr/local/mysql/bin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x48)[0x58f788]/usr/local/mysql/bin/mysqld[0x6e4a36]/usr/local/mysql/bin/mysqld(_Z11plugin_initPiPPci+0xb3e)[0x6e826e]/usr/local/mysql/bin/mysqld[0x582d85]/usr/local/mysql/bin/mysqld(_Z11mysqld_mainiPPc+0x4d8)[0x587d18]/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f11c3149d5d]/usr/local/mysql/bin/mysqld[0x57a019]The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html containsinformation that should help you find out what is causing the crash.161108 23:36:46 mysqld_safe mysqld from pid file /usr/local/mysql/var/VM_241_49_centos.pid ended------------------------------------------------------------------------------主库问题剖析从日志中能够看出是innodb引擎出了问题。日志里提醒到 http://dev.mysql.com/doc/refm... [mysqld]字段下，增加 innodb_force_recovery=1： ...

本文摘要： 在某些非凡情景下，DBLE无奈将关联查问语句正确下压到数据节点，进而导致执行异样。 本文详细分析了此种景象产生的起因，并提供了解决方案。 作者：林海 华夏银行数据库专家，专一于开源及国产分布式数据库技术，多年一线金融行业数据库开发与运维教训。目前次要负责分布式数据库的钻研、利用与推广工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。一、前言采纳分布式数据库中间件模式时，咱们将业务表依照某种特定的算法和规定扩散到了多个业务子表当中。中间层对利用屏蔽后端拆分细节、解析客户端 SQL 申请并转发至后端数据库，整个过程由中间件进行 SQL 解析、重写、路由、执行、后果集归并。对于每一个执行过程，咱们个别心愿语句能残缺公开压至多个后端数据库节点，以达到并行计算的目标。然而有些关联查问语句却可能无奈达到咱们的预期。它会把语句拆分执行，而后将后果集晋升到 DBLE 层匹配计算。这就造成了 DBLE 的 CPU 升高、语句执行耗时重大的问题。极其状况下更可能会造成 DBLE 无奈对外提供服务。什么样的语句会造成这种状况？咱们上面逐个阐明。 二、演示及优化环境查看 DBLE 版本：2.19.11.1 MySQL 版本：5.7.28 波及分片表：h_tempinvm、h_acsn 波及全局表：brhm 分片拆分规定：stringhash 节点数量：4 上面将通过四个示例来展现造成 DBLE 压力升高的状况及优化形式。 2.1 分片规定不统一：论断：关联查问表分片规定不同，关联语句无奈正确下压。 分片表 h_acsn、h_tempinvm 关联查问语句如下： 分片规定如下： 通过配置可见拆分算法 function 是不同的。 执行打算如下： 执行打算可见，DBLE 对语句进行了拆分。别离在每个数据节点扫描两张表后，将各自后果汇合并排序后，在 DBLE 层做 MERGE、JOIN 操作。 调整分片规定如下： 调整后执行打算如下： 语句已齐全下压至后端数据节点，DBLE 层 MERGE 操作。 2.2 关联条件未应用分片键：论断：关联查问条件未应用分片键，关联语句无奈正确下压。 分片表 h_acsn、h_tempinvm 关联查问语句如下： 分片规定如下： 执行打算如下： 该执行打算与示例 1 无奈下压状况雷同，都是将语句做了拆分，在 DBLE 层 JOIN 操作。 ...

应用mybatis框架时，那必然会有对数据库的查问语句的编写，所以这篇文章心愿能够帮忙到你。 什么是Mybatis框架？MyBatis 是一款优良的长久层框架，它反对定制化 SQL、存储过程以及高级映射。MyBatis 防止了简直所有的 JDBC 代码和手动设置参数以及获取后果集。MyBatis 能够应用简略的 XML 或注解来配置和映射原生信息，将接口和 Java 的 POJOs(Plain Ordinary Java Object,一般的 Java对象)映射成数据库中的记录。 如何应用？pom文件依赖 <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.1.3</version></dependency>yml文件配置,这里匹配 resource/mapper/ 门路下的映射文件。 mybatis: mapper-locations: classpath:mapper/*.xml在xml文件中绑定长久层接口和实体对象 <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd"><mapper namespace="com.flamelephant.fabricmgt.dao.HostMapper"> <resultMap type="com.flamelephant.fabricmgt.entity.po.Host" id="HostMap"> <result property="id" column="id" jdbcType="INTEGER"/> <result property="hostName" column="host_name" jdbcType="VARCHAR"/> <result property="ip" column="ip" jdbcType="VARCHAR"/> <result property="userName" column="user_name" jdbcType="VARCHAR"/> <result property="passWord" column="pass_word" jdbcType="VARCHAR"/> <result property="state" column="state" jdbcType="OTHER"/> <result property="tag" column="tag" jdbcType="VARCHAR"/> <result property="gmtCreated" column="gmt_created" jdbcType="TIMESTAMP"/> <result property="gmtModified" column="gmt_modified" jdbcType="TIMESTAMP"/> </resultMap></mapper>mapper标签中的namespace属性指定的是咱们长久层接口的我的项目门路resultMap是Mybatis最弱小的元素，它能够将查问到的简单数据（比方查问到几个表中数据）映射到一个后果集当中resultMap标签的type属性是咱们要映射的实体对象的我的项目门路,id为resultMap的惟一标识。resultMap中的result标签是实体和数据库表字段的绑定，其中property属性为实体对象的属性名，column为数据库的字段名，jdbcType是字段的类型。 xml映射文件的sql编写通过实体作为筛选条件查问<select id="queryAll" resultMap="HostMap"> select id, host_name, ip, user_name, pass_word, state, tag, gmt_created, gmt_modified from host <where> <if test="id != null and id != ''"> and id = #{id} </if> <if test="hostName != null and hostName != ''"> and host_name like CONCAT('%', #{hostName}, '%') </if> <if test="ip != null and ip != ''"> and ip like CONCAT('%', #{ip}, '%') </if> <if test="userName != null and userName != ''"> and user_name = #{userName} </if> <if test="passWord != null and passWord != ''"> and pass_word = #{passWord} </if> <if test="state != null and state != ''"> and state = #{state} </if> <if test="tag != null and tag != ''"> and tag = #{tag} </if> <if test="gmtCreated != null"> and gmt_created = #{gmtCreated} </if> <if test="gmtModified != null"> and gmt_modified = #{gmtModified} /if> </where></select>id="queryAll"为长久层接口的形象办法名resultMap="HostMap" 指定查问后果接管的resultMap的后果集。 ...

mysql数据库中对日期数据列计算的办法分享在一些日常的开发中，咱们经常须要对数据表中的日期进行增减操作，得 到新的日期数据，下文将通过举例的形式讲述mysql下对日期的操作方法，如下所示--1.对数据表中日期减少一年select DATE_ADD(日期列, INTERVAL 1 YEAR) from 数据表名称--2.日期缩小一年select DATE_ADD(日期列, INTERVAL -1 YEAR) from 数据表名称--3.对数据表中日期减少一月select DATE_ADD(日期列, INTERVAL 1 month) from 数据表名称--4.日期缩小一月select DATE_ADD(日期列, INTERVAL -1 month) from 数据表名称--5.对数据表中日期减少一天select DATE_ADD(日期列, INTERVAL 1 day) from 数据表名称--6.日期缩小一天select DATE_ADD(日期列, INTERVAL -1 day) from 数据表名称注意事项：如果相干日期 减少2年，请将数值1批改为2减少n年，请批改为n

转自@twt社区，作者：杨建旭。 【摘要】Oracle 12c 中的 In memory个性，到底对性能有多大晋升？本文形容了在一系列的试验中，不同场景下的性能体现。 Oracle 12c 中的 In memory 选件通过在 SGA 中调配独立的内存区域 (In Memory Area) ，对数据应用列式压缩存储来进步查问性能。 那么，这个 In memory 个性，到底能对性能有多大晋升，咱们做了一系列的试验，来看看不同场景下的性能体现。但首先要说的是，采纳了 In memory 个性，性能并不一定进步，前面我会举例子。 1、相干参数 In Memory 区的大小由参数 inmemory_size 管制，该参数是一个动态参数 , 批改后须要重启数据库方可失效。 批改命令： SQL> alter system set inmemory_size=2G scope=spfile; System altered. 重启之后 2、一般场景下，数据库采纳 In-memory 个性后，利用查问速度都有显著晋升。 利用查问测试后果 能够看出，三种查问条件，采纳了内存个性之后，响应工夫别离晋升了 23倍、2倍和6倍。** 3、数据库采纳 In-memory 个性后，增删改的执行速度差别不大。 增删改测试后果 4、某些场景插入的速度依然有较大晋升不过在某些场景下（比方，单用户大批量插入，前面的案例均采纳单用户），插入的速度还是能够晋升不少的，如下图。 测试案例中筹备了 100 万笔数据，采纳 Insert into Select 形式插入两张表，测试后果如下： 5、有其余业务压力烦扰下的查问性能比照 某简单的联结查问，内存表比一般表的查问速度晋升20倍。那么，在有其余业务压力烦扰下，它的查问性能是怎么样的？ 带着这个问题，咱们以每秒 5000 笔的速度向内存表和一般表插入数据。在该压力下测试这个简单联结查问的性能 ...

B+树索引构造解析一、二分查找法　二分查找法（binary search）也成为折半查找法。用来查找一组有序的记录组中的某一记录。 根本思维是：将记录按有序化（递增或递加）排列，在查找过程中采纳跳跃式办法查找，即先以有序数列的中点地位为比拟对象，如果要找的元素值小于该中点元素，则将待查问列放大为左半局部，否则为右半局部。通过一次比拟，将查问区间放大一半。 如有5,10,19,21,31,37,42,48,50,52这10个数，要查48这个数，其查找过程： 从图看，用了3次就找到了48这个数。如果是程序查找，则须要8次，因而二分查找法的效率比程序查找法要好（均匀）。然而如果要查5这个数，程序查只需1次，而二分查找须要4次。 对于下面的10个数来说，均匀查找次数为（1+2+3+4+5+6+7+8+9+10）/10=5.5次。而二分查找为（4+3+2+4+3+1+4+3+2+3）/10=2.9次。 在最坏的状况下，程序查找的次数为10，而二分查找法为4 二、二叉查找树和均衡二叉树　B+树是通过二叉查找树，再由均衡二叉树，B树演变而来。 二叉查找树中定义：左子树的键值总是小于根的键值，右子树的键值总是大于根的键值。因而能够通过中序遍历失去键值的排序输入 若想最大性能的结构一颗二叉查找树，须要这颗二叉查找树是均衡，从而引出了新的定义-----均衡二叉树，或称为AVL树。 均衡二叉树定义：首先复合二叉查找树的定义，其次必须满足任何节点的两个子树的高度最大差为1. 均衡二叉树的查问速度很快，然而保护一颗均衡二叉树的代价很大，通常来说，须要1次或屡次左旋和右旋来失去插入或更新后树的平衡性。如下所示： 三、B+树　B+树和二叉树、均衡二叉树一样都是经典的数据结构。 B+树由B树和索引程序拜访办法（ISAM，这就是MyISAM引擎最后参考的数据结构）演变而来，理论中曾经没有应用B树的状况了。 B+树是为磁盘或其余间接存储辅助设备设计的一种均衡查找时。 B+树中，所有记录节点都是按键值的大小程序寄存在同一层的叶子节点上，由各叶子节点指针进行连贯。 如下：其高度为2，每页寄存4条记录，扇出（fan out）为5。所有记录都在叶子节点上，并且是程序寄存的。 四、B+树的插入操作　B+树的插入必须保障插入后叶子节点中的记录仍然排序，同时须要思考插入到B+树的三种状况，每种状况都会导致不同的插入算法。如下所示： 1、如下图这颗B+树，若用户插入28这个值，发现以后叶子页leafPage和IndexPage索引页都没有满，直接插入就行。  　图（1） 图（2）  　2、从上图接着插入70这个键值，这时原来的leafPage曾经满了，然而IndexPage还没有。这时插入leafPage后的状况为50、55、60、65、70，并依据两头值60来拆分叶子节点，可得下图。 图（3） 为了保持平衡对于新插入的键值可能须要做大量的拆分页（split）操作。因为B+树结构次要用于磁盘，也拆分意味着磁盘操作，所以应该在可能的状况下尽量减小页的拆分操作。因而B+树会提出均衡二叉树的旋转（Rotation）性能。 旋转产生在leafPage已满，然而其左右兄弟节点没有满的状况下。这时B+树不会急于去拆分页操作，而是将记录移到所在页的兄弟页节点上，通常状况下，左兄弟会被首先查看用来做旋转操作。若如此，插入70应该左旋为： 图（4） 3、最初插入95，这时复合第三种状况，即leafPage和IndexPage都满了，这时须要做两次拆分  　图（5） 五、B+树的删除操作　B+树应用填充因子（fill factor）来管制树的删除变动，50%是填充因子可设的最小值。 B+树的删除操作同样必须保障删除后叶子节点中的记录仍然排序，同插入一样，B+树删除操作同样须要思考以下三种状况： ...

作者：刘开洋 爱可生交付服务部团队北京 DBA，次要负责解决 MySQL 的 troubleshooting 和我司自研数据库自动化治理平台 DMP 的日常运维问题，对数据库及周边技术有浓重的学习趣味，喜爱看书，谋求技术。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 问题前几天遇到一个奇怪的问题，服务器内存明明够用，后果在对 MySQL 进行测压的时候却呈现了 OOM，是 Linux 内核出错了吗？ 具体景象如下：应用 sysbench 对 mysql 进行压测，并发 50、80 均失常输入，当并发达到 100 时开始报 OOM。 [root@yang-01 ~]# sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=yang-02 --mysql-port=3306 --mysql-user=root --mysql-password=*** --mysql-db=test --table-size=100000 --tables=5 --threads=100 --db-ps-mode=disable --auto_inc=off --report-interval=3 --max-requests=0 --time=360 --percentile=95 --skip_trx=off --mysql-ignore-errors=6002,6004,4012,2013,4016,1062 --create_secondary=off runsysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options:Number of threads: 100Report intermediate results every 3 second(s)Initializing random number generator from current time Initializing worker threads... FATAL: mysql_store_result() returned error 5(Out of memory (Needed 48944 bytes))FATAL: 'thread_run' function failed: /usr/share/sysbench/oltp_common.lua:432: SQL error，errno = 5, state = 'HY000': Out of memory (Needed 48944 bytes)FATAL: mysql_store_result() returned error 5(Out of memory (Needed 48944 bytes))FATAL: 'thread_run' function failed: /usr/share/sysbench/oltp_common.lua:432: SQL error，errno = 5, state = 'HY000': Out of memory (Needed 48944 bytes)MySQL 中 error log 的报错为： ...

某日,老师在课堂上想考考学生们的智商,就问一个男孩: “树上有十只鸟,开枪打死一只,还剩几只?” 男孩反诘: “是无声手枪，还是其余没有声音的枪么?” “不是。” “枪声有多大?” “80~100分贝。” “那就是说会震的耳朵疼?” “是。” “您确定那只鸟真的被打死啦?” “确定。” 老师曾经不耐烦了： “托付,你通知我还剩几只就行了,OK?” “OK.鸟里有没有聋子?” “没有。” “有没有关在笼子里的?” “没有。” “有没有残疾或饿的飞不动的鸟?” “没有,都身材倍棒。” “算不算怀孕肚子里的小鸟?” “都是公的。” 下课铃响起,但男孩仍持续问: “它们受到惊吓起飞时会不会慌失措而相互撞上?” “不会。” “恩,如果您的答复没有骗人,” 学生满怀信心的答复： “打死的鸟要是挂在树上没掉下来,那么就剩一只,如果掉下来,就一只不剩。” 老师推推眼镜，强忍着要昏倒的感觉，颤抖地说道： “你能够去当程序员了……” 问题来了：为什么老师说男孩适宜做程序员？ 其实是因为男孩针对一开始的问题，将每一个会影响最终后果的因素都思考进来，并且以更有逻辑的形式去提出疑难，层层递进，最终得出答案。 而这样一种思考形式，可不就是身为一名程序员必须具备的素质？ 上述段子，活泼而形象的从侧面反馈了程序员是一个较高智商、有逻辑并且思维较为麻利的一个职业群体。 那么，是不是每个人都适宜做程序员？ 不肯定！ 常常看到有程序员反映，本人在做了几年程序员后，忽然就发现自己不适宜程序员了，比方上面这个网友： 而对于初学者最慌的一个问题，同样是“我适不适宜做一名程序员？” 所以，到底什么样的人才适宜做程序员呢？ 本文由此总结了适宜做程序员的几个特点： 1、喜爱计算机 喜爱计算机，认为code is beautiful ,每天都与计算机为伴，愿与计算机长相厮守。喜爱写程序，做程序员就是上地狱；不喜爱写程序，做程序员就是下天堂。只有喜爱，只有酷爱，能力把程序写好。 2、数学好 计算机的外围是数学，因为编程语言是程序设计的工具，程序设计的外围是算法，算法的外围是数学。会写代码不难，难的是将生存形象成数学模型，应用算法解决生存中的理论问题。 3、逻辑思维能力强 编程不是谈恋爱，能够理性的自由发挥，他须要谨严的逻辑思维能力，1就是1,2就是2，任何一个看似不起眼的问题，都有可能导致整个软件系统产生故障。 4、好强 编程是一项聪明者的游戏，是一场驯服之旅，他须要程序员具备争强好胜的冲劲，可能一直的去克服各种挑战，去解决各种看似很奇怪、看似不可能解决的问题。 5、强烈的好奇心与求知欲 在这样一个信息大爆炸的时代，与其余行业相比，IT行业的教训比书本知识价值更小，如果长期满足于已有常识，闭门造车，按部就班，不去学习新的技术，那么，必然会造成集体思维局限，创意“生锈”，跟不上时代的步调。 6、仔细 编程过程处处是细节。程序设计语言不是人的自然语言，自身就是严格的计算机语言，来不得半点马虎。即便少了一个句号，忘了对变量进行初始化，也会让本来很完满的程序产生随机谬误，而这些谬误足以导致计算机死机甚至零碎解体，让程序员抓耳挠腮破费很长时间去解决。 7、坚定不移 IT行业与其余行业不一样，程序员遇到困难就可能让程序无奈进行上来，他们必须要把问题解决了程序能力实现。所以程序员在谋求最优的解决方案时，无论遇到千难万难，他们都不能轻言放弃，哪怕是屡战屡败，他们依然屡败屡战，迎难而上。 8、自学能力强 这可能是做一名程序员最最重要的素质了。因为这个行业倒退太快的起因，很多技术，平台，语言都在一直的迭代更新，所以一个程序员永远都在不停的学习，学习新的平台，学习新的语言（编程语言），学习新的架构等等。 如果大家对于学习Java有任何的问题，对于如何晋升学习Java以及学习办法、学习技巧、疾速达到待业的技术水平，都能够随时来问我，这是我建设了5年的Java学习交换QQ群：796866257。有不懂的问题能够随时在外面问，须要Java各个阶段的学习材料也能够在外面进行下载。对于前端和Python的问题也能够问。

Elasticsearch相干概念文档1. elasticsearch是面向文档的，文档是所有可搜寻数据的最小单位，例如： 1. 日志文件中的日志项 2. 一本电影的具体信息 / 一张唱片的详细信息 3. MP3播放器里的一首歌 / 一篇PDF文档中的具体内容2. 文档会被序列化为Json格局，放弃在elasticsearch中 1. Json对象有字段注册 2. 每个字段都有对应的字段类型(字符串，数值，布尔，日期，二进制，范畴类型)3. 每个文档都有一个 uniqueID 1. 你能够本人指定ID 2. 或者通过Elasticsearch主动生成文档的元数据1. 元数据能够认为是每个json数据自带的原始的字段，用于标注文档的相干信息，次要有以下几个元数据： 1. _indx 文档所属的索引名 2. _type 文档所属的类型名 3. _id 文档的惟一ID 4. _source 文档的原始JSON数据 5. _version 文档的版本信息 6. _score 相关性打分索引 Index1. 索引是文档的容器，是一类文档联合 Index体现了逻辑空间的概念：每个索引都有本人的Mapping定义，用于定义蕴含的文档的字段名和字段类型 每个索引的数据分布在Shard上，Shard体现了物理空间的概念2. 索引的Mapping和Settings Mapping定义文档字段的类型 settings定义不同的数据分布索引的不同语义1. 名词：一个Elasticsearch集群中，能够创立很多不同的索引2. 动词：保留一个文档到elasticsearch的过程也叫索引(indexing)，即es创立一个倒排索引的过程3. 名词：一个B树索引，一个倒排索引TypeType是一类索引的组合1. 在7.0之前，一个Index能够设置很多Types2. 6.0开始，Type曾经被Deprecated。7.0开始，一个索引只能创立一个type，即“_doc”与传统关系型数据库RDMS的比照1. ES的特点是弱结构化，相关性，高性能全文检索2. RDMS 事务性和数据聚合JoinRDMSESTableIndex(Type)RowDocumentColumnFieldSchemaMappingSQLDSLREST APIES提供rest api的接口，以便于各种语言调用 分布式集群 分布式集群是目前的支流做法，起因也是不言而喻的，分布式系统具备单机零碎无法比拟的高可用性和可扩展性1. 高可用性： 1. 服务可用性：容许有节点进行服务 2. 数据可用性：局部节点失落，不会失落数据2. 可扩展性： 1. 能够程度扩大节点1. 节点是一个ES实例 1. 实质上就是一个JAVA过程 2. 一台机器上能够运行多个ES过程，然而生产环境个别倡议一台机器只运行一个ES实例2. 每个节点都有名字，通过配置文件配置，或者启动的时候，加上 -E node.name=node1 指定3. 每个节点在启动后，会调配一个UID，放弃在data目录下Master-eligible nodes 和Master Node1. 每个节点启动后，默认就是一个Master eligible节点 1. 能够设置node.master:false禁止2. Master-eligible节点能够加入选主流程，成为Master节点3. 当第一个节点启动的时候，它会将本人选举为Master节点4. 每个节点上都保留了集群的状态，只有Master节点能力批改集群的状态信息 1. 集群状态(Cluster State) ，保护了一个集群中，必须的信息 1. 所有的节点信息 2. 所有的索引和棋相干的Mapping和Settings信息 3. 分片的路有信息Data Node 能够保留数据的节点，叫做Data Node，负责保留分片数据，在数据扩大上起到了至关重要的作用Coordinating Node1. 负责接管Client的申请，将申请散发到适合的节点，最终把后果会集到一起2. 每个节点默认都起了Coordinationg Node的职责Hot & Warm Node 不同硬件配置的Data Node,用来实现Hot & Warm 架构，升高集群部署的老本Machine Learning Node 顾名思义，负责跑机器学习的Job，用来做异样检测Tribe Node(5.3开始用Cross Cluster Serach) Tribe Node 连贯到不同的ES集群，并且反对将这些集群当做一个独自的集群解决配置节点类型1. 开发环境中一个节点能够承当多种角色2. 生产环境中，应该设置繁多的角色的节点节点类型配置参数默认值master eligiblenode.mastertruedatanode.datatrueingestnode.ingesttruecoordinating only无每个节点默认都是coordinating，设置其它类型全副为falsemachine_learingnode.mlture(须要 enable x-pack)分片1. 主分片：用以解决数据程度扩大的问题，通过主分片，能够将数据分布到集群内的所有节点之上 1. 一个分片是一个运行的Lucene的实例 2. 主分片数在索引创立时指定，后续不容许批改，除非Reindex2. 正本，用以解决数据高可用的问题，分片是主分片的拷贝 1. 正本分片数，能够动静调整 2. 减少正本数，还能够在肯定水平上进步服务的可用性(读取的吞吐)3. 对于生产环境中分片的设定，须要提前做好容量布局 1. 分片数设置过小 1. 导致后续无奈减少节点，实现程度扩大 2. 单个分片的数据量太大，导致数据重新分配耗时 2. 分片数设置过大 1. 影响搜寻后果的相关性打分，影响统计后果的准确性 2. 单个节点上过多的分片，会导致资源节约，同时也会影响性能查看集群的衰弱状况1. Green： 主分片与正本都失常调配2. Yellow：主分片全副失常调配，有正本调配未能失常调配3. Red：有主分片未能调配 1. 例如，当服务器的磁盘容量超过85%时，去创立一个新的索引更多内容欢送关注我的集体公众号“韩哥有话说”，100G人工智能学习材料，大量后端学习材料等你来拿。 ...

前言说起MySQL的查问优化，置信大家珍藏了一堆奇技淫巧：不能应用SELECT *、不应用NULL字段、正当创立索引、为字段抉择适合的数据类型…  你是否真的了解这些优化技巧？是否了解其背地的工作原理？在理论场景下性能真有晋升吗？我想未必。因此了解这些优化倡议背地的原理就尤为重要，心愿本文能让你从新扫视这些优化倡议，并在理论业务场景下正当的使用。 能够下载一本 Java技术栈手册，这本手册蕴含公布过的 MYSQL 技术博文。 MySQL逻辑架构如果能在头脑中构建一幅MySQL各组件之间如何协同工作的架构图，有助于深刻了解MySQL服务器。下图展现了MySQL的逻辑架构图。 MySQL逻辑架构整体分为三层，最上层为客户端层，并非MySQL所独有，诸如：连贯解决、受权认证、平安等性能均在这一层解决。 MySQL大多数外围服务均在两头这一层，包含查问解析、剖析、优化、缓存、内置函数(比方：工夫、数学、加密等函数)。所有的跨存储引擎的性能也在这一层实现：存储过程、触发器、视图等。 最上层为存储引擎，其负责MySQL中的数据存储和提取。和Linux下的文件系统相似，每种存储引擎都有其劣势和劣势。两头的服务层通过API与存储引擎通信，这些API接口屏蔽了不同存储引擎间的差别。 MySQL查问过程咱们总是心愿MySQL可能取得更高的查问性能，最好的方法是弄清楚MySQL是如何优化和执行查问的。一旦了解了这一点，就会发现：很多的查问优化工作实际上就是遵循一些准则让MySQL的优化器可能依照料想的正当形式运行而已。当向MySQL发送一个申请的时候，MySQL到底做了些什么呢？ 客户端/服务端通信协议MySQL客户端/服务端通信协议是“半双工”的：在任一时刻，要么是服务器向客户端发送数据，要么是客户端向服务器发送数据，这两个动作不能同时产生。 一旦一端开始发送音讯，另一端要接管残缺个音讯能力响应它，所以咱们无奈也毋庸将一个音讯切成小块独立发送，也没有方法进行流量管制。 客户端用一个独自的数据包将查问申请发送给服务器，所以当查问语句很长的时候，须要设置max_allowed_packet参数。然而须要留神的是，如果查问切实是太大，服务端会回绝接管更多数据并抛出异样。 与之相同的是，服务器响应给用户的数据通常会很多，由多个数据包组成。然而当服务器响应客户端申请时，客户端必须残缺的接管整个返回后果，而不能简略的只取后面几条后果，而后让服务器进行发送。因此在理论开发中，尽量放弃查问简略且只返回必须的数据，减小通信间数据包的大小和数量是一个十分好的习惯，这也是查问中尽量避免应用SELECT *以及加上LIMIT限度的起因之一。 整顿了一下2021年的Java工程师经典面试真题以及学习笔记，共485页大略850道含答案的面试题PDF，蕴含了Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、Redis、MySQL、Spring、Spring Boot、Spring Cloud、RabbitMQ、Kafka、Linux 等简直所有技术栈，每个技术栈都有不少于50道经典面试真题和学习笔记，不敢说刷完包你进大厂，只是让你面对面试官的时候多几分底气还是没问题的。查问缓存在解析一个查问语句前，如果查问缓存是关上的，那么MySQL会查看这个查问语句是否命中查问缓存中的数据。如果以后查问恰好命中查问缓存，在查看一次用户权限后间接返回缓存中的后果。这种状况下，查问不会被解析，也不会生成执行打算，更不会执行。 MySQL将缓存寄存在一个援用表（不要了解成table，能够认为是相似于HashMap的数据结构），通过一个哈希值索引，这个哈希值通过查问自身、以后要查问的数据库、客户端协定版本号等一些可能影响后果的信息计算得来。所以两个查问在任何字符上的不同（例如：空格、正文），都会导致缓存不会命中。 如果查问中蕴含任何用户自定义函数、存储函数、用户变量、长期表、MySQL库中的零碎表，其查问后果都不会被缓存。比方函数NOW()或者CURRENT_DATE()会因为不同的查问工夫，返回不同的查问后果，再比方蕴含CURRENT_USER或者CONNECION_ID()的查问语句会因为不同的用户而返回不同的后果，将这样的查问后果缓存起来没有任何的意义。 既然是缓存，就会生效，那查问缓存何时生效呢？MySQL的查问缓存零碎会跟踪查问中波及的每个表，如果这些表（数据或构造）发生变化，那么和这张表相干的所有缓存数据都将生效。 正因为如此，在任何的写操作时，MySQL必须将对应表的所有缓存都设置为生效。如果查问缓存十分大或者碎片很多，这个操作就可能带来很大的零碎耗费，甚至导致系统僵死一会儿。而且查问缓存对系统的额定耗费也不仅仅在写操作，读操作也不例外： 任何的查问语句在开始之前都必须通过查看，即便这条SQL语句永远不会命中缓存如果查问后果能够被缓存，那么执行实现后，会将后果存入缓存，也会带来额定的零碎耗费基于此，咱们要晓得并不是什么状况下查问缓存都会进步零碎性能，缓存和生效都会带来额定耗费，只有当缓存带来的资源节约大于其自身耗费的资源时，才会给零碎带来性能晋升。但要如何评估关上缓存是否可能带来性能晋升是一件十分艰难的事件，也不在本文探讨的领域内。如果零碎的确存在一些性能问题，能够尝试关上查问缓存，并在数据库设计上做一些优化，比方： 用多个小表代替一个大表，留神不要适度设计批量插入代替循环单条插入正当管制缓存空间大小，一般来说其大小设置为几十兆比拟适合能够通过SQL_CACHE和SQL_NO_CACHE来管制某个查问语句是否须要进行缓存最初的忠告是不要轻易关上查问缓存，特地是写密集型利用。如果你切实是忍不住，能够将query_cache_type设置为DEMAND，这时只有退出SQL_CACHE的查问才会走缓存，其余查问则不会，这样能够十分自在地管制哪些查问须要被缓存。 当然查问缓存零碎自身是非常复杂的，这里探讨的也只是很小的一部分，其余更深刻的话题，比方：缓存是如何应用内存的？如何管制内存的碎片化？事务对查问缓存有何影响等等，读者能够自行浏览相干材料，这里权当抛砖引玉吧。 语法解析和预处理MySQL通过关键字将SQL语句进行解析，并生成一颗对应的解析树。这个过程解析器次要通过语法规定来验证和解析。比方SQL中是否应用了谬误的关键字或者关键字的程序是否正确等等。预处理则会依据MySQL规定进一步查看解析树是否非法。比方查看要查问的数据表和数据列是否存在等。 查问优化通过后面的步骤生成的语法树被认为是非法的了，并且由优化器将其转化成查问打算。少数状况下，一条查问能够有很多种执行形式，最初都返回相应的后果。优化器的作用就是找到这其中最好的执行打算。 MySQL应用基于老本的优化器，它尝试预测一个查问应用某种执行打算时的老本，并抉择其中老本最小的一个。在MySQL能够通过查问以后会话的last_query_cost的值来失去其计算以后查问的老本。 mysql> select * from t_message limit 10;...省略后果集mysql> show status like 'last_query_cost';+-----------------+-------------+| Variable_name | Value |+-----------------+-------------+| Last_query_cost | 6391.799000 |+-----------------+-------------+示例中的后果示意优化器认为大略须要做6391个数据页的随机查找能力实现下面的查问。这个后果是依据一些列的统计信息计算得来的，这些统计信息包含：每张表或者索引的页面个数、索引的基数、索引和数据行的长度、索引的散布状况等等。 有十分多的起因会导致MySQL抉择谬误的执行打算，比方统计信息不精确、不会思考不受其管制的操作老本（用户自定义函数、存储过程）、MySQL认为的最优跟咱们想的不一样（咱们心愿执行工夫尽可能短，但MySQL值抉择它认为老本小的，但老本小并不意味着执行工夫短）等等。 MySQL的查问优化器是一个非常复杂的部件，它应用了十分多的优化策略来生成一个最优的执行打算： 从新定义表的关联程序（多张表关联查问时，并不一定依照SQL中指定的程序进行，但有一些技巧能够指定关联程序）优化MIN()和MAX()函数（找某列的最小值，如果该列有索引，只须要查找B+Tree索引最左端，反之则能够找到最大值，具体原理见下文）提前终止查问（比方：应用Limit时，查找到满足数量的后果集后会立刻终止查问）优化排序（在老版本MySQL会应用两次传输排序，即先读取行指针和须要排序的字段在内存中对其排序，而后再依据排序后果去读取数据行，而新版本采纳的是单次传输排序，也就是一次读取所有的数据行，而后依据给定的列排序。对于I/O密集型利用，效率会高很多）随着MySQL的一直倒退，优化器应用的优化策略也在一直的进化，这里仅仅介绍几个十分罕用且容易了解的优化策略，其余的优化策略，大家自行查阅吧。 查问执行引擎在实现解析和优化阶段当前，MySQL会生成对应的执行打算，查问执行引擎依据执行打算给出的指令逐渐执行得出后果。整个执行过程的大部分操作均是通过调用存储引擎实现的接口来实现，这些接口被称为handler API。查问过程中的每一张表由一个handler实例示意。 实际上，MySQL在查问优化阶段就为每一张表创立了一个handler实例，优化器能够依据这些实例的接口来获取表的相干信息，包含表的所有列名、索引统计信息等。存储引擎接口提供了十分丰盛的性能，但其底层仅有几十个接口，这些接口像搭积木一样实现了一次查问的大部分操作。 返回后果给客户端查问执行的最初一个阶段就是将后果返回给客户端。即便查问不到数据，MySQL依然会返回这个查问的相干信息，比方该查问影响到的行数以及执行工夫等。 如果查问缓存被关上且这个查问能够被缓存，MySQL也会将后果寄存到缓存中。 后果集返回客户端是一个增量且逐渐返回的过程。有可能MySQL在生成第一条后果时，就开始向客户端逐渐返回后果集了。这样服务端就毋庸存储太多后果而耗费过多内存，也能够让客户端第一工夫取得返回后果。 须要留神的是，后果集中的每一行都会以一个满足①中所形容的通信协议的数据包发送，再通过TCP协定进行传输，在传输过程中，可能对MySQL的数据包进行缓存而后批量发送。回头总结一下MySQL整个查问执行过程，总的来说分为6个步骤： 客户端向MySQL服务器发送一条查问申请服务器首先查看查问缓存，如果命中缓存，则立即返回存储在缓存中的后果。否则进入下一阶段服务器进行SQL解析、预处理、再由优化器生成对应的执行打算MySQL依据执行打算，调用存储引擎的API来执行查问将后果返回给客户端，同时缓存查问后果性能优化倡议看了这么多，你可能会期待给出一些优化伎俩，是的，上面会从3个不同方面给出一些优化倡议。但请等等，还有一句忠告要先送给你：不要听信你看到的对于优化的“绝对真理”，包含本文所探讨的内容，而应该是在理论的业务场景下通过测试来验证你对于执行打算以及响应工夫的假如。 1、Scheme设计与数据类型优化 抉择数据类型只有遵循小而简略的准则就好，越小的数据类型通常会更快，占用更少的磁盘、内存，解决时须要的CPU周期也更少。越简略的数据类型在计算时须要更少的CPU周期，比方，整型就比字符操作代价低，因此会应用整型来存储ip地址，应用DATETIME来存储工夫，而不是应用字符串。 这里总结几个可能容易了解谬误的技巧：1. 通常来说把可为NULL的列改为NOT NULL不会对性能晋升有多少帮忙，只是如果打算在列上创立索引，就应该将该列设置为NOT NULL。2. 对整数类型指定宽度，比方INT(11)，没有任何卵用。INT应用32位（4个字节）存储空间，那么它的示意范畴曾经确定，所以INT(1)和INT(20)对于存储和计算是雷同的。3. UNSIGNED示意不容许负值，大抵能够使负数的下限进步一倍。比方TINYINT存储范畴是-128 ~ 127，而UNSIGNED TINYINT存储的范畴却是0 - 255。4. 通常来讲，没有太大的必要应用DECIMAL数据类型。即便是在须要存储财务数据时，依然能够应用BIGINT。比方须要准确到万分之一，那么能够将数据乘以一百万而后应用BIGINT存储。这样能够防止浮点数计算不精确和DECIMAL准确计算代价高的问题。5. TIMESTAMP应用4个字节存储空间，DATETIME应用8个字节存储空间。因此，TIMESTAMP只能示意1970 - 2038年，比DATETIME示意的范畴小得多，而且TIMESTAMP的值因时区不同而不同。6. 大多数状况下没有应用枚举类型的必要，其中一个毛病是枚举的字符串列表是固定的，增加和删除字符串（枚举选项）必须应用ALTER TABLE（如果只只是在列表开端追加元素，不须要重建表）。7. schema的列不要太多。起因是存储引擎的API工作时须要在服务器层和存储引擎层之间通过行缓冲格局拷贝数据，而后在服务器层将缓冲内容解码成各个列，这个转换过程的代价是十分高的。如果列太多而理论应用的列又很少的话，有可能会导致CPU占用过高。8. 大表ALTER TABLE十分耗时，MySQL执行大部分批改表后果操作的办法是用新的构造创立一个张空表，从旧表中查出所有的数据插入新表，而后再删除旧表。尤其当内存不足而表又很大，而且还有很大索引的状况下，耗时更久。当然有一些奇技淫巧能够解决这个问题，有趣味可自行查阅。 ...

一、外键1、在MySQL中，为了把2个表关联起来，会用到2个重要的性能：外键（FOREIGN KEY）和连贯（JOIN）。外键须要在创立表的阶段定义，连贯能够通过雷同意义的字段把2个表连接起来，用在查问阶段。2、假如有2个表，别离是表A和表B，它们通过一个公共字段id 产生关联关系，咱们把这个关联关系叫做R。如果id在表A中是主键，那么表A就是这个关系R中的主表，相应的，表B就是这个关系中的从表，表B中的id，就是表B用来援用表A中数据的，叫外键。所以，外键就是从表中用来援用主表中数据的那个公共字段。 创立主表 CREATE TABLE demo.importhead ( listnumber INT PRIMARY KEY, supplierid INT, stocknumber INT, importtype INT, importquantity DECIMAL(10 , 3 ), importvalue DECIMAL(10 , 2 ), recorder INT, recordingdate DATETIME);创立从表 CREATE TABLE demo.importdetails( listnumber INT, itemnumber INT, quantity DECIMAL(10,3), importprice DECIMAL(10,2), importvalue DECIMAL(10,2), -- 定义外键束缚，指出外键字段和参照的主表字段 CONSTRAINT fk_importdetails_importhead FOREIGN KEY (listnumber) REFERENCES importhead (listnumber));运行这个SQL语句，咱们就在创立表的同时定义了一个名字叫fk_importdetails_importhead的外键束缚，同时，咱们申明，这个外键束缚的字段listnumber援用的是表importhead外面的字段listnumber。创立实现后，咱们能够通过SQL语句来查看，这里咱们要用到MySQL自带的、用于存储系统信息的数据库：information_schema。咱们能够查看外键束缚的相干信息：外键束缚所在的表是importdetails，外键字段是listnumber参照的主表是importhead，参照主表字段是listnumber，这样通过定义外键束缚，咱们曾经建设起了2个表之间的关联关系。 3、连贯在MySQL中有2种类型的连贯，别离是内连贯（INNER JOIN）和外连贯（OUTER JOIN） 内连贯示意查问后果只返回合乎连贯条件的记录，这种连贯形式比拟罕用；外连贯则不同，示意查问后果返回某一个表中的所有记录，以及另一个表中满足连贯条件的记录。

最近在做公司CRMEB我的项目，刚好用到这个就收回来供大家借鉴，欢送各位大佬斧正 App打包（应用Hbuilder进行App打包） 一、批改接口地址 1.关上uni-app下config/app.js批改接口地址，将下图两个地址批改成您的域名 二、配置参数 1.关上 uni-app 根目录下的 manifest.json 文件， 点击《根底配置》，从新获取 uni-app利用标识，获取之后填写 利用名称，利用形容，利用版本名称，利用版本号 2.点击《App图标配置》，上传APP的图标文件，点击《主动生成所有图标并替换》 3.点击《App模块配置》 3-1. 抉择《Geolocation》，在《高德定位》和《百度定位》中抉择一个，填写appkey_ios 和 appkey_android 3-2. 抉择《LivePusher》 3-3. 抉择《Maps》，在《高德地图》和《百度地图》中抉择一个，填写appkey_ios 和 appkey_android 3-4. 抉择《OAuth(登录受权)》，抉择《微信登录》，填写开放平台的 appid 和 appsecret 以及 Universal Links 注：IOS必须同时要抉择苹果登录 3-5. 抉择《Payment(领取)》，抉择对应的领取形式，微信领取请填写开放平台的 appid 和 Universal Links 3-6. 勾选《Push(音讯推送)》 3-7. 勾选《Share(分享)》，抉择微信分享，填写开放平台的 appid 和 Universal Links 3-8. 勾选《VideoPalyer(视频播放)》 4.点击《App权限配置》，android会主动增加权限，IOS须要配置如下权限 5.点击《App罕用其余配置》，勾选《反对CPU类型》下的armeabi-v7a 三、打包APP 1.抉择发行，点击原生app-云打包 2.抉择android和ios，填写对应的信息 3.点击左下方打包，期待进度条实现后点击确定，期待打包实现，下载APP包即可 ...

这篇次要介绍 MySQL 索引的 Cardinality 值（基数）以及索引的可选择性。 索引基数值索引基数的含意：由索引中惟一值计算的一个预估值。索引基数值的精确水平间接影响到 MySQL 优化器基于此索引的查问打算是否精确高效。 与索引基数值最为亲密的典型场景就是：一条 SQL 在某一时刻执行比较慢，其中较为可能的起因就是以后表记录更新频繁，这条 SQL 执行打算走的索引基数值没及时更新，优化器抉择走备用索引或者走全表扫描，从而非最优执行打算，最终执行后果没有达到预期，总体查问工夫较慢，这时可能得手工更新索引的基数值。 索引的可选择性：索引的可选择性好与坏，和索引基数关系十分亲密。基数值越高，索引的可选择性越好；相同，基数越低，索引的可选择性越差。优化器优先应用的索引个别选择性都不差，除非没得选，才会走选择性稍差点的索引或者走全表扫描。 影响索引基数值的相干指标：表的 sample page 个数， 也就是表样例数据页的个数，这个在之前表样例数据计算中具体讲过。表的更新频率，一般来说，当 1/16 的数据页被更新过，就会自动更新索引基数。索引列的数据分布水平，比方状态类，订单号，日期等。不同的数据分布，有不同的索引基数。手动进行索引基数更新，比方 analyze table、show table status 等。查看某个索引的基数值，有多种形式：间接执行 show index from tablename。查问数据字典表 information_schema.statstics。举例上面来举例说明索引基数在不同的数据分布场景下的变动以及对优化器的影响。 根底表构造如下：表 ytt_sample 有 7 个字段，5 个索引，其中主键的基数最大，可选择性最好，其余的索引要看数据的散布情况来定。 (localhost:mysqld.sock)|(ytt)>show create table ytt_sample\G*************************** 1. row *************************** Table: ytt_sampleCreate Table: CREATE TABLE `ytt_sample` ( `id` int NOT NULL AUTO_INCREMENT, `r1` int DEFAULT NULL, `r2` int DEFAULT NULL, `r3` int DEFAULT NULL, `r4` int DEFAULT NULL, `r5` tinyint DEFAULT NULL, `r6` date DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_u1` (`r1`,`r2`,`r3`), KEY `idx_r4` (`r4`), KEY `idx_r5` (`r5`), KEY `idx_r6` (`r6`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci1 row in set (0.00 sec)这张表有 100 行记录。 ...

问题形容：在MySQL数据库下，执行SQL插入语句报错。错误信息如下： 谬误起因：在MySQL5.7之后，sql_mode中默认存在ONLY_FULL_GROUP_BY，SQL语句未通过ONLY_FULL_GROUP_BY语义查看所以报错。 ONLY_FULL_GROUP_BY：ONLY_FULL_GROUP_BY要求select语句中查问进去的列必须是明确的（其余语句也是一样）。 以SQL语句select columes from table group by list为例：columns必须是汇集函数或者在group by后的表达式list中，并且list中必须蕴含主键，否则也会报错。 insert、update、delete语句都会报错（但不影响SQL语句的执行），因为这三种语句执行之前也会执行查问操作。 以主键为id的表为例： SELECT count(1) FROM customer GROUP BY name;该SQL执行胜利，因为count是汇集函数； SELECT FROM customer GROUP BY name;该SQL执行失败，因为中蕴含主键id，而group by后的表达式中并没有蕴含id SELECT name FROM customer GROUP BY name;该SQL执行胜利，因为name蕴含在group by后的表达式中 SELECT name, contact FROM customer GROUP BY name;该SQL执行失败，因为contact没有蕴含在group by后的表达式中 解决方案： 一、永恒解决 1）在MySQL下执行SELECT @@sql_mode语句 2）将查问后果中的ONLY_FULL_GROUP_BY去掉而后复制，关上MySQL的配置文件，将sql_mode的值设置为复制的值 （若没有sql_mode在[mysqld]下方增加一行即可）。 MySQL配置文件所在位置：安装版可通过windows服务所对应mysql启动项，查看其对应属性->可执行文件门路，获取my.ini门路。  免安装版个别在其根目录下。（默认是my-default.ini，必须将名字改为my.ini能力失效） 3）从新MySQL服务即可失效 ...

select 语句执行流程流程创立连贯，先连贯到数据库，通过连接器连贯到客户端（TCP握手链接）此时会获取用户的权限，并且权限获取后，如果批改权限，不会影响以后连贯。并且链接的默认有效期是8小时，到期之后会主动断开，默认应用长连贯。然而因为长连贯内存占用大，会导致mysql内存涨得比拟快，导致OOM。目前常见的解决方案是应用连接池。MySQL 在执行过程中长期应用的内存是治理在连贯对象外面的导致连贯内存大查问缓存建设连贯后，进行一个查问申请，会先查问mysql的查问缓存。执行的sql作为key，上次查问的后果作为value。如果缓存命中，则间接返回。如果语句不在查问缓存中，就会持续前面的执行阶段。然而因为缓存的生效条件是只有表上有一次更新，就会淘汰这个表上所有的缓存，所以缓存的命中率会非常低。MySQL 8.0 版本间接将查问缓存的整块性能删掉了，也就是说 8.0 开始彻底没有这个性能了解析器如果在查问缓存的步骤中没有查问到缓存（8.0之前），则进行这一步。这里解析器会进行SQL语句的解析，外部将文本格式转换为二进制构造，把关键字解析进去，而后会判断的你的SQL是否合乎语法。解析器次要性能有：通过这两个性能会产生一棵解析树相似于java的词法剖析留神这里的解析树不是个别的字节代码，而是C/C++构造 这里不对解析树进行深刻解说，如果想理解能够看这篇博文。 MySQL内核源码解读-SQL解析之解析器浅析这里会产生一个很多人常常碰到的谬误。 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'xxxxx' at line 1这个谬误就示意，你的SQL存在语法问题。 * 词法剖析(Lexical scanner)：作用是将整个查问合成为多个元素。* 语法规定(Grammar rule module)：寻找sql语法规定组合，产生一个序列，执行这些规定相干的代码。优化器优化器算是整个流程中最重要的一个局部，整个SQL的索引抉择，JOIN查问的表连贯程序，依附它来实现。特地是在多索引的环境下，会影响到整个SQL的效率。在上面我会具体的说。执行器执行器，顾名思义就是用来真正执行SQL的货色。第一步会先判断你有没有被操作表的权限，如果没有会报错。 ERROR 1142 (42000): SELECT command denied to user 'xx'@'localhost' for table 'xx'如果有权限就会进入表，执行查问语句。而依据优化对于索引的抉择不同又有不同的查问逻辑。 优化器是怎么抉择索引的优化器是MySQL比较复杂的一个组件，一条语句在后果雷同的状况下个别会有多种执行形式，而优化器则是找到多种执行形式中最优的一个。 查问优化程序有几个指标，然而其次要指标是∶尽可能应用索引，并且应用最严格的索引来打消对行数量随时可能疾速减少的顾虑。 ——《MySQL技术底细》在这里，咱们能够通过这个SQL去查看咱们上次查问的老本，它是io\_cost和cpu\_cost的开销总和 show status like 'Last_query_cost'; 后果示意 MySQL的优化器认为大略须要做3.399个数据页的随机查找能力实现下面的查问。 对于这个老本在《高性能MySQL》是这样形容的：每个表或者索引的页面个数、索引的基数（索引中不同值的数量）、索引和数据行的长度、索引散布状况。优化器在评估老本的时候并不思考任何层面的缓存，它假如读取任何数据都须要一次磁盘 I/O。 这句话能够总结为统计后果仅供参考，会和理论的老本有差异，最间接的就是，InnoDB 因为MVCC 导致每个视图统计的行数不一样，所以老本也会不一样。 ...

什么是Druid？Druid：Druid不仅是一个数据库连接池，还蕴含一个ProxyDriver、一系列内置的JDBC组件库、一个SQL Parser。反对所有JDBC兼容的数据库，包含Oracle、MySql、Derby、Postgresql、SQL Server、H2等。Druid针对Oracle和MySql做了特地优化，比方：Oracle的PS Cache内存占用优化MySql的ping检测优化Druid提供了MySql、Oracle、Postgresql、SQL-92的SQL的残缺反对，这是一个手写的高性能SQL Parser，反对Visitor模式，使得剖析SQL的形象语法树很不便。简略SQL语句用时10微秒以内，简单SQL用时30微秒。通过Druid提供的SQL Parser能够在JDBC层拦挡SQL做相应解决，比如说分库分表、审计等。Druid进攻SQL注入攻打的WallFilter，就是通过Druid的SQL Parser剖析语义实现的应用druid的数据库加密/解密操作1.pom文件依赖<dependency> <groupId>com.alibaba</groupId> <artifactId>druid</artifactId> <version>1.1.23</version></dependency>2.在磁盘中找到下载的druid依赖 3.在jar包所在目录下关上dos窗口 4.在dos窗口输出druid的命令，点击回车执行 yxkj_123456为未加密的数据库明码privateKey为生成的私钥publicKey为生成的公钥password为加密后的数据库明码以上的公钥和明码钥，要特地留神，解密的话是用这两个进行解密 5.关上我的项目的yml文件，将生成的明码钥替换之前的yml里的数据库明码，增加public-key在datasource下，填写生成的明码公钥，增加druid的配置，表明公钥，解密 6.启动我的项目进行测试，能够看到，数据库曾经连贯胜利。

问题如果打算为项目选择一款收费、开源的数据库，那么你可能会在MySQL与PostgreSQL之间举棋不定。MySQL与PostgreSQL都是收费、开源、弱小、且功能丰富的数据库。你次要的问题可能是：哪一个才是最好的开源数据库，MySQL还是PostgreSQL呢？该抉择哪一个开源数据库呢？ 在抉择数据库时，你所做的是个长期的决策，因为前面如果再扭转决定将是十分艰难且代价昂扬的。你心愿一开始就抉择正确。两个风行的开源数据库MySQL与PostgreSQL经常成为最初要抉择的产品。对这两个开源数据库的高层次概览将会有助于你抉择最适宜本人须要的。 MySQL介绍MySQL相对来说比拟年老，首度呈现在1994年。它宣称本人是最风行的开源数据库。MySQL就是LAMP（用于Web开发的软件包，包含 Linux、Apache及Perl/PHP/Python）中的M。构建在LAMP栈之上的大多数利用都会应用MySQL，包含那些出名的利用，如 WordPress、Drupal、Zend及phpBB等。 一开始，MySQL的设计指标是成为一个疾速的Web服务器后端，应用疾速的索引序列拜访办法（ISAM），不反对ACID。通过晚期疾速的倒退之 后，MySQL开始反对更多的存储引擎，并通过InnoDB引擎实现了ACID。MySQL还反对其余存储引擎，提供了长期表的性能（应用MEMORY存 储引擎），通过MyISAM引擎实现了高速读的数据库，此外还有其余的外围存储引擎与第三方引擎。 MySQL的文档十分丰盛，有很多品质不错的收费参考手册、图书与在线文档，还有来自于Oracle和第三方厂商的培训与反对。 MySQL近几年经验了所有权的变更和一些颇具戏剧性的事件。它最后是由MySQL AB开发的，而后在2008年以10亿美金的价格卖给了Sun公司，Sun公司又在2010年被Oracle收买。Oracle反对MySQL的多个版 本：Standard、Enterprise、Classic、Cluster、Embedded与Community。其中有一些是收费下载的，另外一 些则是免费的。其外围代码基于GPL许可，对于那些不想应用GPL许可的开发者与厂商来说还有商业许可可供使用。 当初，基于最后的MySQL代码还有更多的数据库可供选择，因为几个外围的MySQL开发者曾经公布了MySQL分支。最后的MySQL创建者之一 Michael “Monty” Widenius貌似悔恨将MySQL卖给了Sun公司，于是又开发了他本人的MySQL分支MariaDB，它是收费的，基于GPL许可。出名的 MySQL开发者Brian Aker所创立的分支Drizzle对其进行了大量的改写，特地针对多CPU、云、网络应用与高并发进行了优化。 PostgreSQL 介绍PostgreSQL标榜本人是世界上最先进的开源数据库。PostgreSQL的一些粉丝说它能与Oracle相媲美，而且没有那么低廉的价格和高傲的客服。它领有很长的历史，最后是1985年在加利福尼亚大学伯克利分校开发的，作为Ingres数据库的后继。 PostgreSQL是齐全由社区驱动的开源我的项目，由全世界超过1000名贡献者所保护。它提供了单个残缺性能的版本，而不像MySQL那样提供了 多个不同的社区版、商业版与企业版。PostgreSQL基于自在的BSD/MIT许可，组织能够应用、复制、批改和从新散发代码，只须要提供一个版权申明即可。 可靠性是PostgreSQL的最高优先级。它以坚如磐石的品质和良好的工程化而闻名，反对高事务、工作要害型利用。PostgreSQL的文档非 常精良，提供了大量收费的在线手册，还针对旧版本提供了归档的参考手册。PostgreSQL的社区反对是十分棒的，还有来自于独立厂商的商业反对。 数据一致性与完整性也是PostgreSQL的高优先级个性。PostgreSQL是齐全反对ACID个性的，它对于数据库拜访提供了弱小的安全性 保障，充分利用了企业平安工具，如Kerberos与OpenSSL等。你能够定义本人的查看，依据本人的业务规定确保数据品质。 在泛滥的治理个性 中，point-in-time recovery（PITR）是十分棒的个性，这是个灵便的高可用个性，提供了诸如针对失败复原创立热备份以及快照与复原的能力。但这并不是 PostgreSQL的全副，我的项目还提供了几个办法来治理PostgreSQL以实现高可用、负载平衡与复制等，这样你就能够应用适宜本人特定需要的性能了。 平台MySQL与PostgreSQL都呈现在一些高流量的Web站点上： MySQL：Slashdot、Twitter、Facebook与WikipediaPostgreSQL：Yahoo应用了一个批改的PostgreSQL数据库来解决每天数以亿计的事件，还有Reddit和DisqusMySQL与PostgreSQL都能运行在多个操作系统上，如Linux、Unix、Mac OS X与Windows。他们都是开源、收费的，因而测试他们时的惟一代价就是你的工夫与硬件。他们都很灵便且具备可伸缩性，可用在小型零碎和大型分布式系统上。 MySQL在一个畛域上要比PostgreSQL更进一步，那就是它的触角延长到了嵌入式畛域，这是通过libmysqld实现的。PostgreSQL不反对嵌入式应用，仍然坚守在传统的客户端/服务器架构上。 MySQL通常被认为是针对网站与利用的疾速数据库后端，可能进行疾速的读取和大量的查问操作，不过在简单个性与数据完整性查看方面不太尽如人意。 PostgreSQL是针对事务型企业应用的庄重、功能完善的数据库，反对强ACID个性和很多数据完整性查看。他们二者都在某些工作上具备很快的速 度，MySQL不同存储引擎的行为有较大差异。 MyISAM引擎是最快的，因为它只执行很少的数据完整性查看，适宜于后端读操作较多的站点，不过对于蕴含 敏感数据的读/写数据库来说就是个劫难了，因为MyISAM表最终可能会损坏。MySQL提供了修复MySQL表的工具，不过对于敏感数据来说，反对 ACID个性的InnoDB则是个更好的抉择。 与之相同，PostgreSQL则是个只有繁多存储引擎的齐全集成的数据库。你能够通过调整postgresql.conf文件的参数来改良性能，也能够调整查问与事务。PostgreSQL文档对于性能调优提供了十分详尽的介绍。 MySQL与PostgreSQL都是高可配置的，并且能够针对不同的工作进行相应的优化。他们都反对通过扩大来增加额定的性能。 一个常见的误会就是MySQL要比PostgreSQL更容易学习。关系数据库系统都是非常复杂的，这两个数据库的学习曲线其实是差不多的。 规范兼容性PostgreSQL旨在实现SQL兼容性（以后规范是ANSI-SQL:2008）。MySQL则兼容大部分SQL，不过还有本人的扩大，能够支 持NoSQL个性，这在参考手册中都有介绍。每种形式都有优缺点。兼容规范会让数据库管理员、数据库开发者与利用开发者更难受一些，因为这意味着他们只需 学习一套规范、一套个性和命令即可。这会节省时间，晋升效率，也不会被锁定在特定的厂商上。 反对应用非标准的自定义性能的人们认为这样能够疾速采纳新的个性，而不用期待规范过程实现。ANSI/ISO规范在一直演变，因而规范兼容性也是个 变动的指标：出名的关系型数据库Microsoft SQL Server、Oracle与IBM DB2也只是局部兼容于规范。 论断尽管有不同的历史、引擎与工具，不过并没有明确的参考可能表明这两个数据库哪一个可能实用于所有状况。很多组织喜爱应用PostgreSQL，因为它的可靠性好，在爱护数据方面很善于，而且是个社区我的项目，不会陷入厂商的牢笼之中。 MySQL更加灵便，提供了更多选项来针对不同的工作进行裁剪。很多时候，对于一个组织来说，对某个软件应用的熟练程度要比个性上的起因更重要。 PostgreSQL绝对于MySQL的劣势在SQL的规范实现上要比MySQL欠缺，而且性能实现比拟谨严；存储过程的性能反对要比MySQL好，具备本地缓存执行打算的能力；对表连贯反对较完整，优化器的性能较完整，反对的索引类型很多，简单查问能力较强；PG主表采纳堆表寄存，MySQL采纳索引组织表，可能反对比MySQL更大的数据量。PG的主备复制属于物理复制，绝对于MySQL基于binlog的逻辑复制，数据的一致性更加牢靠，复制性能更高，对主机性能的影响也更小。MySQL的存储引擎插件化机制，存在锁机制简单影响并发的问题，而PG不存在。MySQL绝对于PG的劣势：innodb的基于回滚段实现的MVCC机制，绝对PG新老数据一起寄存的基于XID的MVCC机制，是占优的。新老数据一起寄存，须要定时触 发VACUUM，会带来多余的IO和数据库对象加锁开销，引起数据库整体的并发能力降落。而且VACUUM清理不及时，还可能会引发数据收缩；MySQL采纳索引组织表，这种存储形式非常适合基于主键匹配的查问、删改操作，然而对表结构设计存在束缚；MySQL的优化器较简略，零碎表、运算符、数据类型的实现都很精简，非常适合简略的查问操作；MySQL分区表的实现要优于PG的基于继承表的分区实现，次要体现在分区个数达到上千上万后的解决性能差别较大。MySQL的存储引擎插件化机制，使得它的利用场景更加宽泛，比方除了innodb适宜事务处理场景外，myisam适宜静态数据的查问场景。总结开源数据库都不是很欠缺，商业数据库oracle在架构和性能方面都还是欠缺很多的。从利用场景来说，PG更加适宜严格的企业应用场景（比方金融、电信、ERP、CRM），而MySQL更加适宜业务逻辑绝对简略、数据可靠性要求较低的互联网场景（比方google、facebook、alibaba）。 MySQL 与 PostgreSQL 比拟，选哪个为了弄明确PostgreSQL和MySQL的差异，我搜寻了关键字：MySQL vs PostgreSQL，并看了第一页的几个文章。以下是简略总结： MySQL与PostgreSQL的区别MySQL是利用开发者创立进去的DBMS；而PostgreSQL是由数据库开发者创立进去的DBMS 。换句话说，MySQL偏向于使用者的角度，答复的问题是 “你想解决的是什么问题”；而PostgreSQL偏向于实践角度，答复的问题是 “数据库应该如何来解决问题” 。 ...

根底语法须要有 GRANT OPTION 权限或 mysql 零碎表的 UPDATE 权限。 REVOKE ALL ON *.* FROM 'finley'@'%.example.com';REVOKE INSERT ON *.* FROM 'jeffrey'@'localhost';REVOKE 'role1', 'role2' FROM 'user1'@'localhost', 'user2'@'localhost';REVOKE SELECT ON world.* FROM 'role3';撤销全局权限须要有 CREATE USER 权限或 mysql 零碎表的 UPDATE 权限。 REVOKE ALL PRIVILEGES, GRANT OPTION FROM user_or_role [, user_or_role] ...撤销数据库权限REVOKE INSERT, UPDATE ON db1.* FROM 'jeffrey'@'localhost';查看权限mysql> SHOW GRANTS FOR 'someuser'@'somehost';+-------------------------------------------------------+| Grants for admin@localhost |+-------------------------------------------------------+| GRANT RELOAD, PROCESS ON *.* TO 'someuser'@'somehost' |+-------------------------------------------------------+查看用户mysql> SET print_identified_with_as_hex = ON;mysql> SHOW CREATE USER 'admin'@'localhost'\G*************************** 1. row ***************************CREATE USER for admin@localhost: CREATE USER 'admin'@'localhost'IDENTIFIED WITH 'caching_sha2_password'AS 0x24412430303524301D0E17054E2241362B1419313C3E44326F294133734B30792F436E77764270373039612E32445250786D43594F45354532324B6169794F47457852796E32REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCKPASSWORD HISTORY DEFAULTPASSWORD REUSE INTERVAL DEFAULTPASSWORD REQUIRE CURRENT DEFAULT

GRANT 简介GRANT语句能够用于进行受权和设置角色，须要有 GRANT OPTION 权限或 mysql 零碎表的 UPDATE 权限。 不能在一个GRANT语句中同时进行受权和设置角色。GRANT语句应用ON子句辨别是进行受权还是设置角色。 有 ON子句则为受权。没有ON子句则为设置角色。根底语法GRANT ALL ON db1.* TO 'jeffrey'@'localhost';GRANT 'role1', 'role2' TO 'user1'@'localhost', 'user2'@'localhost';GRANT SELECT ON world.* TO 'role3';全局权限实用于所有数据库，全局权限存储在 mysql.user零碎表中。 GRANT ALL ON *.* TO 'someuser'@'somehost';GRANT SELECT, INSERT ON *.* TO 'someuser'@'somehost';数据库权限实用于给定数据库中的所有对象，数据库权限存储在 mysql.db零碎表中。 GRANT ALL ON mydb.* TO 'someuser'@'somehost';GRANT SELECT, INSERT ON mydb.* TO 'someuser'@'somehost';表权限实用于给定表中的所有列，表权限存储在 mysql.tables_priv零碎表中。 GRANT ALL ON mydb.mytbl TO 'someuser'@'somehost';GRANT SELECT, INSERT ON mydb.mytbl TO 'someuser'@'somehost';列权限实用于给定表中的单个列，列权限存储在 mysql.columns_priv零碎表中。 GRANT SELECT (col1), INSERT (col1, col2) ON mydb.mytbl TO 'someuser'@'somehost';存储过程权限略 ...

在索引构造篇咱们晓得了汇集索引和非汇集索引的区别，在mysql中，还有一些其余类型索引的概念 联结索引（多列索引）：应用多列字段组合创立索引，联结索引查问比设置多个单列索引效率高 联结索引如何查问：按程序先比拟第一个联结的字段大小，雷同就持续比拟下一个最左前缀准则：波及到联结索引的查问时，最左优先，从联结索引的最右边开始匹配，否则，因为其余字段的非有序性，须要去扫描全表，无奈进行联结索引的应用前缀索引：当对长类型的字段增加索引的时候，要应用前缀索引对字段指定长度的局部创立索引，否则会造成索引存储空间过大 笼罩索引：对字段进行笼罩索引操作，如果索引存储的数据满足查问语句须要的后果，则不须要再去进行零碎调用，间接返回索引中的数据 惟一索引（Unique）：索引字段要求唯一性，不容许反复数据 一般索引（Normal）：根本索引类型，非主键 全文索引（Full Text）：个别对长文本创立的索引 空间索引（SPATIAL）：对空间类型数据创立的索引 tips：1.索引不能放在表达式或者函数中，否则会生效 2.有时候正确应用联结索引，或者辅助索引中的主键，能够防止回表

批改用户批改用户须要有全局的创立用户权限、或零碎 mysql 数据库的更新权限。 # 批改以后登录的用户的明码ALTER USER USER() IDENTIFIED BY 'auth_string';# 批改指定用户的明码ALTER USER 'jeffrey'@'localhost' IDENTIFIED BY 'password';# 批改以后用户的明码并对现有明码进行验证，验证失败不会批改ALTER USER 'jeffrey'@'localhost' IDENTIFIED BY 'password' REPLACE 'current_password';# 批改指定用户的属性ALTER USER 'bill'@'localhost' ATTRIBUTE '{"baz": "faz", "foo": "moo"}';# 删除指定用户的某个属性ALTER USER 'bill'@'localhost' ATTRIBUTE '{"foo": null}';# 批改指定用户的 comment 属性ALTER USER 'bill'@'localhost' COMMENT 'Something about Bill';# 批改指定用户的 comment 属性为空字符串ALTER USER 'bill'@'localhost' COMMENT '';# 删除指定用户的 comment 属性ALTER USER 'bill'@'localhost' ATTRIBUTE '{"comment": null}';# 将用户的明码标记为过期，下次登录必须批改ALTER USER 'jeffrey'@'localhost' IDENTIFIED BY 'new_password' PASSWORD EXPIRE;# 批改用户的角色，角色不须要存在ALTER USER 'joe'@'10.0.0.1' DEFAULT ROLE administrator, developer;# 批改指定用户的明码SET PASSWORD FOR 'jeffrey'@'localhost' = 'auth_string';# 批改以后登录用户的明码，不须要任何权限SET PASSWORD = 'auth_string';锁定用户帐户锁定状态记录在零碎表 mysql.user 的 account_locked 列中。 ...

创立用户创立用户须要有全局的创立用户权限、或零碎 mysql 数据库的插入权限。 对于每个帐户，CREATE USER 语句在 mysql.user 零碎表中创立一个新行。 # 主机名局部（如果省略）默认为'%'CREATE USER 'jeffrey'@'localhost' IDENTIFIED BY 'password';# 创立用户并指定 comment 属性CREATE USER 'jeffrey'@'localhost' IDENTIFIED BY 'password' COMMENT 'Some information about Jon';Query OK, 0 rows affected (0.06 sec)# 查看用户的属性SELECT * FROM INFORMATION_SCHEMA.USER_ATTRIBUTES WHERE USER = 'jon' AND HOST = 'localhost';+------+-----------+-------------------------------------------+| USER | HOST | ATTRIBUTE |+------+-----------+-------------------------------------------+| jon | localhost | {"comment": "Some information about Jon"} |+------+-----------+-------------------------------------------+1 row in set (0.00 sec)# 创立用户并指定角色，角色不须要存在CREATE USER 'jeffrey'@'localhost' DEFAULT ROLE administrator, developer;删除用户删除用户须要有全局的创立用户权限、或零碎 mysql 数据库的删除权限。 ...

应用mysqld --initialize手动执行数据目录初始化，mysqld会生成一个初始随机明码，将其标记为过期，并将其写入服务器谬误日志。 mysql.user受权表定义了初始MySQL用户账户和拜访权限。装置MySQL只会创立一个'root'@'localhost' 领有所有特权并且能够执行任何操作的超级用户帐户。 mysql -u root -pEnter password: (enter the random root password here)*********mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY 'root-password';测试： shell> mysql -u root -pEnter password: (enter root password here)root-password敞开服务器： shell> mysqladmin -u root -p shutdownEnter password: (enter root password here)

Mysql能够说是最宽泛应用的数据库之一了，体积小，成本低，开源（收费才是王道呀-。-），本文旨在和大家一起摸索Mysql的一些相干常识，不仅要会用它来写sql，更要学习它的底层设计和技术延长。 索引数据结构Mysql索引是基于B+tree的数据结构来设计的，那么为什么不应用二叉树，Hash（其实是反对的），B-tree等构造来设计索引呢？ 二叉树：树的层数过高，容易进化成链表 均衡二叉树，红黑树：层数依然过高，会大大增加零碎的IO频率 HashMysql是反对Hash索引的，只不过Hash索引不反对范畴查找，而咱们在日常工作中须要宽泛的使用到范畴查问 B-tree：1.在B-tree和B+tree中，每一个节点叫做一个磁盘页，每一个磁盘页的大小是16K，那么相比拟于B-tree是在每个节点上都存储数据，B+tree是只在叶子节点上存储数据，雷同层数下，B+tree能存储的数据量要大于B-tree2.B+tree的叶子节点有双向指针，对于范畴查找的效率能大大晋升 存储引擎Mysql中有很多种存储引擎，咱们这里次要介绍的是MyISAM和InnoDB。 关上不同引擎的表的存储文件夹，会发现这两种引擎用来保留相干数据的文件不同:MyISAM .frm文件：存储表构造.MYD文件：存储数据.MYI文件：存储索引查问时，如果有索引，在MYI文件中依据索引获取数据地址，再去MYD文件中查找到数据InnoDB .frm文件:存储表构造.ibd文件：存储索引和数据索引和数据都存储在ibd文件除了存储文件上的区别，MyISAM和InnoDB还有以下的区别： 前者是非汇集索引，后者是汇集索引前者不反对事务，后者反对前者不反对外键，后者反对前者只反对表锁，后者反对表锁和行锁前者保留表的行数，后者每次仅限count(*)操作须要去扫描全表delete表的时候，前者是从新建表，后者是一行行的删···那么，什么时候应用哪个最好呢？一般来说，零碎业务波及到查问占大部分，对事务需要度低，容忍度高的，能够应用MyISAM引擎，MyISAM查问效率要高于InnoDB。反之，零碎波及并发量大，须要大量的增删改操作，倡议应用InnoDB引擎。 tips：MyISAM查问效率更高，是因为：InnoDB要缓存数据块，而MyISAM只有缓存索引块；在select的时候InnoDB须要去保护MVCC（多版本并发管制）；InnoDB查问须要映射到块再到行，而MyISAM间接记录文件的offset，定位更快汇集索引和非汇集索引对于主键索引和非主键索引来说，MyISAM节点的主键索引和非主键索引都寄存的是行数据的磁盘地址。InnoDB非主键索引存储的是主键值，而主键索引里存储的是行数据，当进行非主键索引查问时，先在非主键索引中查找到对应的主键值，而后依据主键值再去主键索引里进行一次树查问，获取主键索引中存储的行数据。（这种第一次树查问定位主键，第二次再进行一次树查问的操作叫做回表）依据索引存储形式的不同，咱们把MyISAM的主键索引和非主键索引类型叫做非汇集索引，把InnoDB的主键索引类型叫做汇集索引，非主键索引类型叫做辅助索引（一般索引）。汇集的含意能够了解为索引和数据聚合在一起。应用InnoDB时的tips：1.基于下面的设计，InnoDB必须设置主键索引，所以个别倡议咱们在进行表的设计的时候都要增加主键列，如果不设置主键，mysql会在表中寻找一个惟一列来当做主键索引，如果没有这样的列，它会去保护一个虚构列，用以建设主键索引2.主键尽可能的要设置成自增整型类型，因为最终在B+tree中是须要去比拟索引大小的，如果是非整型的，或者是无序的主键，还须要先去进行值转换，无疑减少了额定工夫开销

应用amoeba实现mysql读写拆散1、什么是amoeba？Amoeba(变形虫)我的项目，专一 分布式数据库 proxy 开发。座落与Client、DB Server(s)之间。对客户端通明。具备负载平衡、高可用性、sql过滤、读写拆散、可路由相干的query到指标数据库、可并发申请多台数据库合并后果。 次要解决： • 升高 数据切分带来的简单多数据库构造 • 提供切分规定并升高 数据切分规定 给利用带来的影响 • 升高db 与客户端的连接数 • 读写拆散 2、为什么要用Amoeba目前要实现mysql的主从读写拆散，次要有以下几种计划： 1、 通过程序实现，网上很多现成的代码，比较复杂，如果增加从服务器要更改多台服务器的代码。 2、 通过mysql-proxy来实现，因为mysql-proxy的主从读写拆散是通过lua脚本来实现，目前lua的脚本的开发跟不上节奏，而写没有完满的现成的脚本，因而导致用于生产环境的话危险比拟大，据网上很多人说mysql-proxy的性能不高。 3、 本人开发接口实现，这种计划门槛高，开发成本高，不是个别的小公司能承当得起。 4、 利用阿里巴巴的开源我的项目Amoeba来实现，具备负载平衡、高可用性、sql过滤、读写拆散、可路由相干的query到指标数据库，并且装置配置非常简单。国产的开源软件，应该反对，目前正在应用，不发表太多论断，所有等测试完再发表论断吧，哈哈！ 3、amoeba装置1、首先装置jdk，间接应用rpm包装置即可2、下载amoeba对应的版本https://sourceforge.net/projects/amoeba/，间接解压即可3、配置amoeba的配置文件dbServers.xml <?xml version="1.0" encoding="gbk"?><!DOCTYPE amoeba:dbServers SYSTEM "dbserver.dtd"><amoeba:dbServers xmlns:amoeba="http://amoeba.meidusa.com/"> <!-- Each dbServer needs to be configured into a Pool, If you need to configure multiple dbServer with load balancing that can be simplified by the following configuration: add attribute with name virtual = "true" in dbServer, but the configuration does not allow the element with name factoryConfig such as 'multiPool' dbServer --> ...

前两天共事负责的订单模块查问呈现了一个奇怪的问题，当退出筛选条件后会呈现查问超时的问题，查问全副订单的时候没有问题，SQL如下（数据已脱敏，应用的是MySql）： SELECT a.consumer_code AS orderCode, a.rent_equipment_snid AS eqSn, a.powerbank_snid AS pbSn, a.rent_merchant_name AS rentMerchant, a.rent_merchant_address AS merchantAddress, a.rent_date AS rentTime, a.close_date AS returnTime, a.payment_money AS orderAmount, a.order_status AS orderStatus, a.consume_schema AS consumeSchema, a.transaction_status AS transStatus, a.rent_equipment_model AS eqModel FROM cp_consumer_order_2020_10 a WHERE a.agent_code = xxxx # 上面两个条件就是筛选时才会加上 AND a.order_status = xxx AND a.close_date IS NULL ORDER BY a.consumer_code desccp_consumer_order_2020_10是订单月表，差不多有1000多万数据，consumer_code是主键，agent_code 上有一般索引。我拿到下面的SQL在数据库执行发现是走了agent_code索引的，并且查问效率也是失常的，而后删掉了筛选条件，执行后果也是一样。 下面别离是带条件和不带条件的执行打算，能够看到没有什么区别。这时我猜测是不是代码中有什么耗时的操作： 这个代码看起来也没有什么特地耗时的操作，getAgentOrderList就是执行那条SQL，getAgentStaffOrderList也试过查问很快，因为有分页，上面的for循环执行也不会特地慢。难不成又呈现“灵异事件”了？这时我忽然想到会不会是分页导致的，咱们都晓得limit在offset十分大的状况下会导致查问慢，但咱们这里还没有翻页，也就是第一页，所以不是这个问题。除此之外我又想到之前看到过limit和order by连用会呈现索引抉择谬误的问题，于是我在带上limit 0,30在数据库执行刚刚的SQL，果不其然，慢SQL呈现了。这时我再看执行打算如下： 能够看到这时候Mysql应用了主键索引，即咱们排序的字段，于是我倡议共事用force index强制走一般索引，查问就恢复正常了。到这里，SQL优化就完结了，然而为什么加上limit就会导致Mysql选错索引呢，而且为什么走主键索引就很慢呢，预估扫描行数明明更少了呀？本着“知其然还要知其所以然”的准则我查阅了很多材料，都没有齐全能解决心中的纳闷，最终本人重复尝试，总算搞明确了。 首先为什么走一般索引更快，而主键索引更慢？因为我这条SQL是查问主键索引倒序后果，索引人造有序，不必排序了，所以看到执行打算外面的Extra字段没有了Using filesort，这里比一般索引快，然而这条SQL是有where条件筛选的，那么在拿到有序后果后，还须要逐条取出agent_code和where条件进行匹配。看到这里置信读者应该根本明确了，如果没有limit，那么这条SQL会呈现全表扫描；而这里有limit 0,30，就会呈现上面的状况：一是和where条件匹配的30条记录刚好是排序后的前30条，那么mysql就只须要扫描30条；如果有余30条或者匹配的记录都在排序的开端，也会全表扫描。而应用一般索引agent_code没有这个问题，是因为筛选条件就是agent_code，能够很快的进行匹配。为什么加了limit就会应用主键索引？因为不加limit的时候如果应用主键索引，就会如上所说挨个匹配where条件，但此时没有限度返回的条数，就会进行全表扫描（能够用force index(primary)+explain看到row是表总行数（1000w条）），Mysql就认为应用一般索引更快，因为一般索引预估扫描行数只有不到1.8W条；然而加了limit之后走主键索引的预估扫描行数可能会少于走一般索引的预估扫描行数，导致索引抉择谬误。————————————————版权申明：本文为CSDN博主「夜勿语」的原创文章，遵循CC 4.0 BY-SA版权协定，转载请附上原文出处链接及本申明。原文链接：https://blog.csdn.net/l610800... ...

mysql读写拆散 1、读写拆散的介绍 MySQL读写拆散基本原理是让master数据库解决写操作，slave数据库解决读操作。master将写操作的变更同步到各个slave节点。 MySQL读写拆散能进步零碎性能的起因在于： 1、物理服务器减少，机器解决能力晋升。拿硬件换性能。 2、主从只负责各自的读和写，极大水平缓解X锁和S锁争用。 3、slave能够配置myiasm引擎，晋升查问性能以及节约零碎开销。 4、master间接写是并发的，slave通过主库发送来的binlog复原数据是异步。 5、slave能够独自设置一些参数来晋升其读的性能。 6、减少冗余，进步可用性。 2、读写拆散的配置1、硬件配置master 192.168.85.11slave 192.168.85.12proxy 192，168.85.14 2、首先在master和slave上配置主从复制3、进行proxy的相干配置1、下载mysql-proxyhttps://downloads.mysql.com/a... 2、上传软件到proxy的机器间接通过xftp进行上传 3、解压安装包tar -zxvf mysql-proxy-0.8.5-linux-glibc2.3-x86-64bit.tar.gz 4、批改解压后的目录mv mysql-proxy-0.8.5-linux-glibc2.3-x86-64bit mysql-proxy 5、进入mysql-proxy的目录cd mysql-proxy 6、创立目录mkdir confmkdir logs 7、增加环境变量关上/etc/profile文件vi /etc/profile 在文件的最初面增加一下命令export PATH=$PATH:/root/mysql-proxy/bin 8、执行命令让环境变量失效source /etc/profile 9、进入conf目录，创立文件并增加一下内容vi mysql-proxy.conf增加内容[mysql-proxy]user=rootproxy-address=192.168.85.14:4040proxy-backend-addresses=192.168.85.11:3306proxy-read-only-backend-addresses=192.168.85.12:3306proxy-lua-script=/root/mysql-proxy/share/doc/mysql-proxy/rw-splitting.lualog-file=/root/mysql-proxy/logs/mysql-proxy.loglog-level=debugdaemon=true 10、开启mysql-proxymysql-proxy --defaults-file=/root/mysql-proxy/conf/mysql-proxy.conf 11、查看是否装置胜利，关上日志文件cd /root/mysql-proxy/logstail -100 mysql-proxy.log 内容如下：示意装置胜利2019-10-11 21:49:41: (debug) max open file-descriptors = 10242019-10-11 21:49:41: (message) proxy listening on port 192.168.85.14:40402019-10-11 21:49:41: (message) added read/write backend: 192.168.85.11:33062019-10-11 21:49:41: (message) added read-only backend: 192.168.85.12:33062019-10-11 21:49:41: (debug) now running as user: root (0/0) ...

原创】研发应该懂的binlog常识(上)引言为什么写这篇文章?大家当年在学MySQL的时候，为了可能迅速待业，个别是学习一下MySQL的根本语法，差不多就出山找工作了。程度略微好一点的童鞋呢还会懂一点存储过程的编写，又或者是懂一点索引的创立和应用。然而呢，基本上大家都疏忽了对底层常识的学习。为什么呢？因为工作中很少用到嘛。而后呢，市面上流传的大部分这种底层的常识，又比拟偏运维，研发懂这么多意义也不是太大，很多常识可能这辈子都不会用到。 因而，我整顿了一部分相干的常识，心愿大家有所播种。 研发到底要懂哪些?次要分为两个局部 binlog的相干概念怎么解析binlog打算分高低两个局部来叙述。上局部讲述binlog的相干概念这部分的常识，咱们不须要像运维懂的那么深，我会列举一些常见概念和常见配置，大家匆匆扫一眼，有个概念即可。这样大家当前和运维探讨问题的时候，也不会一脸的懵逼。正所谓 懵逼树上懵逼果,懵逼树下你和我。 懵逼树前排排坐,一人一个懵逼果。博主一个人默默的把懵逼果收走独享就好，各位读者还是懂点基本概念，当前不便和运维沟通。下半局部讲怎么解析binlog。 另外，这篇文章是给研发大大看的，可能有些概念我了解的也不对，请运维大大轻喷。 注释记得我的"一个定义,两个误会,三个用处,四个常识" 一个定义先从定义开始讲起 binlog是记录所有数据库表构造变更（例如CREATE、ALTER TABLE…）以及表数据批改（INSERT、UPDATE、DELETE…）的二进制日志。 binlog不会记录SELECT和SHOW这类操作，因为这类操作对数据自身并没有批改，但你能够通过查问通用日志来查看MySQL执行过的所有语句。多说一句，如果update操作没有造成数据变动，也是会记入binlog。 两个误会误会一:binlog只是一类记录操作内容的日志文件 因为binlog称之为二进制日志，很多研发会把这个二进制日志和咱们平时在代码里写的代码日志分割在一起。因为咱们的代码日志，只有一类记录操作容的文件，并不蕴含索引文件。然而，这个二进制日志包含两类文件： 索引文件（文件名后缀为.index）用于记录哪些日志文件正在被应用日志文件（文件名后缀为.00000*）记录数据库所有的DDL和DML(除了数据查问语句)语句事件。这么说可能还有一点形象，假如文件my.cnf中有这么三条配置 log_bin：on 关上binlog日志log_bin_basename：bin文件门路及名前缀（/var/log/mysql/mysql-bin）log_bin_index：bin文件index（/var/log/mysql/mysql-bin.index） 那么你会在文件目录/var/log/mysql/上面发现两个文件mysql-bin.000001和mysql-bin.index。 mysql-bin.index就是咱们所说的索引文件，关上瞅瞅，内容是上面这样,记录哪些文件是日志文件。 ./mysql-bin.000001 那么说到日志文件。在innodb里其实又能够分为两局部，一部分在缓存中，一部分在磁盘上。这里业内有一个词叫做刷盘，就是指将缓存中的日志刷到磁盘上。跟刷盘无关的参数有两个:sync_binlog和binlog_cache_size。这两个参数作用如下 binlog_cache_size: 二进制日志缓存局部的大小，默认值32ksync_binlog=[N]: 示意写缓冲多少次，刷一次盘,默认值为0 留神两点: (1)binlog_cache_size设过大，会造成内存节约。binlog_cache_size设置过小，会频繁将缓冲日志写入临时文件。具体怎么设，有趣味自行查问，我感觉研发大大基本没机会去设这个值的，理解即可。(2)sync_binlog=0:示意刷新binlog工夫点由操作系统本身来决定，操作系统本身会每隔一段时间就会刷新缓存数据到磁盘，这个性能最好。sync_binlog=1，代表每次事务提交时就会刷新binlog到磁盘。sync_binlog=N,代表每N个事务提交会进行一次binlog刷新。另外，这里存在一个一致性问题，sync_binlog=N，数据库在操作系统宕机的时候，可能数据并没有同步到磁盘，于是再次重启数据库，会带来数据失落问题。 当sync_binlog=1，事务在commit的时候，数据写入binlog，然而还没写入事务日志(redo log和undo log)。此时宕机，重启数据库，数据被回滚。然而binlog里曾经记录，这里存在不统一问题。这个事务日志和binlog一致性的问题，大家能够查问mysql的外部XA协定，该协定就是解决这个一致性问题的。 误会二:binlog是InnoDb独有的 binlog是以事件模式记录的，这句话艰深点说，就是binlog的内容都是一个个的事件。这块具体的我会在下一篇讲，这篇记住binlog的内容就是一个个事件就行。 留神了，这里的用词，是一个个事件，而不是事务。大家应该晓得Innodb和mysiam最显著的区别就是一个反对事务，一个不反对事务。 因而你能够说，binlog是基于事务来记录二进制日志，比方sync_binlog=1,每提交一次事务，就写入binlog。你却不能说binlog是事务日志，binlog不仅记录innodb日志，在myisam中，也一样存在binlog。 三个用处这三个用处，出自《MySQL技术底细 InnoDB存储引擎》一书，别离为复原、复制、审计。这三个用处，研发大大们理解一下即可，比方数据恢复，你碰到共事删库的机会切实太少。如果真的有共事杀人越货，冒着到职的危险给你提供做数据复原的机会，大把运维工程师待命在那，轮不到你的。所以，这三个性能理解即可。 复原：这里网上有大把的文章领导你，如何利用binlog日志复原数据库数据。如果你真的感觉本人很有工夫，就本人去创立个库，而后删了，再去复原一下数据，练练手吧。 复制: 如图所示（图片不是本人画的，偷懒了） 主库有一个log dump线程，将binlog传给从库 从库有两个线程，一个I/O线程，一个SQL线程，I/O线程读取主库传过来的binlog内容并写入到relay log,SQL线程从relay log外面读取内容，写入从库的数据库。 审计：用户能够通过二进制日志中的信息来进行审计，判断是否有对数据库进行注入攻打。 四个常识常识一:binlog常见格局 这块常识我用一个表格来示意，没必要啰嗦一大堆。 format 定义 长处 毛病 statement 记录的是批改SQL语句 日志文件小，节约IO，进步性能 准确性差，对一些零碎函数不能精确复制或不能复制，如now()、uuid()等 row 记录的是每行理论数据的变更 准确性强，能精确复制数据的变更 日志文件大，较大的网络IO和磁盘IO mixed statement和row模式的混合 准确性强，文件大小适中 有可能产生主从不统一问题 业内目前举荐应用的是row模式，准确性高，尽管说文件大，然而当初有SSD和万兆光纤网络，这些磁盘IO和网络IO都是能够承受的。 那么，大家肯定想问，为什么不举荐应用mixed模式，理由如下 假如master有两条记录，而slave只有一条记录。 master的数据为 idn1d24c2c7e-430b-11e7-bf1b-00155d0167102dddslave的数据为 idn1d24c2c7e-430b-11e7-bf1b-00155d016710当在master上更新一条从库不存在的记录时，也就是id=2的记录，你会发现master是能够执行胜利的。而slave拿到这个SQL后，也会照常执行，不报任何异样，只是更新操作不影响行数而已。并且你执行命令show slave status，查看输入，你会发现没有异样。然而，如果你是row模式，因为这行基本不存在，是会报1062谬误的。 ...

mysql主从复制原理1、为什么须要主从复制？1、在业务简单的零碎中，有这么一个情景，有一句sql语句须要锁表，导致临时不能应用读的服务，那么就很影响运行中的业务，应用主从复制，让主库负责写，从库负责读，这样，即便主库呈现了锁表的情景，通过读从库也能够保障业务的失常运作。 2、做数据的热备 3、架构的扩大。业务量越来越大，I/O拜访频率过高，单机无奈满足，此时做多库的存储，升高磁盘I/O拜访的频率，进步单个机器的I/O性能。 2、什么是mysql的主从复制？MySQL 主从复制是指数据能够从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采纳异步复制形式，这样从节点不必始终拜访主服务器来更新本人的数据，数据的更新能够在近程连贯上进行，从节点能够复制主数据库中的所有数据库或者特定的数据库，或者特定的表。 3、mysql复制原理原理：（1）master服务器将数据的扭转记录二进制binlog日志，当master上的数据产生扭转时，则将其扭转写入二进制日志中； （2）slave服务器会在肯定工夫距离内对master二进制日志进行探测其是否产生扭转，如果产生扭转，则开始一个I/OThread申请master二进制事件 （3）同时主节点为每个I/O线程启动一个dump线程，用于向其发送二进制事件，并保留至从节点本地的中继日志中，从节点将启动SQL线程从中继日志中读取二进制日志，在本地重放，使得其数据和主节点的保持一致，最初I/OThread和SQLThread将进入睡眠状态，期待下一次被唤醒。 也就是说：从库会生成两个线程,一个I/O线程,一个SQL线程;I/O线程会去申请主库的binlog,并将失去的binlog写到本地的relay-log(中继日志)文件中;主库会生成一个log dump线程,用来给从库I/O线程传binlog;SQL线程,会读取relay log文件中的日志,并解析成sql语句逐个执行;留神：1--master将操作语句记录到binlog日志中，而后授予slave近程连贯的权限（master肯定要开启binlog二进制日志性能；通常为了数据安全思考，slave也开启binlog性能）。 2--slave开启两个线程：IO线程和SQL线程。其中：IO线程负责读取master的binlog内容到中继日志relay log里；SQL线程负责从relay log日志里读出binlog内容，并更新到slave的数据库里，这样就能保障slave数据和master数据保持一致了。 3--Mysql复制至多须要两个Mysql的服务，当然Mysql服务能够散布在不同的服务器上，也能够在一台服务器上启动多个服务。 4--Mysql复制最好确保master和slave服务器上的Mysql版本雷同（如果不能满足版本统一，那么要保障master主节点的版本低于slave从节点的版本） 5--master和slave两节点间工夫需同步 具体步骤：1、从库通过手工执行change master to 语句连贯主库，提供了连贯的用户所有条件（user 、password、port、ip），并且让从库晓得，二进制日志的终点地位（file名 position 号）； start slave 2、从库的IO线程和主库的dump线程建设连贯。 3、从库依据change master to 语句提供的file名和position号，IO线程向主库发动binlog的申请。 4、主库dump线程依据从库的申请，将本地binlog以events的形式发给从库IO线程。 5、从库IO线程接管binlog events，并存放到本地relay-log中，传送过去的信息，会记录到master.info中 6、从库SQL线程利用relay-log，并且把利用过的记录到relay-log.info中，默认状况下，曾经利用过的relay 会主动被清理purge 4、mysql主从模式（一）一主一从 （二）主主复制 （三）一主多从 （四）多主一从![上传中...]() （五）联级复制 4、mysql主从同步延时剖析mysql的主从复制都是单线程的操作，主库对所有DDL和DML产生的日志写进binlog，因为binlog是程序写，所以效率很高，slave的sql thread线程将主库的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是随机的，不是程序，所以老本要高很多，另一方面，因为sql thread也是单线程的，当主库的并发较高时，产生的DML数量超过slave的SQL thread所能解决的速度，或者当slave中有大型query语句产生了锁期待，那么延时就产生了。 解决方案： 1.业务的长久化层的实现采纳分库架构，mysql服务可平行扩大，扩散压力。 2.单个库读写拆散，一主多从，主写从读，扩散压力。这样从库压力比主库高，爱护主库。 3.服务的基础架构在业务和mysql之间退出memcache或者redis的cache层。升高mysql的读压力。 4.不同业务的mysql物理上放在不同机器，扩散压力。 5.应用比主库更好的硬件设施作为slave，mysql压力小，提早天然会变小。 6.应用更加强劲的硬件设施 mysql5.7之后应用MTS并行复制技术，永恒解决复制延时问题 mysql主从复制装置配置1、根底设置筹备操作系统：centos6.5 mysql版本：5.7 两台虚拟机：node1:192.168.85.111（主）node2:192.168.85.112（从） 2、在两台数据库中别离创立数据库--留神两台必须全副执行create database demo; 3、在主（node1）服务器进行如下配置：批改配置文件，执行以下命令关上mysql配置文件vi /etc/my.cnf 在mysqld模块中增加如下配置信息log-bin=master-bin #二进制文件名称binlog-format=ROW  #二进制日志格局，有row、statement、mixed三种格局，row指的是把扭转的内容复制过来，而不是把命令在从服务器上执行一遍，statement指的是在主服务器上执行的SQL语句，在从服务器上执行同样的语句。MySQL默认采纳基于语句的复制，效率比拟高。mixed指的是默认采纳基于语句的复制，一旦发现基于语句的无奈准确的复制时，就会采纳基于行的复制。server-id=1   #要求各个服务器的id必须不一样binlog-do-db=msb   #同步的数据库名称 ...

下载地址：https://dev.mysql.com/downloa...零碎偏好设置找到mysql点击start mysql serve 关上itemvim ~/.bash_profile退出PATH=$PATH:/usr/local/mysql/bin并保留（vim 中先按 Esc键，在输出 :wq ）在命令行输出source ~/.bash_profile mysql -u root -p测试是否胜利

select 语句执行流程流程创立连贯，先连贯到数据库，通过连接器连贯到客户端（TCP握手链接）此时会获取用户的权限，并且权限获取后，如果批改权限，不会影响以后连贯。并且链接的默认有效期是8小时，到期之后会主动断开，默认应用长连贯。然而因为长连贯内存占用大，会导致mysql内存涨得比拟快，导致OOM。目前常见的解决方案是应用连接池。MySQL 在执行过程中长期应用的内存是治理在连贯对象外面的导致连贯内存大查问缓存建设连贯后，进行一个查问申请，会先查问mysql的查问缓存。执行的sql作为key，上次查问的后果作为value。如果缓存命中，则间接返回。如果语句不在查问缓存中，就会持续前面的执行阶段。然而因为缓存的生效条件是只有表上有一次更新，就会淘汰这个表上所有的缓存，所以缓存的命中率会非常低。MySQL 8.0 版本间接将查问缓存的整块性能删掉了，也就是说 8.0 开始彻底没有这个性能了解析器如果在查问缓存的步骤中没有查问到缓存（8.0之前），则进行这一步。这里解析器会进行SQL语句的解析，外部将文本格式转换为二进制构造，把关键字解析进去，而后会判断的你的SQL是否合乎语法。解析器次要性能有：通过这两个性能会产生一棵解析树相似于java的词法剖析留神这里的解析树不是个别的字节代码，而是C/C++构造 这里不对解析树进行深刻解说，如果想理解能够看这篇博文。MySQL内核源码解读-SQL解析之解析器浅析这里会产生一个很多人常常碰到的谬误。 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'xxxxx' at line 1这个谬误就示意，你的SQL存在语法问题。 * 词法剖析(Lexical scanner)：作用是将整个查问合成为多个元素。* 语法规定(Grammar rule module)：寻找sql语法规定组合，产生一个序列，执行这些规定相干的代码。优化器优化器算是整个流程中最重要的一个局部，整个SQL的索引抉择，JOIN查问的表连贯程序，依附它来实现。特地是在多索引的环境下，会影响到整个SQL的效率。在上面我会具体的说。执行器执行器，顾名思义就是用来真正执行SQL的货色。第一步会先判断你有没有被操作表的权限，如果没有会报错。 ERROR 1142 (42000): SELECT command denied to user 'xx'@'localhost' for table 'xx'如果有权限就会进入表，执行查问语句。而依据优化对于索引的抉择不同又有不同的查问逻辑。 优化器是怎么抉择索引的优化器是MySQL比较复杂的一个组件，一条语句在后果雷同的状况下个别会有多种执行形式，而优化器则是找到多种执行形式中最优的一个。 查问优化程序有几个指标，然而其次要指标是∶尽可能应用索引，并且应用最严格的索引来打消对行数量随时可能疾速减少的顾虑。 ——《MySQL技术底细》在这里，咱们能够通过这个SQL去查看咱们上次查问的老本，它是io\_cost和cpu\_cost的开销总和 show status like 'Last_query_cost'; 后果示意 MySQL的优化器认为大略须要做3.399个数据页的随机查找能力实现下面的查问。 对于这个老本在《高性能MySQL》是这样形容的：每个表或者索引的页面个数、索引的基数（索引中不同值的数量）、索引和数据行的长度、索引散布状况。优化器在评估老本的时候并不思考任何层面的缓存，它假如读取任何数据都须要一次磁盘 I/O。 这句话能够总结为统计后果仅供参考，会和理论的老本有差异，最间接的就是，InnoDB 因为MVCC 导致每个视图统计的行数不一样，所以老本也会不一样。 ...

mysql逻辑架构 利用show profile查看sql的执行周期 批改配置文件/etc/my.cnf,新增以下一行,并重启mysql query_cache_type=1开启profiling: mysql> show variables like '%profiling%';mysql> set profiling=1;显示最近的几次查问: mysql> show profiles;+----------+------------+-----------------------------------+| Query_ID | Duration | Query |+----------+------------+-----------------------------------+| 1 | 0.00136600 | show variables like '%profiling%' || 2 | 0.00049975 | select * from mytbl2 where id = 2 |+----------+------------+-----------------------------------+查问id 时长 sql查看具体过程: show profile cpu,block io for query 编号就是上图的过程存储引擎查看存储引擎: SHOW ENGINES;1、InnoDB存储引擎InnoDB是MySQL的默认事务型引擎，它被设计用来解决大量的短期(short-lived)事务。除非有十分特地的起因须要应用其余的存储引擎，否则应该优先思考InnoDB引擎。 2、MyISAM存储引擎MyISAM提供了大量的个性，包含全文索引、压缩、空间函数(GIS)等，但MyISAM不反对事务和行级锁，有一个毫无疑问的缺点就是解体后无奈平安复原。 3、Archive引擎Archive档案存储引擎只反对INSERT和SELECT操作，在MySQL5.1之前不反对索引。Archive表适宜日志和数据采集类利用。依据英文的测试论断来看，Archive表比MyISAM表要小大概75%，比反对事务处理的InnoDB表小大概83%。 4、Blackhole引擎Blackhole引擎没有实现任何存储机制，它会抛弃所有插入的数据，不做任何保留。但服务器会记录Blackhole表的日志，所以能够用于复制数据到备库，或者简略地记录到日志。但这种利用形式会碰到很多问题，因而并不举荐。 5、CSV引擎 CSV引擎能够将一般的CSV文件作为MySQL的表来解决，但不反对索引。CSV引擎能够作为一种数据交换的机制，十分有用。CSV存储的数据间接能够在操作系统里，用文本编辑器，或者excel读取。 6、Memory引擎如果须要疾速地拜访数据，并且这些数据不会被批改，重启当前失落也没有关系，那么应用Memory表是十分有用。Memory表至多比MyISAM表要快一个数量级。 7、Federated引擎Federated引擎是拜访其余MySQL服务器的一个代理，只管该引擎看起来提供了一种很好的跨服务器的灵活性，但也常常带来问题，因而默认是禁用的。 罕用的有MyISAM和InnoDB 它们的区别: 比照项MyISAMInnoDB外键不反对反对事务不反对反对行表锁表锁，即便操作一条记录也会锁住整个表，不适宜高并发的操作行锁,操作时只锁某一行，不对其它行有影响，适宜高并发的操作缓存只缓存索引，不缓存实在数据不仅缓存索引还要缓存实在数据，对内存要求较高，而且内存大小对性能有决定性的影响关注点节俭资源、耗费少、简略业务并发写、事务、更大资源mysql默认应用InnoDB,但mysql内置的零碎表应用MyISAM,因为没有高并发,而且节俭资源. mysql单表瓶颈500w数据,单库瓶颈5000w数据 索引MySQL官网对索引的定义为:索引(Index)是帮忙MySQL高效获取数据的数据结构. 索引的目标在于进步查问效率，能够类比字典， 如果要查“mysql”这个单词，咱们必定须要定位到m字母，而后从下往下找到y字母，再找到剩下的sql。 如果没有索引，那么你可能须要a----z，如果我想找到Java结尾的单词呢？或者Oracle结尾的单词呢？ ...

Mycat数据库中间件1、数据库中间件： 是一类连贯软件组件和利用的计算机软件，以便于软件各部件之间的沟通。 例子：Tomcat，web中间件。 数据库中间件：连贯java应用程序和数据库 2、为什么要用Mycat？ Java与数据库紧耦合高访问量高并发对数据库的压力读写申请数据不统一mysql单表瓶颈1000w数据,单库瓶颈5000w数据 数据库中间件比照: Mycat的官网: http://www.mycat.io/ Mycat能干什么: 读写拆散数据分片 垂直拆分（分库）、程度拆分（分表）、垂直+程度拆分（分库分表)多数据源整合 原理: Mycat 的原理中最重要的一个动词是“拦挡”，它拦挡了用户发送过去的 SQL 语句，首先对 SQL 语句做了一些特定的剖析：如分片剖析、路由剖析、读写拆散剖析、缓存剖析等，而后将此 SQL 发 往后端的实在数据库，并将返回的后果做适当的解决，最终再返回给用户 装置启动1、解压后即可应用 解压缩文件拷贝到 linux 下 /usr/local/ 2、三个配置文件 schema.xml：定义逻辑库，表、分片节点等内容rule.xml：定义分片规定server.xml：定义用户以及零碎相干变量，如端口等3、批改配置文件server.xml 批改用户信息，与MySQL辨别 <!--用户名--><user name="root"> <property name="password">123456</property>     <!--明码--> <property name="schemas">TESTDB</property> <!--治理的库--></user> schemas:数据库名，这里会和schema.xml中的配置关联，多个用逗号离开，例如须要这个用户须要治理两个数据库db1,db2，则配置db1,db2 4.批改配置文件 schema.xml 删除<schema>标签间的表信息配置dataNode="dn1"， <dataNode>标签只留一个， <dataHost>标签只留一个， <writeHost>,<readHost>只留一对 <mycat:schema xmlns:mycat="http://io.mycat/"> <!-- 逻辑库 --> <schema name="TESTDB" checkSQLschema="false" sqlMaxLimit="100"  dataNode="dn1"> <!-- 逻辑表 --> </schema> <!-- 数据节点 database填写实在数据库--> <dataNode name="dn1" dataHost="host1" database="testdb" /> <!-- 数据主机 --> <dataHost name="host1" maxCon="1000" minCon="10" balance="0" writeType="0" dbType="mysql" dbDriver="native" switchType="1"  slaveThreshold="100"> <!-- 心跳检测 --> <heartbeat>select user()</heartbeat> <!-- 写主机 --> <writeHost host="hostM1" url="192.168.107.132:3306" user="root" password="000000"> <!-- 读主机 --> <readHost host="hostS2" url="192.168.107.108:3306" user="hzy" password="000000"/> </writeHost> ...

问题这是一个同行问的问题：有一张表，带一个联结索引，SQL 不满足最左匹配，为什么执行打算显示能用到这个联结索引？ 叨叨叨 有教训的 DBA 此刻曾经晓得起因了。 本文立意次要是介绍诊断的办法，不便大家在没有相干常识时找到线索。 试验起手先来个数据库： 造个表： 看一下执行打算： 看上去的确有点怪， 咱们来剖析一下：这个 SQL 不满足索引的最左匹配的准则（跳过了 b 列，间接应用 c 列），不应该抉择联结索引。但执行打算的确抉择了联结索引，可能是优化器在起作用。 咱们在试验 27 中介绍过如何诊断优化器的应用，这里咱们再来用一次： trace 后果比拟长，咱们将其放在一个 json 的图形化工具中，而后查找索引的名字 xx，能够找到以下条目： 能够看到，MySQL 认为: 联结索引是最优的 covering index联结索引可能是 range index持续搜寻： 能够看到，MySQL 因为代价起因，没有抉择联结索引作为 skip scan。 这里波及了三个概念：covering index、range index、skip scan，咱们可能不晓得这些概念是什么，稍加搜寻就能够取得官网文档的帮忙： https://dev.mysql.com/doc/ref...https://dev.mysql.com/doc/ref... 剩下的就是靠大家本人推理和试验取得论断：在这个 SQL 中，组合索引被用作 covering index，成为了全表扫描的替代品。 小贴士 如果大家在 MySQL 5.7 中做这个试验，会发现在 optimizer trace 中找不到相干信息。 MySQL 在 8.0 中对优化器信息的披露进行了加强。当前也举荐大家应用新版原本钻研个性，能取得更多的无效信息 对于 MySQL 的技术内容，你们还有什么想晓得的吗？连忙留言通知小编吧！ ...

Elasticsearch装置与简略配置1. Elasticsearch基于java开发，所以须要装置JDK并设置$JAVA_HOME (Elasticsearch7开始内置了java)2. 各版本对java的依赖 1. Elasticsearch5 须要从Java 8以上的版本 2. Elasticsearch 从6.5开始反对Java 11 3. Elasticsearch 7开始内置了java环境装置(以mac为例，不同零碎能够参考官网的示例)1. 下载源码包装置1. 到官网下载源码包 官网地址 https://www.elastic.co/cn/downloads/elasticsearch2. 双击装置 2. 应用brew装置1. brew tap elastic/tap2. brew install elastic/tap/elasticsearch-full装置当前，Elasticsearch相干文件的装置目录如下图所示 相干目录解释： 目录重要配置文件形容bin 脚本文件，包含启动Elasticsearch，装置插件，运行统计数据等configElasticsearch.yml集群配置文件，user，role based相干配置JDK java运行环境，7版本当前自带datapath.data数据文件lib java类库logsPath.log日志文件modules 蕴含所有ES模块Plugins 蕴含所有已装置插件额定留神： 1. 7.1下载的默认配置是1GB生成环境配置倡议： 1. Xmx和Xms设置成一样 2. Xmx不要超过机器内存的50% 3. 不要超过30GB在命令行输出 elasticsearch,启动集群： 在浏览器输出http://localhost:9200能够看到...： elasticsearch 装置插件1. 这里以装置analysis-icu为例，这是一个国际化分词插件elasticsearch-plugin list 查看本机已装置插件elasticsearch-plugin install analysis-icu 装置插件咱们能够应用插件的模式对elasticsearch进行扩大如何在开发机上运行多个elasticsearch实例elasticsearch -E node.name=node1 -E cluster.name=adp -E path.data=node1_data -delasticsearch -E node.name=node2 -E cluster.name=adp -E path.data=node2_data -delasticsearch -E node.name=node3 -E cluster.name=adp -E path.data=node3_data -d咱们在启动elasticsearch服务的时候，指定节点名，集群名称以及每个节点存储数据的文件即可能够通过浏览器拜访 http://localhost:9200/_cat/nodes来查看集群节点Kibana的装置与界面疾速浏览装置与配置1. kibaba的装置与elasticsearch相似，也能够通过下载源码包或者brew装置brew install elastic/tap/kibana-full注：须要先增加elastic homebrew 的仓库brew tap elastic/tap装置实现当前，各目录如下图所示 ...

服务的治理shell> systemctl {start|stop|restart|status} mysqld# 或者应用与System V零碎兼容的service命令shell> service mysqld {start|stop|restart|status}对systemd的反对包含以下文件： mysqld.service（RPM平台）：systemd服务单元配置文件，其中蕴含无关MySQL服务的详细信息。mysqld@.service（RPM平台）：相似 mysqld.service，但用于治理多个MySQL实例。开机自启动systemctl enable mysqld# 禁止开机启动systemctl disable mysqld参考： 主动启动和进行MySQL 应用systemd治理MySQL Server 服务器和服务器启动程序

咱们select的时候，会把数据对应的数据页加载到缓冲池Buffer Pool，那批改的时候，其实就是批改缓冲池Buffer Pool里的缓存页数据，而不是间接批改磁盘的数据，这样性能就会有比拟大的晋升。然而这里会有几个问题： 事务怎么回滚？存在缓存里机器宕机了怎么办？ undo日志文件在批改缓存页数据之前，会先把数据写入undo日志文件，用来解决事务回滚。如果是INSERT操作，那undo日志文件就会记录主键，回滚的时候通过主键删除。如果是UPDATE操作，那undo日志文件就会记录批改之前的数据，回滚的时候就会用之前的数据进行复原。如果是DELETE操作，那undo日志文件就会记录删除之前的数据，回滚的时候就会用之前的数据进行复原。 redo日志文件在Buffer Pool批改数据后，接下来就是把变动的值写入到redo日志文件。如果此时曾经写入redo日志文件，事务曾经提交了，然而数据还没写入磁盘，MySql服务器宕机了，Buffer Pool里批改的数据并不会批改到磁盘里。当MySql重启的时候，他会读取redo日志文件，把变动的值从新写入Buffer Pool，对于客户端来说，他读取的时候，就是读取Buffer Pool的值，所以客户端读取到的数据就是新数据。对于写入redo和undo不一样的是，他有一个redo缓存，首先把值写入redo缓存而后再写入redo日志文件。所以他这里会有几种策略： 数据写入缓存，事务提交。数据写入磁盘文件，事务提交。写入缓存后事务提交，一秒后写入磁盘文件。从数据的可靠性来讲，咱们个别抉择第二种，等写入磁盘才提交事务。为什么要写redo而不是间接写数据库文件呢？因为写入数据库文件是随机写，写入redo是程序写，这边就有很大的性能差别。 binlog日志文件实际上在redo写入后，并不会间接提交事务，而是会写入binlog归档日志，而后才会提交事务。与redo相似，他也提供了两种策略： 写入oscache后提交事务。写入磁盘后提交事务。从数据的可靠性来讲，咱们个别抉择第二种，等写入磁盘才提交事务。写入binlog后，他会对redo文件进行commit操作。比方咱们批改了10条数据，而后写入binlog是8条，那咱们理论提交胜利的事务是多少呢？要怎么判断呢？此时就须要commit来判断了，当写入binlog写入后并进行commit后，才证实这条数据是胜利的事务。如果没有进行commit操作，那么有可能是写入redo文件然而没有写入binlog的时候宕机了，或者曾经写入binlog然而没有commit的时候宕机了，那这样的事务其实就是没有胜利的。 flush链表在下面的流程中，咱们看到写入undo日志文件、redo日志文件、binlog归档日志，就是没有看到怎么写入磁盘的。在MySql中，他会有一个线程，定期的把缓存页的内容刷入到磁盘。那这里又有一个问题，咱们晓得Buffer Pool有很多缓存页，那这个线程怎么晓得应该刷入哪个缓存页到磁盘呢？跟之前的free链表、LRU链表一样，MySql也提供了一个链表，flush链表，当缓存页的内容有批改的时候，形容数据就会退出到flush链表。所以这个线程每次从flush链表找到对应的缓存页，把数据刷到磁盘，而后再把他从flush链表移走。

一、MySQL锁的根本介绍锁是计算机协调多个过程或线程并发拜访某一资源的机制。在数据库中，除传统的 计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发拜访的一致性、有效性是所有数据库必须解决的一 个问题，锁抵触也是影响数据库并发拜访性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加简单。 绝对其余数据库而言，MySQL的锁机制比较简单，其最 显著的特点是不同的存储引擎反对不同的锁机制。比方，MyISAM和MEMORY存储引擎采纳的是表级锁（table-level locking）；InnoDB存储引擎既反对行级锁（row-level locking），也反对表级锁，但默认状况下是采纳行级锁。 表级锁：开销小，加锁快；不会呈现死锁；锁定粒度大，产生锁抵触的概率最高，并发度最低。 行级锁：开销大，加锁慢；会呈现死锁；锁定粒度最小，产生锁抵触的概率最低，并发度也最高。 从上述特点可见，很难抽象地说哪种锁更好，只能就具体利用的特点来说哪种锁更适合！仅从锁的角度 来说：表级锁更适宜于以查问为主，只有大量按索引条件更新数据的利用，如Web利用；而行级锁则更适宜于有大量按索引条件并发更新大量不同数据，同时又有 并发查问的利用，如一些在线事务处理（OLTP）零碎。 二、 MyISAM表锁MySQL的表级锁有两种模式：表共享读锁（Table Read Lock）和表独占写锁（Table Write Lock）。 对MyISAM表的读操作，不会阻塞其余用户对同一表的读申请，但会阻塞对同一表的写申请；对 MyISAM表的写操作，则会阻塞其余用户对同一表的读和写操作；MyISAM表的读操作与写操作之间，以及写操作之间是串行的！ 建表语句： CREATE TABLE mylock (id int(11) NOT NULL AUTO_INCREMENT,NAME varchar(20) DEFAULT NULL, PRIMARY KEY (id)) ENGINE=MyISAM DEFAULT CHARSET=utf8;INSERT INTO mylock (id, NAME) VALUES ('1', 'a');INSERT INTO mylock (id, NAME) VALUES ('2', 'b');INSERT INTO mylock (id, NAME) VALUES ('3', 'c');INSERT INTO mylock (id, NAME) VALUES ('4', 'd'); MyISAM写锁阻塞读的案例： 当一个线程取得对一个表的写锁之后，只有持有锁的线程能够对表进行更新操作。其余线程的读写操作都会期待，直到锁开释为止。 ...

作者：王顺 爱可生 DBA 团队成员，在公司负责我的项目中解决数据库问题，喜爱学习技术，钻研技术问题。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 背景用户遇到问题，生产环境中对立脚本装置的 MySQL 8.0.18，为什么有的环境有明码策略，有的环境没有？ 剖析查看配置文件 my.cnf 并没有 validate_password 参数配置。 查看数据库中的参数配置，查到明码策略。 查看数据库的插件并没有 validate_password。 奇怪，为什么配置文件里没有 validate_password 参数，也没有装置过插件，明码策略是怎么来的？ 起因查阅官网文档，找到了起因。 8.0 之后，能够用 validate_password 组件来实现明码策略。 MySQL Components 是 8.0 新性能，用于扩大服务器性能的基于组件的根底构造。组件提供服务器和其余组件可用的服务。（就服务应用而言，服务器是一个组件，与其余组件雷同。）组件仅通过它们提供的服务进行交互。 MySQL 发行版蕴含几个实现服务器扩大的组件： 用于配置谬误日志记录的组件。用于查看明码的组件。使应用程序可能将其本人的音讯事件增加到审核日志的组件。实现用于拜访查问属性的用户定义性能的组件。https://dev.mysql.com/doc/ref... 删除该组件后，明码策略就生效了。 论断在 8.0 之前，validate_password 是个独自的插件。 8.0 后可独自装置 validate_password 插件，也能够装置 validate_password 组件来实现明码策略，用户的环境对立脚本装置数据库时，没有装置插件，但独自装置 validate_password 组件也实现了明码策略。

背景因为不同业务的数据存储和利用需要不同，企业通常会将不同业务产生的数据别离存储在独立的数据库中。随着业务架构的一直调整，以及受开发过程的影响，原先离开存储的数据库逐步暴露出一些问题：1、数据扩散在不同的数据库实例上，造成独立的数据孤岛，难以实现数据的聚合剖析。传统的通过MySQL主从关系同步数据的形式，在MySQL5.7版本之前无奈建设多对一的增量同步关系。MySQL5.7版本尽管推出了多源复制性能，但性能繁多，无奈进行不同库表间的映射，且配置过程简单，当源数量较多时容易出错。2、数据库分库分表之后存在多个数据库实例，难以再合并到对立的库表中。传统的数据库迁徙工具无奈解决合并过程中产生的数据抵触问题。3、数据量越来越大，在不影响业务的前提下很难调整数据库架构。在线批改字段类型或者字段名，要么受限于数据库性能，要么可能给业务带来较大影响而难以调整。 为此，UDTS在数据传输的根底上，减少了数据集成服务，可实现多个数据源合并，买通数据孤岛以取得数据的对立视图，不便业务进行数据分析决策; 助力企业灵便调整业务架构，优化现有的数据库服务; 疾速实现分库分表合并、自定义抵触解决策略、不便业务构建数据看板。 一站式数据集成解决方案多源数据聚合 针对数据库扩散，难以聚合的问题。UDTS推出数据集成服务，可轻松帮忙用户实现多源聚合。单个工作可反对多达 10 个数据源聚合，同时可反对不同类型网络环境下的数据源，包含外网、内网以及专线。 举例: 假如当初有两个数据源，别离是 10.10.10.100:3306 和 10.10.10.120:3306 ，聚合模式如下图所示 ： 思考到大多数据源都承载着在线业务，为了防止多源聚合对线上业务的影响，UDTS数据集成服务还反对针对每个数据源独立限速。 数据库合库合表 数据库合库合表通常存在以下难点: 数据库实例扩散；数据可能存在抵触；对不同的数据库须要不同的数据抵触解决办法。针对以上这些问题，UDTS数据集成服务在多源聚合的根底上，提供以下形式解决： 1、自定义根底数据 对于每个数据源，都可指定“是否保留指标库的原数据”，如果抉择“是”，在导入数据表时，会保留原有数据库表定义及数据。而如果抉择了不保留数据，则在导入数据时，会依据映射规定先清理对应的表及其数据。 2. 主动解决数据抵触 在创立工作时可对每个数据源独立定义数据抵触解决策略，在数据集成时，可依据本人的数据抵触解决策略来解决抵触数据。以后提供“保留”与“替换”两种策略。 保留: 当数据发生冲突时，保留指标库中的原数据，而抛弃以后数据。当应用保留规定时，导入数据应用 INSERT IGNORE INTO , 比方 INSERT IGNORE INTO table VALUES(1, "name", 18) ，当有反复数据时，保留原有的数据，新插入的数据会被疏忽。 替换: 当产生数据抵触时，应用新的数据替换指标库中原来的数据。当应用替换规定时，导入数据应用 REPLACE INTO ，比方 REPLACE INTO table VALUES(1, "name", 18) ，老的数据将会被新数据笼罩，集成工作中有多个子工作(多个源往同一个指标数据库同步)时，须要留神程序。 数据库架构调整在开发的过程中，难免会遇到数据库改名、表变更等问题，但等到数据库架构要调整的时候，才发现累积了一堆“陈年旧债”。通过UDTS数据集成服务的全量+增量，不仅能够将全量数据按映射规定迁徙到指标库中，还可动静实现增量数据的库表名称的映射。 防止用户对数据源锁库锁表的担心，UDTS数据集成服务还提供了No Lock模式，在此模式下数据集成服务运行的过程中不会对源库表进行任何的锁操作。 数据集成服务案例 1、数据脱敏某教育企业，应用UDTS数据集成服务，将数据脱敏解决后，再交由外部其它部⻔进行数据分析，提取数据的无效价值。既防止了敏感数据透露危险，又帮忙企业更快、更精准的决策。 2、数据合并某金融企业应用UDTS数据集成服务，将后期拆分后的数据库合并，不便进行后续的业务开发和剖析。 3、架构调整 某交友软件为了适应新的架构，通过UDTS数据集成服务对数据库 db 和 table 进行了从新调整，适应了新的环境。 架构的调整不仅仅是对现有数据库的改名，还依赖于存量数据的变更、增量数据的同步、业务的回滚等。 ...

Elasticsearch生态圈 Elasticsearch次要性能1. 海量数据的分布式存储和集群治理 1. 服务和数据的高可用，程度扩大2. 近实时搜寻，性能卓越 1. 结构化/全文/地理位置/主动实现3. 海量数据的近实时剖析 1. 数据聚合Elastic Stack家族成员以及利用场景Logstash(做日志采集与解决)1. 开源的服务器端数据处理管道，反对从不同的起源采集数据，转换数据，并将数据发送到不同的存储库中2. 实时解析和转换数据 1. 从IP地址破译出地理坐标 2. 讲PLL数据匿名化，齐全排除敏感字段3. 可扩大 1. 200多个插件(日志，数据库，Arcsigh，Netflow)4. 可靠性安全性 1. Logstash会通过长久化队列来保障将运行中的事件至多送达一次 2. 数据传输加密5. 监控 Kibana(可视化剖析利器)1. 基于Logstash做各种各样的图表剖析Beats 轻量级数据采集器1. 各种数据源的抓取X-pack(商业化套件)1. 平安2. 告警3. 监控4. 图查问5. 机器学习ELK利用场景1. 网站搜寻/垂直搜寻/代码搜寻2. 日志治理与剖析/平安指标监控/利用性能监控/web专区舆情剖析 流程1. 日志收集2. 格式化剖析3. 全文检索4. 危险告警Elastichsearch与数据库集成1. 独自应用elastichsearch作为存储2. 以下状况能够思考与数据库集成(先写入数据库，再同步elastichsearch) 1. 与现有零碎的集成 2. 须要思考事务性 3. 数据更新频繁指标剖析/日志剖析流程图 更多内容欢送关注我的集体公众号“韩哥有话说”，100G人工智能学习材料，大量后端学习材料等你来拿。 本文由博客群发一文多发等经营工具平台 OpenWrite 公布

问题概述 应用阿里云rds for MySQL数据库（就是MySQL5.6版本），有个用户上网记录表6个月的数据量近2000万，保留最近一年的数据量达到4000万，查问速度极慢，日常卡死。重大影响业务。 问题前提：老零碎，过后设计零碎的人大略是大学没毕业，表设计和sql语句写的不仅仅是垃圾，几乎无奈直视。原开发人员都已到职，到我来保护，这就是传说中的保护不了就跑路，而后我就是掉坑的那个！！！ 我尝试解决该问题，so，有个这个日志。 计划概述 计划一：优化现有mysql数据库。长处：不影响现有业务，源程序不须要批改代码，老本最低。毛病：有优化瓶颈，数据量过亿就玩完了。 计划二：降级数据库类型，换一种100%兼容mysql的数据库。长处：不影响现有业务，源程序不须要批改代码，你简直不须要做任何操作就能晋升数据库性能，毛病：多花钱 计划三：一步到位，大数据解决方案，更换newsql/nosql数据库。长处：扩展性强，成本低，没有数据容量瓶颈，毛病：须要批改源程序代码 以上三种计划，按程序应用即可，数据量在亿级别一下的没必要换nosql，开发成本太高。三种计划我都试了一遍，而且都造成了落地解决方案。该过程心中慰问跑路的那几个开发者一万遍 计划一具体阐明：优化现有mysql数据库 跟阿里云数据库大佬电话沟通 and Google解决方案 and 问群里大佬，总结如下（都是精髓）： 1.数据库设计和表创立时就要思考性能 2.sql的编写须要留神优化 3.分区 4.分表 5.分库 1.数据库设计和表创立时就要思考性能 mysql数据库自身高度灵便，造成性能有余，重大依赖开发人员能力。也就是说开发人员能力高，则mysql性能高。这也是很多关系型数据库的通病，所以公司的dba通常工资巨高。 设计表时要留神： 1.表字段防止null值呈现，null值很难查问优化且占用额定的索引空间，举荐默认数字0代替null。 2.尽量应用INT而非BIGINT，如果非负则加上UNSIGNED（这样数值容量会扩充一倍），当然能应用TINYINT、SMALLINT、MEDIUM_INT更好。 3.应用枚举或整数代替字符串类型 4.尽量应用TIMESTAMP而非DATETIME 5.单表不要有太多字段，倡议在20以内 6.用整型来存IP 索引 1.索引并不是越多越好，要依据查问有针对性的创立，思考在WHERE和ORDER BY命令上波及的列建设索引，可依据EXPLAIN来查看是否用了索引还是全表扫描 2.应尽量避免在WHERE子句中对字段进行NULL值判断，否则将导致引擎放弃应用索引而进行全表扫描 3.值散布很稀少的字段不适宜建索引，例如"性别"这种只有两三个值的字段 4.字符字段只建前缀索引 5.字符字段最好不要做主键 6.不必外键，由程序保障束缚 7.尽量不必UNIQUE，由程序保障束缚 8.应用多列索引时主见程序和查问条件保持一致，同时删除不必要的单列索引 简言之就是应用适合的数据类型，抉择适合的索引 抉择适合的数据类型（1）应用可存下数据的最小的数据类型，整型 < date,time < char,varchar < blob（2）应用简略的数据类型，整型比字符解决开销更小，因为字符串的比拟更简单。如，int类型存储工夫类型，bigint类型转ip函数（3）应用正当的字段属性长度，固定长度的表会更快。应用enum、char而不是varchar（4）尽可能应用not null定义字段（5）尽量少用text，非用不可最好分表# 抉择适合的索引列（1）查问频繁的列，在where，group by，order by，on从句中呈现的列（2）where条件中<，<=，=，>，>=，between，in，以及like 字符串+通配符（%）呈现的列（3）长度小的列，索引字段越小越好，因为数据库的存储单位是页，一页中能存下的数据越多越好（4）离散度大（不同的值多）的列，放在联结索引后面。查看离散度，通过统计不同的列值来实现，count越大，离散水平越高： 原开发人员曾经跑路，该表早已建设，我无奈批改，故：该措辞无奈执行，放弃！ 2.sql的编写须要留神优化 1.应用limit对查问后果的记录进行限定 2.防止select *，将须要查找的字段列出来 3.应用连贯（join）来代替子查问 4.拆分大的delete或insert语句 5.可通过开启慢查问日志来找出较慢的SQL 6.不做列运算：SELECT id WHERE age + 1 = 10，任何对列的操作都将导致表扫描，它包含数据库教程函数、计算表达式等等，查问时要尽可能将操作移至等号左边 ...

作者：莫善 某互联网公司资深 DBA。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 目 录 一、概述 二、环境信息 三、环境筹备 1、centos1 2、centos2 3、centos3 四、测试 1、筹备数据 2、flush binlog 3、MySQL 压测 4、解析 binlog 五、总结 一、概述作为一个 MySQL DBA，查看剖析 binlog 是日常工作的一部分。 不晓得你是否遇到过这样的需要：一个时间段，各个表的 dml 统计状况。 但，如果 binlog 文件很多呢？又或者负责的业务线比拟多，有多个业务都有这种需要呢？ 其实需要很简略，只是操作起来有点头疼？ 所以，本文就针对这类需要做了一个测试。 如果你在工作中也有相似的懊恼，或者常常须要批量解析 binlog，这篇文章或者对你有帮忙。 二、环境信息 三、环境筹备1、centos1（1）装置 MySQL hostnameip a|grep 192cat /proc/cpuinfo | grep processorfree -mdf -h|grep data/usr/local/mysql80/bin/mysql -uroot -p1234567890 -h192.168.1.10 -P3306 -e "select version()" 提醒：省略装置 MySQL 的步骤。 2、centos2（1）装置 sysbench sysbench --version 提醒：省略装置 sysbench 的步骤。centos 6 的 yum 能够参照如下操作配置。 ...

更新语句正确的写法update table_name set column1 = 'value1', column2 = 'value2' where id = 1更新语句谬误的写法update table_name set column1 = 'value1' and column2 = 'value2' where id = 1运行谬误写法的后果column1 会被更新为 0起因剖析应用and连接符时，该语句会被解析为 update table_name set column1 = ('value1' and column2 = 'value2') where id = 1而 ('value1' and column2 = 'value2') 是一个逻辑表达式，因为 column2 = 'value2'并不成立，故 (column2 = 'value2') 的后果为0，此时表达式等效为 (1 and 0)，故理论的后果被更新为 0

前言： 在 MySQL 运维过程中，锁期待和死锁问题是令各位 DBA 及开发同学十分头痛的事。呈现此类问题会造成业务回滚、卡顿等故障，特地是业务忙碌的零碎，呈现死锁问题后影响会更重大。本篇文章咱们一起来学习下什么是锁期待及死锁，呈现此类问题又应该如何剖析解决呢？ 1.理解锁期待与死锁呈现锁期待或死锁的起因是拜访数据库须要加锁，那你可能要问了，为啥要加锁呢？起因是为了确保并发更新场景下的数据正确性，保障数据库事务的隔离性。 试想一个场景，如果你要去图书馆借一本《高性能MySQL》，为了避免有人提前把这本书借走，你能够提前进行预约（加锁），这把锁能够怎么加？ 封闭图书馆（数据库级别的锁）把数据库相干的书都锁住（表级别的锁）只锁 MySQL 相干的书（页级别的锁）只锁《高性能MySQL》这本书（行级别的锁）锁的粒度越细，并发级别越高，实现也更简单。 锁期待也可称为事务期待，后执行的事务期待后面解决的事务开释锁，然而等待时间超过了 MySQL 的锁等待时间，就会引发这个异样。期待超时后的报错为“Lock wait timeout exceeded...”。 死锁产生的起因是两个事务相互期待对方开释雷同资源的锁，从而造成的死循环。产生死锁后会立刻报错“Deadlock found when trying to get lock...”。 2.景象复现及解决上面咱们以 MySQL 5.7.23 版本为例（隔离级别是 RR ），来复现下上述两种异常现象。 mysql> show create table test_tb\G*************************** 1. row *************************** Table: test_tbCreate Table: CREATE TABLE `test_tb` ( `id` int(11) NOT NULL AUTO_INCREMENT, `col1` varchar(50) NOT NULL DEFAULT '', `col2` int(11) NOT NULL DEFAULT '1', `col3` varchar(20) NOT NULL DEFAULT '', PRIMARY KEY (`id`), KEY `idx_col1` (`col1`)) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf81 row in set (0.00 sec)mysql> select * from test_tb;+----+------+------+------+| id | col1 | col2 | col3 |+----+------+------+------+| 1 | fdg | 1 | abc || 2 | a | 2 | fg || 3 | ghrv | 2 | rhdv |+----+------+------+------+3 rows in set (0.00 sec)# 事务一首先执行mysql> begin;Query OK, 0 rows affected (0.00 sec)mysql> select * from test_tb where col1 = 'a' for update;+----+------+------+------+| id | col1 | col2 | col3 |+----+------+------+------+| 2 | a | 2 | fg |+----+------+------+------+1 row in set (0.00 sec)# 事务二而后执行mysql> begin;Query OK, 0 rows affected (0.01 sec)mysql> update test_tb set col2 = 1 where col1 = 'a';ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction呈现上种异样的起因是事务二在期待事务一的行锁，但事务一始终没提交，期待超时而报错。InnoDB 行锁期待超时工夫由 innodb_lock_wait_timeout 参数管制，此参数默认值为 50 ，单位为秒，即默认状况下，事务二会期待 50s ，若仍拿不到行锁则会报期待超时异样并回滚此条语句。 ...

1.图示各种连贯：INNER JOIN(JOIN): LEFT JOIN: RIGHT JOIN: 2.应用案例创立a\_table和b\_table，并插入测试数据CREATE TABLE `a_table` ( `a_id` int(11) DEFAULT NULL, `a_name` varchar(10) DEFAULT NULL, `a_part` varchar(10) DEFAULT NULL) ENGINE=InnoDB DEFAULT CHARSET=utf8;insert into a_table values(1,'老潘','总裁部');insert into a_table values(2,'老王','秘书部');insert into a_table values(3,'老张','设计部');insert into a_table values(4,'老李','运行部');CREATE TABLE `b_table` ( `b_id` int(11) DEFAULT NULL, `b_name` varchar(10) DEFAULT NULL, `b_part` varchar(10) DEFAULT NULL) ENGINE=InnoDB DEFAULT CHARSET=utf8;insert into b_table values(2,'老王','秘书部');insert into b_table values(3,'老张','设计部');insert into b_table values(5,'老刘','人事部');insert into b_table values(6,'老黄','生产部');insert into b_table values(7,'老张','测试部');各种连贯测试的sql脚本：-- left joinleft join select a.a_name,a.a_part,b.b_name,b.b_part from a_table a left join b_table b on a.a_id = b.b_id;-- 主表与左连贯表中若有1:n的连贯，选取左连贯表中最大的id进行左连贯查问select a.a_name,a.a_part,b.b_name,b.b_partfrom a_table aleft join( select * from b_table t1 join (select max(b_id) as id from b_table group by b_name ) t2 on t1.b_id = t2.id)b on a.a_name = b.b_name;-- inner join select a.a_name,a.a_part,b.b_name,b.b_partfrom a_table ainner join b_table b on a.a_id = b.b_id;-- right joinselect a.a_name,a.a_part,b.b_name,b.b_partfrom a_table aright join b_table b on a.a_id = b.b_id;以上参考自：https://blog.csdn.net/plg17/article/details/78758593https://blog.csdn.net/J\_\_Max/article/details/87453024 ...

一、mysql执行打算在企业的利用场景中，为了晓得优化SQL语句的执行，须要查看SQL语句的具体执行过程，以放慢SQL语句的执行效率。能够应用explain+SQL语句来模仿优化器执行SQL查问语句，从而晓得mysql是如何解决sql语句的。官网地址： https://dev.mysql.com/doc/ref... 二、执行打算中蕴含的信息ColumnMeaningidThe SELECT identifierselect_typeThe SELECT typetableThe table for the output rowpartitionsThe matching partitionstypeThe join typepossible_keysThe possible indexes to choosekeyThe index actually chosenkey_lenThe length of the chosen keyrefThe columns compared to the indexrowsEstimate of rows to be examinedfilteredPercentage of rows filtered by table conditionextraAdditional information1、idselect查问的序列号，蕴含一组数字，示意查问中执行select子句或者操作表的程序id号分为三种状况： 1、如果id雷同，那么执行程序从上到下 explain select * from emp e join dept d on e.deptno = d.deptno join salgrade sg on e.sal between sg.losal and sg.hisal; 2、如果id不同，如果是子查问，id的序号会递增，id值越大优先级越高，越先被执行 ...

Thresh锁分类从操作的粒度可分为表级锁、行级锁和页级锁。 表级锁：每次操作锁住整张表。锁定粒度大，产生锁抵触的概率最高，并发度最低。利用在MyISAM、InnoDB、BDB 等存储引擎中。行级锁：每次操作锁住一行数据。锁定粒度最小，产生锁抵触的概率最低，并发度最高。利用在InnoDB 存储引擎中。页级锁：每次锁定相邻的一组记录，锁定粒度界于表锁和行锁之间，开销和加锁工夫界于表锁和行锁之间，并发度个别。利用在BDB 存储引擎中。从操作的类型可分为读锁和写锁。 读锁（S锁）：共享锁，针对同一份数据，多个读操作能够同时进行而不会相互影响。 写锁（X锁）：排他锁，以后写操作没有实现前，它会阻断其余写锁和读锁。IS锁、IX锁：动向读锁、动向写锁，属于表级锁，S和X次要针对行级锁。在对表记录增加S或X锁之前，会先对表增加IS或IX锁。 S锁：事务A对记录增加了S锁，能够对记录进行读操作，不能做批改，其余事务能够对该记录追加S锁，然而不能追加X锁，须要追加X锁，须要等记录的S锁全副开释。X锁：事务A对记录增加了X锁，能够对记录进行读和批改操作，其余事务不能对记录做读和批改操作。 从操作的性能可分为乐观锁和乐观锁 乐观锁：个别的实现形式是对记录数据版本进行比对，在数据更新提交的时候才会进行冲突检测，如果发现抵触了，则提醒错误信息。乐观锁：在对一条数据批改的时候，为了防止同时被其他人批改，在批改数据之前先锁定，再批改的管制形式。共享锁和排他锁是乐观锁的不同实现，但都属于乐观锁领域。行锁原理在InnoDB引擎中，咱们能够应用行锁和表锁，其中行锁又分为共享锁和排他锁。InnoDB行锁是通过对索引数据页上的记录加锁实现的，次要实现算法有 3 种：Record Lock、Gap Lock 和 Next-key Lock。 RecordLock锁：锁定单个行记录的锁。（记录锁，RC、RR隔离级别都反对）GapLock锁：间隙锁，锁定索引记录间隙，确保索引记录的间隙不变。（范畴锁，RR隔离级别反对）Next-key Lock 锁：记录锁和间隙锁组合，同时锁住数据，并且锁住数据前后范畴。（记录锁+范畴锁，RR隔离级别反对）在RR隔离级别，InnoDB对于记录加锁行为都是先采纳Next-Key Lock，然而当SQL操作含有惟一索引时，Innodb会对Next-Key Lock进行优化，降级为RecordLock，仅锁住索引自身而非范畴。 1）select ... from 语句：InnoDB引擎采纳MVCC机制实现非阻塞读，所以对于一般的select语句，InnoDB不加锁2）select ... from lock in share mode语句：追加了共享锁，InnoDB会应用Next-Key Lock锁进行解决，如果扫描发现惟一索引，能够降级为RecordLock锁。3）select ... from for update语句：追加了排他锁，InnoDB会应用Next-Key Lock锁进行解决，如果扫描发现惟一索引，能够降级为RecordLock锁。4）update ... where 语句：InnoDB会应用Next-Key Lock锁进行解决，如果扫描发现惟一索引，能够降级为RecordLock锁。5）delete ... where 语句：InnoDB会应用Next-Key Lock锁进行解决，如果扫描发现惟一索引，能够降级为RecordLock锁。6）insert语句：InnoDB会在将要插入的那一行设置一个排他的RecordLock锁。乐观锁乐观锁（Pessimistic Locking），是指在数据处理过程，将数据处于锁定状态，个别应用数据库的锁机制实现。从狭义上来讲，后面提到的行锁、表锁、读锁、写锁、共享锁、排他锁等，这些都属于乐观锁领域 表级锁表级锁每次操作都锁住整张表，并发度最低。手动减少表锁 lock table 表名称 read|write,表名称2 read|write;查看表上加过的锁 show open tables;删除表锁 unlock tables;表级读锁：以后表追加read锁，以后连贯和其余的连贯都能够读操作；然而以后连贯增删改操作会报错，其余连贯增删改会被阻塞。表级写锁：以后表追加write锁，以后连贯能够对表做增删改查操作，其余连贯对该表所有操作都被阻塞（包含查问）。总结：表级读锁会阻塞写操作，然而不会阻塞读操作。而写锁则会把读和写操作都阻塞。 共享锁（行级锁-读锁）共享锁又称为读锁，简称S锁。共享锁就是多个事务对于同一数据能够共享一把锁，都能拜访到数据，然而只能读不能批改。应用共享锁的办法是在select ... lock in share mode，只实用查问语句。总结：事务应用了共享锁（读锁），只能读取，不能批改，批改操作被阻塞。 排他锁（行级锁-写锁）排他锁又称为写锁，简称X锁。排他锁就是不能与其余锁并存，如一个事务获取了一个数据行的排他锁，其余事务就不能对该行记录做其余操作，也不能获取该行的锁。应用排他锁的办法是在SQL开端加上for update，innodb引擎默认会在update，delete语句加上for update。行级锁的实现其实是依附其对应的索引，所以如果操作没用到索引的查问，那么会锁住全表记录。 总结：事务应用了排他锁（写锁），以后事务能够读取和批改，其余事务不能批改，也不能获取记录锁（select... for update）。如果查问没有应用到索引，将会锁住整个表记录。 ...

Mysql的根本架构图mysql8之后不存在查问缓存了 1、连接器▪ 连接器负责跟客户端建设连贯，获取权限、维持和治理连贯– 用户名明码验证– 查问权限信息，调配对应的权限– 能够应用show processlist查看当初的连贯– 如果太长时间没有动静，就会主动断开，通过wait_timeout管制，默认8小时▪ 连贯能够分为两类：– 长连贯：举荐应用，然而要周期性的断开长连贯– 短链接： 查问缓存▪ 当执行查问语句的时候，会先去查问缓存中查看后果，之前执行过的sql语句及其后果可能以key-value的模式存储在缓存中，如果能找到则间接返回，如果找不到，就继续执行后续的阶段。▪ 然而，不举荐应用查问缓存：– 1、查问缓存的生效比拟频繁，只有表更新，缓存就会清空– 2、缓存对应新更新的数据命中率比拟低 2、分析器▪ 词法剖析：Mysql须要把输出的字符串进行辨认每个局部代表什么意思– 把字符串 T 辨认成 表名 T– 把字符串 ID 辨认成 列ID▪ 语法分析：▪ 依据语法规定判断这个sql语句是否满足mysql的语法，如果不合乎就会报错“You have an error in your SQL synta” 3、优化器▪ 在具体执行SQL语句之前，要先通过优化器的解决– 当表中有多个索引的时候，决定用哪个索引– 当sql语句须要做多表关联的时候，决定表的连贯程序等等▪ 不同的执行形式对SQL语句的执行效率影响很大– RBO:基于规定的优化– CBO:基于老本的优化 4、Redo日志—innodb存储引擎的日志文件▪ 当产生数据批改的时候，innodb引擎会先将记录写到redo log中，并更新内存，此时更新就算是实现了，同时innodb引擎会在适合的机会将记录操作到磁盘中▪ Redolog是固定大小的，是循环写的过程▪ 有了redolog之后，innodb就能够保障即便数据库产生异样重启，之前的记录也不会失落，叫做crash-safe 5、纳闷 6、Undo log▪ Undo Log是为了实现事务的原子性，在MySQL数据库InnoDB存储引擎中，还用Undo Log来实现多版本并发管制(简称：MVCC)▪ 在操作任何数据之前，首先将数据备份到一个中央（这个存储数据备份的中央称为Undo Log）。而后进行数据的批改。如果呈现了谬误或者用户执行了ROLLBACK语句，零碎能够利用Undo Log中的备份将数据恢复到事务开始之前的状态▪ 留神：undo log是逻辑日志，能够了解为：– 当delete一条记录时，undo log中会记录一条对应的insert记录– 当insert一条记录时，undo log中会记录一条对应的delete记录– 当update一条记录时，它记录一条对应相同的update记录 7、binlog—服务端的日志文件▪ Binlog是server层的日志，次要做mysql性能层面的事件▪ 与redo日志的区别:– 1、redo是innodb独有的，binlog是所有引擎都能够应用的– 2、redo是物理日志，记录的是在某个数据页上做了什么批改，binlog是逻辑日志，记录的是这个语句的原始逻辑– 3、redo是循环写的，空间会用完，binlog是能够追加写的，不会笼罩之前的日志信息 ...

ThreshACID 个性在关系型数据库管理系统中，一个逻辑工作单元要成为事务，必须满足这 4 个个性，即所谓的 ACID： 原子性（Atomicity）一致性（Consistency）隔离性（Isolation）持久性（Durability）原子性原子性：事务是一个原子操作单元，其对数据的批改，要么全都执行，要么全都不执行。 批改 ---> Buffer Pool批改 ---> 刷盘。可能会有上面两种状况： 事务提交了，如果此时Buffer Pool的脏页没有刷盘，如何保障批改的数据失效？ Redo如果事务没提交，然而Buffer Pool的脏页刷盘了，如何保障不该存在的数据撤销？Undo每一个写事务，都会批改BufferPool，从而产生相应的Redo/Undo日志，在Buffer Pool 中的页被刷到磁盘之前，这些日志信息都会先写入到日志文件中，如果 Buffer Pool 中的脏页没有刷胜利，此时数据库挂了，那在数据库再次启动之后，能够通过 Redo 日志将其复原进去，以保障脏页写的数据不会失落。如果脏页刷新胜利，此时数据库挂了，就须要通过Undo来实现了。 持久性持久性：指的是一个事务一旦提交，它对数据库中数据的扭转就应该是永久性的，后续的操作或故障不应该对其有任何影响，不会失落。 一个“提交”动作触发的操作有：binlog落地、发送binlog、存储引擎提交、flush_logs，check_point、事务提交标记等。这些都是数据库保障其数据完整性、持久性的伎俩 隔离性隔离性：指的是一个事务的执行不能被其余事务烦扰，即一个事务外部的操作及应用的数据对其余的并发事务是隔离的。 InnoDB 反对的隔离性有 4 种，隔离性从低到高别离为：读未提交、读提交、可反复读、可串行化。锁和多版本控制（MVCC）技术就是用于保障隔离性的。 一致性一致性：指的是事务开始之前和事务完结之后，数据库的完整性限度未被毁坏。一致性包含两方面的内容，别离是束缚一致性和数据一致性。 束缚一致性：创立表构造时所指定的外键、Check、惟一索引等束缚，惋惜在 MySQL 中不反对Check。数据一致性：是一个综合性的规定，因为它是由原子性、持久性、隔离性独特保障的后果，而不是单单依赖于某一种技术。一致性也能够了解为数据的完整性。数据的完整性是通过原子性、隔离性、持久性来保障的，而这3个个性又是通过 Redo/Undo 来保障的。(先写日志，再写磁盘)逻辑上的一致性，包含惟一索引、外键束缚、check 束缚，这属于业务逻辑领域。 事务管制的演进并发事务事务并发解决可能会带来一些问题，比方：更新失落、脏读、不可反复读、幻读等。 更新失落 当两个或多个事务更新同一行记录，会产生更新失落景象。能够分为回滚笼罩和提交笼罩。 回滚笼罩：一个事务回滚操作，把其余事务已提交的数据给笼罩了。 提交笼罩：一个事务提交操作，把其余事务已提交的数据给笼罩了。 脏读 一个事务读取到了另一个事务批改但未提交的数据。不可反复读 一个事务中屡次读取同一行记录不统一，前面读取的跟后面读取的不统一。幻读 一个事务中屡次按雷同条件查问，后果不统一。后续查问的后果和背后查问后果不同，多了或少了几行记录排队最简略的办法，就是齐全程序执行所有事务的数据库操作，不须要加锁，简略的说就是全局排队。序列化执行所有的事务单元，数据库某个时刻只解决一个事务操作，特点是强一致性，解决性能低。 排他锁引入锁之后就能够反对并发处理事务，如果事务之间波及到雷同的数据项时，会应用排他锁，或叫互斥锁，先进入的事务独占数据项当前，其余事务被阻塞，期待后面的事务开释锁。在整个事务1完结之前，锁是不会被开释的，所以，事务2必须等到事务1完结之后开始。 读写锁读和写操作：读读、写写、读写、写读。读写锁就是进一步细化锁的颗粒度，辨别读操作和写操作，让读和读之间不加锁，这样两个读事务就能够同时被执行了读写锁，能够让读和读并行，而读和写、写和读、写和写这几种之间还是要加排他锁。 MVCC多版本控制MVCC，也就是Copy on Write的思维。MVCC除了反对读和读并行，还反对读和写、写和读的并行，但为了保障一致性，写和写是无奈并行的 在事务1开始写操作的时候会copy一个记录的正本，其余事务读操作会读取这个记录正本，因而不会影响其余事务对此记录的读取，实现写和读并行。 MVCC概念MVCC（Multi Version Concurrency Control）被称为多版本控制，是指在数据库中为了实现高并发的数据拜访，对数据进行多版本解决，并通过事务的可见性来保障事务能看到本人应该看到的数据版本。多版本控制很奇妙地将稀缺资源的独占互斥转换为并发，大大提高了数据库的吞吐量及读写性能。 如何生成的多版本？每次事务批改操作之前，都会在Undo日志中记录批改之前的数据状态和事务号，该备份记录能够用于其余事务的读取，也能够进行必要时的数据回滚。 MVCC最大的益处是读不加锁，读写不抵触。在读多写少的零碎利用中，读写不抵触是十分重要的，极大的晋升零碎的并发性能，这也是为什么现阶段简直所有的关系型数据库都反对 MVCC 的起因，不过目前MVCC只在 Read Commited 和 Repeatable Read 两种隔离级别下工作。 在 MVCC 并发管制中，读操作能够分为两类: 快照读（Snapshot Read）与以后读 （Current Read）。 ...

一张图让你彻底搞懂 MySQL 的锁机制“ 锁在 MySQL 中是十分重要的一部分，锁对 MySQL 的数据拜访并发有着无足轻重的影响。锁波及到的常识篇幅也很多，所以要啃完并消化到本人的肚子里，是须要静下心好好反反复复几遍地细细品味。本文是对锁的一个大略的整顿，一些相干深刻的细节，还是须要找到相干书籍来持续夯实。” 锁的意识1.1 锁的解释计算机协调多个过程或线程并发拜访某一资源的机制。 1.2 锁的重要性在数据库中，除传统计算资源（CPU、RAM、IO等）的争抢，数据也是一种供多用户共享的资源。 如何保证数据并发拜访的一致性，有效性，是所有数据库必须要解决的问题。 锁抵触也是影响数据库并发拜访性能的一个重要因素，因而锁对数据库尤其重要。 1.3 锁的毛病加锁是耗费资源的，锁的各种操作，包含取得锁、检测锁是否已解除、开释锁等 ，都会减少零碎的开销。 1.4 简略的例子现如今网购曾经特地广泛了，比方淘宝双十一流动，当天的人流量是千万及亿级别的，但商家的库存是无限的。 零碎为了保障商家的商品库存不产生超卖景象，会对商品的库存进行锁管制。当有用户正在下单某款商品最初一件时， 零碎会立马对该件商品进行锁定，避免其余用户也反复下单，直到领取动作实现才会开释（领取胜利则立刻减库存售罄，领取失败则立刻开释）。 锁的类型2.1 表锁品种 读锁（read lock），也叫共享锁（shared lock） 针对同一份数据，多个读操作能够同时进行而不会相互影响（select） 写锁（write lock），也叫排他锁（exclusive lock） 以后操作没实现之前，会阻塞其它读和写操作（update、insert、delete） 存储引擎默认锁MyISAM 特点 对整张表加锁开销小加锁快无死锁锁粒度大，产生锁抵触概率大，并发性低论断读锁会阻塞写操作，不会阻塞读操作写锁会阻塞读和写操作倡议MyISAM的读写锁调度是写优先，这也是MyISAM不适宜做写为主表的引擎，因为写锁当前，其它线程不能做任何操作，大量的更新使查问很难失去锁，从而造成永远阻塞。 2.2 行锁品种读锁（read lock），也叫共享锁（shared lock）容许一个事务去读一行，阻止其余事务取得雷同数据集的排他锁写锁（write lock），也叫排他锁（exclusive lock）容许取得排他锁的事务更新数据，阻止其余事务获得雷同数据集的共享锁和排他锁动向共享锁（IS）一个事务给一个数据行加共享锁时，必须先取得表的IS锁动向排它锁（IX）一个事务给一个数据行加排他锁时，必须先取得该表的IX锁 存储引擎默认锁InnoDB 特点 对一行数据加锁开销大加锁慢会呈现死锁锁粒度小，产生锁抵触概率最低，并发性高事务并发带来的问题更新失落 解决：让事务变成串行操作，而不是并发的操作，即对每个事务开始—-对读取记录加排他锁脏读 解决：隔离级别为Read uncommitted不可重读 解决：应用Next-Key Lock算法来防止幻读 解决：间隙锁（Gap Lock）2.3 页锁开销、加锁工夫和锁粒度介于表锁和行锁之间，会呈现死锁，并发解决能力个别（此锁不做多介绍） 如何上锁？3.1 表锁隐式上锁（默认，主动加锁主动开释）select //上读锁insert、update、delete //上写锁 显式上锁（手动）lock table tableName read;//读锁lock table tableName write;//写锁 解锁（手动）unlock tables;//所有锁表 session01 session02 lock table teacher read;// 上读锁 ...

01 前言事件是这样的，我负责我司的报表零碎，小胖是我小弟。某天他手贱误删了一条生产的数据。被用户在群里疯狂投诉质问，火急火燎的跑来问我怎么办。我特么冷汗都进去了，申斥了他一顿：蠢，蠢得都能够进博物馆了，生产的数据能轻易动？ 小胖看我平时笑嘻嘻的，没想到发这么大的火。心一急，竟然给我跪下了：远哥，我上有老，下有小，中有女朋友，不要开革我呀。我一听火更大了：合着就你有女朋友？？？这个时候咱们 DBA 老林来打圆场：别慌，年轻人管不住下自身，不免做错事。我能够把数据恢复到一个月内任意时刻的状态。听到这，小胖忙抱着老林大腿哭爹喊娘地感激。 听到这你是不是很奇怪？能复原到半个月前的数据？DBA 老林到底是如何做到的？我跟他细聊了一番。老林点燃了手中 82 年的华子，深深吸了一口说到：事件还得从 update 语句是如何执行的说起。 1.1 从更新语句说起假如我当初有建表语句，如下： CREATE TABLE `student` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL, `age` int(11) NULL DEFAULT NULL, PRIMARY KEY (`id`) USING BTREE) ENGINE = InnoDB AUTO_INCREMENT = 66 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;表数据如下： 明天恰好张三生日，我要把它的 age 加一岁。于是执行以下的 sql 语句： update student set age = age + 1 where id = 2;后面聊过查问语句是如何执行的？错过的同学看这篇《工作三年：小胖连 select 语句是如何执行的都不晓得，真的菜！》，外面的查问语句流程，更新语句也会走一遍，如下流程图： ...

mysql 作为一个关系型数据库，在国内应用应该是最宽泛的。兴许你司应用 Oracle、Pg 等等，然而大多数互联网公司，比方我司应用得最多的还是 Mysql，重要性显而易见。 事件是这样的，某天我司小胖问我执行select * from table，数据库底层到底产生了啥？从而咱们失去数据呢？以下把我给问住了，为此我查阅了大量的书籍、博客。于是就有了这篇文章。 假如当初我有张 user 表，只有两列，一列 id 自增的，一列 name 是 varchar 类型。建表语句是这样的： CREATE TABLE IF NOT EXISTS `user`( `id` INT UNSIGNED AUTO_INCREMENT, `name` VARCHAR(100) NOT NULL, PRIMARY KEY ( `id` ))ENGINE=InnoDB DEFAULT CHARSET=utf8;小胖的问题就是上面这个语句的执行过程。 select * from user where id = 1; 01 mysql 架构概览要想了解这个问题就必须要晓得 mysql 的外部架构。为此，我画了张 mysql 的架构图（你也能够了解为 sql 查问语句的执行过程），如下所示： 首先 msql 分为 server 层和存储引擎层两个局部。server 层包含四个功能模块，别离是：连接器、查问缓存、优化器、执行器。这一层负责了 mysql 的所有外围工作，比方：内置函数、存储过程、触发器以及视图等。 而存储引擎层则是负责数据的存取。留神，存储引擎在 mysql 是可选的，常见的还有：InnoDB、MyISAM 以及 Memory等，最罕用的就是 InnoDB。当初默认的存储引擎也是它（从 mysql 5.5.5 版本开始），大家能够看到我下面的建表语句就是指定了 InnoDB 引擎。当然，你不指定的话默认也是它。 ...

一、前置常识1、常见索引面试题▪ 数据库中最常见的慢查问优化形式是什么？▪ 为什么加索引能优化慢查问？▪ 你晓得哪些数据结构能够进步查问速度？▪ 那这些数据结构既然都能优化查问速度，Mysql为何抉择应用B+树？ 2、基础知识储备▪ 局部性原理▪ 磁盘预读(预读的长度个别为页（page）的整数倍)– 页是存储器的逻辑块，操作系统往往将主存和磁盘存储区宰割为间断的大小相等的块，每个存储块称为一页（在许多操作系统中，页大小通常为4k），主存和磁盘以页为单位替换数据。 3、mysql执行流程 二、索引1、索引是什么▪ 索引是帮忙 MySQL 高效获取数据的数据结构▪ 索引存储在文件系统中▪ 索引的文件存储模式与存储引擎无关 2、索引文件的构造hash哈希表能够实现索引的存储，每次在增加索引的时候须要计算指定列的hash值，取模运算后计算出下标，将元素插入下标地位即可适宜的场景： 等值查问表中的数据是无序数据(返回查找的时候比拟浪费时间，须要挨个进行遍历操作) 返回查找不适合 hash表在应用的时候，须要将全副数据加载到内存，比拟消耗内存的空间，也不是很适合 树在树的构造中，左子树必须小于双亲节点，右子树必须大于双亲节点，如果是多叉树，从左到右是有序的 树：多叉树->二叉树(二分查找)->AVL树(均衡树)->红黑树 AVL树：是一种严格意义上的均衡树，最高子树跟最低子树高度只差不能超过1，因而在进行元素插入的时候，会进行1到N此旋转，重大影响插入的性能红黑树：是基于AVL树的一个降级，损失了局部查问的性能，来晋升插入的性能，在红黑树中最低子树跟最高子树之差小于2倍即可，在插入的时候不须要进行N屡次的旋转操作，而且还退出了变色的个性，来满足插入和查问的性能的均衡 二叉树及其N多的变种，都不能撑持索引，要么是树的深度无法控制，要么是 B树 所有键值散布在整颗树种 搜寻有可能在非叶子节点完结，在关键字选集内做一次查找，性能迫近二分查找 每个节点最多领有m个子树 根节点至多有2个子树 分支节点至多领有m/2颗子树（除根节点和叶子节点外都是分支节点） 所有叶子节点都在同一层，每个节点最多能够有m-1个key，并且升序排列 毛病： 1、每个节点都有key，同时也蕴含data，而每个页存储空间是无限的，如果data比拟大的话会导致每个节点存储的key数量变小2、当存储的数据量很大的时候会导致树的深度较大，增大查问时磁盘的IO次数，进而影响查问性能B+树 B+树是在B树的根底之上做的一种优化，变动如下 (1)B+Tree每个节点能够蕴含更多的节点，这么做的起因有两个，第一个是为了升高树的高度，第二个是将数据范畴变为多个区间，区间越多，数据检索越快(2)非叶子节点存储key，叶子节点存储key和数据 (3)叶子节点两两指针相互连接（合乎磁盘的预读个性），程序查问性能更高 3、索引的分类▪ mysql索引的五种类型：主键索引、惟一索引、一般索引和全文索引、组合索引。通过给字段增加索引能够进步数据的读取速度，进步我的项目的并发能力和抗压能力。 主键索引– 主键是一种唯一性索引，但它必须指定为PRIMARY KEY，每个表只能有一个主键。 惟一索引– 索引列的所有值都只能呈现一次，即必须惟一，值能够为空，惟一索引不会回表。 一般索引– 根本的索引类型，值能够为空，没有唯一性的限度。（笼罩索引） 全文索引,MyISAM反对，Innodb在5.6之后反对– 全文索引的索引类型为FULLTEXT。全文索引能够在varchar、char、text类型的列上创立 组合索引– 多列值组成一个索引，专门用于组合搜寻（最左匹配准则） 4、Mysql存储引擎不同的存储引擎，数据文件和索引文件寄存的地位是不同的，因而有了分类： 聚簇索引：数据和文件放在一起：InnoDB .frm:寄存的是表构造.ibd:寄存的是数据文件和索引文件留神：mysql的InnoDB存储引擎默认状况下会把所有的数据文件放到表空间中，不会为每一个独自的表保留一份数据文件，如果须要每一个表独自应用文件保留，设置如下属性：set global innodb_file_per_table=on;非聚簇索引：数据和文件分凋谢：MyISAM .frm:寄存表构造.MYI:寄存索引数据.MYD:寄存理论数据5、mysql索引机制 6、索引难点回表1、InnoDB是通过B+树结构对主键创立索引，而后叶子节点种存储记录，如果没有主键，那么会抉择惟一键，如果没有惟一键，那么会生成一个暗藏的6位的row_id来作为主键2、如果创立索引的列是其余字段，那么在叶子节点中存储的是该记录的主键，而后再通过主键找到对应的记录，叫做回表3、MyISAM:不存在回表问题，起因是MySIAM存储引擎，索引文件和数据文件是离开寄存的，在B+树的叶子节点存储的是数据行所在的磁盘地址，一般索引也是如此，所以不存在回表问题笼罩索引1、针对InnoDB,笼罩索引是指，如果查问的时候用到的是一般索引，而查问的列正好是主键id，那么在一般索引的B+树中叶子节点存储的正好就是主键id，间接返回即可，便不须要再去主键索引的B+树中遍历最左前缀1、最左前缀，是指应用组合索引的时候，必须从左到右顺次匹配索引列索引下推参考https://zhuanlan.zhihu.com/p/121084592

苏三说技术 「苏三说技术」 维护者目前就任于某出名互联网公司，从事开发、架构和局部管理工作。实战经验丰盛，对jdk、spring、springboot、springcloud、mybatis等开源框架源码有肯定钻研，欢送关注，和我一起交换。 29篇原创内容 公众号 前言 ===== 无论是开发、测试，还是DBA，都难免会波及到数据库的操作，比方：创立某张表，增加某个字段、增加数据、更新数据、删除数据、查问数据等等。 失常状况下还好，但如果操作数据库时呈现失误，比方： 删除订单数据时where条件写错了，导致多删了很多用户订单。更新会员无效工夫时，一次性把所有会员的无效工夫都更新了。修复线上数据时，改错了，想还原。还有很多很多场景，我就不一一列举了。 如果呈现线上环境数据库误操作怎么办？有没有后悔药？ 答案是有的，请各位看官认真往下看。 1.不要用聊天工具发sql语句通常开发人员写好sql语句之后，习惯通过聊天工具，比方：qq、钉钉、或者腾讯通等，发给团队老大或者DBA在线上环境执行。但因为有些聊天工具，对局部特殊字符会主动本义，而且有些音讯因为内容太长，会被主动分成多条音讯。 这样会导致团队老大或者DBA复制进去的sql不肯定是正确的。 他们须要手动拼接成一条残缺的sql，有时甚至须要把本义后的字符替换回以前的特殊字符，无形之中会节约很多额定的工夫。即便最终sql拼接好了，真正执行sql的人，心里肯定很虚。 所以，强烈建议你把要在线上执行的sql语句用邮件发过来，能够防止应用聊天工具的一些弊病，缩小一些误操作的机会。而且有个存档，不便今后有问题的时候回溯起因。很多聊天工具只保留最近7天的历史记录，邮件会保留更久一些。 别用聊天工具发sql语句！ 别用聊天工具发sql语句！ 别用聊天工具发sql语句！ 重要的事件说三遍，它真的能缩小一些误操作。 2.把sql语句压缩成一行有些时候，开发人员写的sql语句很长，应用了各种join和union，而且应用丑化工具，将一条sql变成了多行。在复制sql的时候，本人都无奈确定sql是否残缺。（为了装逼，把本人也坑了，哈哈哈） 线上环境有时候须要通过命令行连贯数据库，比方：mysql，你把sql语句复制过去后，在命令行界面执行，因为屏幕滚动太快，这时根本无法确定sql是否都执行胜利。 针对这类问题，强烈建议把sql语句压缩成一行，去掉多余的换行符和空格，能够无效的缩小一些误操作。 sql压缩工具举荐应用：https://tool.lu/sql/ 3.操作数据之前先select一下须要特地阐明的是：本文的操作数据次要指批改和删除数据。 很多时候，因为咱们人为失误，把where条件写错了。但没有怎么仔细检查，就把sql语句间接执行了。影响范畴小还好，如果影响几万、几十万，甚至几百万行数据，咱们可能要哭了。 针对这种状况，在操作数据之前，把sql先改成select count(*)语句，比方： update order set status=1 where status=0;改成： select count(*) from order where status=0;查一下该sql执行后影响的记录行数，做到本人成竹在胸。也给本人一次测试sql是否正确，确认是否执行的机会。 4.操作数据sql加limit即便通过下面的select语句确认了sql语句没有问题，执行后影响的记录行数是对的。 也倡议你不要立即执行，倡议在正在执行的时候，加上limit + select出的记录行数。例如： update order set status=1 where status=0 limit 1000;假如有一次性更新的数据太多，所有相干记录行都会被锁住，造成长时间的锁期待，而造成用户申请超时。 此外，加limit能够防止一次性操作太多数据，对服务器的cpu造成影响。 还有一个最重要的起因：加limit后，操作数据的影响范畴是齐全可控的。 5.update时更新批改人和批改工夫很多人写update语句时，如果要批改状态，就只更新状态，不论其余的字段。比方： update order set status=1 where status=0;这条sql会把status等于0的数据，全副更新成1。 起初发现业务逻辑有问题，不应该这么更新，须要把status状态回滚。 这时你可能会很天然想到这条sql： update order set status=0 where status=1;但认真想想又有些不对。 这样不是会把有局部以前status就是1的数据更新成0？ 这回真的要哭了，呜呜呜。 这时，送你一个好习惯：在更新数据的时候，同时更新批改人和批改工夫字段。 update order set status=1,edit_date=now(),edit_user='admin' where status=0;这样在复原数据时就能通过批改人和批改工夫字段过滤数据了。前面须要用到的批改工夫通过这条sql语句能够轻松找到： ...

mysql 聚簇索引 和聚簇索引 （二级索引）的 那些事 mysql的聚簇索引是指innodb引擎的个性，mysiam并没有，如果须要该索引，只有将索引指定为主键（primary key）就能够了。 比方： create table blog_user( user_Name char(15) not null check(user_Name !=''), user_Password char(15) not null, user_emial varchar(20) not null unique, primary key(user_Name) )engine=innodb default charset=utf8 auto_increment=1; 其中的 primary key(user_Name) 这个就是聚簇索引索引了； 聚簇索引的叶节点就是数据节点，而非聚簇索引的叶节点依然是索引节点，并保留一个链接指向对应数据块。 聚簇索引主键的插入速度要比非聚簇索引主键的插入速度慢很多。相比之下，聚簇索引适宜排序，非聚簇索引（也叫二级索引）不适宜用在排序的场合。 因为聚簇索引自身曾经是依照物理程序搁置的，排序很快。非聚簇索引则没有按序寄存，须要额定耗费资源来排序。 当你须要取出肯定范畴内的数据时，用聚簇索引也比用非聚簇索引好。 另外，二级索引须要两次索引查找，而不是一次能力取到数据，因为存储引擎第一次须要通过二级索引找到索引的叶子节点，从而找到数据的主键，而后在聚簇索引中用主键再次查找索引，再找到数据。 innodb索引分类： 聚簇索引(clustered index) 1) 有主键时，依据主键创立聚簇索引 2) 没有主键时，会用一个惟一且不为空的索引列做为主键，成为此表的聚簇索引 3) 如果以上两个都不满足那innodb本人创立一个虚构的汇集索引 辅助索引(secondary index) 非聚簇索引都是辅助索引，像复合索引、前缀索引、惟一索引 myisam索引：因为myisam的索引和数据是离开存储存储的，myisam通过key_buffer把索引先缓存到内存中，当须要拜访数据时（通过索引拜访数据），在内存中间接搜寻 索引，而后通过索引找到磁盘相应数据，这也就是为什么索引不在key buffer命中时，速度慢的起因 innodb索引：innodb的数据和索引放在一起，当找到索引也就找到了数据 自适应哈希索引：innodb会监控表上的索引应用状况，如果察看到建设哈希索引能够带来速度的晋升，那就建设哈希索引，自 适应哈希索引通过缓冲池的B+树结构而来， 因而建设的速度很快，不须要将整个表都建哈希索引，InnoDB 存储引擎会主动依据拜访的频率和模式来为某些页建设哈希索引。自适应哈希索引不须要 存储磁盘的，当停库内容会失落，数据库起来会本人创立，缓缓保护索引。 聚簇索引： MySQL InnoDB肯定会建设聚簇索引，把理论数据行和相干的键值保留在一块，这也决定了一个表只能有一个聚簇索引，即MySQL不会一次把数据行保留在二个中央。 1) InnoDB通常依据主键值(primary key)进行聚簇 2) 如果没有创立主键，则会用一个惟一且不为空的索引列做为主键，成为此表的聚簇索引 3) 下面二个条件都不满足，InnoDB会本人创立一个虚构的汇集索引 ...

数据库索引原理及优化一、摘要本文以MySQL数据库为钻研对象，探讨与数据库索引相干的一些话题。特地须要阐明的是，MySQL反对诸多存储引擎，而各种存储引擎对索引的反对也各不相同，因而MySQL数据库反对多种索引类型，如BTree索引，哈希索引，全文索引等等。为了防止凌乱，本文将只关注于BTree索引，因为这是平时应用MySQL时次要打交道的索引，至于哈希索引和全文索引本文暂不探讨。 二、常见的查问算法及数据结构为什么这里要讲查问算法和数据结构呢？因为之所以要建设索引，其实就是为了构建一种数据结构，能够在下面利用一种高效的查问算法，最终进步数据的查问速度。 2.1 索引的实质MySQL官网对索引的定义为：索引（Index）是帮忙MySQL高效获取数据的数据结构。提取句子骨干，就能够失去索引的实质：索引是数据结构。 2.2 常见的查问算法咱们晓得，数据库查问是数据库的最次要性能之一。咱们都心愿查问数据的速度能尽可能的快，因而数据库系统的设计者会从查问算法的角度进行优化。那么有哪些查问算法能够使查问速度变得更快呢？ 2.2.1 程序查找（linear search ）最根本的查问算法当然是程序查找（linear search），也就是比照每个元素的办法，不过这种算法在数据量很大时效率是极低的。 数据结构：有序或无序队列 复杂度：O(n) 实例代码： //程序查找int SequenceSearch(int a[], int value, int n){ int i; for(i=0; i<n; i++) if(a[i]==value) return i; return -1;}123456789 2.2.2 二分查找（binary search）比程序查找更快的查询方法应该就是二分查找了，二分查找的原理是查找过程从数组的两头元素开始，如果两头元素正好是要查找的元素，则搜素过程完结；如果某一特定元素大于或者小于两头元素，则在数组大于或小于两头元素的那一半中查找，而且跟开始一样从两头元素开始比拟。如果在某一步骤数组为空，则代表找不到。 数据结构：有序数组 复杂度：O(logn) 实例代码： //二分查找，递归版本int BinarySearch2(int a[], int value, int low, int high){ int mid = low+(high-low)/2; if(a[mid]==value) return mid; if(a[mid]>value) return BinarySearch2(a, value, low, mid-1); if(a[mid]<value) return BinarySearch2(a, value, mid+1, high);}1234567891011 2.2.3 二叉排序树查找二叉排序树的特点是： 若它的左子树不空，则左子树上所有结点的值均小于它的根结点的值；若它的右子树不空，则右子树上所有结点的值均大于它的根结点的值；它的左、右子树也别离为二叉排序树。搜寻的原理： 若b是空树，则搜寻失败，否则：若x等于b的根节点的数据域之值，则查找胜利；否则：若x小于b的根节点的数据域之值，则搜寻左子树；否则：查找右子树。数据结构：二叉排序树 工夫复杂度： O(log2N) ...

思考MySQL的一个国内镜像：http://mirrors.sohu.com/ 抉择相应的版本，我抉择的是.dmg，须要手动装置。 中途会提醒输出root用户的明码。 在零碎偏好设置中进入MySQL，点击启动。 将/usr/local/mysql/bin退出到环境变量中 留神本人shell的语言类型，zsh是不会在启动时执行~/.bash_profile的。针对zsh应该批改~/.zprofile和~/.zshrc。此时输出mysql -u root -p再输出明码即可登录MySQL了。 参考：https://blog.csdn.net/qq_4200...

什么是事务事务提供一种机制，能够将一个流动波及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能失常执行的状况下方能提交，只有其中任一操作执行失败，都将导致整个事务的回滚。简略地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）机制。如果A要给B转账1000元，这个转账会波及到两个要害操作就是：将A的余额缩小1000元，将B的余额减少1000元。事务就是保障这两个要害操作要么都胜利，要么都要失败。 ACID事务应该具备4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为ACID个性。原子性（Atomicity）：原子性是指单个事务自身波及到的数据库操作，要么全副胜利，要么全副失败，不存在实现事务中一部分操作的可能。以上文说的转账为例，就是要么操作全副胜利，A的钱少了，B的钱多了；要么就是全副失败，AB放弃和原来一样的数目。一致性（Consistency）：一致性就是事务执行前后的数据状态是稳固的。还是以转账为例，原来AB账户的钱加一起是1000，互相转账实现时候彼此还是1000，所以，对于转账就是金额稳固不变，对于其余的事务操作就是事务执行实现之后，数据库的状态是正确的，没有脏数据。隔离性（isolation）：一个事务的执行不能被其余事务烦扰。也就是说多个事务之间是没有相互影响的比方A给B转账和B给C转账这两个事务是没有影响的。持久性（durability）：持久性也称永久性（permanence），指一个事务一旦提交，它对数据库中数据的扭转就应该是永久性的。 事务的隔离级别在多个事务并发操作数据库（多线程、网络并发等）的时候，如果没有无效的防止机制，就会呈现脏读、不可反复读和幻读这3种问题。脏读（Dirty Read）脏读是指在一个事务处理过程里读取了另一个未提交的事务中的数据。不可反复读（Nonrepeatable Read）不可反复读是指在对于数据库中的某个数据，一个事务范畴内屡次查问却返回了不同的数据值，这是因为在查问距离，被另一个事务批改并提交了。幻读（Phantom Read）一个事务内前后屡次读取，数据总量不统一。不可反复读和幻读有些类似，两者的区别在于：不可反复读的重点在于批改，同样的条件, 你读取过的数据,再次读取进去发现值不一样了；而幻读的重点在于新增或者删除对幻读的定义，记录的缩小也应该算是幻读），同样的条件, 第 1 次和第 2 次读出来的记录数不一样。 隔离级别读未提交（Read Uncommitted）：一个事务能够读取到另一个事务未提交的批改。这种隔离级别是最弱的，可能会产生脏读，幻读，不可反复读的问题问题。 读已提交（Read Committed）：一个事务只能读取另一个事务曾经提交的批改。其防止了脏读，依然存在不能够反复读和幻读的问题。SQL Server和Oracle的默认隔离级别就是这个。 可反复读（Repeated Read）：同一个事务中屡次读取雷同的数据返回的后果是一样的。其防止了脏读和不可反复读问题，然而幻读仍然存在。MySQL中的默认隔离级别就是这个，不过MySQL通过多版本并发管制（MVCC）、Next-key Lock等技术解决了幻读问题。 串行化（Serializable）：这是数据库最高的隔离级别，这种级别下，事务“串行化程序执行”，也就是一个一个排队执行。在这种级别下，脏读、不可反复读、幻读都能够被防止，然而执行效率奇差，性能开销也最大。 MySQL是如何解决幻读可反复读的隔离级别没有方法彻底的解决幻读的问题，如果须要解决幻读的话也有两个方法：1.应用串行化读的隔离级别2.MVCC+next-key locks：next-key locks由record locks(索引加锁) 和 gap locks(间隙锁，每次锁住的不光是须要应用的数据，还会锁住这些数据左近的数据) 快照读当执行select操作是innodb默认会执行快照读，会记录下这次select后的后果，之后select 的时候就会返回这次快照的数据，即便其余事务提交了不会影响以后select的数据，这就实现了可反复读了。 以后读对于会对数据批改的操作(update、insert、delete)都是采纳以后读的模式。在执行这几个操作时会读取最新的记录，即便是别的事务提交的数据也能够查问到。假如要update一条记录，然而在另一个事务中曾经delete掉这条数据并且commit了，如果update就会产生抵触，所以在update的时候须要晓得最新的数据。 MVCC仅能解决快照读状况下，也就是select查问的时候的幻读问题。对于以后读状况下，也就是update、insert、delete等操作时产生幻读问题MVCC无奈解决，须要应用临键锁也就是next-key locks解决

老大：来，你搞一搞分布式事务吧我：......,啥是事务？ 我：先从实践学起吧 我不懂什么是事务如果事务都不懂，就更不用说分布式事务了，于是我马上开始学习了。 事务是应用程序中一系列紧密的操作，所有操作必须胜利实现，否则在每个操作中所作的所有更改都会被吊销。 事务应该具备 4 个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为 ACID 个性。 换成比拟容易了解的话就是，就是一组操作比方增删改查四个操作要么都胜利，要么都失败，不存后果不统一的状态。 我不懂什么是分布式事务终于弄明确什么是事务了，又来了分布式事务。为什么须要分布式事务呢？ 事务更多指的是单机版、单数据库的概念。分布式事务 指事务的参与者、反对事务的服务器、资源服务器以及事务管理器别离位于不同的分布式系统的不同节点之上 。 换成比拟容易了解的话，就是多个事务之间再放弃事务的个性，也就是多个事务之间保障后果的一致性。 XA标准有了分布式事务的场景，就会有解决该问题的形式标准，XA标准就是解决分布式事务的标准，具体形容见维基百科解释： XA标准提供了一种重要思维: 1、引入全局事务的管制节点，事务的协调者2、多个本地事务划分多阶段提交（也就是上面讲的2PC，3PC） 我不懂分布式计划有了标准就会有落地计划，上面介绍基于XA标准的几个实现协定。 首先介绍两阶段提交( Two-phase Commit )和三阶段提交( Three-phase Commit ) 2PC( Two-phase Commit ) 两阶段提交，顾名思义就是要分两步提交。 这里第一阶段称为筹备或者投票阶段。引入一个负责协调各个本地资源管理器的事务管理器， 本地资源管理器个别是由数据库实现，事务管理器在第一阶段的时候询问各个资源管理器是否都就绪，并执行完除提交事务外所有事件，而后把后果返回给事务协调者。 如果收到每个资源的回复都是 胜利，则在第二阶段提交事务，如果其中任意一个资源的回复是 失败, 则回滚事务。 这里的实现形式和咱们平时开黑玩游戏时差不多，当咱们组队时，队长会让大家筹备，让队员上完厕所吃饱饭，如果所有队员都筹备好，那就开始游戏，如果有任一一个队员没有吃饱，没有确认筹备好，就不会开始游戏。然而这种协定也会存在一些问题，如下： 同步阻塞，这是2PC最大的问题， 严格的2PC执行过程中，所有参加节点都是事务阻塞型的。当参与者占有公共资源时，其余第三方节点拜访公共资源不得不处于阻塞状态 解决方案：引入引入超时机制，如果长时间没有收到响应，执行特定的动作。协调者单点故障，协调者在2PC中是最重要的角色，同时也意味着如果他出问题，整个过程就GG了 解决方案：单点故障的惯例计划就引入正本而后当主节点挂掉后，从新选主，就像组队游戏中，如果队员都筹备好后，队长长时间蹲厕所不开始游戏，游戏程序个别就会踢掉队长，其余组员切换成队长身份。数据不统一，尽管解决了下面几个问题，然而因为分布式系统存在很多网络抖动和调用失败场景还是会有数据不统一的状况，上面分为协调者、参与者、网络等故障来详细分析一下： 1、协调者发送筹备命令前挂掉 这种相当于事务间接没有开始，没有啥太大影响2、协调者发送筹备命令后挂掉 这种状况，如果参与者没有超时机制，就会造成资源锁定3、协调者发送提交命令前挂掉 这种状况和上一种状况相似，也会造成资源锁定4、协调者发送提交命令后挂掉 这种状况很可能是可能胜利执行分布式事务的，因为曾经到了提交阶段阐明其余参与者都曾经筹备好，如果失败就一直重试5、协调者发送回滚命令前挂掉 这种状况和2、3是相似的，因为参与者收不到执行操作的命令，如果没有超时会始终阻塞并占据着资源6、协调者发送回滚命令后挂掉 这种状况和4差不多，也是很大概率是可能胜利执行回滚事务的，如果没有胜利，因为曾经造成了决定，所以只能一直重试7、协调者发送筹备命令后，局部参与者挂掉 这种状况协调者有超时机制，间接断定成失败，而后告诉所有参与者回滚8、协调者发送筹备命令后挂掉，且局部参与者挂掉 这种状况从新选举协调者后，发现还在第一阶段，因为没有收到挂掉参与者的响应，所以断定失败，告诉其余参与者执行回滚9、协调者发送提交或回滚命令后挂掉，且收到音讯的参与者挂掉 这种状况从新选举协调者后，没有收到音讯的参与者没有执行事务，然而协调者无奈确定收到音讯的参与者执行第二阶段的提交或回滚到底是否胜利，就会呈现事务不统一的状况3PC( Three-phase Commit )从下面介绍的相干内容也能够大体晓得2PC的毛病和解决形式，于是就有了上面的解决协定，三阶段提交 从百科能够看到3PC的引入次要就是为了解决下面咱们说的2PC的毛病，咋就能解决呢？ 1、3PC是非阻塞协定 好的，就是为了解决了资源占用问题，次要也就是引入了参与者超时机制2、 第一阶段与第二阶段之间插入了一个筹备阶段 解决了在两阶段提交中，参与者在投票之后，因为协调者产生解体或谬误，而导致参与者处于无奈通晓是否提交或者回滚的“不确定状态”，也就是为了保障最初提交阶段之前所有参加节点状态统一 3PC 把2PC第一阶段再次拆分为2个阶段，多了一个阶段其实就是在执行事务之前来确认参与者是否失常，避免个别参与者不失常的状况下，其余参与者都执行了事务锁定资源。 他的大略步骤其实能够依照参与者4个状态来划分 0、初始状态，此阶段事务发起者触发全局事务，参与者切换本地状态为开始状态，并把本人注册到协调者中。 1、可提交或状态期待，此阶段协调者发送命令到每个注册过去的参与者，让他们更改状态为可提交状态。 2、预提交状态，此阶段协调者收到参与者确认能够提交并进入状态，而后协调者向他们发送预提交音讯，参与者锁定资源，并更改状态为预提交状态。同时 协调者也进入预提交状态。 ...

问题随着 MySQL 应用的内存越来越大，咱们倡议应用多个 buffer pool instance。 那么咱们的问题是: 一张表有多少在 buffer pool 中，一张表只能在一个 buffer pool instance 中么？ 试验这期的试验很短很简略， 先宽油起一个数据库： 接下来，咱们建一个有数据的表，建表的办法参考试验 11： 重复执行 insert，让表里有更多数据： 咱们查问一下 buffer pool 的散布： 这里会输入 196 行，咱们将后果手工简化一下来剖析（如果是 MySQL 8.0，能够用窗口函数来间接剖析，此处偷个懒，手工简化一下）： 咱们能够看到其中的法则： 咱们这张表的各个数据页，交替呈现在两个 buffer pool instance中（POOL_ID 为 0 和 1，以下简称 POOL）；3-35 页呈现在 POOL 1 中，36-63 空缺；其后，每 64 页更换一个 POOL，两个 POOL 交替呈现。来整顿一下思路： 为什么 buffer pool 须要应用多个 POOL? 拜访 buffer pool 时须要上锁，只是用一个 POOL，锁抵触比较严重。应用多个 POOL，能够分担锁的抵触压力。 一张表的各个页为什么交替呈现在各个 POOL 中？ ...

Thresh慢查问定位开启慢查问日志查看 MySQL 数据库是否开启了慢查问日志和慢查问日志文件的存储地位的命令如下： SHOW VARIABLES LIKE 'slow_query_log%'通过如下命令开启慢查问日志： SET global slow_query_log = ON; SET global slow_query_log_file = 'OAK-slow.log'; SET global log_queries_not_using_indexes = ON; SET long_query_time = 10;(long_query_time：指定慢查问的阀值，单位秒。如果SQL执行工夫超过阀值，就属于慢查问记录到日志文件中。)(log_queries_not_using_indexes：示意会记录没有应用索引的查问SQL。前提是slow_query_log的值为ON，否则不会见效)查看慢查问日志文本形式查看间接应用文本编辑器关上slow.log日志即可。 time：日志记录的工夫User@Host：执行的用户及主机Query_time：执行的工夫Lock_time：锁表工夫Rows_sent：发送给申请方的记录数，后果数量Rows_examined：语句扫描的记录条数SET timestamp：语句执行的工夫点select....：执行的具体的SQL语句应用mysqldumpslow查看 MySQL 提供了一个慢查问日志剖析工具mysqldumpslow，能够通过该工具剖析慢查问日志内容。 在 MySQL bin目录下执行上面命令能够查看该应用格局。 Usage: mysqldumpslow [ OPTS... ] [ LOGS... ] -- 后跟参数以及log文件的相对地址; -s what to sort by (al, at, ar, c, l, r, t), 'at' is default al: average lock time ar: average rows sent at: average query time c: count l: lock time r: rows sent t: query time -r reverse the sort order (largest last instead of first) -t NUM just show the top n queries -a don't abstract all numbers to N and strings to 'S' -n NUM abstract numbers with at least n digits within names -g PATTERN grep: only consider stmts that include this string -h HOSTNAME hostname of db server for *-slow.log filename (can be wildcard), default is '*', i.e. match all -i NAME name of server instance (if using mysql.server startup script) -l don't subtract lock time from total time例子: ...

ThreshEXPLAINMySQL 提供了一个 EXPLAIN 命令，它能够对 SELECT 语句进行剖析，并输入 SELECT 执行的详细信息，供开发人员有针对性的优化。 EXPLAIN SELECT * from USERS where id >1 ; select_type示意查问的类型。罕用的值如下： SIMPLE ： 示意查问语句不蕴含子查问或unionPRIMARY：示意此查问是最外层的查问UNION：示意此查问是UNION的第二个或后续的查问EXPLAIN SELECT * from user WHERE id < 3;DEPENDENT UNION：UNION中的第二个或后续的查问语句，应用了里面查问后果UNION RESULT：UNION的后果SUBQUERY：SELECT子查问语句DEPENDENT SUBQUERY：SELECT子查问语句依赖外层查问的后果。type示意存储引擎查问数据时采纳的形式。比拟重要的一个属性，通过它能够判断出查问是全表扫描还是基于索引的局部扫描。罕用属性值如下，从上至下效率顺次加强。 ALL：示意全表扫描，性能最差。index：示意基于索引的全表扫描，先扫描索引再扫描全表数据。range：示意应用索引范畴查问。应用>、>=、<、<=、in等等。ref：示意应用非惟一索引进行单值查问。eq_ref：个别状况下呈现在多表join查问，示意后面表的每一个记录，都只能匹配前面表的一行后果。const：示意应用主键或惟一索引做等值查问，常量查问。NULL：示意不必拜访表，速度最快possible_keys示意查问时可能应用到的索引。留神并不一定会真正应用，显示的是索引名称。 key示意查问时真正应用到的索引，显示的是索引名称。 rowsMySQL查问优化器会依据统计信息，估算SQL要查问到后果须要扫描多少行记录。原则上rows是越少效率越高，能够直观的理解到SQL效率高下。 key_len示意查问应用了索引的字节数量。能够判断是否全副应用了组合索引。key_len的计算规定如下： 字符串类型 字符串长度跟字符集无关：latin1=1、gbk=2、utf8=3、utf8mb4=4 char(n)：n*字符集长度 varchar(n)：n * 字符集长度 + 2字节 数值类型 TINYINT：1个字节 SMALLINT：2个字节 MEDIUMINT：3个字节 INT、FLOAT：4个字节 BIGINT、DOUBLE：8个字节 工夫类型 DATE：3个字节 TIMESTAMP：4个字节 DATETIME：8个字节 字段属性 NULL属性占用1个字节，如果一个字段设置了NOT NULL，则没有此项ExtraExtra示意很多额定的信息，各种操作会在Extra提醒相干信息，常见几种如下： Using where 示意查问须要通过索引回表查问数据。Using index 示意查问须要通过索引，索引就能够满足所需数据。Using filesort 示意查问进去的后果须要额定排序，数据量小在内存，大的话在磁盘，因而有Using filesort倡议优化。Using temprorary 查问应用到了长期表，个别呈现于去重、分组等操作。回表查问InnoDB索引有聚簇索引(主键索引)和辅助索引。聚簇索引的叶子节点存储行记录，InnoDB必须要有，且只有一个。辅助索引的叶子节点存储的是主键值和索引字段值，通过辅助索引无奈间接定位行记录，通常状况下，须要扫码两遍索引树。先通过辅助索引定位主键值，而后再通过聚簇索引定位行记录，这就叫做回表查问，它的性能比扫一遍索引树低。 总结：通过索引查问主键值，而后再去聚簇索引查问记录信息 笼罩索引即explain的输入后果Extra字段为Using index时，可能触发索引笼罩。 ...

咱们晓得MySql数据是存在磁盘的，也从上一篇文章晓得他是怎么读取磁盘文件的数据。那咱们通过select查问数据的时候，就会从磁盘读到MySql，而后返回给客户端。咱们能够试想一下，假如有个热数据，咱们每秒须要查10次，依照下面的流程，就要查10次磁盘，只管有索引的存在，那效率也是很低的，所以MySql有一个缓冲池Buffer Pool，把每次查问的数据寄存在Buffer Pool里，前面如果再查这个数据，就间接从Buffer Pool里取，就防止了每次从磁盘查找，性能就有了很大的晋升。在磁盘中，咱们每次查问的时候，会定位到数据页，而后二分查找某一行，在Buffer Pool中，他也是相似的，所以咱们查找到某一条数据的时候，他就会把这个数据所在的数据页加载到Buffer Pool。把数据页的信息加载到Buffer Pool时，咱们称之为缓存页，他也是16kb，另外每个缓存页还对应着形容数据，这些形容数据包含缓存页的信息（比方地址）、数据页的信息等。咱们假如Buffer Pool的大小是160kb，那他就有10个缓存页和10个形容数据，所以Buffer Pool理论大小会超过160kb。当从磁盘读取一个数据页的时候，咱们须要晓得把他放在哪个缓存页里，也须要晓得缓存页的地址，这些信息是存在形容数据里的，所以MySql保护了一个双向链表数据结构的free链表，当还没有加载数据页的时候，他的构造是这样的（这里形容数据就画了6个，以及疏忽了形容数据到缓存页的指向）：当咱们加载一个数据页的时候，会先从free链表判断是否还有形容数据，如果有，阐明缓存页还没有满，那就把数据页的信息加载到缓存页中。同时把这个形容信息从free链表中移除，而后退出到双向链表数据结构的LRU链表。LRU链表就是会把最新拜访的挪动到头部去。如果没有，阐明缓存页都有数据了。下面的LRU链表作用就在这里体现了，既然缓存页都满了，那必定会淘汰已有的缓存页给新的缓存页，LRU链表就是把链表最初面的，也就是起码拜访的形容数据对应的缓存页的数据刷入磁盘，而后把这个缓存页给新的数据页。

Thresh索引是物理数据页存储，在数据文件中（InnoDB，ibd文件），利用数据页(page)存储。索引能够放慢检索速度，然而同时也会升高增删改操作速度，索引保护须要代价。索引波及的理论知识：二分查找法、Hash和B+Tree。 二分查找法二分查找法也叫作折半查找法，它是在有序数组中查找指定数据的搜索算法。 长处是等值查问、范畴查问性能优良毛病是更新数据、新增数据、删除数据保护老本高。首先定位left和right两个指针计算(left+right)/2判断除2后索引地位值与目标值的大小比对索引地位值大于目标值就-1，right挪动；如果小于目标值就+1，left挪动 public static int binarySearch(int key, int... array) { int low = 0; int high = array.length - 1; while (low <= high) { int mid = low + (high - low) / 2; if (key < array[mid]) { high = mid - 1; } else if (key > array[mid]) { low = mid + 1; } else { return mid; } } return -1; }Hash构造Hash底层实现是由Hash表来实现的，是依据键值 <key,value> 存储数据的构造。非常适合依据key查找value值，也就是单个key查问，或者说等值查问。 ...