Mysql

今天来系统地学习一下MySQL，主要有以下知识点： InnoDB引擎索引锁MyISAM和InnoDB区别MyISAM是MySQL的默认数据库引擎（5.5版之前）。虽然性能极佳，而且提供了大量的特性，包括全文索引、压缩、空间函数等，但MyISAM不支持事务和行级锁，而且最大的缺陷就是崩溃后无法安全恢复。不过，5.5版本之后，MySQL引入了InnoDB（事务性数据库引擎），MySQL 5.5版本后默认的存储引擎为InnoDB。 两者的对比： 是否支持行级锁: MyISAM 只有表级锁(table-level locking)，而InnoDB 支持行级锁(row-level locking)和表级锁,默认为行级锁。是否支持事务和崩溃后的安全恢复： MyISAM强调的是性能，每次查询具有原子性,其执行速度比InnoDB类型更快，但是不提供事务支持。但是InnoDB提供事务支持事务，外部键等高级数据库功能。 具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表。是否支持外键：MyISAM不支持，而InnoDB支持。是否支持MVCC：仅 InnoDB 支持。应对高并发事务, MVCC比单纯的加锁更高效;MVCC只在READ COMMITTED和REPEATABLE READ两个隔离级别下工作;MVCC可以使用 乐观(optimistic)锁 和 悲观(pessimistic)锁来实现;各数据库中MVCC实现并不统一。索引基础知识Mysql的基本存储结构是页(记录都存在页里边) 各个数据页可以组成一个双向链表而每个数据页中的记录又可以组成一个单向链表 每个数据页都会为存储在它里边儿的记录生成一个页目录，在通过主键查找某条记录的时候可以在页目录中使用二分法快速定位到对应的槽，然后再遍历该槽对应分组中的记录即可快速找到指定的记录 以其他列(非主键)作为搜索条件：只能从最小记录开始依次遍历单链表中的每条记录。所以说，如果我们写 select * from use where username='wugui' 这样没有进行任何优化的sql语句，默认会这样做： 定位到记录所在的页需要遍历双向链表，找到所在的页从所在的页内中查找相应的记录由于不是根据主键查询，只能遍历所在页的单链表了。很明显，在数据量很大的情况下这样查找会很慢！ 原理索引底层结构就是B+树，B+树是为磁盘或其它直接存储辅助设备设计的一种平衡二叉树。 那么索引是如何加快检索速度的呢？ 总结非叶子结点不保存数据，只用来索引，所有数据都保存在叶子节点。 所有的数据都在叶子节点，各叶子结点形成了一个有序的双向链表。为什么要有序呢？其实是为了范围查询。比如说 select * from Table where id > 1 and id < 100; 当找到1后，只需顺着节点和指针顺序遍历就可以一次性访问到所有数据节点，极大提到了区间查询效率。 一般情况下，数据库的B+树的高度一般在2~4层，这就是说找到某一键值的行记录最多需要2到4次磁盘IO，相当于0.02到0.04s。哈希索引除了B+树之外，还有一种常见的是哈希索引。 哈希索引就是采用一定的哈希算法，把键值换算成新的哈希值，检索时不需要类似B+树那样从根节点到叶子节点逐级查找，只需一次哈希算法即可立刻定位到相应的位置，速度非常快。 哈希索引有好几个局限(根据他本质的原理可得)： 哈希索引也没办法利用索引完成排序不支持最左匹配原则在有大量重复键值情况下，哈希索引的效率也是极低的---->哈希碰撞问题。不支持范围查询聚集和非聚集索引简单概括聚集索引就是以主键创建的索引非聚集索引就是以非主键创建的索引区别聚集索引在叶子节点存储的是表中的数据非聚集索引在叶子节点存储的是主键和索引列使用非聚集索引查询出数据时，拿到叶子上的主键再去查到想要查找的数据非聚集索引在建立的时候也未必是单列的，可以多个列来创建索引。 覆盖索引在创建多列索引中也涉及到了一种特殊的索引-->覆盖索引 我们前面知道了，如果不是聚集索引，叶子节点存储的是主键+列值最终还是要“回表”，也就是要通过主键再查找一次。这样就会比较慢覆盖索引就是把要查询出的列和索引是对应的，不做回表操作！ 比如说：现在我创建了索引 (username,age)，在查询数据的时候： select username,age from user where username = 'wugui' and age = 20。 ...

今天打开网站后台，发现报错，并提示：“MySQL server PID file could not be found”与“too much connection"错误，并且登录不上去，使用shell也报同样的错误，于是进行问题调研，调研过程如下： 1.试着重启mysql 2.发现无法重启 3.试着给放pid文件的文件夹附写权限，重启，同样失败 4.查看硬盘使用，发现硬盘空间被占用完 5.使用mysql -u name -p 进入数据库后台，使用"reset masters;“清空数据库日志（几十个G大小。。。。） 6.修改/etc/my.cnf文件， 找到 log-bin=mysql-bin binlog_format=mixed ...

事务初学的时候，感觉事务的四大特性就那么回事，不就是一堆事要么完成，要么全部失败吗。还有经常说的脏读，幻读，不可重复读根本无法理解，就是那个存款取款的例子，我修改了数据，对方看到我修改的数据，这不很正常吗。现在看来，当时根本就不知道并发是什么鬼，更何谈并发事物了。 然后给你来一堆名词，共享锁，排它锁，悲观锁，乐观锁...... 想想就觉得那时候能记下来已经是奇迹了。 Spring 还给事务弄了一个传播机制的家伙，Spring 事务传播机制可以看这篇文章 。 本文应该来说是对初学者的福音，有一定经验的人看的话应该也会有收获。 事务的四大特性ACID这个是刚入门面试的时候必问一个面试题，刚入行的时候我是硬生生背下来的。 原子性(Atomicity) 一件事情的所有步骤要么全部成功，要么全部失败，不存在中间状态。一致性(Consistency) 事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。隔离性(Isolation) 两个事务之间是隔离程度，具体的隔离程度由隔离级别决定，隔离级别有 读未提交的 (read-uncommitted)读提交的 (read-committed)可重复读 (repeatable-read)串行 (serializable)持久性 (Durability) 一个事务提交后，数据库状态就永远的发生改变，不会因为数据库宕机而让提交不生效。一个事务和并发事务事务指的是从开始事务->执行操作->提交/回滚 整个过程，在程序中使用一个连接对应一个事务 -- sql 中的事务START TRANSACTION;select * from question;commit ;// 最原始的 jdbc 事务Connection connection = 获取数据库连接;try{ connection.setAutoCommit(false); // todo something connection.commit();}catch(Exception e){log(e); connection.rollback();}finally{ try{connection.close()}catch(Exception e){log(e);};}并发事务是指两个事务一同开始执行，如果两个事务操作的数据之间有交集，则很有可能产生冲突。这时怎么办呢，其实这也是 临界资源 的一种，在应用程序中，我们解决这类问题的关键是加锁，在数据库的实现也是一样，但在数据库中需要考虑更多。常见的需要考虑的问题有（下面说的我和人都是指一个会话） 对整张表数据加锁还是对当前操作的数据行加锁，这时有表锁和行锁，MyISAM 引擎只支持表锁，而 innodb 支持行锁和表锁如果数据量庞大，比如选到了百万数据，千万数据，不可能一次性全部加锁， 会很影响性能，innodb 是逐条加锁的数据库的操作其实有很大一部分是查询操作，如果锁住数据，任何人都不让进的话，性能也会很低下，所以会有读锁和写锁，也叫共享锁和排它锁根据检测冲突的时间不同，可以在一开始就把数据锁住，直到我使用完，还有就是在真正操作数据的时候才去锁住，就是悲观锁和乐观锁就算是让别人可以读数据，在两个事务也可能互相影响，比如脏读。事务的隔离级别及会带来的问题看过网上的大部分文章，基本都是一个表格来演示两个事务的并发，有的根本就是直接抄的，不知道那作者真的懂了没，其实我们是可以用客户端来模拟两个事务并发的情况的，打开两个 session ，让两个事务互相穿插。 下面的演示都是基于 mysql5.7 版本，查询事务隔离级别和修改隔离级别语句 -- 查看事务隔离级别select @@tx_isolation;-- 修改当前 session 事务隔离级别set session transaction isolation level read uncommitted;set session transaction isolation level read committed ;set session transaction isolation level repeatable read ;set session transaction isolation level serializable;-- 开启事务提交和回滚START TRANSACTION;select * from question;commit ;rollback;准备数据表，暂时先使用 InnoDB 引擎 ...

Ubuntu 18.04 下配置 MySQL ServerMySQL是一个免费且广泛使用的开源关系数据库。如果您知道自己需要数据库但对所有可用选项知之甚少，那么这是一个不错的选择。安装MySQL sudo apt-get update sudo apt-get install mysql-server启动MySQL服务安装完成后，您可以通过运行以下命令来启动数据库服务。如果该服务已启动，则会显示一条消息，通知您该服务已在运行： systemctl start mysql重启时启动要确保在重新引导后启动数据库服务器，请运行以下命令： systemctl enable mysql跨权使用mysql sudo mysql(用于忘记root密码时配置MySQL)添加数据库用户当应用程序使用root用户连接到数据库时，它们通常具有超出所需权限的权限。您可以添加应用程序可用于连接到新数据库的用户。 添加新的用户: 这里以user：yang,password:yang 为例允许本地IP访问localhost的MySQL数据库 use mysql; select host,user from user; +-----------+------------------+ | host | user | +-----------+------------------+ | localhost | debian-sys-maint | | localhost | mysql.session | | localhost | mysql.sys | | localhost | root | +-----------+------------------+ mysql> create user 'yang'@'localhost' identified by 'yang'; select host,user from user; +-----------+------------------+ | host | user | +-----------+------------------+ | localhost | debian-sys-maint | | localhost | mysql.session | | localhost | mysql.sys | | localhost | root | | localhost | yang | +-----------+------------------+允许外网IP访问数据库,所有的IP都可以访问该数据库 mysql> create user 'yang'@'%' identified by 'yang';创建完成后，刷新 mysql> flush privileges;用户授权更改用户赋权，并刷新授权 mysql> GRANT ALL PRIVILEGES ON *.* TO 'yang'@'%' IDENTIFIED BY 'yang' WITH GRANT OPTION; mysql> flush privileges;开启外网访问权限开启MySQL远程访问 sudo ufw allow mysql查看3306端口是否对外开放 netstat -an | grep 3306 tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN如果显示如上，说明mysql端口目前只监听本地连接127.0.0.1。然后需要修改mysql的配置文件 ...

思路：根据当前记录的id查询前后记录。 mongodb实现方法：mongo可以通过时间或者通过id来判断上一条记录或者下一条记录： 通过记录的_id上一条记录 db.数据库名称.find({ '_id': { '$lt': ids } }).sort({_id: -1}).limit(1)下一条记录 db.数据库名称.find({ '_id': { '$gt': ids } }).sort({_id: 1}).limit(1)通过时间字段来查询：上一条记录 db.数据库名称.find({ 'created': { '$lt': created } }).sort({_id: -1}).limit(1)下一条记录 db.数据库名称.find({ 'created': { '$gt': created } }).sort({_id: 1}).limit(1)mysql实现方法:mysql查询，网上有很多方法，通常我们用如下方法： 查询上一条记录的SQL语句（如果有其他的查询条件记得加上other_conditions以免出现不必要的错误）： select * from table_a where id = (select id from table_a where id < {$id} [and other_conditions] order by id desc limit 1 ) [and other_conditions];查询下一条记录的SQL语句（如果有其他的查询条件记得加上other_conditions以免出现不必要的错误）： select * from table_a where id = (select id from table_a where id > {$id} [and other_conditions] order by id asc limit 1 ) [and other_conditions];

问题描述数据库中有如下的地址信息表，需要实现一个更具用户输入的任何内容进行搜索可能匹配的地址信息。 -- MySQL版本: 5.7.25CREATE TABLE Address ( id BIGINT NOT NULL AUTO_INCREMENT, address VARCHAR(100) NOT NULL DEFAULT '', city VARCHAR(50) NOT NULL DEFAULT '', state VARCHAR(50) NOT NULL DEFAULT '', country VARCHAR(50) NOT NULL DEFAULT '', zip_code VARCHAR(10) NOT NULL DEFAULT '', FULLTEXT ftidx_location(address, city, state, country, zip_code)) ENGINE=INNODB DEFAULT CHARSET=utf8;insert into Address(city, state) values ('Irving', 'TX');容易想到利用如下的sql进行检索。 -- 这里的 ${input} 为用户输入的内容select * from Address where match(address, city, state, country, zip_code) against (${input});然而对于太短的输入，如 "TX"，即使数据库中存在 state = TX 的数据，该SQL也是无法检索到任何结果。或者输入 "Irvin" 也是无法查找到内容的。下面将对该问题进行分析和解决，使用"Irvin,TX"作为用户输入进行分析（不含双引号）。 ...

首先说一下数据库事务的四大特性 1 ACID事务的四大特性是ACID(不是"酸"....) (1) A:原子性(Atomicity)原子性指的是事务要么完全执行,要么完全不执行. (2) C:一致性(Consistency)事务完成时,数据必须处于一致的状态.若事务执行途中出错,会回滚到之前的事务没有执行前的状态,这样数据就处于一致的状态.若事务出错后没有回滚,部分修改的内容写入到了数据库中,这时数据就是不一致的状态. (3) I:隔离性(Isolation)同时处理多个事务时,一个事务的执行不能被另一个事务所干扰,事务的内部操作与其他并发事务隔离. (4) D:持久性(Durability)事务提交后,对数据的修改是永久性的. 2 Mysql的锁Mysql的锁其实可以按很多种形式分类: 按加锁机制分,可分为乐观锁与悲观锁.按兼容性来分,可分为X锁与S锁.按锁粒度分,可分为表锁,行锁,页锁.按锁模式分,可分为记录锁,gap锁,next-key锁,意向锁,插入意向锁.这里主要讨论S锁,X锁,乐观锁与悲观锁. (1) S锁与X锁S锁与X锁是InnoDB引擎实现的两种标准行锁机制.查看默认引擎可使用 show variables like '%storage_engine%';作者的mysql版本为8.0.17,结果如下: 先建好测试库与测试表,很简单,表就两个字段. create database test;use test;create table a(id int primary key auto_increment,money int); Ⅰ.S锁S锁也叫共享锁,读锁,数据只能被读取不能被修改.玩一下,上锁! lock table a read;然后..... 只能读不能改,删,也不能增. Ⅱ.X锁X锁也叫排他锁,写锁,一个事务对表加锁后,其他事务就不能对其进行加锁与增删查改操作. 设置手动提交,开启事务,上X锁. set autocmmmit=0;start transaction;lock table a write; 在开启另一个事务,使用select语句. set autocommit=0;start transaction;select * from a; 这里是阻塞select操作,因为一直都没释放X锁. 同样也不能再加锁,也是阻塞中. 回到原来那个加锁的事务,嗯,什么事也没有,正常读写. 释放锁后: unlock table; 在另一个事务中可以看到中断时间. ...

分享一个亲测可用的Navicat Premiun 中文破解版 安装完之后：复制中文包”zh-Hans.lproj”放到 /Contents/Resources 即可。（应用程序右键显示包内容） 链接:https://pan.baidu.com/s/1Taad... 密码:s9xh

仅限在mac环境下解决问题由于MYSQL8.0验证密码的方式改变了 连接Docker启动的mysql出现：ERROR 2059 (HY000): Authentication plugin 'caching_sha2_password' cannot be loaded C:mysqldata>mysql -h 127.0.0.1 -P 13306 -uroot -pEnter password: **ERROR 2059 (HY000): Authentication plugin 'caching_sha2_password' cannot be loaded: ÕÒ²»µ½Ö¸¶¨µÄÄ£¿é¡£ 解决方案：打开终端进入mysql容器首先获得超级权限：sudo su 输入绝对路径 /usr/local/mysql/bin/mysql -u root -p 输入密码 登录MySQL后输入： ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'YourPassword'; FLUSH PRIVILEGES;

作者：高鹏文章末尾有他著作的《深入理解 MySQL 主从原理 32 讲》，深入透彻理解 MySQL 主从，GTID 相关技术知识。源码版本：5.7.22水平有限，如有误请谅解本文建议横屏观看，效果更佳 一、案例来源和现象这个案例是朋友 @peaceful 遇到的线上问题，最终线索也是他自己找到的。现象如下： 1、出现了大量很小的 relay log 如下，堆积量大约 2600 个：...-rw-r----- 1 mysql dba 12827 Oct 11 12:28 mysql-relay-bin.036615-rw-r----- 1 mysql dba 4908 Oct 11 12:28 mysql-relay-bin.036616-rw-r----- 1 mysql dba 1188 Oct 11 12:28 mysql-relay-bin.036617-rw-r----- 1 mysql dba 5823 Oct 11 12:29 mysql-relay-bin.036618-rw-r----- 1 mysql dba 507 Oct 11 12:29 mysql-relay-bin.036619-rw-r----- 1 mysql dba 1188 Oct 11 12:29 mysql-relay-bin.036620-rw-r----- 1 mysql dba 3203 Oct 11 12:29 mysql-relay-bin.036621-rw-r----- 1 mysql dba 37916 Oct 11 12:30 mysql-relay-bin.036622-rw-r----- 1 mysql dba 507 Oct 11 12:30 mysql-relay-bin.036623-rw-r----- 1 mysql dba 1188 Oct 11 12:31 mysql-relay-bin.036624-rw-r----- 1 mysql dba 4909 Oct 11 12:31 mysql-relay-bin.036625-rw-r----- 1 mysql dba 1188 Oct 11 12:31 mysql-relay-bin.036626-rw-r----- 1 mysql dba 507 Oct 11 12:31 mysql-relay-bin.036627-rw-r----- 1 mysql dba 507 Oct 11 12:32 mysql-relay-bin.036628-rw-r----- 1 mysql dba 1188 Oct 11 12:32 mysql-relay-bin.036629-rw-r----- 1 mysql dba 454 Oct 11 12:32 mysql-relay-bin.036630-rw-r----- 1 mysql dba 6223 Oct 11 12:32 mysql-relay-bin.index2、主库错误日志有如下错误2019-10-11T12:31:26.517309+08:00 61303425 [Note] While initializing dump thread for slave with UUID <eade0d03-ad91-11e7-8559-c81f66be1379>, found a zombie dump thread with the same UUID. Master is killing the zombie dump thread(61303421).2019-10-11T12:31:26.517489+08:00 61303425 [Note] Start binlog_dump to master_thread_id(61303425) slave_server(19304313), pos(, 4)2019-10-11T12:31:44.203747+08:00 61303449 [Note] While initializing dump thread for slave with UUID <eade0d03-ad91-11e7-8559-c81f66be1379>, found a zombie dump thread with the same UUID. Master is killing the zombie dump thread(61303425).2019-10-11T12:31:44.203896+08:00 61303449 [Note] Start binlog_dump to master_thread_id(61303449) slave_server(19304313), pos(, 4)二、slave_net_timeout 参数分析实际上第一眼看这个案例我也觉得很奇怪，因为很少有人会去设置 slave_net_timeout 参数，同样我们也没有设置过，因此关注较少。但是 @peaceful 自己找到了可能出现问题的设置就是当前从库 slave_net_timeout 参数设置为 10。我就顺着这个线索往下分析，我们先来看看 slave_net_timeout 参数的功能。 ...

数据库的五个概念数据库服务器数据库数据表数据字段数据行那么这里下面既是对上面几个概念进行基本的日常操作。 数据库引擎使用这里仅仅只介绍常用的两种引擎,而InnoDB是从MySQL 5.6.版本以后InnoDB就是作为默认启动使用的存储引擎。 (1) InnoDB a,支持ACID，简单地说就是支持事务完整性、一致性； b,支持行锁，以及类似ORACLE的一致性读，多用户并发； c,独有的聚集索引主键设计方式，可大幅提升并发读写性能； d,支持外键； e,支持崩溃数据自修复； InnoDB设计目标是处理大容量数据库系统，它的CPU利用率是其它基于磁盘的关系数据库引擎所不能比的。 它是一个可靠地事务处理引擎，不支持全文本搜索(2) MyISAM a,不支持 每次查询具有原子性 b,只支持表所 c,强调的是性能，其执行数 度比InnoDB类型更快，但是不提供事务支持 d,如果执行大量的SELECT，MyISAM是更好的选择 e,缺点：就是不能在表损坏后恢复数据。（是不能主动恢复）既然知道了这俩种引擎的优缺点，那么写一下几个常用的API操作。 show engines; --显示所有可用的引擎show table status from myDB; --查看myDB数据库下的所有表使用的引擎show create table 表名; --指定查看表名的所有段名以及引擎create table 表名(id int primary key, name varchar(50)) engine=MyISAM; --建表的时候指定引擎 alter table 表名 Engine= MyISAM; --建完表后修改引擎为MyISAM当然，也可以通过修改配置文件my.ini在[mysqld]最后添加为上default-storage-engine=InnoDB，重启服务，数据库默认的引擎修改为InnoDB。 数据库操作>net start mysql //启动数据库和停止net stop mysql>mysql -u root -p //默认登陆本机(-h是主机地址)>SELECT USER(); //显示当前用户>create database 数据库名; //创建数据库>SELECT DATABASE(); //显示当前使用数据库>SHOW DATABASES //显示所有数据库列表>USE DATABASE 库名; //使用该数据库>DROP DATABASE 库名 //删除数据库>CMD终端：mysqladmin -u用户名 -p旧密码 password 新密码 //修改密码>mysql语句：set password for 用户名@localhost = password('新密码'); 数据表操作>SHOW TABLES; //列出库中所有的表>DESCRIBE table1; //查看表结构>show columns from 数据表; //显示表的所有段名以及类型>CREATE TABLE 表名 (字段名 VARCHAR(20), 字段名 CHAR(1)); //增加数据表和字段名>DROP TABLE 表名; //删除表>alter table stu rename as students; //将旧表明stu改为新表明students。表字段操作添加字段语法：ALTER TABLE 表名 ADD COLUMN 字段名 字段类型 DEFAULT NULL;示例：ALTER TABLE dictionary ADD COLUMN calss VARCHAR(10) DEFAULT NULL;-- dictionary是表名修改字段名称语法：ALTER TABLE 表名 CHANGE 旧字段名 新字段名 新字段类型 DEFAULT NULL;示例：ALTER TABLE dictionary CHANGE calss class VARCHAR(10) DEFAULT NULL;删除字段语法：ALTER TABLE 表名 DROP COLUMN 字段名示例：ALTER TABLE dictionary DROP COLUMN calss;批量增加字段bagin; //事务开始alter table em_day_data add f_day_house7 int(11);alter table em_day_data add f_day_house8 int(11);alter table em_day_data add f_day_house9 int(11);alter table em_day_data add f_day_house10 int(11);commit; //提交事务，事务结束数据增删改查MySQL语句忽略大小写的。每张数据表只能存在一个主键。 ...

作者：胡呈清slave_relay_log_info 表是这样的： mysql> select * from mysql.slave_relay_log_info\G *************************** 1. row *************************** Number_of_lines: 7 Relay_log_name: ./mysql-relay.000015 Relay_log_pos: 621 Master_log_name: mysql-bin.000001 Master_log_pos: 2407 Sql_delay: 0Number_of_workers: 16 Id: 1 Channel_name:slave_relay_log_info 表存储 slave sql thread 的工作位置。在从库启动的时候时，读取 slave_relay_log_info 表中存储的位置，并把值传给 "show slave status" 中的 Relay_Log_File、Relay_Log_Pos，下次 "start slave" 是从这个位置开始继续回放 relay log。slave_relay_log_info 表存储的是持久化的状态、show slave status 输出的是内存中的状态： 两者输出的位置可能不一样stop slave 或者正常关闭 mysqld，都会将内存中的状态持久化到磁盘上（slave_relay_log_info表中）启动 mysqld 时会读取磁盘状态，初始化给内存状态start slave 时生效的是内存状态slave io thread 按照 Master_Log_File、Read_Master_Log_Pos 位置读取主库的 binlog，并写入到本地 relay log（注意这两个位点信息保存在 slave_master_info 表中）；slave sql thread 按照 Relay_Log_Name、Relay_Log_Pos 位置进行 realy log 的回放。 ...

简介：在本教程中，您将学习如何使用MySQL JSON数据类型, 以及数据库中存储JSON文档。 MySQL JSON数据类型简介从版本5.7.8开始，MySQL支持本机JSON数据类型。本地JSON数据类型使您比以前版本中的JSON文本格式更有效地存储JSON文档。 MySQL 以内部格式存储 JSON 文档，该格式允许快速读取文档元素。JSON 二进制格式的结构允许服务器直接通过键或数组索引在 JSON 文档中搜索值。 JSON文档的存储与 LONGBLOB 或 LONGTEXT 数据的存储大致相同。 要定义数据类型为JSON的列，请使用以下语法： CREATE TABLE table_name ( ... json_column_name JSON, ... );注意: JSON 列不能具有默认值。此外，JSON 列无法直接建立索引。您可以在生成的虚拟列（Generated Column）上创建索引，该索引包含从 JSON 列提取的值。当您从 JSON 列查询数据时，MySQL 优化器将在与 JSON 表达式匹配的虚拟列上查找兼容索引。在MySQL 5.7中，支持两种Generated Column，即Virtual Generated Column和Stored Generated Column，前者只将Generated Column保存在数据字典中（表的元数据），并不会将这一列数据持久化到磁盘上；后者会将Generated Column持久化到磁盘上，而不是每次读取的时候计算所得。很明显，后者存放了可以通过已有数据计算而得的数据，需要更多的磁盘空间，与Virtual Column相比并没有优势，因此，MySQL 5.7中，不指定Generated Column的类型，默认是Virtual Column。 生成列索引创建方式如下： CREATE TABLE table_name ( ...`names_virtual` VARCHAR(20) GENERATED ALWAYS AS (`json_column_name` ->> '$.name') NOT NULL, ... );MySQL JSON数据类型示例假设我们必须在网站上跟踪访问者及其行为。一些访问者可能只是查看页面，而其他访问者可能会查看页面并购买产品。为了存储此信息，我们将创建一个名为的新表 events。 ...

前言最近有个需求解析一个订单文件，并且说明文件可达到千万条数据，每条数据大概在20个字段左右，每个字段使用逗号分隔，需要尽量在半小时内入库。 思路1.估算文件大小因为告诉文件有千万条，同时每条记录大概在20个字段左右，所以可以大致估算一下整个订单文件的大小，方法也很简单使用FileWriter往文件中插入一千万条数据，查看文件大小，经测试大概在1.5G左右； 2.如何批量插入由上可知文件比较大，一次性读取内存肯定不行，方法是每次从当前订单文件中截取一部分数据，然后进行批量插入，如何批次插入可以使用insert(...)values(...),(...)的方式，经测试这种方式效率还是挺高的； 3.数据的完整性截取数据的时候需要注意，需要保证数据的完整性，每条记录最后都是一个换行符，需要根据这个标识保证每次截取都是整条数，不要出现半条数据这种情况； 4.数据库是否支持批次数据因为需要进行批次数据的插入，数据库是否支持大量数据写入，比如这边使用的mysql，可以通过设置max_allowed_packet来保证批次提交的数据量； 5.中途出错的情况因为是大文件解析，如果中途出现错误，比如数据刚好插入到900w的时候，数据库连接失败，这种情况不可能重新来插一遍，所有需要记录每次插入数据的位置，并且需要保证和批次插入的数据在同一个事务中，这样恢复之后可以从记录的位置开始继续插入。 实现1.准备数据表这里需要准备两张表分别是：订单状态位置信息表，订单表； CREATE TABLE `file_analysis` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `file_type` varchar(255) NOT NULL COMMENT '文件类型 01:类型1，02:类型2', `file_name` varchar(255) NOT NULL COMMENT '文件名称', `file_path` varchar(255) NOT NULL COMMENT '文件路径', `status` varchar(255) NOT NULL COMMENT '文件状态 0初始化；1成功；2失败：3处理中', `position` bigint(20) NOT NULL COMMENT '上一次处理完成的位置', `crt_time` datetime NOT NULL COMMENT '创建时间', `upd_time` datetime NOT NULL COMMENT '更新时间', PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8CREATE TABLE `file_order` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `file_id` bigint(20) DEFAULT NULL, `field1` varchar(255) DEFAULT NULL, `field2` varchar(255) DEFAULT NULL, `field3` varchar(255) DEFAULT NULL, `field4` varchar(255) DEFAULT NULL, `field5` varchar(255) DEFAULT NULL, `field6` varchar(255) DEFAULT NULL, `field7` varchar(255) DEFAULT NULL, `field8` varchar(255) DEFAULT NULL, `field9` varchar(255) DEFAULT NULL, `field10` varchar(255) DEFAULT NULL, `field11` varchar(255) DEFAULT NULL, `field12` varchar(255) DEFAULT NULL, `field13` varchar(255) DEFAULT NULL, `field14` varchar(255) DEFAULT NULL, `field15` varchar(255) DEFAULT NULL, `field16` varchar(255) DEFAULT NULL, `field17` varchar(255) DEFAULT NULL, `field18` varchar(255) DEFAULT NULL, `crt_time` datetime NOT NULL COMMENT '创建时间', `upd_time` datetime NOT NULL COMMENT '更新时间', PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=10000024 DEFAULT CHARSET=utf82.配置数据库包大小mysql> show VARIABLES like '%max_allowed_packet%';+--------------------------+------------+| Variable_name | Value |+--------------------------+------------+| max_allowed_packet | 1048576 || slave_max_allowed_packet | 1073741824 |+--------------------------+------------+2 rows in setmysql> set global max_allowed_packet = 1024*1024*10;Query OK, 0 rows affected通过设置max_allowed_packet，保证数据库能够接收批次插入的数据包大小；不然会出现如下错误： ...

作者：管长龙 王均 田帅萌前一阵圈内人士发布了一个关于新版本的消息：《MySQL 8.0.18 Hash Join 来啦！》 该文章概括介绍了 MySQL 8.0.18 将支持 Hash Join 和推出 EXPLAIN ANALYZE 等新功能。国庆一过，全国各处秋高气爽，感觉到 8.0.18 的脚步也近了。除了上述的新功能之外，有关 8.0.18 的更新细节已经出现在 MySQL 官网文档上了，对此做了一些整理，让我们先预览一下吧！ 一、Replication1、新的主从复制信息记录方式我们知道主从复制建立前，需要在 slave 通过 CHANGE MASTER TO 语句来设置 master 选项。若 slave 启动是添加 --master-info-file=file_name 参数，则开启记录 master 信息的日志文件，默认文件为 master.info 在 datadir 下。 8.0.18 版本开始将不推荐使用 --master-info-file 和 --master-info-repository 选项。未来将使用 crash-safe slave 表来代替 master 信息文件记录的方式。 同理，relay_log_info_file 也将在 crash-safe slave 表中记录，固也不推荐使用。 2、对 row-based 日志的搜索模式优化目前 --slave-rows-search-algorithms=list 的作用是在启动时控制选择如何在行中搜索匹配项。特备是是否使用 HASH_SCAN，未来将默认使用 INDEX_SCAN, HASH_SCAN 这两种方式，它们的性能是最佳的，并可以在所有情况下正常工作。 ...

1.前言mysql作为应用程序的数据存储服务，要实现mysql数据库的高可用。必然要使用的技术就是数据库的复制，如果主节点出现故障可以手动的切换应用到从节点，这点相信运维同学都是知道，并且可以实现的。但是这种情况只是手动的切换，对可用性有要求的业务需要分别实现主库和从库的高可用，保障在数据库出现down机的情况下，可以自动实现数据库的故障转移，保障应用的可用性和用户体验。 本文将会对一些常用的数据库高可用方案进行介绍，根据你不同的场景，选择合适的高可用方案即可。 2.MMM高可用方案2.1.Mysql-MMM介绍 MMM(Master-Master replication managerfor Mysql，Mysql主主复制管理器)是一套灵活的脚本程序，基于perl实现，用来对mysql replication进行监控和故障迁移，并能管理mysql Master-Master复制的配置(同一时间只有一个节点是可写的)。 2.2.组件 mmm_mond：监控进程，负责所有的监控工作，决定和处理所有节点角色活动。此脚本需要在监管机上运行。 mmm_agentd：运行在每个mysql服务器上的代理进程，完成监控的探针工作和执行简单的远端服务设置。此脚本需要在被监管机上运行。 mmm_control：一个简单的脚本，提供管理mmm_mond进程的命令。 mysql-mmm的监管端会提供多个虚拟IP（VIP），包括一个可写VIP，多个可读VIP，通过监管的管理，这些IP会绑定在可用mysql之上，当某一台mysql宕机时，监管会将VIP迁移至其他mysql。 在整个监管过程中，需要在mysql中添加相关授权用户，以便让mysql可以支持监理机的维护。授权的用户包括一个mmm_monitor用户和一个mmm_agent用户，如果想使用mmm的备份工具则还要添加一个mmm_tools用户。 2.3.架构图 正常工作时： 主节点故障时： 2.4.MMM优点 （1）高可用性，扩展性好，出现故障自动转移，对于主主同步，在同一时间只提供一台数据库写操作，保证数据的一致性。（2）配置简单，容易操作。 2.5.MMM缺点 （1）需要一台备份服务器，浪费资源（2）需要多个虚拟IP（3）agent可能意外终止，引起裂脑。 3.MHA介绍MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 3.1.MHA架构介绍 该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。 在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失(配合mysql半同步复制效果更佳)，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。 注意：目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器，出于机器成本的考虑，淘宝也在该基础上进行了改造，目前淘宝TMHA已经支持一主一从。 3.2.MHA架构图 正常工作时架构图： 主库down机时架构： 3.3.故障转移过程 （1）从宕机崩溃的master保存二进制日志事件（binlog events）;（2）识别含有最新更新的slave；（3）应用差异的中继日志（relay log）到其他的slave；（4）应用从master保存的二进制日志事件（binlog events）；（5）提升一个slave为新的master；（6）使其他的slave连接新的master进行复制；（7）在新的master启动vip地址，保证前端请求可以发送到新的master。 3.4.MHA优点 （1）不需要备份服务器（2）不改变现有环境（3）操作非常简单（4）可以进行日志的差异修复（5）可以将任意slave提升为master 3.5.MHA缺点 （1）需要全部节点做ssh秘钥（2）MHA出现故障后配置文件会被修改，如果再次故障转移需要重新修改配置文件。（3）自带的脚本还需要进一步补充完善，且用perl开发，二次开发困难。 4.DRBD+（heartbeat,corosync）4.1.方案简介 本方案采用Heartbeat或者corosync双机热备软件来保证数据库的高稳定性和连续性，数据的一致性由DRBD这个工具来保证（如果可以尽量放到分布式存储上面）。默认情况下只有一台mysql在工作，当主mysql服务器出现问题后，系统将自动切换到备机上继续提供服务，当主数据库修复完毕，又将服务切回继续由主mysql提供服务。 4.2.组件 Heartbeat,corosync作为心跳检测机制，监控primary节点的状态。当主节点宕掉之后，迅速提升secondary节点为新的主节点，并切换IP；drbd负责数据同步 4.3.架构图 4.4.数据同步过程 mysql进行刷盘时，会通过不同的sync方式，最终将数据写入disk；drbd收到刷盘成功的信息后，将对应的磁盘块位置，和变更动作，通过网络传递至secondary节点； secondary的drbd接收到变更信息后，将这些信息落盘； 4.5.切换过程 前提：secondary节点的mysql服务不启动； heartbeat检测到primary的mysql服务停止，则摘掉IP、umount掉数据盘、将primary切换为secondary； 在原来的secondary上，提升drbd同步为primary，挂载数据盘，启动mysql服务、绑定IP； 从库跟着IP和端口自动进行迁移； 4.6.方案优点 （1）历史悠久、安全性高、稳定性高、可用性高、出现故障自动切换。（2）数据一致性强 4.7.方案缺点 （1）需要一台备份服务器，浪费资源（2）不方便扩展（3）无论drbd还是headbetart，corosync都可能发生裂脑 5.Mysql route介绍5.1.什么是mysql route ...

接上一篇：MySQL数据库主从同步实战过程 mysql命令介绍mysql 是数据库管理命令 通过mysql --help来查看相关参数及使用说明mysql --help #mysql数据库管理命令Usage: mysql [OPTIONS] [database] #语法格式--help #查看帮助文档--auto-rehash #自动补全功能-A, --no-auto-rehash #不需自动补全-B, --batch #不使用历史文件，禁用交互--character-sets-dir=name #字符集安装目录-C, --compress #客户端与服务端传递信息时压缩-#--debug[=#] #调用功能-D, --database=name #使用数据库--default-character-set=name #设置默认字符集-e, --execute=name #执行sql语句-E, --vertical #垂直打印输出信息-f, --force #跳过错误，执行下面的命令-G, --named-commands #查询结果按列打印-i, --ignore-spaces #忽略空格-h, --host=name #设置连接服务器的地址与IP--line-numbers #显示有错误的行号-L, --skip-line-numbers #忽略有错误的行号-n, --unbuffered #每次执行sql后刷新缓存--column-names #查询时显示列信息-N, --skip-column-names #不显示列信息-p, --password[=name] #输入密码信息-P, --port=# #设置端口信息 --prompt=name #设置mysql提示符 --protocol=name #设置使用协议-s, --silent #一行一行输出，tab间隔-S, --socket=name #连接服务器使用socket文件-t, --table #以表格的格式输出-u, --user=name #连接服务器的用户名-v, --verbose #打印sql执行的命令-V, --version #输出版本信息-w, --wait #服务器停机后等待重启的时间--connect-timeout=# #连接前要等待的时间--max-allowed-packet=# #服务器发送与接收包的最大长度--show-warnings #显示警告信息mysqldump命令介绍mysqldump数据备份命令（逻辑备份） ...

@[toc] 1.背景开发一个app与后台数据库交互,基于mysql+jdbc+tomcat,没有使用DBUtils或jdbc框架,纯粹底层jdbc实现.以后逐步改用Spring框架,优化mysql,进一步部署tomcat等等,现在项目刚刚起步,还有很多不懂的东西,得慢慢来......这几天踩了很多坑,说得夸张点真是踩到我没有知觉,希望能帮助别人少踩坑... 2.开发环境系统 : win10IDE : Android Studio 3.5.1,IntelliJ IDEA 2019.02DBMS : Mysql 8.0.17web服务器: tomcat93.相关资源1.相关jar包:mysqlV8.0.17驱动(注意这个要与自己的mysql版本对应)java-servlet-api-V4.0.1其他版本可以来这里搜索下载Maven仓库2.github这是源码地址,包括前后端与建表等所有代码.(欢迎star) 3.码云这也是源码地址 4.配置开发环境IDE就不说了,重点说一下mysql与tomcat9的安装 一. 安装Mysql8.0.17这个是目前比较新的mysql版本. 服务器系统是centos其他系统安装看这里 win10ubuntufedroareahatcentos使用yum命令安装(参考链接) (1) 下载mysqlsudo yum localinstall https://repo.mysql.com//mysql80-community-release-el7-1.noarch.rpm(2) 安装mysqlsudo yum install mysql-community-server(3) 启动服务sudo service mysqld start(4) 查看初始化密码,用于下一步设置自己的root密码sudo grep 'temporary password' /var/log/mysqld.log(5) 本地使用root登录mysql -u root -p输入上一步看到的密码 (6) 更改密码alter mysql.user 'root'@'localhost' identified by 'password';注意新版本的mysql不能使用太弱的密码如果出现如下提示则说明密码太弱了,请使用一个更高强度的密码 (7) 允许外部访问use mysql;update user set host='%' where user='root';这个可以根据自己的需要去修改,host='%'表明允许所有的ip登录,也可以设置特定的ip,若使用host='%'的话建议新建一个用户配置相应的权限. (8) 配置防火墙(可选)由于作者使用的是阿里云的服务器,没配置防火墙的话远程连接不上,因此需要手动配置,如图 其中授权对象可以根据自己的需要更改,0.0.0.0/0表示允许所有的ip. 二.安装tomcat9(1) 先去官网下载,下载后上传文件到服务器作者使用的是scp命令,不会的可以看这里 scp apache-tomcat-xxxx.tar.gz username@xx.xx.xx.xx:/改成自己的用户名和ip (2) 连接到服务器,解压压缩包mkdir /usr/local/tomcatmv apache-tomcat-xxxx.tar.gz /usr/local/tomcattar -xzvf apache-tomcat-xxx.tar.gz(3) 修改tomcat默认端口(可选)修改conf/server.xml文件,一般只需修改 ...

作者：高鹏文章末尾有他著作的《深入理解 MySQL 主从原理 32 讲》，深入透彻理解 MySQL 主从，GTID 相关技术知识。源码版本：5.7.22水平有限，如有误请谅解 一、问题来源这是一个朋友问我的典型案例。整个故障现象表现为，MySQL 数据库频繁的出现大量的请求不能响应。下面是一些他提供的证据： 1、show processlist从状态信息来看出现如下情况： insert 操作：状态为 updateupdate/delete 操作：状态为 updatingselect 操作：状态为 sending data因此可以推断应该是语句执行期间出现了问题，由于篇幅原因只给出一部分，并且我将语句部分也做了相应截断： show processlist----------------------------......11827639 root dbmis Execute 9 updating UPDATE 17224594 root dbmis Execute 8 Sending data SELECT sum(exchange_coin) as exchange_coin FROM 17224595 root dbmis Execute 8 update INSERT INTO 17224596 root dg Execute 8 update INSERT INTO 17224597 root dbmis Execute 8 update INSERT INTO 17224598 root dbmis Execute 7 update INSERT INTO 17224599 root dbmis Execute 7 Sending data SELECT COUNT(*) AS tp_count FROM 17224600 root dg Execute 7 update INSERT INTO 17224601 root dbmis Execute 6 update INSERT INTO 17224602 root dbmis Execute 6 Sending data SELECT sum(exchange_coin) as exchange_coin FROM 17224606 root dbmis Execute 5 update INSERT INTO 17224619 root dbmis Execute 2 update INSERT INTO 17224620 root dbmis Execute 2 update INSERT INTO 17224621 root dbmis Execute 2 Sending data SELECT sum(exchange_coin) as exchange_coin 17224622 root dg Execute 2 update INSERT INTO 17224623 root dbmis Execute 1 update INSERT INTO 17224624 root dbmis Execute 1 update INSERT INTO 17224625 root dg Execute 1 update INSERT INTO 17224626 root dbmis Execute 0 update INSERT INTO 2、系统 IO/CPU从 vmstat 来看，CPU 使用不大，而 IO 也在可以接受的范围内（vmstat wa% 不高且 b 列为 0 ）如下： ...

MySQL 数据库(一) 建表规约 【强制】表达是与否概念的字段，必须使用 is_xxx 的方式命名，数据类型是 unsignedtinyint（1 表示是，0 表示否）。说明：任何字段如果为非负数，必须是 unsigned。注意：POJO 类中的任何布尔类型的变量，都不要加 is 前缀，所以，需要在设置从 is_xxx到 Xxx 的映射关系。数据库表示是与否的值，使用 tinyint 类型，坚持 is_xxx 的命名方式是为了明确其取值含义与取值范围。正例：表达逻辑删除的字段名 is_deleted，1 表示删除，0 表示未删除。【强制】表名、字段名必须使用小写字母或数字，禁止出现数字开头，禁止两个下划线中间只出现数字。数据库字段名的修改代价很大，因为无法进行预发布，所以字段名称需要慎重考虑。说明：MySQL 在 Windows 下不区分大小写，但在 Linux 下默认是区分大小写。因此，数据库名、表名、字段名，都不允许出现任何大写字母，避免节外生枝。正例：aliyun_admin，rdc_config，level3_name反例：AliyunAdmin，rdcConfig，level_3_name【强制】表名不使用复数名词。说明：表名应该仅仅表示表里面的实体内容，不应该表示实体数量，对应于 DO 类名也是单数形式，符合表达习惯。【强制】禁用保留字，如 desc、range、match、delayed 等，请参考 MySQL 官方保留字。【强制】主键索引名为 pk_字段名；唯一索引名为 uk_字段名；普通索引名则为 idx_字段名。说明：pk_ 即 primary key；uk_ 即 unique key；idx_ 即 index 的简称。【强制】小数类型为 decimal，禁止使用 float 和 double。说明：在存储的时候，float 和 double 都存在精度损失的问题，很可能在比较值的时候，得到不正确的结果。如果存储的数据范围超过 decimal 的范围，建议将数据拆成整数和小数并分开存储。【强制】如果存储的字符串长度几乎相等，使用 char 定长字符串类型。【强制】varchar 是可变长字符串，不预先分配存储空间，长度不要超过 5000，如果存储长度大于此值，定义字段类型为 text，独立出来一张表，用主键来对应，避免影响其它字段索引效率。【强制】表必备三字段：id, create_time, update_time。说明：其中 id 必为主键，类型为 bigint unsigned、单表时自增、步长为 1。create_time, update_time的类型均为 datetime 类型。【推荐】表的命名最好是遵循“业务名称_表的作用”。 正例：alipay_task / force_project / trade_config【推荐】库名与应用名称尽量一致。【推荐】如果修改字段含义或对字段表示的状态追加时，需要及时更新字段注释。【推荐】字段允许适当冗余，以提高查询性能，但必须考虑数据一致。冗余字段应遵循： 1） 不是频繁修改的字段。 2） 不是 varchar 超长字段，更不能是 text 字段。 3） 不是唯一索引的字段。 正例：商品类目名称使用频率高，字段长度短，名称基本一不变，可在相关联的表中冗余存储类目名 称，避免关联查询。【推荐】单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。 说明：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。【参考】合适的字符存储长度，不但节约数据库表空间、节约索引存储，更重要的是提升检 索速度。 正例：如下表，其中无符号值可以避免误存负数，且扩大了表示范围。 对象 年龄区间 类型 字节 表示范围 人 150 岁之内 tinyint unsigned 1 无符号值：0 到 255 龟 数百岁 smallint unsigned 2 无符号值：0 到 65535 恐龙化石 数千万年 int unsigned 4 无符号值：0 到约 42.9 亿 太阳 约 50 亿年 bigint unsigned 8 无符号值：0 到约 10 的 19 次方(二) 索引规约 ...

纠错在某些博文中看到对于幻读的解释是这样的： 一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为“幻读”。即事务A 执行两次 select 操作得到不同的数据集，即 select 1 得到 10 条记录，select 2 得到 11 条记录。这其实并不是幻读，这是不可重复读的一种，只会在 R-U R-C 级别下出现，而在 mysql 默认的 RR 隔离级别是不会出现的（下面会举例推翻）。 然而，我终于在茫茫文章中，找到了相对正确的解释： 幻读，并不是说两次读取获取的结果集不同，幻读侧重的方面是某一次的 select 操作得到的结果所表征的数据状态无法支撑后续的业务操作。更为具体一些：select 某记录是否存在，不存在，准备插入此记录，但执行 insert 时发现此记录已存在，无法插入，此时就发生了幻读。推翻错误的解释事务隔离级别mysql 有四级事务隔离级别 每个级别都有字符或数字编号 读未提交 READ-UNCOMMITTED | 0：存在脏读，不可重复读，幻读的问题读已提交 READ-COMMITTED | 1：解决脏读的问题，存在不可重复读，幻读的问题 可重复读 REPEATABLE-READ | 2：解决脏读，不可重复读的问题，存在幻读的问题，默认隔离级别，使用 MMVC机制 实现可重复读 序列化 SERIALIZABLE | 3：解决脏读，不可重复读，幻读，可保证事务安全，但完全串行执行，性能最低 幻读会在 RU / RC / RR 级别下出现，SERIALIZABLE 则杜绝了幻读，但 RU / RC 下还会存在脏读，不可重复读，故我们就以 RR 级别来研究幻读，排除其他干扰。 举例推翻建表a，id列自增主键，name列唯一索引。 CREATE TABLE a ( id int(11) NOT NULL AUTO_INCREMENT, name varchar(255) DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY UIDX_NAME (name)) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8;准备初始数据： ...

安装MySQL$ sudo apt-get install mysql-server$ sudo apt install mysql-client$ sudo apt install libmysqlclient-dev检查是否安装成功 $ netstat -tap | grep mysql若安装成功会有如下输出 注意: 如果出现command not found: netstat,请先安装 net-tools,然后再检查是否成功： sudo apt-get install net-tools设置远程访问编辑MySQL的配置文件 $ vim /etc/mysql/mysql.conf.d/mysqld.cnf 把下面的内容注释 bind-address = 127.0.0.1以root权限进入MySQL命令行，执行开启权限命令，本示例中MySQL中用户与密码皆为root grant all on *.* to root@'%' identified by 'root' with grant option;flush privileges;重启MySQL $ sudo /etc/init.d/mysql restart

今天我们来说一说数据可视化，想必很多人在入门数据分析之后，就会经常进行可视化的工作，所谓一图胜千言，图表用的好，真的是会事半功倍的。但现实情况下，很多人遇到的问题是： 你做的图表太丑了？你做的图表到底想表达什么？图表太多，该用哪一个更好呢？ 很多人看着下面这些高级上档次的数据可视化都觉得羡慕，但是到自己动手的时候又不知从何下手，或者实现难度太大，只能“望图兴叹”。 其实我们想要做好可视化并不难，最简单的方法就是要学一些高级的图表效果，折线图、柱状图这种常见图表很容易给人一种普通感，而高级的图表效果不仅可以提升颜值和逼格，而且能够更清晰地实现数据展示。 下面我就分享五个可视化中常用的高级图表，以及实现这些图表效果的具体方法。 首先，挑个可视化工具想要做出优秀的可视化，一个好的工具是必不可少的。 其实，简单一点的如excel，这个基本人人都会用，还能配置图表颜色，是数据可视化的入门基础。但是这个对原始数据有一定要求，量不能大数据要干净，也不能绘制地图等更加酷炫的图表，最后的结果是什么呢？ 结果就是，数据可视化沦为了千篇一律的柱形图和折线图，还有那一成不变的配色。 因此数据分析师一般都使用专业的可视化工具，比较常见的就是python、R这些编程语言和FineBI、tableau这些专业BI工具，这次我就以FineBI为例，教大家怎么做出高级图表。 这里要先说一下FineBI进行可视化操作的流程： 数据准备：通过数据连接，将数据库中的数据以自助数据集的形式存储在业务包中，为可视化进行数据准备 数据加工：根据需求对数据进行初步加工，比如过滤、分组、排序、合并等操作 可视化图表制作：通过拖拽指标的形式，实现可视化图表的制作 仪表板设计完成：在仪表板上进行图表的排列设计，最终形成完整的可视化仪表板 高级图表一：流向地图地图图表是我们在进行可视化中经常会用的组件之一，比较普通的就是区域地图、线地图，比较高级的比如热力地图、点地图，这些基本都是静态地图；而流向地图则是更为高级的动态图表，经常应用于区际贸易、交通流向、人口迁移、购物消费行为等场景。 1、数据准备 在进行春运迁徙流向分析之前，我们需要准备流向地图的制作数据，包括迁徙路线、城市、城市对应经纬度和ID，如下图： 在准备好数据以后，我们就可以开始制作春运迁徙流向地图了。 2、拖拽地理字段 因为我们直接准备的经度、纬度字段，因此我们先将经纬度字段转换为地理角色，然后将转换后的经纬度字段拖入横纵轴中，如下图： 3、设置细粒度 经纬度默认汇总方式为求平均，此时图表中仅显示了一个点。我们还需要一个维度字段来为经纬度字段划分细粒度，因此我们将迁徙路线字段拖拽到细粒度中，并在图表类型中选择流向地图，如下图： 然后进一步划分细粒度，即每条迁徙路线下对应的城市维度。将城市字段拖拽至细粒度下、迁徙路线字段移到图形属性下的颜色栏，就可以做出这种效果了： 4、增加流向效果 在实现按照迁徙路线和城市划分连线以后，我们还需要指定流向的顺序，将ID字段拖入图形属性下的连线栏，如下图： 点击确定进行动画效果设置。可以看到图表中即按照迁徙路线的方向来流动。 5、优化效果 如果我们想增加迁徙人数的说明，即按照迁徙人数来调整流向线的颜色，此时就需要将迁徙人数字段拖拽至图形属性下的颜色栏，并将原来的迁徙路线字段移动至标签/提示/细粒度中城市上方，选择任一位置移动即可，如下图： 高级图表二：瀑布图瀑布图本质上属于一种柱状图，当用户想表达两个数据点之间数量的演变过程，比如薪酬支出构成，经过连续的数值加减关系得到最终的实发工资，就可以用瀑布图实现。 1、数据处理 数据准备同上，我们首先要进行数据的处理，先新增一列，并添加列名为“累计值准备”，公式如下图： 再新增列，添加列名为y值准备，选择累计值/组内，并设置取值规则为累计值，数值来自累计值准备，如下图： 再新增列，添加列名为y轴值，公式如下图： 再次新增列将其命名为标签，公式为如下图，此步骤即将基本、绩效、加班标记为增加，保险、公积金、个税标记为减少，应发工资和实发工资标记为汇总； 2、创建瀑布图 新建仪表板和组件，拖拽项目字段到横轴，拖拽y轴值、数据字段到纵轴，在图表类型下选择瀑布图，则数据字段被自动移至图形属性下的大小栏，且图表显示为瀑布图，如下图； 对项目字段选择自定义排序，自行排序如下图： 拖拽标签字段至图形属性下的颜色栏，瀑布图中的矩形块颜色即按照增加、减少、汇总来显示，如下图： 3、效果展示 调整矩形块、组件背景、标题栏等的颜色和字体，即可得到如下示例的效果： 高级图表三：人口金字塔人口金字塔图显示人口中各个年龄组的分布，通常用于此可视化类型的一种常见分布是按年龄列出的女性和男性人口，如下图： ...

接上一次： MySQL数据库入门多实例配置 一提到数据，大家神经都会很紧张，数据的类型有很多种，但是总归一点，数据很重要，非常重要，因此，日常的数据备份工作就成了运维工作的重点中的重点的重点................. 首先来看看数据库中的数据 mysql> select * from test;+-----+------+| id | name |+-----+------+| 1 | 1 || 11 | text || 21 | abc || 9 | bcd || 111 | 1 || 441 | text || 41 | abc || 999 | bcd |+-----+------+8 rows in set (0.00 sec)1、单库备份[root@centos6 ~]# mysqldump -uroot -p test >/download/testbak_$(date +%F).sqlEnter password: [root@centos6 ~]# ll /download/total 2-rw-r--r--. 1 root root 1888 Dec 12 20:34 testbak_2016-12-12.sql下面我们看看这个备份文件到底是什么内容 ...

本篇将介绍如何使用 Docker 部署 MySQL 数据库及远程访问配置 安装 MySQL拉取镜像使用下面的命令拉取 MySQL 数据库的镜像： $ sudo docker pull mysql # 拉取最新版本的镜像，当前为 MySQL 8 版本，tag 为 latest$ sudo docker pull mysql:5.7 # 指定拉取 MySQL 5.7 版本也可以使用搜索命令，查找其他的 MySQL 相关镜像，其中有标识 Stars 数，即受欢迎程度。 $ sudo docker search mysql运行 MySQL$ sudo docker run -p 3306:3306 \ --name mysql \ -v $PWD/conf:/etc/mysql/conf.d \ -v $PWD/logs:/logs \ -v $PWD/data:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORD=your-password \ -d mysql命令说明： -p 3306:3306 ：将容器的 3306 端口映射到主机的 3306 端口。-v $PWD/conf:/etc/mysql/conf.d ：将主机当前目录下的 conf/my.cnf 挂载到容器的 /etc/mysql/my.cnf。-v $PWD/logs:/logs ：将主机当前目录下的 logs 目录挂载到容器的 /logs。-v $PWD/data:/var/lib/mysql ：将主机当前目录下的data目录挂载到容器的 /var/lib/mysql 。-e MYSQL_ROOT_PASSWORD=your-password ：初始化 root 用户的密码,建议使用复杂度高的密码。-d mysql : 要部署的镜像名，如果是5.7版本的话，这里则为mysql:5.7配置远程访问远程访问 MySQL 属于基本配置，但是在配置的时候要注意安全性问题，否则将存在安全性隐患，尤其是企业用服务器更要注重安全性。 ...

如果有人问你“数据库事务有哪些特性”？你可能会很快回答出原子性、一致性、隔离性、持久性即ACID特性。那么你知道InnoDB如何保证这些事务特性的吗？如果知道的话这篇文章就可以直接跳过不看啦(#^.^#) 先说结论： redo log重做日志用来保证事务的持久性undo log回滚日志保证事务的原子性undo log+redo log保证事务的一致性锁（共享、排他）用来保证事务的隔离性重做日志 redo log重做日志 redo log 分为两部分：一部分是内存中的重做日志缓冲（redo log buffer），是易丢失的；二部分是重做日志文件（redo log file），是持久的。InnoDB通过Force Log at Commit机制来实现持久性，当commit时，必须先将事务的所有日志写到重做日志文件进行持久化，待commit操作完成才算完成。InnoDB在下面情况下会将重做日志缓冲的内容写入重做日志文件： master thread 每一秒将重做日志缓冲刷新到重做日志文件;每个事务提交时当重做日志缓冲池剩余空间小于1/2时为了确保每次日志都写入重做日志文件，在每次将日志缓冲写入重做日志文件后，InnoDB存储引擎都需要调用一次fsync（刷盘）操作。但这也不是绝对的。用户可以通过修改innodb_flush_log_at_trx_commoit参数来控制重做日志刷新到磁盘的策略，这个可以作为大量事务提交时的优化点。 1参数默认值，表示事务提交时必须调用一次fsync操作。0表示事务提交时，重做日志缓存并不立即写入重做日志文件，而是随着Master Thread的间隔进行fsync操作。2表示事务提交时将重做日志写入重做日志文件，但仅写入文件系统的缓存中，不进行fsync操作。fsync的效率取决于磁盘的性能，因此磁盘的性能决定了事务提交的性能，也就是数据库的性能。所以如果有人问你如何优化Mysql数据库的时候别忘了有硬件这一条，让他们提升硬盘配置，换SSD固态硬盘重做日志都是以512字节进行存储的，称之为重做日志块，与磁盘扇区大小一致，这意味着重做日志的写入可以保证原子性，不需要doublewrite技术。它有以下3个特性： 重做日志是在InnoDB层产生的重做日志是物理格式日志，记录的是对每个页的修改重做日志在事务进行中不断被写入，而且是顺序写入回滚日志 undo log为了满足事务的原子性，在操作任何数据之前，首先将数据备份到一个地方（这个存储数据备份的地方称为Undo Log），然后进行数据的修改。如果出现了错误或者用户执行了 ROLLBACK语句，系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。undo log实现多版本并发控制（MVCC）来辅助保证事务的隔离性。 回滚日志不同于重做日志，它是逻辑日志，对数据库的修改都逻辑的取消了。当事务回滚时，它实际上做的是与先前相反的工作。对于每个INSERT，InnoDB存储引擎都会完成一个DELETE；对于每个UPDATE，InnoDB存储引擎都会执行一个相反的UPDATE。 事务提交后并不能马上删除undo log，这是因为可能还有其他事务需要通过undo log 来得到行记录之前的版本。故事务提交时将undo log 放入一个链表中，是否可以删除undo log 根据操作不同分以下2种情况： Insert undo log： insert操作的记录，只对事务本身可见，对其他事务不可见(这是事务隔离性的要求),故该undo log可以在事务提交后直接删除。不需要进行 purge操作。update undo log：记录的是对 delete和 update操作产生的 undo log。该undo log可能需要提供MVCC机制，因此不能在事务提交时就进行删除。提交时放入undo log链表,等待 purge线程进行最后的删除。锁事务的隔离性的实现原理就是锁，因而隔离性也可以称为并发控制、锁等。事务的隔离性要求每个读写事务的对象对其他事务的操作对象能互相分离。再者，比如操作缓冲池中的LRU列表，删除，添加、移动LRU列表中的元素，为了保证一致性那么就要锁的介入。 锁的类型InnoDB主要有2种锁：行级锁，意向锁 行级锁： 共享锁（读锁 S），允许事务读一行数据。事务拿到某一行记录的共享S锁，才可以读取这一行，并阻止别的事务对其添加X锁。共享锁的目的是提高读读并发。排它锁（写锁 X），允许事务删除一行数据或者更新一行数据。事务拿到某一行记录的排它X锁，才可以修改或者删除这一行。排他锁的目的是为了保证数据的一致性。行级锁中，除了S和S兼容，其他都不兼容。 意向锁： 意向共享锁（读锁 IS ），事务想要获取一张表的几行数据的共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。意向排他锁（写锁 IX），事务想要获取一张表中几行数据的排它锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。解释一下意向锁 The main purpose of IX and IS locks is to show that someone is locking a row, or going to lock a row in the table.意向锁的主要用途是为了表达某个事务正在锁定一行或者将要锁定一行数据。e.g:事务A要对一行记录r进行上X锁，那么InnoDB会先申请表的IX锁，再锁定记录r的X锁。在事务A完成之前，事务B想要来个全表操作，此时直接在表级别的IX就告诉事务B需要等待而不需要在表上判断每一行是否有锁。意向排它锁存在的价值在于节约InnoDB对于锁的定位和处理性能。另外注意了，除了全表扫描以外意向锁都不会阻塞。 ...

POLARDB是阿里巴巴自主研发的云原生关系型数据库，目前兼容三种数据库引擎：MySQL、PostgreSQL、Oracle。POLARDB的计算能力最高可扩展至1000核以上，存储容量可达100TB。 POLARDB融合了商业数据库稳定、可靠、高性能的特征，同时具有开源数据库简单、可扩展、高速迭代的优势，适合各个行业公司的创新业务使用。本专场中，来自阿里云、江娱互动以及猿辅导的各位技术大咖一起共同探讨了下一代云原生数据库POLARDB。1、云原生数据库的演进方向和客户价值阿里云智能数据库总经理曹伟为大家介绍了云原生数据库的演进方向以及阿里云POLARDB数据库的产品能力。 阿里云RDS和POLARDB都属于OLTP的关系性数据库，那就让我们先看下全球关系型数据库的市场情况。 如今，关系型数据库依旧是“老大哥”，但是过去的十年中关系型数据库领域也发生了一些微妙的变化。伴随着开源运动的兴起和MySQL、PostgreSQL等数据库的出现，很多用户开始在生产系统中大量使用开源数据库，因此商业数据库的市场受到了一定的挤压。 开源数据库的出现影响了整个数据库市场的格局和版图，也为阿里巴巴在数据库市场提供了一个重大的机会。经过十年的时间，阿里云数据库做到了“全国第一，全球领先”。当然，影响数据库格局的重要因素除了开源之外，还有云计算的兴起。 在云时代，数据库的演化经历了从采购License自建到云上托管数据库再到云原生数据库的转变。过去云是云，数据库是数据库，数据库只是部署在云上。但在云原生时代，数据库和云是合二为一的，云就是数据库，数据库就是云。 云原生数据库具有以下的几个发展趋势：弹性：弹性不仅仅是规格的弹性，而是未来CPU、容量等计算资源都可以按量付费。 HTAP：之前TP和AP是分开处理的，TP使用关系型数据库，而AP使用大数据存储。未来则会融合两者，提供一个入口跑事务，一个入口跑报表和BI。 智能：智能让数据库更加实用，未来数据库的磁盘备份、内存调度等都不需要DBA来操作，而是全部由数据库自己来完成。此外，数据库还能够自动完成诊断和修复。 混合云：因为一些合规的要求，并不是所有数据都能跑在云上，因此还需要使用这种云上云下互联的生态。云原生数据库已经成为了一种趋势，智能和混合负载成为了用户使用数据库必须依赖的特性。而由于这些特性具有非常高的技术门槛，因此在未来的两到三年内，云原生技术落后的数据库厂商必将会被淘汰。 对于很多企业而言，如果采用自建数据库方案，那么无论是对于研发还是运维而言，都会带来很多痛点，比如： 活动上线时造成压力突增，而数据库却来不及升级； 业务发展很快，来不及进行拆库，也来不及分库分表； 应用扩容之后，上百台ECS连接一台数据库，因此在高并发下性能很差； 使用读写分离，但是刚更新的数据却查询不到； 主从复制经常中断； 一次全量数据备份需要大量时间，并且必须锁表等。这些都是互联网公司在使用自建数据库时会遇到的问题。那么，如何解决这些问题呢？答案就是需要一个强大的云原生数据库。 因此，阿里云提供了POLARDB数据库。POLARDB基于业界先进的Shared-Everything架构，简单而言，就是借助高速的RDMA网络将所有数据库节点连接在同一网络下。POLARDB采用计算与存储分离的架构，数据节点是无状态的，因此一旦发生宕机可以随时进行迁移。 对于企业级数据库而言，一般会从可靠性、可用性、性能、弹性、成本和易用性这六个方面进行评价。 在可靠性方面，POLARDB基于Parallel Raft协议并借助RDMA能够做到RPO=0。此外，POLARDB基于TCP的远程物理复制技术实现了跨AZ的容灾。 在可用性方面，POLARDB借助Parallel Raft复制技术使得单节点存储切换RTO控制在10毫秒以内，基于Warm Buffer Pool技术使得读写节点重启速度加快4倍以上，并且基于跨节点物理复制技术使得日志并发应用的节点间延迟控制在100毫秒以内。 在性能方面，POLARDB使用了高速硬件和用户态I/O协议栈，使得计算节点的写延迟小于100us，而读带宽大于4GB/s。除此之外，还在I/O上进行了优化，借助Parallel Query技术使得TPC-H性能提升超过25倍。 在成本方面，POLARDB这样的云原生数据库的成本往往低于传统的托管数据库。这是因为企业在使用POLARDB时可以按需扩容，弹性伸缩，而这是在实现存储与计算分离的云原生架构诞生之前无法实现的。目前来看，相较于RDS，使用POLARDB将会使得成本降低约44%，这就是技术释放的红利。 在易用性方面，POLARDB可以100%兼容RDS，并且可以在阿里云上一键将RDS替换为POLARDB，此外还提供了智能读写分离、性能洞察以及SQL审计等优秀的功能。 此外，POLARDB在2019年也实现了技术的全面升级。首先，POLARDB MySQL 8.0兼容版于9月12日正式发布，这是全球第一个兼容MySQL 8.0版本的云原生数据库。其次，POLARDB分布式数据库服务也正式发布，其存储容量支持最多超过100TB。再次，POLARDB的高性能存储引擎X-Engine即将发布，X-Engine存储引擎具有高性能和高压缩率，并且经历了2018年双11的实战考验。此外，POLARDB对于Oracle的语法兼容性特性也即将实现商业化，能够为用户带来将近6倍的成本降低。此外，本次的云栖大会上还正式发布了POLARDB一体机，它能够更好地帮助用户在私有云上使用POLARDB数据库。 目前，阿里云POLARDB数据库已经成了增长最快的云数据库产品，未来也将会提供更多的特性，为客户带来更多的价值。 2、POLARDB MySQL存储引擎优化实践杨辛军（Jimmy Yang） 阿里云智能资深技术专家为大家介绍了阿里云POLARDB 8.0基于MySQL 8.0所做的存储引擎优化实践。 POLARDB实现了快速高效的物理复制，使得IO操作减少了50%，同时能够达到100T的存储容量。与此同时，相比于原本的逻辑复制，POLARDB的物理复制更加可靠、高效，并且对于性能影响几乎不可见。传统的逻辑复制比物理复制延迟大很多，而且可能会出现系统堵塞，对业务造成影响，物理复制则不会产生这样的影响。此外，POLARDB基于共享存储还实现了非堵塞、低延迟的DDL复制，并且支持快速动态的读扩展，最高支持扩展到16个只读节点。 POLARDB是全球第一个具有高效物理复制的，共享存储并兼容MySQL 8.0的云数据库。POLARDB不仅包含了MySQL 8.0的所有重要功能，还在MySQL内核引擎的基础之上进行了大量的优化。 虽然POLARDB使用了物理复制，但是基于客户对于数据进行数据分析和传输需要Binlog的考虑，POLARDB也支持了Binlog。在性能优化方面，POLARDB最新的“Copy Page”功能减少了主节点Flush Constraint。POLARDB对于逻辑锁系统进行了分区，减少了mutex的冲突，并且将死锁检测实现了并行化。POLARDB对于Transaction System也进行了优化，使用Lock Free数据结构来管理Transaction System的Lists。 相比于POLARDB 5.6版本，POLARDB 8.0版本在性能表现上有了显著提升，在关键情况下都有了数倍的改进。相比于MySQL 8.0的官方版本，POLARDB 8.0的优化改进所带来的效果也非常明显，尤其是物理复制方面具有显著的优势，在Insert情况下POLARDB性能可达到MySQL的约6倍。 官方MySQL向8.0版本演进时过于重视高配机型的适配，而忽略了小型机的性能。而云上用户大部分还是用的8核、16核的小型机，因此使用MySQL8.0的性能会发生退化。因此，阿里云POLARDB数据库针对于这个问题进行了一系列优化。 相较于MySQL 8.0，阿里云POLARDB 8.0版本提供了更多的内核引擎功能，比如独立可扩展的共享Buffer Pool、行级压缩、全球实例支持、并行DDL、分区表自建索引以及自建分区表等。 3、POLARDB MySQL并行查询优化详解阿里云智能资深技术专家封仲淹为大家详细介绍了POLARDB基于MySQL 8.0内核所做的并行查询优化。并行查询是POLARDB 8.0版本重磅推出的一个特性，阿里云POLARDB团队投入了大量人力和物力来开发这个特性，并且从目前来看，客户对于并行查询的反馈非常好。 首先思考一个问题：为什么需要并行查询？阿里使用MySQL的历史已经过了十余年，在MySQL使用中遇到的所有问题，阿里基本都遇到过。其中最令人头痛的问题就是当MySQL表的数据量特别大时，查询会非常的慢。大部分方案都是通过拆库将数据量缩小。 此外，业界的一个趋势CPU单核频率达到了瓶颈，增长放缓。而我们对于计算能力的诉求是永无止境的，因此CPU只能向着多核演进。而MySQL属于传统事务型数据库，其无法并行执行单条Query，因此无法充分利用多核的作用。业界的通用做法就是并行查询，如今几乎所有商业数据库都提供并行查询的能力，将任务分摊给多个线程并行计算，大幅度缩短计算时间。 那么，如何实现并行查询呢？并行查询首要关注的就是数据分区，这样才能使得每个Worker同时工作，互不干扰。由优化器决定分区的数量，并且让 Worker与分区动态绑定，实现“能者多劳”，防止热点问题的出现，使得计算更加均匀，保障了并行查询的线性性能提升。在并行计算里面，将单线程Plan Tree改为了多线程，划分Worker和Leader两个角色，尽可能将所有算子下推到Worker中，利用Worker并行能力加速，而让Leader做汇总和反馈。 ...

很多人，这里说的是运维工程师们，一提到写某某方案，很是头疼。不是上某度一统搜索，就是同样一句话在N个群全部群发一遍：“有没有某某方案，可以共享一下的吗？？求助，各位大佬们”，估计十有八九，全部石沉大海，杳无音讯。 其实，到底是真的很难，还是说你没有完全掌握整个备份思路的整理？一个方案的好坏，在于对于外行人来说，能不能一眼就能看懂其中要表达的意思，而且不需要很多的思考就可以。 一份好的备份方案无非包括以下几点： 为什么需要备份？备份的方式有哪些？某几种备份方式的区别在哪？备份实战操作概述恢复实战操作概述其它备注信息那么，此文将从以上几个角度，结合一些实际的实战经验，分步阐述一个完整的备份方案到底是怎么样构成的。需要学习更多Mysql数据库相关的知识，可以在公众号：民工哥技术之路的后台回复「MySQL」即可获取一份最全的MySQL数据库学习指南。 为什么需要数据库备份？很多人，一看这标题，肯定张口就会答，这不是废话么。不备份故障了怎么办？跑路吗？数据被沙雕开发（不许喷）误删了怎么办？背锅吗？ 当然，大家都知道备份的重要性与必要性。 1、保证数据安全与完整 企业的数据安全应该来说是企业的命脉，一旦丢失或造成损坏，轻则损失客户与金钱，重则倒闭（已经有前例在）。 备份的目的：为了保证数据在被人为失误、操作不当、蓄意等情况下删除或损坏后，能及时、有效的进行恢复并不会很大程度上影响到业务运行。 2、为业务提供不间断服务 实际生产环境对数据库的要求，首先就是具备7×24×365不间断服务的能力，这也是一定要备份数据库的其中原因之一。 数据库的备份方式常用的备份方式包括以下： 逻辑备份物理备份1、逻辑备份 逻辑备份其实就是利用MySQL数据库自带的mysqldump命令，或者使用第三方的工具，然后把数据库里的数据以SQL语句的方式导出成文件的形式。在需要恢复数据时，通过使用相关的命令（如：source ）将备份文件里的SQL语句提取出来重新在数据库中执行一遍，从而达到恢复数据的目的。 实例如下： mysqldump -A -B --single-transaction >/server/backup/mysql_$(date +%F).sql一般备份时都会进行压缩处理，以节省磁盘空间，如下 mysqldump -A -B --single-transaction ｜gzip>/server/backup/mysql_$(date +%F).sql.gz恢复操作 cd /server/backup/gzip -o mysql_$(date +%F).sql.gzmysql -uroot -pMyadmin -h mysqldb.mingongge.com> source /server/backup/mysql_$(date +%F).sql逻辑备份的优点与使用场景 优点：简单，易操作，自带工具方便、可靠。 使用场景：数据库数据量不大的情况可以使用，数据量比较大（超过20G左右）时备份速度比较慢，一定程度上还会影响数据库本身的性能。 2、物理备份 物理备份就是利用命令（如cp、tar、scp等）直接将数据库的存储数据文件复制一份或多份，分别存放在其它目录，以达到备份的效果。 这种备份方式，由于在备份时数据库还会存在数据写入的情况，一定程度上会造成数据丢失的可能性。在进行数据恢复时，需要注意新安装的数据的目录路径、版本、配置等与原数据要保持高度一致，否则同样也会有问题。 所以，这种物理备份方式，常常需要在停机状态下进行，一般对实际生产中的数据库不太可取。因此，此方式比较适用于数据库物理迁移，这种场景下这种方式比较高效率。 物理备份的优点及使用场景 优点：速度快，效率高。 场景：可用于停机维护及数据库物理迁移场景中。 实际生产环境中，具体使用哪种方式，就需要看需求与应用场景所定。 全量与增量备份概述在介绍完备份方式之后，再来介绍一下，增量与全量备份这两个概念。 什么是全量备份？ 全量备份：就是将数据库中的所有数据，或者是某一个特定的库里的所有数据，一次全部备份下来。 备份数据库中所有数据 mysqldump -A -B --single-transaction ｜gzip>/server/backup/All_data_$(date +%F).sql.gz备份某个库的数据 mysqldump -A -B --single-transaction testDB1｜gzip>/server/backup/testDB1_$(date +%F).sql.gz什么是增量备份？ ...

docker搭建MySQL教程本教程非零基础教程，本教程不需要你具备docker和docker-compose基本知识，照葫芦画瓢也能把代码仓库搭建起来使用，但如果对docker和docker-compose感兴趣的可以在网上找一下相关的教程学习，后面也会出一个简单的docker入门教程，前提是机器必须先安装好了docker和docker-compose。本教程搭建mysql数据是为了搭建代码仓库gogs做准备的，这里不对mysql做过多的解析，做开发的都知道MySQL是干嘛用的。 MySQL搭建创建项目1.命令行输入以下命令创建项目： > mkdir docker注意：该命令只在类unix系统生效的，window系统的可以使用makedir docker或者手动创建 2.进入项目目录并创建docker-compose.yml文件： > cd docker && touch docker-compose.yml注意：该命令只在类unix系统生效的，window系统的可以使用type null>docker-compose.yml或者手动创建 3.编辑docker-compose.yml: > vim docker-compose.yml添加mysql的编排内容： version: "3"networks: frontend:services: mysql: image: mysql:${MYSQL_VERSION} networks: frontend: tty: true restart: always ports: - 3306:3306 volumes: - ${DATA_DIR}/mysql/:/var/lib/mysql environment: - MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD} - MYSQL_USER=${MYSQL_USER} - MYSQL_PASSWORD=${MYSQL_PASSWORD}编排内容中的DATA_DIR、MYSQL_ROOT_PASSWORD、MYSQL_USER、MYSQL_PASSWORD是环境变量，我们可以项目的根目录创建.env文件： > vim .env在.env中定义环境变量： #容器映射数据存储的路径DATA_DIR=./data#mysql相关环境变量的定义MYSQL_VERSION=5.7 #mysql数据库的版本MYSQL_ROOT_PASSWORD=root # root账户的密码MYSQL_USER=default # 创建一个default用户MYSQL_PASSWORD=secret # default用的密码mysql的编排内容就绪完毕。 4.启动MySQL > docker-compose up -d mysql如果是第一次启动会进行build构建进行，等待构建完成后，MySQL容器就启动成功了。 测试MySQL这里使用navicat进行测试的，添加MySQL链接，然后填入主机，端口，账号，密码，点击链接测试。 出现该界面证明MySQL搭建成功。 更多精彩文章，请关注我的博客SOCKSTACK，分享我的工作经验。

本文由 简悦 SimpRead 转码， 原文地址 https://hitzhangjie.github.io...在介绍 select-case 实现机制之前，最好先了解下 chan 操作规则，明白 goroutine 何时阻塞，又在什么时机被唤醒，这对后续理解 select-case 实现有帮助。所以接下来先介绍 chan 操作规则，然后再介绍 select-case 的实现。 1.1 chan 操作规则 1当一个 goroutine 要从一个 non-nil & non-closed chan 上接收数据时，goroutine 首先会去获取 chan 上的锁，然后执行如下操作直到某个条件被满足： 1）如果 chan 上的 value buffer 不空，这也意味着 chan 上的 recv goroutine queue 也一定是空的，该接收 goroutine 将从 value buffer 中 unshift 出一个 value。这个时候，如果 send goroutine 队列不空的情况下，因为刚才 value buffer 中空出了一个位置，有位置可写，所以这个时候会从 send goroutine queue 中 unshift 出一个发送 goroutine 并让其恢复执行，让其执行把数据写入 chan 的操作，实际上是恢复该发送该 goroutine 执行，并把该发送 goroutine 要发送的数据 push 到 value buffer 中。然后呢，该接收 goroutine 也拿到了数据了，就继续执行。这种情景，channel 的接收操作称为 non-blocking 操作。 ...

现如今很多 win7系统 用户的工作都延伸到了休息时间，很多win7系统用户下班之后回到家还要继续工作，如果公司员工有什么问题，一般情况下需要通过Windows远程桌面连接帮忙解答，尤其是对于互联网行业的用户。现在很多用户使用的是win7系统，但还是有一部分的用户继续使用着xp系统，那么就遇到一个问题，win7系统如何远程管理xp系统桌面呢？下面小编就以 win7 64位系统 为例，为大家介绍远程win7系统远程管理xp系统桌面的解决方法！如果不想碰到那么多的问题的话，我们可以用更专业的iis7远程桌面管理工具来直接管理，iis7远程桌面连接工具，又叫做iis7远程桌面管理软件，是一款绿色小巧，功能实用的远程桌面管理工具，其界面简洁，操作便捷，能够同时远程操作多台服务器，并且多台服务器间可以自由切换，适用于网站管理人员使用。　开启客户端电脑的远程桌面连接　1、进行远程桌面管理前，先对被管理的xp系统电脑进行设置；　2、进入客户端系统，创建一个管理员账户并设置密码；　3、右击桌面的“我的电脑”图标，选择“属性”选项；　4、出现窗口，切换到“计算机名”选项卡，单击“更改”按钮；　5、设置当前电脑的计算机名和工作组，工作组和管理员的工作保持一致；　6、修改后单击“确定”要重新启动电脑；　7、切换到“远程选项”，选择“远程桌面”下的“允许用户远程连接到此计算机”；　8、单击“选择远程用户”按钮出现对话框，单击“高级”；　9、在单击“立即查找”按钮选择创建的管理员账户，再连续单击“确定”按钮即可。　设置Windows 7系统　1、单击“开始→所有程序→附件→远程桌面连接”，单击“选项”按钮；　2、展示设置面板，输入远程计算机名和账户，出 现提示框选择“是”进行连接；　3、连接后会要求输入远程计算机当前登录账户的密码，输入密码；　4、单击“确定”即可登录到远程计算机；　5、切换到“显示”选项设置远程计算桌面的分辨率；　6、在“本地资源”选项中可设置远程计算机的音频、键盘、打印机等属性；　7、在“程序”选项中可设置连 接到远程计算机时，自动启动远程计算机中的某个程序；　8、在“体验”中可设置连接速度，取消某些远程计算机的设置等，如果感觉连接速度慢，可取消远程计算机的桌面背景等功能。

MongoDB 使用 BI Connector 来支持 BI 组件直接使用 SQL 或 ODBC 数据源方式直接访问 MongoDB，在早期 MongoDB 直接使用 Postgresql FDW 来实现 SQL 到 MQL 的转换，后来实现更加轻量级的 mongosqld 来支持 BI 工具的连接。 安装 BI Connector参考 Install BI Connector wget https://info-mongodb-com.s3.amazonaws.com/mongodb-bi/v2/mongodb-bi-linux-x86_64-rhel70-v2.12.0.tgz$tar xvf mongodb-bi-linux-x86_64-rhel70-v2.12.0.tgzmongodb-bi-linux-x86_64-rhel70-v2.12.0/LICENSEmongodb-bi-linux-x86_64-rhel70-v2.12.0/READMEmongodb-bi-linux-x86_64-rhel70-v2.12.0/THIRD-PARTY-NOTICESmongodb-bi-linux-x86_64-rhel70-v2.12.0/example-mongosqld-config.ymlmongodb-bi-linux-x86_64-rhel70-v2.12.0/bin/mongosqldmongodb-bi-linux-x86_64-rhel70-v2.12.0/bin/mongodrdlmongodb-bi-linux-x86_64-rhel70-v2.12.0/bin/mongotranslatemongosqld 接受 SQL 查询，并将请求发到 MongoDB Server，是 BI Connector 的核心mongodrdl 工具生成数据库 schema 信息，用于服务 BI SQL 查询mongotranslate 工具将 SQL 查询转换为 MongoDB Aggregation Pipeline启动 mongosqld参考 Lauch BI Connector mongodb-bi-linux-x86_64-rhel70-v2.12.0/bin/mongosqld --addr 127.0.0.1:3307 --mongo-uri 127.0.0.1:9555--addr 指定 mongosqld 监听的地址--mongo-uri 指定连接的 MongoDB Server 地址默认情况下，mongosqld 自动会分析目标 MongoDB Server 里数据的 Schema，并缓存在内存，我们也可以直接在启动时指定 schema 影射关系。schema 也可以直接 mongodrdl 工具来生成，指定集合，可以将集合里的字段 shema 信息导出。 ...

跳表（skip list） 查询数据的时间复杂度是 O(n)插入操作的时间复杂度是 O(n)删除操作的时间复杂度是 O(n)索引动态更新的时间复杂度 O(1)B+ 树（B+tree）

PS：文章整理的知识内容及资料均来自极客时间《SQL必知必会》专栏 MySQL的InnoDB引擎支持事务，MyISAM不支持事务；事务基础事务的4大特性：ACID A，也就是原子性（Atomicity）。原子的概念就是不可分割，可以把它理解为组成物质的基本单位，也是我们进行数据处理操作的基本单位，换句话说是：要么完全执行，要么全都不执行；C，就是一致性（Consistency）。一致性指的就是数据库在进行事务操作后，会由原来的一致状态，变成另一种一致的状态。也就是说当事务提交后，或者当事务发生回滚后，数据库的完整性约束不能被破坏；I，就是隔离性（Isolation）。它指的是每个事务都是彼此独立的，不会受到其他事务的执行影响。也就是说一个事务在提交之前，对其他事务都是不可见的；D，指的是持久性（Durability）。事务提交之后对数据的修改是持久性的，即使在系统出故障的情况下，比如系统崩溃或者存储介质发生故障，数据的修改依然是有效的。因为当事务完成，数据库的日志就会被更新，这时可以通过日志，让系统恢复到最后一次成功的更新状态。持久性是通过事务日志来保证的。日志包括了回滚日志和重做日志。当我们通过事务对数据进行修改的时候，首先会将数据库的变化信息记录到重做日志中，然后再对数据库中对应的行进行修改。这样做的好处是，即使数据库系统崩溃，数据库重启后也能找到没有更新到数据库系统中的重做日志，重新执行，从而使事务具有持久性。事务的常用操作语句 START TRANSACTION 或者 BEGIN，作用是显式开启一个事务。COMMIT：提交事务。当提交事务后，对数据库的修改是永久性的。ROLLBACK 或者 ROLLBACK TO [SAVEPOINT]，意为回滚事务。意思是撤销正在进行的所有没有提交的修改，或者将事务回滚到某个保存点。SAVEPOINT：在事务中创建保存点，方便后续针对保存点进行回滚。一个事务中可以存在多个保存点。RELEASE SAVEPOINT：删除某个保存点。SET TRANSACTION，设置事务的隔离级别。使用事务有两种方式，分别为隐式事务和显式事务。隐式事务实际上就是自动提交，Oracle 默认不自动提交，需要手写 COMMIT 命令，而 MySQL 默认自动提交，当然我们可以配置 MySQL 的参数：MySQL 中 completion_type 参数对于事务的作用completion_type=0，这是默认情况。也就是说当我们执行 COMMIT 的时候会提交事务，在执行下一个事务时，还需要我们使用 START TRANSACTION 或者 BEGIN 来开启。CREATE TABLE test(name varchar(255), PRIMARY KEY (name)) ENGINE=InnoDB;BEGIN;INSERT INTO test SELECT '关羽';COMMIT;INSERT INTO test SELECT '张飞';INSERT INTO test SELECT '张飞';ROLLBACK;SELECT * FROM test;运行结果（1 行数据）： completion_type=1，这种情况下，当我们提交事务后，相当于执行了 COMMIT AND CHAIN，也就是开启一个链式事务，即当我们提交事务之后会开启一个相同隔离级别的事务（隔离级别会在下一节中进行介绍）。CREATE TABLE test(name varchar(255), PRIMARY KEY (name)) ENGINE=InnoDB;SET @@completion_type = 1;BEGIN;INSERT INTO test SELECT '关羽';COMMIT;INSERT INTO test SELECT '张飞';INSERT INTO test SELECT '张飞';ROLLBACK;SELECT * FROM test;运行结果（2 行数据）： ...

10月4日消息 据中新网报道，10月2日，国际事务处理性能委员会（Transaction Processing Performance Council，简称TPC）公布了数据库最新性能测试结果，阿里巴巴关联公司蚂蚁金服自主研发的数据库位列第一位。 蚂蚁金服自主研发的数据库OceanBase打破数据库基准性能测试的世界记录，成绩是前世界记录保持者、老牌巨头甲骨文（Oracle）的两倍。数据库领域最权威的国际机构国际事务处理性能委员会（TPC，Transaction Processing Performance Council）在官网发表了这一最新结果。

锁锁机制用于管理对共享资源的并发访问。 lock和latch在数据库中，lock和Latch都称为锁，但是两者意义不同。 latch称为闩锁（shuang suo），其要求锁定的时间必须非常短。若持续的时间长，则应用的性能会非常差。在InnoDB存储引擎中，latch又分为mutex互斥锁 和 rwLock读写锁。其目的是为了保证并发线程操作临界资源的正确性。通常没有死锁的检测机制。 lock的对象是事务，用来锁定的是数据库中的对象，如表、页、行。并且一般lock的对象仅在事务commit或者rollback后进行释放。有死锁检测机制。 通过show engine innodb mutex可以查看InnoDB存储引擎的中latch，具体字段详情如下表： 锁的类型有几个索引，需要分别向索引加锁。 共享锁、排他锁InnoDB存储引擎实现了如下两种标准的行级锁： 共享锁（S Lock）：允许事务读一行数据 排他锁（X Lock）：允许事务删除 或 更新一行数据 如果一个事务T1已经获取了行r的共享锁，那么另外的事务T2可以立即获得行r的共享锁。因为读取并不会改变行的数据，所以可以多个事务同时获取共享锁，称这种情况为锁兼容。但若有其他的事务T3想获得行R的排他锁，则其必须等待事务T1、T2释放行r上面的共享锁，称这种情况为锁不兼容。下面显示了共享锁和排他锁的兼容性： 从表6-3可以看出X锁与任何锁都不兼容，而S锁仅和S锁兼容。S锁和X锁都是行锁，兼容是指对同一行记录锁的兼容情况。 普通 select 语句默认不加锁，而CUD操作默认加排他锁。 记录锁Record Lock，仅锁定一行记录（如共享锁、排他锁） 记录锁总是会去锁定索引记录，如果表在建立的时候，没有设置任何一个索引，那么InnoDB会使用隐式的主键来进行锁定。查询条件的列是唯一索引的情况下，临建锁退化为记录锁间隙锁Gap Lock，锁定一个范围，但不包含记录本身。 关闭间隙锁的2种方式： （1）将事务隔离级别变为read committed （2）将参数innodb_locks_unsafe_for_binlog设置为1 在上述配置下，除了外键和唯一性检查依然需要间隙锁，其余情况仅适用行锁进行锁定。 临键锁Next-Key Lock，等于记录锁 + 临键锁，锁定一个范围，并且锁定记录本身。主要是阻止多个事务将记录插入到同一个范围内，从而避免幻读。 假如一个索引有10、11、13、20这四个值，那么该索引可能被锁定的区间为： 若事务T1已经通过临键锁锁定了如下范围： 当插入新的记录12时，则锁定的范围变成： 当查询的索引是唯一索引的时候，InnoDB会将临键锁优化成记录锁，从而提高并发。这时候，将不再由间隙锁避免幻读的问题，但是试验了下，即使优化成记录锁，也不会有幻读的问题，其实是因为MVCC，在可重复读的情况下，SELECT操作只会查找行版本号小于当前事务版本号的记录，其他事务（事务开启时间比当前事务晚）新插入的记录版本号不满足条件，就不会查出来。 对于辅助索引，当执行类似select * from z where b = 3 for update;加锁语句时，会加上临键锁，并且下一个键值的范围也会加上间隙锁。 值得注意的是，对于唯一键值的锁定，由临键锁优化为记录锁，仅存在于查询所有的唯一索引。若唯一索引由多列组成，而查询仅是查找多个唯一索引中的一个，那么查询其实是range类型查询，而不是point类型查询，故InnoDB存储引擎还是继续使用临键锁。 在InnoDB存储引擎中，通过使用临键锁来避免不可重复读的问题（即幻读）。在使用临键锁的情况下，对于索引的扫描，不仅仅锁住扫描的到索引，而且还锁住这些索引覆盖的范围。因此，在这些范围内插入都是不允许的。这样子就避免了其他事务在这些范围内插入数据导致不可重复读的问题。 意向锁概念：未来的某个时刻，事务可能要加共享/排它锁了，先提前声明一个意向 意向锁有这样一些特点： （1）意向锁是表级别的锁 （2）意向锁分为： 意向共享锁(intention shared lock, IS)，它预示着，事务有意向对表中的某些行加共享S锁意向排它锁(intention exclusive lock, IX)，它预示着，事务有意向对表中的某些行加排它X锁（3）意向锁协议： ...

第二章 盲注注意: 本文大部分内容都是参考mysql注入天书学习篇何为盲注?盲注就是在 sql 注入过程中, sql 语句执行的选择后, 选择的数据不能回显 到前端页面. 此时, 我们需要利用一些方法进行判断或者尝试, 这个过程称之为盲注,这种情况下往往需要一个一个字符的去猜解, 需要用到截取字符串. 0x01 基于布尔 SQL 盲注我们可以利用逻辑判断进行盲注, 而布尔注入能够利用的根本就是, 我们能够看到true和false返回页面内容不一致 因为不知道字段是怎样的, 因此只能一个字符一个字符的猜, 所以这里我们需要先学习字符串截取函数:left(), right(),substr(), substring(), mid(), 以及经常一起配套使用的ascii转换函数ascii(), ord(), 最后还有一些配合使用的mysql语句: IF(),IFNULL(),SELECT CASE WHEN left()和right()语法如下: left(string, n)--得到字符串string左边n个字符right(string, n)--得到字符串string右边n个字符一般地, 我们使用left(database(),1) > 'a',查看数据库名第一位, left(database(),2) > 'ab',查看数据库名前二位. right()用法类似, 只不过方向反了 , 从后往前 substr(), substring(), mid()substr(), substring(), mid()函数实现的功能是一样的, 均为截取字符串, 而且用法相同 用法1: substr(str, pos, len)用法2: substr(str FROM pos FOR len)--从字符串str的第pos个字符串开始取, 只取len个字符--str: 要处理的字符串--pos: 开始的位置(初始值是1)--len: 截取的长度ps: substr(str FROM pos FOR len)是应对逗号被过滤的情况比方说, 从abcde的第二个字符开始取, 只取3个字符, 这里分别演示substr(), substring()和mid()函数 ...

原文链接：http://www.studyshare.cn/blog... 一、概念 适配器模式：作为两个不兼容接口之间的桥梁，可以将一个类的接口转换为我们希望的另外一个接口，使用适配器模式可以让原本由于接口不兼容而不能一起工作的那些类可以一起工作。如下图所示： java开发工具下载地址及安装教程大全，点这里。 更多深度技术文章，在这里。 二、应用场景 1、当调用双方都不太容易修改，但又为了复用现有组件，那么可以使用适配器模式进行转换。 2、在系统中接入第三方组件的时候，例如日志组件、支付组件等。可使用适配器模式。 三、案例 此处以接入一个第三方支付组件为例，详细说明适配器模式的使用方式。 假如现在需要开发一个支付功能，对外暴露一个接口，希望这个支付接口可以给其他系统提供多种支付功能（微信支付、支付宝支付、银联支付等），这是一种典型的适配器模式使用场景，第三方的支付组件（微信支付、支付宝支付、银联支付）通过适配器转换为提供出去的统一接口被调用。其他系统只需要调用暴露的统一接口即可。 代码实现： 1、支付宝、微信、银联支付组件 2、统一支付接口 3、适配器类 4、测试类 总结：在合适的场景合理使用适配器模式，上面适用场景1提出在调用双方都不方便修改的时候，例如为了适应自己的业务系统去要求支付宝修改这是不现实的。但是如果是本公司内部的两个或者多个业务子系统之间，能修改的情况尽可能修改，因为使用过多的适配器模式去实现无疑会增加系统的复杂性，不利于代码可读性，系统可维护性，此时设计人员需考虑对系统进行重构。 java开发工具下载地址及安装教程大全，点这里。 更多深度技术文章，在这里。 原创文章，转载请注明出处。

第一章 基础知识在我们的应用系统使用 sql 语句进行管理应用数据库时，往往采用拼接的方式形成一条完整的数据库语言，而危险的是，在拼接 sql 语句的 时候，我们可以改变 sql 语句。从而让数据执行我们想要执行的语句，这就是我们常说的 sql 注入。本章将介绍一些 mysql 注入的一些基础知识, 可能知识有点多, 希望大家认真看一遍, 实操一遍. 学习篇0x01 注入的分类下面这个是阿德玛表哥的总结的，现在理解不了可以跳过 0x02 系统函数这里介绍几个常用函数, 自己实操的话, 可以直接点击Kitematic的EXEC运行一个终端, 然后使用mysql -uroot进入mysql version()——MySQL 版本 user()——数据库用户名 database()——数据库名 @@datadir——数据库路径 @@version_compile_os——操作系统版本 0x03 字符串连接函数在select数据时, 我们往往需要将数据进行连接后进行回显. 很多的时候想将多个数据或者多行数据进行输出的时候, 需要使用字符串连接函数. 而在mysql中，常见的字符串连接函函数有concat(), group_concat(), concat_ws(). 举个例子, 不使用字符串连接函数时 但是这里存在的一个问题是, 当使用union联合注入时, 我们都知道, 联合注入要求前后两个选择的列数要相同, 这里id, username是两个列, 当我们要一个列的时候, (即回显位只有一个)该怎么办? 这时候就需要用到字符串连接函数了 concat()语法如下: concat(str1,str2,...)--没有分隔符地连接字符串--返回结果为连接参数产生的字符串--如有任何一个参数为NULL, 则返回值为 NULL--可以有一个或多个参数一般的我们都要用一个字符(这里是逗号)将各个项隔开, 便于数据的查看. 见下图: 下图是参数中有NULL的情况 concat_ws()语法如下: concat_ws(separator,str1,str2,...)--含有分隔符地连接字符串, 分隔符的位置会放在要连接的两个字符串之间--Separator为字符之间的分隔符, 可以是一个字符串, 也可以是其它参数--如果分隔符为 NULL, 则结果为 NULL--函数会忽略任何分隔符参数后的 NULL 值 ...

一、如何选择在mysql中，我们要查询一条或多条数据，都会通过索引来更快的查询数据，通常每条数据都会有一个主键ID用来构建索引方便查询。由于那么主键ID该选怎么选呢？ 二、自增主键ID自增主键ID通常都会选择int类型或者long类型。 它的优点是:简单方便，有序递增，方便排序和分页等。 缺点：1.随着业务的增长，当id达到int最大值或者long最大值时，服务将不可用，存在上限问题。2.简单递增容易被其他人猜测利用，通过id数来判断新增多少条数据或是用做他途。3.根据业务需要分库分表时，会有id重复等问题。 试用场景：比较适合数据量不多，并发量比较小的情况下使用。 三、UUIDUUID是通用唯一识别码（Universally Unique Identifier)的缩写，开放软件基金会(OSF)规范定义了包括网卡MAC地址、时间戳、名字空间（Namespace）、随机或伪随机数、时序等元素。利用这些元素来生成UUID。 UUID是由128位二进制组成，一般转换成十六进制，然后用String表示。java中自带UUID类,有4种不同的UUID的生成策略: randomly : 基于随机数生成UUID，由于Java中的随机数是伪随机数，其重复的概率是可以被计算出来的。time-based : 基于时间的UUID,这个一般是通过当前时间，随机数，和本地Mac地址来计算出来，自带的JDK包并没有这个算法的我们在一些UUIDUtil中，比如我们的log4j.core.util，会重新定义UUID的高位和低位。DCE security : DCE安全的UUID。name-based ：基于名字的UUID，通过计算名字和名字空间的MD5来计算UUID。 UUID的优点:通过本地生成，没有经过网络I/O，性能较快无序，无法预测生成顺序（也是缺点之一）。不会出现重复 缺点：使用字符串进行存储，占用一定的存储空间，需要排序的时候会比较麻烦，查询相对较慢 适用场景：可以为不需要担心过多的空间占用的情况下，以及不需要生成有递增趋势的数字的场景 四、雪花算法生成ID该算法是推特开源的snowflake（雪花）算法，用来生成分布式ID的。其目的是生成一个64bit的整数: 1bit:一般是符号位，不做处理41bit:从开始用的时间开始算，用来记录时间戳，这里可以记录69年。如果真用完了呢。。。那也是年轻人去解决的事了。。。10bit:10bit用来记录机器ID，总共可以记录1024台机器，一般用前5位代表数据中心，后面5位是某个数据中心的机器ID12bit:循环位，用来对同一个毫秒之内产生不同的ID，12位可以最多记录4095个，也就是在同一个机器同一毫秒最多记录4095个，多余的需要进行等待下毫秒。 优点：整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞(由数据中心ID和机器ID作区分)，并且效率较高，经测试，SnowFlake每秒能够产生26万ID左右 缺点：1.过分依赖机器时钟，如果机器时钟回拨，会导致重复ID生成2.根据雪花算法，在单机上是绝对递增的，但是由于设计到分布式环境，每台机器上的时钟不可能完全同步，有时候会出现不是全局递增的情况（一般分布式ID只要求趋势递增，并不会严格要求递增。我觉得正常配置雪花算法的情况下国内并发量使用雪花算法出问题的公司不会有太多。。） 适用场景：应用在分布式系统中，适用于并发量大的场景。 五、结尾根据自身系统服务的情况来选择生成的主键ID。上面三种我们公司都有用到，看了看数据库里的表，感觉头有点大。。

前言前段时间接手了一个公司内部使用的API调用统计的项目，最近突然频繁的收到慢SQL的告警，正好最近在学习这块的内容，来练把手吧。 实操这条慢SQL主要涉及了两个表。 API_RESULT —— 用于统计api调用结果(数据量为6000W+)DESC API_RESULT; SHOW INDEX FROM API_RESULT; API —— 用于记录api信息(数据量为2000+)DESC API; SHOW INDEX FROM API; 具体慢SQL SELECT SUM(CALL_TIMES) AS TCALLTIMES, SUM(SUCCESS_TIMES) AS TSUCCESSTIMES, SUM(ERROR_TIMES) AS TERRORTIMES FROM API_RESULT AR JOIN API A ON A.API_NAME = AR.API WHERE AR.COUNT_DATE = '2019-08-22' AND A.FREE = '2'; 照着套路来：EXPLAIN SELECT SUM(CALL_TIMES) AS TCALLTIMES, SUM(SUCCESS_TIMES) AS TSUCCESSTIMES, SUM(ERROR_TIMES) AS TERRORTIMES FROM API_RESULT AR JOIN API A ON A.API_NAME = AR.API WHERE AR.COUNT_DATE = '2019-08-22' AND A.FREE = '2'; ...

前言：  『入门MySQL』系列文章已经完结，今后我的文章还是会以MySQL为主，主要记录下近期工作及学习遇到的场景或者自己的感悟想法，可能后续的文章不是那么连贯，但还是希望大家多多支持。言归正传，本篇文章主要介绍MySQL长事务相关内容，比如说我们开启的一个事务，一直没提交或回滚会怎样呢，出现事务等待情况应该如何处理，本篇文章将给你答案。 注意：本篇文章并不聚焦于谈论事务隔离级别以及相关特性。而是介绍长事务相关危害以及监控处理方法。本文是基于MySQL5.7.23版本，不可重复读(RR)隔离级别所做实验。1.什么是长事务首先我们先要知道什么是长事务，顾名思义就是运行时间比较长，长时间未提交的事务，也可以称之为大事务。这类事务往往会造成大量的阻塞和锁超时，容易造成主从延迟，要尽量避免使用长事务。 下面我将演示下如何开启事务及模拟长事务： #假设我们有一张stu_tb表，结构及数据如下mysql> show create table stu_tb\G*************************** 1. row *************************** Table: stu_tbCreate Table: CREATE TABLE `stu_tb` ( `increment_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增主键', `stu_id` int(11) NOT NULL COMMENT '学号', `stu_name` varchar(20) DEFAULT NULL COMMENT '学生姓名', `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间', PRIMARY KEY (`increment_id`), UNIQUE KEY `uk_stu_id` (`stu_id`) USING BTREE) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=utf8 COMMENT='测试学生表'1 row in set (0.01 sec)mysql> select * from stu_tb;+--------------+--------+----------+---------------------+---------------------+| increment_id | stu_id | stu_name | create_time | update_time |+--------------+--------+----------+---------------------+---------------------+| 1 | 1001 | from1 | 2019-09-15 14:27:34 | 2019-09-15 14:27:34 || 2 | 1002 | dfsfd | 2019-09-15 14:27:34 | 2019-09-15 14:27:34 || 3 | 1003 | fdgfg | 2019-09-15 14:27:34 | 2019-09-15 14:27:34 || 4 | 1004 | sdfsdf | 2019-09-15 14:27:34 | 2019-09-15 14:27:34 || 5 | 1005 | dsfsdg | 2019-09-15 14:27:34 | 2019-09-15 14:27:34 || 6 | 1006 | fgd | 2019-09-15 14:27:34 | 2019-09-15 14:27:34 || 7 | 1007 | fgds | 2019-09-15 14:27:34 | 2019-09-15 14:27:34 || 8 | 1008 | dgfsa | 2019-09-15 14:27:34 | 2019-09-15 14:27:34 |+--------------+--------+----------+---------------------+---------------------+8 rows in set (0.00 sec)#显式开启事务，可用begin或start transactionmysql> start transaction;Query OK, 0 rows affected (0.00 sec)mysql> select * from stu_tb where stu_id = 1006 for update;+--------------+--------+----------+---------------------+---------------------+| increment_id | stu_id | stu_name | create_time | update_time |+--------------+--------+----------+---------------------+---------------------+| 6 | 1006 | fgd | 2019-09-15 14:27:34 | 2019-09-15 14:27:34 |+--------------+--------+----------+---------------------+---------------------+1 row in set (0.01 sec)#如果我们不及时提交上个事务，那么这个事务就变成了长事务，当其他会话要操作这条数据时，就会一直等待。2.如何找到长事务遇到事务等待问题时，我们首先要做的是找到正在执行的事务。 information_schema.INNODB_TRX 表中包含了当前innodb内部正在运行的事务信息，这个表中给出了事务的开始时间，我们可以稍加运算即可得到事务的运行时间。 ...

作者：高鹏 文章末尾有他著作的《深入理解MySQL主从原理 32讲》，深入透彻理解MySQL主从，GTID相关技术知识。本文节选自《深入理解MySQL主从原理》第29节注意：本文分为正文和附件两部分，都是图片格式，如果正文有图片不清晰可以将附件的图片保存到本地查看。 背景我想简单说一下我的 MySQL 调试环境的搭建，但是在此之前不得不简单说一下什么是线程，因为如果不解释一下什么是线程，简单的调试可能都会有阻碍，同时了解线程对我们普通DBA诊断性能问题也有极大的帮助。但是详细解释线程已经超出了我的能力范围也超出了本系列讨论的范围。具体我推荐给大家两本书： 《POSIX 多线程程序设计》《Linux UNIX 系统编程手册》 第29到32章第一本书很老了，但是我觉得还可以，如果有兴趣可以参考一下。 一、线程简介我们知道 mysqld 是一个单进程多线程的用户程序，因此我们有必要了解一下什么线程。实际上 MySQL 中的线程都是 POSIX 线程，比如我们的会话线程、DUMP 线程、IO 线程以及其他一些 InnoDB 线程都是 POSIX 线程。 进程实际上就是运行中的程序，一个进程中可以包含多个线程，也可以只包含一个线程。在 Linux 中线程也叫轻量级进程（light-weight process）简称为 LWP，进程的第一个线程通常称为主控线程。进程是内存分配的最小单位，线程是 CPU 调度的最小单位，也就是说如果 CPU 有足够多核，那么多个线程可以达到并行处理的效果，内核直接调度线程。下面是我学习 Linux 线程的时候看到的一张我认为比较好理解的图，我重新画了一下放在下面供大家参考（图29-1，高清原图包含在文末原图中）： 一个进程内部的所有线程都拥有相同的代码程序、堆、全局变量、共享库等，但是每个线程拥有自己独立栈空间和寄存器，他们共享进程的虚拟内存地址空间。下面我们假定是32位操作系统下的 mysqld 进程，它的进程虚拟内存地址示意图如下,实际上这个图也是参考《Linux UNIX 系统编程手册》画的（图29-2，高清原图包含在文末原图中）： 我们发现线程的堆内存和全局变量是共享的，因此线程之间数据共享很轻松，但是要控制好这些共享内存就需要引入我们的线程同步技术，比如我们常说的 Mutex。 如果想了解线程到底共享了哪些资源，线程和进程到底各有什么优势和劣势，可执行参考上面我给出的书籍。 二、PID、LWP ID、Thread TID如果要进行调试就需要了解这三种 ID，其中 PID 和 LWP ID 是比较重要，因为不管是调试和运维都会遇到它们，而 Thread TID 不做多线程开发一般很少用到。下面是我对它们的总结： PID：内核分配，用于识别各个进程的 ID。这个应该是大家最熟悉的。LWP ID：内核分配，用于识别各个线程的 ID，它就像是线程是‘PID’一样。同一个进程下的所有线程有相同的 PID，但是 LWP ID 却不一样，主控线程的 LWP ID 就是进程 PID。Thread TID：进程内部用于识别各个线程的内部 ID，这个 ID 用得不多。下面我写了一个简单的 C 测试程序仅仅用于观察这些 ID，它是通过主控线程再创建一个线程，也就是说这个进程包含了两个线程。它们分别打印自己的 PID、LWP ID、Thread TID，然后做一个循环自加操作引起高 CPU 消耗现象便于观察。然后我们使用 Linux 的 top -H 和 ps -eLlf 命令分别进行观察。 ...

什么是事务事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。也就是事务具有原子性，一个事务中的一系列的操作要么全部成功，要么一个都不做。事务的结束有两种，当事务中的所以步骤全部成功执行时，事务提交。如果其中一个步骤失败，将发生回滚操作，撤消撤消之前到事务开始时的所以操作。 事务的ACID1、原子性（Atomicity）：事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。 2、一致性（Consistency）：事务开始前和结束后，数据库的完整性约束没有被破坏 。比如A向B转账，不可能A扣了钱，B却没收到。 3、隔离性（Isolation）：同一时间，只允许一个事务请求同一数据，并发执行不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账。 4、持久性（Durability）：事务完成后，事务对数据库的所有更新将被保存到数据库，其它操作或故障不应该对其执行结果有任何影响，不能回滚。 事务的并发问题1、脏读：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据2、不可重复读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果 不一致。3、幻读：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。 小结：不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表 事务隔离级别1、Read Uncommitted（读取未提交内容）在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。2、Read Committed（读取提交内容）这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。3、Repeatable Read（可重读）这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。4、Serializable（可串行化）这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。mysql默认的事务隔离级别为repeatable-read 各个隔离级别的情况CREATE TABLE `account` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `name` varchar(11) DEFAULT '', `balance` decimal(10,2) DEFAULT NULL , PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4; 1、读未提交(1)打开一个客户端A，并设置当前事务模式为read uncommitted（未提交读），查询表account的初始值：(2)在客户端A的事务提交之前，打开另一个客户端B，更新表account：(3)这时，虽然客户端B的事务还没提交，但是客户端A就可以查询到B已经更新的数据：(4)一旦客户端B的事务因为某种原因回滚，所有的操作都将会被撤销，那客户端A查询到的数据其实就是脏数据：(5)在客户端A执行更新语句update account set balance = balance - 50 where id =4，Lucy的balance没有变成200，居然是250，是不是很奇怪，数据不一致啊，如果你这么想就太天真了，在应用程序中，我们会用250-50=200，并不知道其他会话回滚了，要想解决这个问题可以采用读已提交的隔离级别 2、读已提交(1)打开一个客户端A，并设置当前事务模式为read committed（已提交读），查询表account的所有记录：(2)在客户端A的事务提交之前，打开另一个客户端B，更新表account：(3)这时，客户端B的事务还没提交，客户端A不能查询到B已经更新的数据，解决了脏读问题：(4)客户端B的事务提交(5)客户端A执行与上一步相同的查询，结果 与上一步不一致，即产生了不可重复读的问题 3、可重复读(1)打开一个客户端A，并设置当前事务模式为repeatable read，查询表account的所有记录(2)在客户端A的事务提交之前，打开另一个客户端B，更新表account并提交(3)在客户端A查询表account的所有记录，与步骤（1）查询结果一致，没有出现不可重复读的问题(4)在客户端A，接着执行update balance = balance - 50 where id = 1，balance没有变成350-50=300，lucy的balance值用的是步骤（2）中的300来算的，所以是250，数据的一致性倒是没有被破坏。可重复读的隔离级别下使用了MVCC机制，select操作不会更新版本号，是快照读（历史版本）；insert、update和delete会更新版本号，是当前读（当前版本）。(5)重新打开客户端B，插入一条新数据后提交(6)在客户端A查询表account的所有记录，没有 查出 新增数据，所以没有出现幻读 ...

在使用Mysql数据库的过程中,经常需要使用到备份和恢复数据库,最简单便捷的方法便是通过导出SQL数据文件和导入SQL数据文件来完成备份和恢复,但是随着项目的增长,数据量越来越大,每次恢复就成了一件很头疼的事情。 当我最近一次拉下项目中的5GB大小的数据库到本地进行恢复时,竟然需要耗时40-50分钟,想着日后的数据扩增,数据量越来越大,恢复成本也越来越高,于是便查阅了一些资料,可以通过以下设置来提高你的恢复效率. 1.更改备份参数首先我们需要在备份数据库的时候,可以通过更改参数来提高我们的恢复效率. mysqldump --extended-insertmysqldump的--extended-insert参数表示批量插入,会将多个insert语句合并成一个语句,与没有开启-extended-insert的备份导入效率相差3-4倍. 使用--extended-insert=false导出的sql文件数据是这样的,每行一条insert语句,执行效率非常低下 使用--extended-insert=true导出的表如下图这种，一个很长的insert语句,会进行批量插入。 2.调整MYSQL快速插入参数如果你的数据库储存引擎是MYISAM参数的话,可以将此参数设置到512M或256M,MyISAM会使用一种特殊的树状缓存来做出更快的批量插入。 相关文档https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_bulk_insert_buffer_size 该值默认是8M = 8388608byte 查看插入缓冲区大小 SHOW VARIABLES LIKE '%bulk%';设置插入缓冲区大小(全局) SET GLOBAL bulk_insert_buffer_size =1024*1024*512;设置插入缓冲区大小(session) SET bulk_insert_buffer_size =1024*1024*256;如果需要设置Mysql重新启动时,依然保留该值,需要将这段配置添加了my.cnf [mysqld]bulk_insert_buffer_size = 256M3.关闭检查项对于Innodb引擎中,我们可以关闭一些系统检查项来实现更快的插入的方案. //关闭自动提交SET autocommit=0;//关闭唯一检查set unique_checks = 0;//关闭外键检查SET foreign_key_checks=0;//备份的时候开启--extended-insert参数关于Innodb批量数据加载相关文档:https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-bulk-data-loading.html 4.实践做好以上优化后,你的Mysql恢复效率瞬间会提升一个档次,在没做以上参数优化时,每次恢复数据库都需要耗费40分钟的时间,设置后只需要16分钟左右,我的数据库文件容量在5GB左右. 以上就这些,途观有更好的方案和建议的话,希望各位同学一起探讨,Happy Coding。

为了方便快捷的搭建linux环境，于是有了这几篇文字 CentOS使用yum安装jdkCentOS安装tomcatCentOS安装NginxCentOS安装MySql5.6CentOS安装MySql5.71下载mysql #进入local目录cd /usr/local/#下载mysqlwget https://dev.mysql.com/get/Downloads/MySQL-5.7/mysql-5.7.17-linux-glibc2.5-x86_64.tar.gz2.解压mysql修改名称 tar -zxvf mysql-5.7.17-linux-glibc2.5-x86_64.tar.gzmv mysql-5.7.17-linux-glibc2.5-x86_64 mysqlmkdir data3.添加用户和组 groupadd mysqluseradd -r -s /sbin/nologin -g mysql mysql -d /usr/local/mysqlchown -R mysql.mysql /usr/local/mysql/4安装命令 yum -y install libaio-devel./bin/mysql_install_db --user=mysql --basedir=/usr/local/mysql/ --datadir=/usr/local/mysql/data/cp -a ./support-files/my-default.cnf /etc/my.cnfcp -a ./support-files/mysql.server /etc/init.d/mysqld5.修改配置文件 #打开配置目录vi /etc/my.cnf#增加目录配置basedir=/usr/local/mysql/datadir=/usr/local/mysql/data6.启动，修改root密码，添加远程连接用户权限 #修改环境变量配置文件vi /etc/profile#增加mysql全局变量，使service mysqld start可以在任意位置使用export PATH=$PATH:/usr/local/mysql/bin#即时生效source /etc/profile#启动mysqlservice mysqld start#mysql刚安装完毕没有密码进入mysql命令行mysql -uroot -p#查询mysql用户select User, Host, Password FROM mysql.user;#修改root密码update mysql.user set password=password('root') where User="root";#为root添加远程权限grant all privileges on *.* to 'root'@'%'identified by 'root' with grant option;#刷新权限flush privileges;

-- 示例表CREATE TABLE `employees` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(24) NOT NULL DEFAULT '' COMMENT '姓名', `age` int(20) NOT NULL DEFAULT '0' COMMENT '年龄', `position` varchar(20) NOT NULL DEFAULT '' COMMENT '职位', `hire_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '入职时间', PRIMARY KEY (`id`), KEY `idx_name_age_position` (`name`,`age`,`position`) USING BTREE, KEY `idx_age` (`age`) USING BTREE) ENGINE=InnoDB AUTO_INCREMENT=136326 DEFAULT CHARSET=utf8 COMMENT='员工表'--创建100000条记录drop procedure if EXISTS insert_emp;delimiter ;;create procedure insert_emp()BEGIN declare i int; set i=1; while(i < 100000)DO INSERT INTO employees(name,age,position) values(CONCAT('xiaoqiang',i),i,'coder'); SET i=i+1; end WHILE;end;;delimiter ;call insert_emp();根据自增且连续的主键排序的分页查询select * from employees LIMIT 9999 ,5;表示从表employees 中取出从10000行开始的5行记录。看似只查询5条记录，实际这条SQL是先读取10005条记录，然后抛弃前10000条记录，然后读到后面5条想要的数据。没有添加单独的order by，表示通过主键排序。因此要查询一张大表比较靠后的数据，执行效率是非常低的。因为主键是自增且连续的，所以可以改写成按照主键查询从第10001开始的五行数据，如下： ...

-- 示例表CREATE TABLE `employees` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(24) NOT NULL DEFAULT '' COMMENT '姓名', `age` int(20) NOT NULL DEFAULT '0' COMMENT '年龄', `position` varchar(20) NOT NULL DEFAULT '' COMMENT '职位', `hire_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '入职时间', PRIMARY KEY (`id`), KEY `idx_name_age_position` (`name`,`age`,`position`) USING BTREE, KEY `idx_age` (`age`) USING BTREE) ENGINE=InnoDB AUTO_INCREMENT=136326 DEFAULT CHARSET=utf8 COMMENT='员工表'Order by与Group by优化EXPLAIN select * from employees WHERE name='LiLei' and position='dev' order by age; ...

最近更新为spring boot 2.1.7后，遇到了一系列小的问题。本文阐述下spring boot对mysql引擎的支持。 解决方法spring: jpa: properties: hibernate: dialect: org.hibernate.dialect.MySQL55Dialect问题描述当我们配置spring.jap.hibernate.ddl-auto: create或是update等属性后，hibernate为我们自己动生成了数据表。但系统启动时在控制台中有报错，报错内容指明hibernate在给字段添加外键时产生了错误。经排查，错误产生的原因在于hibernate为我们自己动生成的表的引擎为MyISAM，而MyISAM并不支持外键。其实我们想要的引擎是Innodb。 尝试解决由于spring 1.x版本中，是不需要配置此项的，所以我首先来到了spring boot官方参考文档： https://docs.spring.io/spring-boot/docs/2.x.x.RELEASE/reference/html/common-application-properties.html具体使用时，请将2.x.x换成自己使用的版本，比如2.1.7。很遗憾，自2.0.0开始至2.1.8结束，我们以关键字dialect查询，并没有找到关于dialect的选项。而且我们查看jpa的配置项，也没有找到相关的记录： spring.data.jpa.repositories.bootstrap-mode=default # Bootstrap mode for JPA repositories.spring.data.jpa.repositories.enabled=true # Whether to enable JPA repositories.spring.jpa.database= # Target database to operate on, auto-detected by default. Can be alternatively set using the "databasePlatform" property.spring.jpa.database-platform= # Name of the target database to operate on, auto-detected by default. Can be alternatively set using the "Database" enum.spring.jpa.generate-ddl=false # Whether to initialize the schema on startup.spring.jpa.hibernate.ddl-auto= # DDL mode. This is actually a shortcut for the "hibernate.hbm2ddl.auto" property. Defaults to "create-drop" when using an embedded database and no schema manager was detected. Otherwise, defaults to "none".spring.jpa.hibernate.naming.implicit-strategy= # Fully qualified name of the implicit naming strategy.spring.jpa.hibernate.naming.physical-strategy= # Fully qualified name of the physical naming strategy.spring.jpa.hibernate.use-new-id-generator-mappings= # Whether to use Hibernate's newer IdentifierGenerator for AUTO, TABLE and SEQUENCE.spring.jpa.mapping-resources= # Mapping resources (equivalent to "mapping-file" entries in persistence.xml).spring.jpa.open-in-view=true # Register OpenEntityManagerInViewInterceptor. Binds a JPA EntityManager to the thread for the entire processing of the request.spring.jpa.properties.*= # Additional native properties to set on the JPA provider.spring.jpa.show-sql=false # Whether to enable logging of SQL statements.除此以外，spring.DATASOURCE中的配置项目也未找到相关的配置信息。莫非，官方将其取消了？ ...

MySQL简介关于MySQL发音的官方答案：The official way to pronounce “MySQL” is “My Ess Que Ell” (not “my sequel”), but we do not mind if you pronounce it as “my sequel” or in some other localized way.        MySQL 可以分为 Server 层和存储引擎层两部分。         Server层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖MySQL的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。         存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持 InnoDB、MyISAM、Memory 等多个存储引擎。现在最常用的存储引擎是InnoDB，它从MySQL 5.5.5版本开始成为了默认存储引擎。create table 语句中使用 engine=memory，来指定使用内存引擎创建表。         现在最常用的存储引擎是InnoDB，它从MySQL 5.5.5版本开始成为了默认存储引擎。create table 语句中使用 engine=memory, 来指定使用内存引擎创建表。 查询语句执行过程 连接器        第一步，连接器连接到数据库，连接器负责跟客户端建立连接、获取权限、维持和管理连接。 连接命令一般是这么写的：mysql -h$ip -P$port -u$user -p$password账号密码错误会报错：Access denied for user         连接完成后，如果没有后续的动作，这个连接就处于空闲状态，可以在show processlist命令中看到它。文本中这个图是show processlist的结果，其中的Command列显示为"Sleep"的这一行，就表示现在系统里面有一个空闲连接。         客户端如果太长时间没动静，连接器就会自动将它断开。这个时间是由参数wait timeout控制的，默认值是8小时。 断开后再执行sql会报错：Lost connection to MySQL server during query        建立连接的过程通常是比较复杂的，所以建议在使用中要尽量减少建立连接的动作，也就是尽量使用长连接。 ...

声明本文档请用于学习，生产环境谨慎使用 前言网络上有很多关于Windows或者Linux下面安装LNMP的教程，非常多。但是我还是选择自己去一步一步实现，即使我已经按照网上的教程在不同系统中装了N多次。为什么？因为不懂。不懂为什么需要那些系统软件，不懂那些编译项为什么要加？有何作用？只会复制粘贴。 几点建议: 编译安装只是环境搭建的开始，别想着把所有问题都在此阶段解决坚持按需编译，最小化安装,把问题暴露出来,去解决它对使用的每一个编译参数负责远离复制粘贴，你可能还有救完全不了解的软件尽可能避免编译安装目标我们把Laravel跑起来！ 基本情况软件文档列表此处文档是基础软件文档，不是很全，一部分软件文档在内容中。 NginxMysqlRedisPhpSwoole系统要求# 查看CentOS版本[root@bogon source]# cat /etc/redhat-release CentOS Linux release 7.6.1810 (Core) [root@bogon source]# cat /proc/versionLinux version 3.10.0-957.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) ) #1 SMP Thu Nov 8 23:39:32 UTC 2018软件列表系统内置 CURL 命令,所以我们选择CURL下载软件curl -O xxx，如果软件包出现解压问题，不是因为tar -zxf 解压不了这个包。而是说明这个包下载的不完整，或者说因为网络原因只是一个空包，解决办法是删除后重新下载。另外防止网站迁移，请使用curl -OL参数.-L：跟踪重定向国外资源下载太慢，请使用迅雷下载，然后通过scp上传到服务器，常用参数： -r 下载整个目录-p 指定端口，默认 22使用场景： scp -p <server port> <server user>@<server ip>:<server path>/<server file> <local path> 这是下载服务器资源，资源将被保存到 <local path>。scp -p <server port> <local path>/<local file> <server user>@<server ip>:<server path> 这是上传本地文件到服务器指定路径mysql-8.0.17.tar.gznginx-1.16.1.tar.gzphp-7.3.9.tar.gzredis-5.0.5.tar.gzswoole-4.4.4.tgzSoftware Collections为什么先说这个，为了给大家提供一个不需要关注 lnmp 系统依赖，而只是编译安装 lnmp 的方法。 ...

1 Mysql5.61.1 相关参数MySQL 5.6增加了参数innodb_undo_directory、innodb_undo_logs和innodb_undo_tablespaces这3个参数，可以把undo log从ibdata1移出来单独存放。 innodb_undo_directory：指定单独存放undo表空间的目录，默认为.（即datadir），可以设置相对路径或者绝对路径。该参数实例初始化之后虽然不可直接改动，但是可以通过先停库，修改配置文件，然后移动undo表空间文件的方式去修改该参数。 默认参数： mysql> show variables like '%undo%';+-------------------------+-------+| Variable_name | Value |+-------------------------+-------+| innodb_undo_directory | . || innodb_undo_logs | 128 || innodb_undo_tablespaces | 0 |+-------------------------+-------+innodb_undo_tablespaces：指定单独存放的undo表空间个数，例如如果设置为3，则undo表空间为undo001、undo002、undo003，每个文件初始大小默认为10M。该参数我们推荐设置为大于等于3，原因下文将解释。该参数实例初始化之后不可改动实例初始化是修改innodb_undo_tablespaces： mysql_install_db ...... --innodb_undo_tablespaces$ ls...undo001 undo002 undo003innodb_rollback_segments：默认128个。每个回滚段可同时支持1024个在线事务。这些回滚段会平均分布到各个undo表空间中。该变量可以动态调整，但是物理上的回滚段不会减少，只是会控制用到的回滚段的个数。1.2 使用初始化实例之前，我们只需要设置innodb_undo_tablespaces参数（建议大于等于3）即可将undo log设置到单独的undo表空间中。如果需要将undo log放到更快的设备上时，可以设置innodb_undo_directory参数，但是一般我们不这么做，因为现在SSD非常普及。innodb_undo_logs可以默认为128不变。 undo log可以存储于ibdata之外。但这个特性依然鸡肋： 首先你必须在install实例的时候就指定好独立Undo tablespace, 在install完成后不可更改。Undo tablepsace的space id必须从1开始，无法增加或者删除undo tablespace。1.3 大事务测试mysql> create table test.tbl( id int primary key auto_increment, name varchar(200));Query OK, 0 rows affected (0.03 sec)mysql> start transaction;Query OK, 0 rows affected (0.00 sec)mysql> insert into test.tbl(name) values(repeat('1',00));Query OK, 1 row affected (0.00 sec)mysql> insert into test.tbl(name) select name from test.tbl;Query OK, 1 row affected (0.00 sec)Records: 1 Duplicates: 0 Warnings: 0...mysql> insert into test.tbl(name) select name from test.tbl;Query OK, 2097152 rows affected (24.84 sec)Records: 2097152 Duplicates: 0 Warnings: 0mysql> commit;Query OK, 0 rows affected (7.90 sec)观察undolog已经开始膨胀了！事务commit后空间也没有回收。 ...

1 REDOLOG / BINLOG redologbinlog日志作用保护脏数据数据库备份恢复使用引擎支持只适合InnoDB引擎所有引擎日志格式物理日志逻辑日志,SQL语句提交方式快速提交提交时一次性写入保存形式会被循环覆盖长期保存redolog记录的是对于每个页的修改binlog只是记录DML、DDL、DCL，不记录SELECT 2 BINLOG参数2.1 开启binlog修改配置文件/etc/my.cnf，在[mysqld]下添加： log-bin = …/mydata5470/mysql-bin.log 2.2 存储binlogmysql> show variables like 'log_bin%';+---------------------------------+--------------------------------------------------------+| Variable_name | Value |+---------------------------------+--------------------------------------------------------+| log_bin | ON | log_bin_basename | .../mydata5470/mysql-bin | log_bin_index | .../mydata5470/master-log-bin.index | log_bin_trust_function_creators | ON | log_bin_use_v1_row_events | OFF +---------------------------------+--------------------------------------------------------+2.3 手工切换binlog1、重启数据库，每次重启都会新切binlog2、mysql> flush logs; 2.4 查看binlog日志文件mysqlbinlog -vv mysql-bin.000005 | more 2.5 binlog_cache_sizeshow variables like 'binlog_cache_size';+-------------------+-------+| Variable_name | Value |+-------------------+-------+| binlog_cache_size | 32768 |+-------------------+-------+所有未提交的二进制日志文件会被记录到用户工作空间的binlog cache中，等该事务提交时直接将缓冲区中的binlog写入二进制日志文件里。 show global status like 'Binlog_cache_disk_use';+-----------------------+-------+| Variable_name | Value |+-----------------------+-------+| Binlog_cache_disk_use | 10 |+-----------------------+-------+判断binlog_cache_size是否设置过小的依据，如果Binlog_cache_disk_use>0(次数)，说明事务未提交，binlog在用户工作空间存放不下，需要借用tmp目录。 ...

洪斌背景在用 xtrabackup 等备份工具做备份时会有全局锁，正常情况锁占用时间很短，但偶尔会遇到锁长时间占用导致系统写入阻塞，现象是 show processlist 看到众多会话显示 wait global read lock，那可能对业务影响会很大。而且 show processlist 是无法看到哪个会话持有了全局锁，如果直接杀掉备份进程有可能进程杀掉了，但锁依然没释放，数据库还是无法写入。这时我们需要有快速定位持有全局锁会话的方法，杀掉对应会话数据库就恢复正常了。 通常这种紧急情况发生，需要 DBA 有能力快速恢复业务，如果平时没有储备，现找方法肯定是来不及的，所以我整理了几种方法，在实际故障中帮助我快速的定位到锁会话恢复了业务，非常有效，与大家分享。 方法方法1：利用 metadata_locks 视图此方法仅适用于 MySQL 5.7 以上版本，该版本 performance_schema 新增了 metadata_locks，如果上锁前启用了元数据锁的探针（默认是未启用的），可以比较容易的定位全局锁会话。过程如下。 开启元数据锁对应的探针mysql> UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME = 'wait/lock/metadata/sql/mdl';Query OK, 1 row affected (0.04 sec)Rows matched: 1 Changed: 1 Warnings: 0模拟上锁mysql> flush tables with read lock;Query OK, 0 rows affected (0.06 sec)mysql> select * from performance_schema.metadata_locks;+-------------+--------------------+----------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE | LOCK_DURATION | LOCK_STATUS | SOURCE | OWNER_THREAD_ID | OWNER_EVENT_ID |+-------------+--------------------+----------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+| GLOBAL | NULL | NULL | 140613033070288 | SHARED | EXPLICIT | GRANTED | lock.cc:1110 | 268969 | 80 || COMMIT | NULL | NULL | 140612979226448 | SHARED | EXPLICIT | GRANTED | lock.cc:1194 | 268969 | 80 || GLOBAL | NULL | NULL | 140612981185856 | INTENTION_EXCLUSIVE | STATEMENT | PENDING | sql_base.cc:3189 | 303901 | 665 || TABLE | performance_schema | metadata_locks | 140612983552320 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:6030 | 268969 | 81 |+-------------+--------------------+----------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+4 rows in set (0.01 sec)OBJECT_TYPE=GLOBAL LOCK_TYPE=SHARED 表示全局锁mysql> select t.processlist_id from performance_schema.threads t join performance_schema.metadata_locks ml on ml.owner_thread_id = t.thread_id where ml.object_type='GLOBAL' and ml.lock_type='SHARED';+----------------+| processlist_id |+----------------+| 268944 |+----------------+1 row in set (0.00 sec)定位到锁会话 ID 直接 kill 该会话即可。 ...

前言随机数我们应该不陌生，业务中我们用它来生成验证码，或者对重复性要求不高的id，甚至我们还用它在年会上搞抽奖。今天我们来探讨一下这个东西。如果使用不当会引发一系列问题。 java中的随机数我们需要在Java中随机生成一个数字。java开发中我们通常使用java.util.Random来搞，它提供了一种伪随机的生成机制。Jvm 通过传入的种子（seed）来确定生成随机数的区间，只要种子一样，获取的随机数的序列就是一致的。而且生成的结果都是可以预测的。是一种伪随机数的实现，而不是真正的随机数。来确定使用的但是有些用例直接使用可能会导致一些意想不到的问题。Random的一个普遍用法： // Random 实例Random random = new Random();//调用 nextInt() 方法 此外还有nextDouble(), nextBoolean(), nextFloat(), ...random.nextInt();或者，我们可以使用java中的数学计算类： Math.random();Math类只包含一个Random实例来生成随机数： public static double random() { Random rnd = randomNumberGenerator; if (rnd == null) ｛ // 返回一个新的Random实例 rnd = initRNG(); ｝ return rnd.nextDouble(); }java.util.Random的用法是线程安全的。但是，在不同线程上并发使用相同的Random实例可能会导致争用，从而导致性能不佳。其原因是使用所谓的种子来生成随机数。种子是一个简单的数字，它为生成新的随机数提供了基础。我们来看看Random中的next(int bits)方法： protected int next(int bits) { long oldseed, nextseed; AtomicLong seed = this.seed; do { oldseed = seed.get(); nextseed = (oldseed * multiplier addend) & mask; } while (!seed.compareAndSet(oldseed, nextseed)); return (int)(nextseed >>> (48 - bits));}首先，旧种子和新种子存储在两个辅助变量上。在这一点上，创造新种子的原则并不重要。要保存新种子，使用compareAndSet()方法将旧种子替换为下一个新种子，但这仅仅在旧种子对应于当前设置的种子的条件下才会触发。如果此时的值由并发线程操纵，则该方法返回false，这意味着旧值与例外值不匹配。因为是循环内进行的操作，那么会发生自旋，直到变量与例外值匹配。这可能会导致性能不佳和线程竞争。 ...

spring-boot-plusV1.2.3发布，CentOS快速安装环境/构建/部署/启动项目[V1.2.3-RELEASE] 2019.09.09 spring-boot-plusV1.2.3发布，CentOS快速安装环境/构建/部署/启动项目⭐️ New Features项目运行环境安装脚本CentOS快速构建/部署/启动项目脚本⚡️ Optimization优化 maven-assembly-plugin 项目打包插件???? Added/ModifiedAdd install-jdk.sh yum安装jdk8脚本Add install-git.sh yum安装git脚本Add install-maven.sh yum安装maven脚本Add install-redis.sh yum安装redis脚本Add install-mysql.sh yum安装mysql脚本Add install-all.sh 安装所有环境脚本Add download-install-all.sh 下载并安装所有环境脚本Add deploy.sh 下载项目/构建/部署/启动项目脚本Add maven-javadoc-plugin java api docs???? DocumentationCentOS Quick Installation Environment / Build / Deploy / Launch Spring-boot-plus Project spring-boot-plus java docs???? Dependency UpgradesUpgrade to springboot 2.1.8.RELEASEUpgrade to Mybatis 3.5.2Upgrade to Mybatis Plus 3.2.0Upgrade to Alibaba Druid 1.1.20Upgrade to Fastjson 1.2.60Upgrade to commons-codec 1.13Upgrade to commons-collections 4.4Upgrade to hutool-all 4.6.4CentOS快速安装环境/构建/部署/启动spring-boot-plus项目1. 下载安装脚本安装 jdk, git, maven, redis, mysqlwget -O download-install-all.sh https://raw.githubusercontent.com/geekidea/spring-boot-plus/master/docs/bin/install/download-install-all.sh2. 运行安装脚本sh download-install-all.sh3. 修改MySQL密码ALTER USER 'root'@'localhost' IDENTIFIED BY 'Springbootplus666!';exitmysql -uroot -pSpringbootplus666!4. 导入MySQL脚本create database if not exists spring_boot_plus character set utf8mb4;use spring_boot_plus;source /root/mysql_spring_boot_plus.sql;show tables;exit5. 下载部署脚本 deploy.shwget -O deploy.sh https://raw.githubusercontent.com/geekidea/spring-boot-plus/master/deploy/deploy.sh6. 执行脚本sh deploy.sh7.访问项目SpringBootAdmin管理页面http://47.105.159.10:8888 ...

⭐ 我的网站: www.mengyingjie.com ⭐ javaweb环境搭配为：tomcat9.0.19+jdk8u211+ mysql一、主要分为以下步骤：1.服务器购买，购买地址2.下载并安装jdk3.下载并安装tomcat4.下载并安装mysql，用Navicat远程访问5.将项目war包放到tomcat的webapps目录下即可二、可能遇到的问题：1.不加项目名或8080端口号，访问tomcat上的项目2.如何向服务器里上传下载文件3.使用xshell登陆时密码框为灰色遇到此类问题，但看了文章还是未解决，评论或加 QQ：781378815

⭐ 我的网站: www.mengyingjie.com ⭐ 下载并安装mysql （1）在服务器上打开Mysql端口号：3306 （2）用Xshell连接服务器(在Windows上下载安装及使用xshell)（3）下载和安装mysql第一步：安装从网上下载文件的wget命令 yum -y install wget第二步：下载mysql的repo源 wget http://repo.mysql.com/mysql-community-release-el7-5.noarch.rpm第三步：安装mysql-community-release-el7-5.noarch.rpm包 rpm -ivh mysql-community-release-el7-5.noarch.rpm第四步：查看下 ls -1 /etc/yum.repos.d/mysql-community*/etc/yum.repos.d/mysql-community.repo/etc/yum.repos.d/mysql-community-source.repo会获得两个mysql的yum repo源：/etc/yum.repos.d/mysql-community.repo，/etc/yum.repos.d/mysql-community-source.repo 第五步：安装mysql yum install mysql-server（4）启动Mysql服务service mysql start（5）连接mysql （6）创建用户GRANT ALL PRIVILEGES ON *.* TO 'username'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION;username:为用户名%：表示所有外网IP都可以连接password:是你自己设置的密码-- 刷新权限表 flush privileges;（7）记得打开服务器的防火墙启动防火墙 systemctl start firewalld.service（8）在本地电脑用Navicat连接第一种方法 第二种方法 遇到此类问题，但看了文章还是未解决，评论或加 QQ：781378815

B-树数据库索引为什么要使用树结构存储呢？这个还不简单，树的查询效率高，而且可以保持有序。既然这样，为什么索引没有使用二叉查找树来实现呢？这就不明白了，明明二叉查找树时间复杂度是O(logN)，性能已经足够高了，难道B树可以比它更快？ 其实从算法逻辑来讲，二叉树查找树的查找速度和比较次数都是最小的，但是我们不得不考虑一个现实问题：磁盘IO ；数据索引是存储在磁盘上的，当数据量比较大的时候，索引的大小可能有几个G甚至更多。 当我们利用索引查询的时候，能把整个索引全部加载到内存吗？显然不可能。能做的只有逐一加载每个磁盘页，这里的磁盘页对应索引树的节点。 在二叉查找树里，磁盘的IO次数等于索引树的高度。 既然如此，为了减少磁盘的IO次数，我们就需要把原本“瘦高”的树结构变成“矮胖”，这是B-树的特征之一。 B-树是一种多路平衡查找树，它的每一个节点最多包含k个孩子，k被称为B树的阶。k的大小取决于磁盘页的大小。 下面来具体介绍以下B-树（Balance Tree），一个m阶的B树具有如下几个特征： 根节点至少有两个子女；每个中间节点都包含k-1个元素和k个孩子，其中m/2<=k<=m；每一个叶子节点都包含k-1个元素，其中m/2<=k<=m；所有叶子节点都位于同一层；每个节点中的元素从小到大排列，节点当中k-1个元素正好是k个孩子包含的元素的值域划分。下面以3阶的B-树为例，来看看B-树的具体结构。 【 9 】 / \ / \ 【2 6】 【12】 / | \ / \ / | \ / \ / | \ / \1 【3 5】 8 11 【13 15】这棵树中，重点看【2 6】节点，该节点有两个元素2和6，又有三个孩子1，【3 5】和8。其中1小于元素2,6之间，8大于【3 5】，正好符合刚刚所列的几条特征。 演示下B-树的查询过程，假如我们要查询数值为5的节点。 第一次IO，查到 9，比较9第二次IO，查到 【2 6】 比较2，比较6第三次IO，查到 【3 5】 比较3， 比较5 虽然 比较次数 并不比二叉查找树少，尤其当单一节点中的元素数量很多时。 但是相比磁盘IO的速度，内存中 比较的操作 耗时几乎可以忽略，所以只要树的高度足够低，IO次数足够少，就可以提高查找性能。相比之下节点内部元素多一些并没关系，最多就是几次内存交换操作而已，只要不超过磁盘页的大小，这就是B-树的优势之一。 但B-树，插入新节点的过程就比较复杂，而且分成很多种情况。所以我们举个典型的例子，上图中插入4.自顶下查找4的节点位置，发现4应该插入【3 5】之间节点【3 5】已经是两个元素节点，根据特征2要求，无法再增加了。父节点【2 6】也是两元素节点，也无法再增加，根节点9是单元素节点，可以升级为两元素节点。于是拆分节点【3 5】和节点【2 6】，让根节点升级为两元素节点【4 9】，节点6独立成为根节点的第二个孩子。 ...

前言：  前面几篇文章为大家介绍了 MySQL 各种语句语法的用法及用户权限相关知识。本篇文章将主要讲解 MySQL 数据库数据备份与恢复相关知识，主要聚焦于逻辑备份，介绍mysqldump工具的使用以及恢复方法。 这里简单讲下物理备份和逻辑备份的概念：物理备份：备份数据文件，转储数据库物理文件到某一目录。物理备份恢复速度比较快，但占用空间比较大，MySQL中可以用 xtrabackup 工具来进行物理备份。逻辑备份：对数据库对象利用工具进行导出工作，汇总入备份文件内。逻辑备份恢复速度慢，但占用空间小，更灵活。MySQL 中常用的逻辑备份工具为mysqldump。1.备份全部数据库若想用mysqldump备份整个实例，可以使用 --all-databases 或 -A 参数： mysqldump -uroot -pxxxxxx --all-databases > /tmp/all_database.sqlmysqldump -uroot -pxxxxxx -A > /tmp/all_database.sql2.备份部分数据库有的时候我们会遇到只需要备份某些库的需求，这个时候我们就可以使用 --databases 或 -B 参数了，该参数后面跟数据库名称，多个数据库间用空格隔开。 mysqldump -uroot -pxxxxxx --databases testdb1 testdb2 > /tmp/testdb.sqlmysqldump -uroot -pxxxxxx -B testdb1 testdb2 > /tmp/testdb.sql3.备份部分表平时我们也会有备份部分表的需求，比如说在表变更前做个备份，那么我们可以这样做： #只备份testdb库中的test_tb表mysqldump -uroot -pxxxxxx testdb test_tb > /tmp/test_tb.sql#备份多张表mysqldump -uroot -pxxxxxx testdb tb1 tb2 tb3 > /tmp/tb.sql4.备份单表的部分数据有些时候一张表的数据量很大，我们只需要部分数据，那么该怎么办呢？这时候就可以使用 --where 选项了。where后面附带需要满足的条件。例如：我们只需要tb1表中create_time大于2019-08-01的数据，那么可以这样导出： mysqldump -uroot -pxxxxxx testdb tb1 --where=" create_time >= '2019-08-01 00:00:00' " > /tmp/tb1.sql5.排除某些表导出如果我们想备份某个库，但是某些表数据量很大或者与业务关联不大，这个时候可以考虑排除掉这些表，同样的，选项 --ignore-table 可以完成这个功能。 ...

SpringBoot实战电商项目mall（20k+star）地址：https://github.com/macrozheng/mall摘要开发者必备Mysql常用命令，涵盖了数据定义语句、数据操纵语句及数据控制语句，基于Mysql5.7。 数据定义语句(DDL)数据库操作登录数据库：mysql -uroot -proot创建数据库：create database test查看所有数据库：show databases 选择数据库并使用：use test查看所有数据表：show tables删除数据库：drop database test表操作创建表：create table emp(ename varchar(10),hiredate date,sal decimal(10,2),deptno int(2)) create table dept(deptno int(2),deptname varchar(10)) 查看表的定义：desc emp 查看表定义（详细）：show create table emp \G 删除表：drop table emp修改表字段：alter table emp modify ename varchar(20)添加表字段：alter table emp add column age int(3)删除表字段：alter table emp drop column age字段改名；alter table emp change age age1 int(4)修改表名：alter table emp rename emp1数据操纵语句(DML)插入记录指定名称插入：insert into emp (ename,hiredate,sal,deptno) values ('zhangsan','2018-01-01','2000',1)不指定名称插入：insert into emp values ('lisi','2018-01-01','2000',1)批量插入数据：insert into dept values(1,'dept1'),(2,'dept2')修改记录update emp set sal='4000',deptno=2 where ename='zhangsan'删除记录delete from emp where ename='zhangsan'查询记录查询所有记录：select * from emp查询不重复的记录：select distinct deptno from emp条件查询：select * from emp where deptno=1 and sal<3000排序和限制：select * from emp order by deptno desc limit 2分页查询(查询从第0条记录开始10条)：select * from emp order by deptno desc limit 0,10聚合(查询部门人数大于1的部门编号)：select deptno,count(1) from emp group by deptno having count(1) > 1连接查询：select * from emp e left join dept d on e.deptno=d.deptno子查询：select * from emp where deptno in (select deptno from dept)记录联合：select deptno from emp union select deptno from dept数据控制语句(DCL)权限相关授予操作权限(将test数据库中所有表的select和insert权限授予test用户)：grant select,insert on test.* to 'test'@'localhost' identified by '123'查看账号权限：show grants for 'test'@'localhost' ...

SpringBoot实战电商项目mall（20k+star）地址：https://github.com/macrozheng/mall摘要当我们要对数据库做有风险的操作时需要对数据库备份，每次上线项目时，线上与线下数据库结构总会有不一致的情况，本文将讲解如何利用Navicat来方便的解决这两个问题。 NavicatNavicat是一套快速、可靠的数据库管理工具，专为简化数据库的管理及降低系统管理成本而设。它的设计符合数据库管理员、开发人员及中小企业的需要。Navicat 是以直觉化的图形用户界面而建的，让你可以以安全并且简单的方式创建、组织、访问并共用信息。注意：本教程采用的时Navicat12版本，下载地址：https://www.navicat.com.cn/download/navicat-premium 使用数据库介绍现在数据库中有两个数据库，mall-test表示测试环境数据库，mall-prod表示线上环境数据库。数据备份现在我们先对mall-test数据库备份，备份完成后，删除商品表的数据，然后利用备份进行数据还原。mall-test中的数据概览目前数据库中只有商品模块的数据库表，pms_product表中有一定的数据。 进行数据备份先点击顶部工具栏的备份图标，再点击新建备份按钮 点击开始按钮开始备份 备份完成后会生成一个备份文件 清空pms_product表的数据 从备份中还原数据 结构同步相关背景说明原来的mall-test模块中只有商品模块的表，现在我们经过了一段时间的开发，新增了订单模块，同时删除和修改了商品模块的一些表，而mall-prod表中还是原来的商品模块表，我们现在要做的是把mall-test的数据库表结构同步到mall-prod。 进行结构同步选择结构同步功能 选择源数据库和目标数据库，点击比对按钮 可以看到修改、新增和删除的表信息，点击部署会出现sql脚本的预览 确认了部署脚本信息后，点击运行会进行数据结构的同步 再次进行结构同步时，已经发现两个数据库结构已经完全一致 公众号mall项目全套学习教程连载中，关注公众号第一时间获取。

当我们搭建MySQL集群时，自然需要完成数据库的主从同步来保证数据一致性。而主从同步的方式也分很多种，一主多从、链式主从、多主多从，根据你的需要来进行设置。但只要你需要主从同步，就一定要注意server-id的配置，否则会出现主从复制异常。 在控制数据库数据复制和日志管理中，有两个重要的配置：server-id和server-uuid，他们会影响二进制日志文件记录和全局事务标识。 server-id配置 当你使用主从拓扑时，一定要对所有MySQL实例都分别指定一个独特的互不相同的server-id。默认值为0，当server-id=0时，对于主机来说依然会记录二进制日志，但会拒绝所有的从机连接；对于从机来说则会拒绝连接其它实例。 MySQL实例的server-id是一个全局变量，可以直接查看： mysql> show variables like '%server_id%';+---------------+-----------+| Variable_name | Value |+---------------+-----------+| server_id | 171562767 |+---------------+-----------+1 row in set (0.00 sec)我们可以在线直接修改全局变量server-id，但不会立即生效，所以修改后记得重启服务。而重启后又会重新读取系统配置文件配置，导致刚才的修改失效，因此建议修改配置文件后重启服务而不是在线修改： #my.cnf[mysqld]#replicationlog-bin=mysql-binserver-id=171562767sync_binlog=1binlog-ignore-db=mysqlbinlog-ignore-db=information_schemaserver-id用途server-id用于标识数据库实例，防止在链式主从、多主多从拓扑中导致SQL语句的无限循环： 标记binlog event的源实例过滤主库binlog，当发现server-id相同时，跳过该event执行，避免无限循环执行。如果设置了replicate-same-server-id=1，则执行所有event，但有可能导致无限循环执行SQL语句。我们用两个例子来说明server-id为什么不要重复： 当主库和备库server-id重复时由于默认情况replicate-same-server-id=0，因此备库会跳过所有主库同步的数据，导致主从数据的不一致。 当两个备库server-id重复时会导致从库跟主库的连接时断时连，产生大量异常。根据MySQL的设计，主库和从库通过事件机制进行连接和同步，当新的连接到来时，如果发现server-id相同，主库会断开之前的连接并重新注册新连接。当A库连接上主库时，此时B库连接到来，会断开A库连接，A库再进行重连，周而复始导致大量异常信息。 生成server-id的规则既然server-id不能相同，而当我们有10个实例时，怎么保证每个都不同呢？有几种常用的方法： 随机数时间戳IP地址+端口在管理中心集中分配，生成自增ID上面的这些方法都可以，但是注意不要超过了最大值2^32-1，同时值最好>2。我采用的方法是IP地址后两位+本机MySQL实例序号，但如果是通过docker来进行管理多实例时，这个怎么生成大家可以想下有没有什么优美的解决方案。 server-uuid配置 MySQL服务会自动创建并生成server-uuid配置： 读取${data_dir}/auto.cnf文件中的UUID如果不存在，自动创建文件和生成新的UUID并读取shell> cat ~/mysql/data/auto.cnf[auto]server-uuid=fd5d03bc-cfde-11e9-ae59-48d539355108这个auto.cnf配置风格类似于my.cnf，但这个文件只包含一个auto配置块和一行server-uuid配置。它是自动创建的，因此不要修改它的内容。 在主从拓扑中，主从可以知道互相的UUID，在主机上使用show slave hosts，在从机上使用show slave status查看Master_UUID字段。 server-uuid参数并不能取代server-id，他们有不同的作用。当主从同步时如果主从实例的server-uuid相同会报错退出，不过我们可以通过设置replicate-same-server-id=1来避免报错（不推荐）。 参考资料17.1.6 Replication and Binary Logging Options and Variables：https://dev.mysql.com/doc/ref...如何生成唯一的server Id：http://ju.outofmemory.cn/entr...

本文源码：GitHub·点这里 || GitEE·点这里 一、配置详解场景描述：MySQL数据表以全量和增量的方式向ElasticSearch搜索引擎同步。1、下载内容elasticsearch 版本 6.3.2logstash 版本 6.3.2mysql-connector-java-5.1.13.jar2、核心配置路径：/usr/local/logstash新建配置目录：sync-config1)、配置全文 /usr/local/logstash/sync-config/cicadaes.conf input { stdin {} jdbc { jdbc_connection_string => "jdbc:mysql://127.0.0.1:3306/cicada?characterEncoding=utf8" jdbc_user => "root" jdbc_password => "root123" jdbc_driver_library => "/usr/local/logstash/sync-config/mysql-connector-java-5.1.13.jar" jdbc_driver_class => "com.mysql.jdbc.Driver" jdbc_paging_enabled => "true" jdbc_page_size => "50000" jdbc_default_timezone => "Asia/Shanghai" statement_filepath => "/usr/local/logstash/sync-config/user_sql.sql" schedule => "* * * * *" type => "User" lowercase_column_names => false record_last_run => true use_column_value => true tracking_column => "updateTime" tracking_column_type => "timestamp" last_run_metadata_path => "/usr/local/logstash/sync-config/user_last_time" clean_run => false } jdbc { jdbc_connection_string => "jdbc:mysql://127.0.0.1:3306/cicada?characterEncoding=utf8" jdbc_user => "root" jdbc_password => "root123" jdbc_driver_library => "/usr/local/logstash/sync-config/mysql-connector-java-5.1.13.jar" jdbc_driver_class => "com.mysql.jdbc.Driver" jdbc_paging_enabled => "true" jdbc_page_size => "50000" jdbc_default_timezone => "Asia/Shanghai" statement_filepath => "/usr/local/logstash/sync-config/log_sql.sql" schedule => "* * * * *" type => "Log" lowercase_column_names => false record_last_run => true use_column_value => true tracking_column => "updateTime" tracking_column_type => "timestamp" last_run_metadata_path => "/usr/local/logstash/sync-config/log_last_time" clean_run => false }}filter { json { source => "message" remove_field => ["message"] }}output { if [type] == "User" { elasticsearch { hosts => ["127.0.0.1:9200"] index => "cicada_user_search" document_type => "user_search_index" } } if [type] == "Log" { elasticsearch { hosts => ["127.0.0.1:9200"] index => "cicada_log_search" document_type => "log_search_index" } }}2)、SQL文件 ...

通常我们提到数据库表结构的时候，比较关心的几个属性：字段名称、类型、长度、是否主键、是否自增、是否为空、默认值、备注。那么，使用SQL语句获取这些属性，在各主流数据库下是什么样的呢？MySQL数据库作为时下最流行的数据库，MySQL的获取SQL是最简单的。一般我们用下面一行语句就能搞定： SHOW FULL COLUMNS FROM xxx;当然，也可以用MySQL自带的数据库information_schema中的表，例如：columns等查询更全的信息。 PostgreSQL数据库使用其两个最重要的Schema(information_schema、pg_catalog)下表，进行关联查询，获取常用属性。 SELECT d.column_name AS "Field", d.udt_name AS "Type", COALESCE(d.character_maximum_length, d.numeric_precision, d.datetime_precision) AS "Length", CASE WHEN t.conname IS NOT NULL THEN 'PRI' ELSE '' END AS "Key", CASE WHEN s.extra IS NOT NULL THEN 'auto_increment' ELSE '' END "Extra", d.is_nullable AS "Null", f.adsrc AS "Default", col_description(a.attrelid, a.attnum) AS "Comment" FROM information_schema.columns d, pg_class c, pg_attribute a LEFT JOIN pg_constraint t ON (a.attrelid = t.conrelid AND t.contype = 'p' AND a.attnum = t.conkey[1]) LEFT JOIN pg_attrdef f ON (a.attrelid = f.adrelid AND a.attnum = f.adnum) LEFT JOIN (SELECT 'nextval(''' || c.relname || '''::regclass)' AS extra FROM pg_class c WHERE c.relkind = 'S') s ON f.adsrc = s.extraWHERE a.attrelid = c.oidAND a.attnum > 0AND c.relname = d.table_nameAND d.column_name = a.attnameAND c.relname = 'xxx'ORDER BY a.attnum;Oracle数据库系统表：user_col_comments能提供大部分信息，只有：备注(Comment)、主键(Key)需要关联其他表进行获取。 ...

作者：高鹏 文章末尾有他著作的《深入理解MySQL主从原理 32讲》,深入透彻理解MySQL主从，GTID相关技术知识。本文节选自《深入理解MySQL主从原理》第15节本节包含一个笔记如下：https://www.jianshu.com/write... 本文提要本节将解释 MySQL 层详细的提交流程，但是由于能力有限，这里不可能包含全部的步骤，只是包含了一些重要的、并且我学习过的步骤。 我们首先需要来假设参数设置，因为某些参数的设置会直接影响到提交流程，我们也会逐一解释这些参数的含义。本节介绍的大部分内容都集中在函数 MYSQL_BIN_LOG::prepare和MYSQL_BIN_LOG::ordered_commit 之中。 一、参数设置本部分假定参数设置为： binlog_group_commit_sync_delay：0binlog_group_commit_sync_no_delay_count：0binlog_order_commits：ONsync_binlog：1binlog_transaction_dependency_tracking：COMMIT_ORDER关于参数 binlog_transaction_dependency_tracking 需要重点说明一下。我们知道 Innodb 的行锁是在语句运行期间就已经获取，因此如果多个事务同时进入了提交流程（prepare阶段），在 Innodb 层提交释放 Innodb 行锁资源之前各个事务之间肯定是没有行冲突的，因此可以在从库端并行执行。在基于 COMMIT_ORDER 的并行复制中，last commit 和 seq number 正是基于这种思想生成的，如果 last commit 相同则视为可以在从库并行回放，在19节我们将解释从库判定并行回放的规则。而在基于 WRITESET 的并行复制中，last commit 将会在 WRITESET 的影响下继续降低，来使从库获得更好的并行回放效果，但是它也是 COMMIT_ORDER 为基础的，这个下一节将讨论。我们这节只讨论基于COMMIT_ORDER 的并行复制中 last commit 和 seq number 的生成方式。 而sync_binlog参数则有两个功能： sync_binlog=0：binary log 不 sync 刷盘，依赖于 OS 刷盘机制。同时会在flush阶段后通知DUMP线程发送Event。sync_binlog=1：binary log 每次 sync 队列形成后都进行sync刷盘，约等于每次group commit 进行刷盘。同时会在 sync 阶段后通知DUMP线程发送 Event。注意sync_binlog 非1的设置可能导致从库比主库多事务。sync_binlog>1：binary log 将在指定次 sync 队列形成后进行 sync 刷盘，约等于指定次 group commit 后刷盘。同时会在 flush 阶段后通知 DUMP 线程发送 Event。第二功能将在第17节还会进行介绍。 ...

#杀掉ID为1的线程, 关闭连接kill 1; #杀掉正在执行的ID为1的线程, 不关闭连接kill query 1;#查询出时间大于10的线程, 复制查询结果，批量执行select concat('kill ', id, ';') from information_schema.processlist where time > 10

在实际的项目开发中有时会有对数据库某字段截取部分的需求，这种场景有时直接通过数据库操作来实现比通过代码实现要更方便快捷些，mysql有很多字符串函数可以用来处理这些需求，如Mysql字符串截取总结：left()、right()、substring()、substring_index()。 一.从左开始截取字符串用法：left(str, length)，即：left(被截取字符串， 截取长度) SELECT LEFT('www.yuanrengu.com',8);结果为：www.yuan 二.从右开始截取字符串用法：right(str, length)，即：right(被截取字符串， 截取长度) SELECT RIGHT('www.yuanrengu.com',6);结果为：gu.com 三.截取特定长度的字符串用法： substring(str, pos)，即：substring(被截取字符串， 从第几位开始截取)substring(str, pos, length)，即：substring(被截取字符串，从第几位开始截取，截取长度)1.从字符串的第9个字符开始读取直至结束SELECT SUBSTRING('www.yuanrengu.com', 9);结果为：rengu.com 2.从字符串的第9个字符开始，只取3个字符SELECT SUBSTRING('www.yuanrengu.com', 9, 3);结果为：ren 3.从字符串的倒数第6个字符开始读取直至结束SELECT SUBSTRING('www.yuanrengu.com', -6);结果为：gu.com 4.从字符串的倒数第6个字符开始读取，只取2个字符SELECT SUBSTRING('www.yuanrengu.com', -6, 2);结果为：gu 四.按关键字进行读取用法：substring_index(str, delim, count)，即：substring_index(被截取字符串，关键字，关键字出现的次数) 1.截取第二个“.”之前的所有字符SELECT SUBSTRING_INDEX('www.yuanrengu.com', '.', 2);结果为：www.yuanrengu 2.截取倒数第二个“.”之后的所有字符SELECT SUBSTRING_INDEX('www.yuanrengu.com', '.', -2);结果为：yuanrengu.com 3.如果关键字不存在，则返回整个字符串SELECT SUBSTRING_INDEX('www.yuanrengu.com', 'sprite', 1);结果为：www.yuanrengu.com

【问题详细描述】 有以下 sql 语句。SQL1 耗时约 4s，SQL2、SQL3 耗时约 1 个小时。有办法通过优化 SQL2 做到做完子查询再把所有条件一起下压到 SequoiaDB 吗？ 表：ibs.pb_log， 数据量：600亿 ，索引：log_cstno + log_datetime 表：ibs.pb_cstinf_pro，数据量：4千万， 索引：cip_ctfno SQL1: SELECT * FROM ibs.pb_log WHERE log_cstno IN ('2339139') AND log_datetime BETWEEN CONCAT('20190101', '000000') AND CONCAT('20190429', '000000') SQL2: SELECT * FROM ibs.pb_log WHERE log_cstno IN (SELECT cip_cstno FROM ibs.pb_cstinf_pro WHERE cip_ctfno IN ('360426198807174073')) AND log_datetime BETWEEN CONCAT('20190101', '000000') AND CONCAT('20190429', '000000') SQL3: SELECT * FROM ibs.pb_log LEFT JOIN ibs.pb_cstinf_pro ON log_cstno=cip_cstno WHERE log_datetime BETWEEN CONCAT('20190101', '000000') AND CONCAT('20190429', '000000') AND cip_ctfno IN ('360426198807174073') ...

索引是帮助MySQL高效获取数据的排好序的数据结构索引数据结构对比二叉树左边子节点的数据小于父节点数据，右边子节点的数据大于父节点数据。 如果col2是索引，查找索引为89的行元素，那么只需要查找两次，就可以获取到行元素所在的磁盘指针地址。 如果col1是索引，查找索引为6的行元素，那么需要查找六次，就可以获取到行元素所在的磁盘指针地址，即得到了该索引为6的行元素。因此二叉树不适合存储单边增长的序列字段，近乎全表扫描获取数据。 红黑树本质二叉树，属于二叉平衡树，jdk1.8 hashmap的底层实现； 存储大数据量，树的高度不可控， 数量越大，树的高度越高； 500w行数据，2的n次方=500w数据量， n是树的高度，也就是查询次数； hash表通过散列可以快速获取磁盘文件指针，对于指定索引查找文件非常快，但是对于范围查找没法支持。 B树本质是多路二叉树；叶节点具有相同的深度，叶节点的指针为空；所有索引元素不重复；节点中数据索引从左到右依次递增的； B+树（B树的变种）非叶子节点不存储数据，只存储索引(冗余)和指针，可以放更多的索引，树高降低 ；叶子节点包含所有索引字段；叶子节点比b树增加了指针连接；叶子节点有双向指针链接(首尾子节点还通过指针连接)，提高区间访问的性能，范围查找； 为什么mysql页文件默认16K？MySQL每个B+树节点最大存储容量：16KB （指针+数据+索引）。假设我们一行数据大小为1K，那么一页就能存16条数据，也就是一个叶子节点能存16条数据；再看非叶子节点，假设主键ID为bigint类型，那么长度为8B，指针大小在Innodb源码中为6B，一共就是14B，那么一页里就可以存储16K/14=1170个(主键+指针)那么一颗高度为2的B+树能存储的数据为：117016=18720条，一颗高度为3的B+树能存储的数据为：11701170*16=21902400（千万级条） show global status like `Innodb_page_size`因此，B+树存储大数据量的表也可以非常高效的获取数据，MySQL使用B+树作为索引的数据结构。 存储引擎存储引擎最终作用于：表 ，不是数据库在mysql的安装的根目录下，有一个data目录，里面存放的是所有表的数据。 MyISAM：MyISAM索引文件和数据文件是分离的（非聚集或稀疏）；主键索引和辅助主键索引存储类似； frm文件：存储这张表的表结构MYD文件：存储这张表的所有数据行MYI文件：存储这张表的索引字段 InnoDB（聚集）：表数据文件本身是按照B+tree组织的一个索引结构文件frm文件：存储这张表的表结构ibd文件：存储这张表的所有数据行和索引字段聚集(聚簇)索引----叶节点包含完整数据记录 为什么InnoDB表必须有主键，并且推荐使用整型的自增主键？首先，为了满足MySQL的索引数据结构B+树的特性，必须要有索引作为主键，可以有效提高查询效率，因此InnoDB必须要有主键。如果不手动指定主键，InnoDB会从插入的数据中找出不重复的一列作为主键索引，如果没找到不重复的一列，InnoDB会在后台增加一列rowId做为主键索引。其次，索引的数据类型是整型，一方面整型占有的磁盘空间或内存空间相比字符串更少，另一方面整型比较比字符串比较更快速，字符串比较是先转换为ASCII码，然后再比较的。最后，B+树本质是多路多叉树，如果主键索引不是自增的，那么后续插入的索引就会引起B+树的其他节点的分裂和重新平衡，影响数据插入的效率，如果是自增主键，只用在尾节点做增加就可以。为什么非主键索引结构叶子节点存储的是主键值？主键索引和非主键索引维护各自的B+树结构，当插入的数据的时候，由于数据只有一份，通过非主键索引获取到主键值，然后再去主键索引的B+树数据结构中找到对应的行数据，节省了内存空间；如果非主键索引的叶子节点也存储一份数据，如果通过非主键索引插入数据，那么要向主键索引对应的行数据进行同步，那么会带来数据一致性问题。可以通过事务的方式解决，我们都知道使用事务后，就会对性能有所消耗。联合索引联合索引的底层存储结构长什么样?定义联合索引(员工级别，员工姓名，员工出生年月)，将联合索引按照索引顺序放入节点中，新插入节点时，先按照联合索引中的员工级别比较，如果相同会按照是员工姓名比较，如果员工级别和员工姓名都相同 最后是员工的出生年月比较。可以从图中从上到下，从左到右看，第一个B+树的节点 是通过联合索引的员工级别比较的，第二个节点是 员工级别相同，会按照员工姓名比较，第三个节点是 员工级别和员工姓名都相同，会按照员工出生年月比较。 还没关注我的公众号？扫文末二维码关注公众号【小强的进阶之路】可领取如下:学习资料： 1T视频教程：涵盖Javaweb前后端教学视频、机器学习/人工智能教学视频、Linux系统教程视频、雅思考试视频教程；100多本书：包含C/C++、Java、Python三门编程语言的经典必看图书、LeetCode题解大全；软件工具：几乎包括你在编程道路上的可能会用到的大部分软件；项目源码：20个JavaWeb项目源码。

一、SQLServer优点易用性、适合分布式组织的可伸缩性；用于决策支持的数据仓库功能、与许多其他服务器软件紧密关联的集成性、良好的性价比等；为数据管理与分析带来了灵活性，允许单位在快速变化的环境中从容响应，从而获得竞争优势。从数据管理和分析角度看，将原始数据转化为商业智能和充分利用Web带来的机会非常重要。作为一个完备的数据库和数据分析包，SQLServer为快速开发新一代企业级商业应用程序、为企业赢得核心竞争优势打开了胜利之门；作为重要的基准测试可伸缩性和速度奖的记录保持者，SQLServer是一个具备完全Web支持的数据库产品，提供了对可扩展标记语言 (XML)的核心支持以及在Internet上和防火墙外进行查询的能力；缺点开放性 ：SQL Server 只能windows上运行没有丝毫开放性操作系统系统稳定对数据库十分重要Windows9X系列产品偏重于桌面应用NT server只适合小型企业而且windows平台靠性安全性和伸缩性非常有限象unix样久经考验尤其处理大数据库；伸缩性并行性 ：SQL server 并行实施和共存模型并成熟难处理日益增多用户数和数据卷伸缩性有限；安全性：没有获得任何安全证书。性能 ：SQL Server 多用户时性能佳 ；客户端支持及应用模式：客户端支持及应用模式。只支持C/S模式，SQL Server C/S结构只支持windows客户用ADO、DAO、OLEDB、ODBC连接；使用风险：SQL server 完全重写代码经历了长期测试断延迟许多功能需要时间来证明并十分兼容；二、MySQL优点体积小、速度快、总体拥有成本低，开源；支持多种操作系统；是开源数据库，提供的接口支持多种语言连接操作；MySQL的核心程序采用完全的多线程编程。线程是轻量级的进程，它可以灵活地为用户提供服务，而不过多的系统资源。用多线程和C语言实现的mysql能很容易充分利用CPU；MySql有一个非常灵活而且安全的权限和口令系统。当客户与MySql服务器连接时，他们之间所有的口令传送被加密，而且MySql支持主机认证；支持ODBC for Windows， 支持所有的ODBC 2.5函数和其他许多函数， 可以用Access连接MySql服务器， 使得应用被扩展；支持大型的数据库， 可以方便地支持上千万条记录的数据库。作为一个开放源代码的数据库，可以针对不同的应用进行相应的修改。拥有一个非常快速而且稳定的基于线程的内存分配系统，可以持续使用面不必担心其稳定性；MySQL同时提供高度多样性，能够提供很多不同的使用者介面，包括命令行客户端操作，网页浏览器，以及各式各样的程序语言介面，例如C+，Perl，Java，PHP，以及Python。你可以使用事先包装好的客户端，或者干脆自己写一个合适的应用程序。MySQL可用于Unix，Windows，以及OS/2等平台，因此它可以用在个人电脑或者是服务器上；缺点不支持热备份；MySQL最大的缺点是其安全系统，主要是复杂而非标准，另外只有到调用mysqladmin来重读用户权限时才发生改变；没有一种存储过程(Stored Procedure)语言，这是对习惯于企业级数据库的程序员的最大限制；MySQL的价格随平台和安装方式变化。Linux的MySQL如果由用户自己或系统管理员而不是第三方安装则是免费的，第三方案则必须付许可费。Unix或linux 自行安装 免费 、Unix或Linux 第三方安装 收费；三、Oracle优点开放性：Oracle 能所有主流平台上运行（包括 windows）完全支持所有工业标准采用完全开放策略使客户选择适合解决方案对开发商全力支持；可伸缩性,并行性：oracle 并行服务器通过使组结点共享同簇工作来扩展windownt能力提供高用性和高伸缩性簇解决方案windowsNT能满足需要用户把数据库移UNIXOracle并行服务器对各种UNIX平台集群机制都有着相当高集成度；安全性：获得最高认证级别的ISO标准认证；性能：Oracle 性能高 保持开放平台下TPC-D和TPC-C世界记录；客户端支持及应用模式：Oracle 多层次网络计算支持多种工业标准用ODBC、JDBC、OCI等网络客户连接；使用风险：Oracle 长时间开发经验完全向下兼容得广泛应用地风险低缺点对硬件的要求很高；价格比较昂贵；管理维护麻烦一些；操作比较复杂，需要技术含量较高；推荐阅读1、今天，一周年，感谢有你 2、Linux下MySQL基本操作 3、我必须得告诉大家的MySQL优化原理 4、千行 MySQL 详细学习笔记，你收藏了吗？ 5、记住，永远不要在 Mysql 中使用 “utf8” 6、一次超有意思的 SQL 优化经历！ 7、Oracle SQL 性能优化40条，必看！ 8、Oracle数据库环境搭建 9、Oracle客户端PLSQL的使用说明 10、Linux环境下Oracle数据库常用命令 欢迎关注微信公众号杰哥的IT之旅

简述：技术,spring+mysql....新项目上线碰到一个问题，具体现象为执行一个方法时报异常，异常信息如下： 2019-08-20 09:46:08.917[ERROR][Log4jFilter.java:152][DubboServerHandler-192.168.12.156:28104-thread-207] {conn-10670, pstmt-21062} execute error. delete from Dpgd where shco = ?java.sql.SQLException: Could not retrieve transation read-only status server .... at java.lang.Thread.run(Thread.java:745)Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failureThe last packet successfully received from the server was 7,603 milliseconds ago. The last packet sent successfully to the server was 0 milliseconds ago. ... at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1038)最开始只看到Could not retrieve transation read-only status server没看到下面的Communications link failure，以为是在代码中手动设置事务状态为只读或者事务回滚，后来查代码也没发现。当看到Communications link failure意识到连接异常，但与当前方法连接同一个库的其他方法可以执行成功，所以数据库服务也是正常的。 最终发现原因：排查的方法中有其他操作发送http请求，稍微有点耗时，但整个方法一分钟之类肯定能处理完。 ...

前言： 一致性是指在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。这是说数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。例子： 对银行转帐事务，不管事务成功还是失败，应该保证事务结束后ACCOUNT表中A和B的存款总额为x元不变。Isolation 隔离性： 数据库允许多个并发事务同事对数据进行操作，隔离性保证各个事务相互独立，事务处理时的中间状态对其它事务是不可见的，以此防止出现数据不一致状态。例子： 在Windows中，如果多个进程对同一个文件进行修改是不允许的，Windows通过这种方式来保证不同进程的隔离性。Durable 持久性： 一个事务处理结束后，其对数据库的修改就是永久性的，即使系统故障也不会丢失。脏读、幻读和不可重复读的概念 脏读： 所谓脏读是指一个事务中访问到了另外一个事务未提交的数据，如下图： 如果会话 2 更新 age 为 10，但是在 commit 之前，会话 1 希望得到 age，那么会获得的值就是更新前的值。或者如果会话 2 更新了值但是执行了 rollback，而会话 1 拿到的仍是 10。这就是脏读。 不可重复读： 一个事务查询同一条记录2次，得到的结果不一致： 由于在读取中间变更了数据，所以会话 1 事务查询期间的得到的结果就不一样了。 幻读： 一个事务查询2次，得到的记录条数不一致： 幻读是不可重复读的一种特殊场景。 MySQL 数据隔离级别 MySQL 里有四个隔离级别： Read uncommttied（可以读取未提交数据）Read committed（可以读取已提交数据）Repeatable read（可重复读）Serializable（可串行化）。不同事务隔离级别有不同的效果： 在 InnoDB 中，默认为 Repeatable 级别，InnoDB 中使用一种被称为 next-key locking 的策略来避免幻读（phantom）现象的产生。 隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。

俗话说的好“吃水不忘挖井人”，当自己体验过Hexo搭建个人网站后，也来分享一下搭建过程遇到的乐趣以及遇到的坑！ 准备工作（电脑配置工具）在搭建Hexo博客之前，首先需要简单在你电脑安装一些工具以及依赖包（具体安装方法相信大家都会，就省略了） 首先要有一个github账号其次安装node.js，npm依赖然后安装git工具（当然电脑自身的cmd工具也是可以用的）创建github网站（username.github.io的github仓库）新建一个名为“你的用户名.github.io”的仓库，比如说，如果你的github用户名是mengnn，那么你就新建"mengnn.github.io"的仓库（必须是你的用户名，其它名称无效），将来你的网站访问地址就是 mengnn.github.io了，对的，就是这么方便。 <!--more--> 当然，一个github账户下只能创建一个以此命名的仓库，用来直接访问。 点击New repository输入Repository name，必需为username.github.io格式。username替换为用户名点击按钮Create repository进入仓库username.github.io,点击setting,找到GitHub Pages模块点击choose a theme选择一个页面主题访问https://username.github.io就可以访问博客网站了为github设置SSH Keys之所以配置SSH Keys，是因为你提交代码肯定要拥有你的github权限才可以，但是直接使用用户名和密码太不安全了，所以我们使用ssh key来解决本地和服务器的连接问题。 首先检查机器上是否已经存在id_rsa.pub文件 cd ~/. ssh #检查本机已存在的ssh密钥如果不存在那就通过命令生成秘钥 ssh-keygen -t rsa -C "邮箱地址"一路回车就好（记得应该是连续3次回车），最终会生成一个文件在用户目录下，打开用户目录，找到.ssh\id_rsa.pub文件，记事本打开并复制里面的内容。 打开你的github页面，点击setting进入---> SSH and GPG keys ---> New SSH key,然后把你复制的内容放到Key中，其中Title中的内容可以随便填一个就ok了，如下图： 添加成功保存就OK了。 测试SSH Key输入下面命令，测试SSH Key是否安装成功 ssh -T git@github.com # 不用改邮箱地址如果提示Are you sure you want to continue connecting (yes/no)?，输入yes，然后会类似于：`Hi mengnn! You've successfully authenticated, but GitHub does not provide shell access.`的字符，说明你安装成功了。 安装Hexo以上准备工作完成后，就要放大招了，对，接下来就是重头戏-本地部署Hexo。 ...

MySQL 突然出现写不了的情况, 登录查看磁盘空间, 发现空间不足. 查看 MySQL 数据所在目录 发现占用空间最大的是一个临时文件ibtmp1. 上网搜索得到的解决办法如下:

【问题描述】 已存在集群，在目标集群控制器所在的机器中创建sdbom服务进程，登录SAC添加已存在的集群前添加该服务的主机时报错如下： 执行命令：discovery business，错误码：-6，failed to add business，missing host。需要重试吗？ 【解决办法】 用户在创建节点时填入的hostname为localhost，导致SAC添加已存在的集群前添加该服务的主机时检测到节点配置的hostname为localhost而主机的hostname为xxxx-xxx-xxx，不一致报错。用户需删除已有集群，重新安装部署集群，在创建节点时使用ip作为hostname，然后重新添加该已有的集群

【问题详细描述】 SequoiaDB v2.8.4版本的节点日志中显示的open files中的值是从哪里获取的？6月10号启动节点时open files 显示的值与ulimit.conf设置的保持一致，为1048576，但6月17号，即今天早上节点启动时open files的值却为4096。 【问题排查】 （如下以 sequoiadb 所属默认用户 sdbadmin 为例） 1、确认 /proc/[cm_pid]/limits 是否用 sdbadmin 启动，并确认 /proc/[cm_pid]/limits 当前值； from 用户：所有主机的 sdbcm open files均为 4096； 2、如果执行./bin/sdbstart 加 -i 参数会跳过 limits.conf，以当前 linux 会话中的 ulimit -n 为准，确认 sequoiadb 启动方式； from 用户：客户早上是执行sdbstop 命令显示11820节点(该节点为上面提到的节点日志的节点)停止失败，kill -9 该节点后再使用 sdbadmin / sdbstart 启停的节点； 3、确认编目节点（如11820）是否为 CM 自动拉起的，CM 自身进程什么时候启动的，如果是 bin/sdbcmart -i 也是跳过 ulimit.conf； from 用户：11820是cm拉起的，cm 进程是 2018-05-14，/etc/security/limit.conf 文件的最后修改时间 2017-12-04 【解决办法】 因为 sdbcm 节点的 open files 为 4096，11820 节点是被 kill 掉的，由 sdbcm 拉起；另外，排查 ulimit 的设置也是正确的。客户那边后续没有反馈日志和更多问题进展，没有找到问题原因。 客户重启 sdbcm 后正常。 ...

MySQL 你好，死锁 前言在日常的生活中，相信大家曾或多或少有这么一种体验："每到下班高峰期的时候，原本宽坦的交通干道，一时间变得水泄不通，司机和乘客都烦躁不安，喇叭声响成一片，当车卡在十字路口中间，会很尴尬的发现，此时无论想走哪都…..."。对于这样的体验，大家都是十分的害怕接触和体验，交通部门也无时无刻为解决交通拥堵问题而努力。 其实上面生活案例中拥堵就类似于——高并发场景； 而所有方向的车堵在十字路口中间就类似于——数据库死锁场景。 本章主要围绕InnoDB存储引擎死锁相关的一些概念、产生死锁的原因、死锁场景以及死锁的处理策略。 相关概念为了更好的认识死锁，我们先来了解MySQL中与死锁相关的一些基本概念。 并发控制并发控制（Concurrency control）指的是当多个用户同时更新运行时，用于保护数据库完整性的各种技术。 读写锁为了保证数据库的并发控制，因此MySQL设置了两种锁： 共享锁（Shared Lock）：也叫读锁（Read Lock），允许多个连接可以同一时刻并发的读取同一资源，互不干扰排他锁（Exclusive Lock）：也叫写锁（Write Lock），会阻塞其他写锁或者读书的请求，保证同一时刻只有一个连接可以操作数据，包括读锁策略所谓锁策略就是在锁的开销和数据的安全性之间寻求平衡，这种平衡会影响到性能。目前InnoDB存储引擎有以下两种锁策略： Table Lock（表锁）策略：最基本的锁策略，开销最小，加锁快，不会出现死锁，但发生锁冲突概率高，粒度大，并发低Row Lock（行锁）策略：粒度最小，发生锁冲突态度低，并发也高，但是开销大，加锁慢，会出现死锁事务所谓事务，它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。一个事务是需要通过严格ACID测试的： 原子性(ATOMICITY)：一个事务的整个操作，要么全部提交成功，要么全部失败回滚，不能执行其中的某一部分一致性(CONSISTENCY)：数据库总是从一个一致性的状态转换到另外一个一致性的状态隔离性(ISOLATION)：一个事物所作的修改在提交前，其他事务是看不到的持久性(DURABILITY)：一旦事务提交，则其所做的修改就会永久保存到数据库中隔离级别SQL标准制定了四种隔离级别，规定事务的修改对其它事务是否可见 READ UNCOMMITED（未提交读）：未提交也可见，又称脏读READ COMMITED （提交读）：只有提交才可见，大多数DBMS默认隔离级别都是这个，MySQL不是，也称不可重复读REPEATABLE READ （可重复读），多次重复读取结果一致，MySQL默认这个级别，解决脏读问题，但存在幻读问题（某个事务读取记录时，另一事务插入了新纪录，原事务再读取记录时产生幻行）。SERIALIZABLE （可串行化），最高隔离级别，强制事务串行执行，避免了前面说的幻读问题，并发性能差隔离级别脏读可能性不可重复读可能性幻读可能性加锁读READ UNCOMMITEDYesYesYesNoREAD COMMITEDNoYesYesNoREPEATABLE READNoNoYesNoSERIALIZABLENoNoNoYes死锁的定义死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方占用的资源（我等待你的资源，你却等待我的资源，我们都相互等待，谁也不释放自己占有的资源），从而导致恶性循环的现象： 当多个事务试图以不同顺序锁定资源时，就可能会产生死锁多个事务，同时锁定同一个资源时，也会产生死锁死锁的危害死等和死锁可不是一回事，如果你遇到了死等，大可放心，肯定不是死锁；如果发生了死锁，也大可放心，绝对不会死等。 这是因为MySQL内部有一套死锁检测机制，一旦发生死锁会立即回滚一个事务，让另一个事务执行下去。并且这个死锁回滚的的错误消息也会发送给客户端。即使正常的业务中，死锁也时不时会发生，所以遇到死锁不要害怕，因为这也是对数据安全的一种保护，但是若死锁太频繁，那可能会带来许多的问题： 使进程得不到正确的结果：处于死锁状态的进程得不到所需的资源，不能向前推进，故得不到结果使资源的利用率降低：处于死锁状态的进程不释放已占有的资源，以至于这些资源不能被其他进程利用，故系统资源利用率降低导致产生新的死锁：其它进程因请求不到死锁进程已占用的资源而无法向前推进，所以也会发生死锁死锁产生的原因死锁有四个必要的条件： 互斥排他：一个资源每次只能被一个进程使用保持着排他资源又提出新资源请求：一个进程因请求资源而阻塞时，对已获得的资源保持不放不可剥夺：资源不能被抢占，即资源只能在进程完成任务后自动释放环路：有一组等待进程｛P0、P1、P2｝，P0等待的资源被P1所占有，P1等待的资源被P2所占有，而P2等待的又被P0所占有，形成了一个等待循环死锁的发生场景以下的所有场景是基于 InnoDB存储引擎并且隔离级别为REPEATABLE-READ（可重复读） 查询当前的隔离级别： select @@global.tx_isolation,@@tx_isolation;+-----------------------+-----------------+| @@global.tx_isolation | @@tx_isolation |+-----------------------+-----------------+| REPEATABLE-READ | REPEATABLE-READ |+-----------------------+-----------------+修改隔离级别： set global transaction isolation level read committed; ## 全局的set session transaction isolation level read committed; ## 当前会话(session)创建数据表 CREATE TABLE `deadlock` ( `id` int(11) NOT NULL, `stu_num` int(11) DEFAULT NULL, `score` int(11) DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `idx_uniq_stu_num` (`stu_num`), KEY `idx_score` (`score`)) ENGINE=InnoDB;insert into deadlock(id, stu_num, score) values (1, 11, 111);insert into deadlock(id, stu_num, score) values (2, 22, 222);insert into deadlock(id, stu_num, score) values (3, 33, 333);id主键索引 ...

前言：  在上篇文章中，主要为大家介绍的是DDL语句的用法，可能细心的同学已经发现了。本篇文章将主要聚焦于DML语句，为大家讲解表数据相关操作。 这里说明下DDL与DML语句的分类，可能有的同学还不太清楚。DDL(Data Definition Language)：数据定义语言，用于创建、删除、修改、库或表结构，对数据库或表的结构操作。常见的有create，alter，drop等。DML(Data Manipulation Language)：数据操纵语言，主要对表记录进行更新(增、删、改)。常见的有insert，update，delete等。1.插入数据插入数据主要用到的是insert语法，官方文档同样给出很多选项： INSERT [LOW_PRIORITY | DELAYED | HIGH_PRIORITY] [IGNORE] [INTO] tbl_name [PARTITION (partition_name [, partition_name] ...)] [(col_name [, col_name] ...)] {VALUES | VALUE} (value_list) [, (value_list)] ... [ON DUPLICATE KEY UPDATE assignment_list]INSERT [LOW_PRIORITY | DELAYED | HIGH_PRIORITY] [IGNORE] [INTO] tbl_name [PARTITION (partition_name [, partition_name] ...)] SET assignment_list [ON DUPLICATE KEY UPDATE assignment_list]INSERT [LOW_PRIORITY | HIGH_PRIORITY] [IGNORE] [INTO] tbl_name [PARTITION (partition_name [, partition_name] ...)] [(col_name [, col_name] ...)] SELECT ... [ON DUPLICATE KEY UPDATE assignment_list]value: {expr | DEFAULT}value_list: value [, value] ...assignment: col_name = valueassignment_list: assignment [, assignment] ...有兴趣的同学可以咨询研究下上面的各个选项哦，下面我将分类给大家介绍几个常用的语法。 ...

前言： 前面几篇文章为大家介绍了DML以及DDL语句的使用方法，本篇文章将主要讲述常用的查询语法。其实MySQL官网给出了多个示例数据库供大家实用查询，下面我们以最常用的员工示例数据库为准，详细介绍各自常用的查询语法。 1.员工示例数据库导入官方文档员工示例数据库介绍及下载链接： https://dev.mysql.com/doc/employee/en/employees-installation.html同样的，为了方便大家，我这里将员工库的数据库备份分享给大家，大家也可以下载我这份数据，然后再解压导入进你们本地库就可以了。 链接: https://pan.baidu.com/s/13s1O...  密码: 2xqx下载解压后，直接导入即可，如链接失效可后台联系我。如果你导入完成，就可以看到下面这6张表了，这就是我们接下来练习查询语法要用的表哦。 为了让大家对示例数据库更了解，这里给出此数据库各表之间的关系图： 简单介绍下这6张表： departments ：部门表，记录的是9个部门的部门编号和部门名称。dept_emp ：部门员工表，记录各部门员工数据，员工id和部门id，起始时间和结束时间（注：9999-01-01的意思就是仍在该部门就职）。dept_manager ：部门经理表，同第二张表结构差不多，记录每个部门的每个经理的任职时期。employees ：员工信息表，记录员工信息，员工编号emp_no是唯一键值。salaries ：薪资表，记录每个员工每段时期的薪资。titles ：职称表，记录每个员工每段时期的职位名称。2.模糊查询#查找名字以L开头的员工信息SELECT * FROM employees WHERE first_name LIKE 'L%'；3.排序#按部门编号排序mysql> SELECT * FROM departments ORDER BY dept_no;+---------+--------------------+| dept_no | dept_name |+---------+--------------------+| d001 | Marketing || d002 | Finance || d003 | Human Resources || d004 | Production || d005 | Development || d006 | Quality Management || d007 | Sales || d008 | Research || d009 | Customer Service |+---------+--------------------+9 rows in set (0.00 sec)总结：order by排序默认按asc升序来排列也可指定desc降序排列4.限制多少行#取前5行mysql> SELECT * FROM employees LIMIT 5;+--------+------------+------------+-----------+--------+------------+| emp_no | birth_date | first_name | last_name | gender | hire_date |+--------+------------+------------+-----------+--------+------------+| 10001 | 1953-09-02 | Georgi | Facello | M | 1986-06-26 || 10002 | 1964-06-02 | Bezalel | Simmel | F | 1985-11-21 || 10003 | 1959-12-03 | Parto | Bamford | M | 1986-08-28 || 10004 | 1954-05-01 | Chirstian | Koblick | M | 1986-12-01 || 10005 | 1955-01-21 | Kyoichi | Maliniak | M | 1989-09-12 |+--------+------------+------------+-----------+--------+------------+5 rows in set (0.00 sec)mysql> SELECT * FROM employees ORDER BY hire_date desc LIMIT 5;+--------+------------+------------+-----------+--------+------------+| emp_no | birth_date | first_name | last_name | gender | hire_date |+--------+------------+------------+-----------+--------+------------+| 463807 | 1964-06-12 | Bikash | Covnot | M | 2000-01-28 || 428377 | 1957-05-09 | Yucai | Gerlach | M | 2000-01-23 || 499553 | 1954-05-06 | Hideyuki | Delgrande | F | 2000-01-22 || 222965 | 1959-08-07 | Volkmar | Perko | F | 2000-01-13 || 47291 | 1960-09-09 | Ulf | Flexer | M | 2000-01-12 |+--------+------------+------------+-----------+--------+------------+5 rows in set (0.11 sec)总结：limit限定显示前多少行，可与order by联合使用5.聚合函数#查找某员工薪水总和SELECT SUM(salary) FROM salaries WHERE emp_no = 10001;#统计历史上各个部门所拥有的员工数量，并降序排序mysql> SELECT dept_no, COUNT(*) AS emp_sum FROM dept_emp GROUP BY dept_no ORDER BY emp_sum DESC;+---------+---------+| dept_no | emp_sum |+---------+---------+| d005 | 85707 || d004 | 73485 || d007 | 52245 || d009 | 23580 || d008 | 21126 || d001 | 20211 || d006 | 20117 || d003 | 17786 || d002 | 17346 |+---------+---------+9 rows in set (0.07 sec)6.JOIN#可以试下下面3个语句执行结果的不同SELECT *FROM salaries INNER JOIN dept_empON salaries.emp_no = dept_emp.emp_noWHERE salaries.emp_no = 10010;SELECT *FROM salaries LEFT JOIN dept_empON salaries.emp_no = dept_emp.emp_noWHERE salaries.emp_no = 10010;SELECT *FROM salaries RIGHT JOIN dept_empON salaries.emp_no = dept_emp.emp_noWHERE salaries.emp_no = 10010;总结：a left join b a表全，用b表去匹配a表LEFT JOIN 关键字会从左表 (a) 那里返回所有的行，即使在右表 (b) 中没有匹配的行,匹配不到的列用NULL代替a right join b b表全，用a表去匹配b表RIGHT JOIN 关键字会右表 (b) 那里返回所有的行，即使在左表 (a) 中没有匹配的行,匹配不到的列用NULL代替inner join 与join 效果一样在表中存在至少一个匹配时，INNER JOIN 关键字返回行总结：  ...

今天在排查线上一个奇怪的数据库连接问题，所以打开了 pymysql 的源码在阅读，发现 pymysql 在其 connections 模块里内置了一个 DEBUG 变量用于控制是否开启调试模式，是的话，会将当前连接的操作以及报文内容都打印到控制台。 使用方法在你的服务器初始化代码里，加上对 DEBUG 的设置，比如： import pymysqlpymysql.install_as_MySQLdb()pymysql.connections.DEBUG = True # 这是我新加的一行重启服务器后，访问相关接口，会看到标准输出里有类似下面的一些输出：

以下几个措施可以防止误删数据，如下： 1、生产环境中，业务代码尽量不明文保存数据库连接账号密码信息 2、重要的DML、DDL通过平台型工具自动实施，减少人工操作 3、部署延迟复制从库，万一误删除时用于数据回档，且从库设置为read-only 4、确认备份制度及时有效 5、启用SQL审计功能，养成良好SQL习惯 6、启用 sql_safe_updates 选项，不允许没 WHERE 条件的更新/删除 7、将系统层的rm改为mv 8、线上不进行物理删除，改为逻辑删除（将row data标记为不可用） 9、启用堡垒机，屏蔽高危SQL 10、降低数据库中普通账号的权限级别 11、务必开启binlog

原因：在使用Calendar做为字段类型时，每进行一次findById()操作返回的数据的值都比实际值要大一点。更新后再调用查询，还会再大一点。也就是说：如果我们用Calendar做为字段类型，那么该字段会在程序运行时会静悄悄的增大。 代码准备示例代码很简单：我们只需要准备两个类，一个实体，一个数据访问对象。 Student.java package com.example.demo;import org.hibernate.annotations.CreationTimestamp;import javax.persistence.*;import java.sql.Timestamp;import java.util.Calendar;@Entitypublic class Student { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; private String name; @CreationTimestamp private Calendar applyTime; @CreationTimestamp private Timestamp applyTimestamp; // 省略构造函数及setter/getter}为了测试代码更简单，我们为applyTime及applyTime加入CreationTimestamp注解。让其自动生成。 删除自动时间戳并不会影响测试结果package com.example.demo;import org.springframework.data.repository.CrudRepository;public interface StudentRepository extends CrudRepository<Student, Long> {}测试代码package com.example.demo;import org.junit.Test;import org.junit.runner.RunWith;import org.slf4j.Logger;import org.slf4j.LoggerFactory;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.boot.test.context.SpringBootTest;import org.springframework.test.context.junit4.SpringRunner;@SpringBootTest@RunWith(SpringRunner.class)public class StudentRepositoryTest { private static final Logger logger = LoggerFactory.getLogger(StudentRepositoryTest.class); @Autowired StudentRepository studentRepository; @Test public void test() { Student student = new Student(); studentRepository.save(student); Student student1 = studentRepository.findById(student.getId()).get(); System.out.println(student1.getApplyTime().getTimeInMillis()); System.out.println(student1.getApplyTimestamp().getTime()); }}结果如下： ...

1 hadoophive的使用依赖hadoop,所以先介绍hadoop。 1.1 hadoop下载和安装笔者是在Centos7.3上安装的hadoop,使用的是hadoop-3.2的版本。直接按照hadoop-2.9文档安装即可。 hadoop下载地址 1.2 设置hadoop的环境变量hadoop的环境变量一定要设置，不然hive启动的时候会提示找不到hadoop。 在/etc/profile中加入export $HADOOP_HOME=hadoop的安装路径export $PATH=$PATH:$HADOOP_HOME/bin 注意：如果环境变量PATH设置错误，会导致一些命令失效。centos 输入什么命令都失效 1.3 ssh localhost启动hadoop的时候要求在不输入密码的情况下能够ssh localhost成功。在hadoop的官方文档有提到解决办法。我自己遇到的问题是：localhost:permission denied(publickey,password) 解决办法：解决ssh localhost中root@localhost:要求输入密码问题（已经进行了无密码设置登录）root用户操作文件：Operation not permitted 1.4 Name node is in safe mode在使用bin/hdfs dfs -mkdir /tmp命令时出现Cannot create directory /usr. Name node is in safe mode问题，百度上很多答案都说用bin/hdfs dfsadmin -safemode leave关闭安全模式，但是我使用了这个命令，安全模式会自动再次打开，也有一种说法是磁盘满了，但是我的还有一半的空间没利用，最后没有找到其他办法，重启了Hadoop，就解决了。 2 hive2.1 hive的下载和安装我使用的是hive-3.1.1-bin版本，按照官方文档安装即可。 2.2 hive环境变量的配置export HIVE_HOME=hive安装目录export PATH=$PATH:$HIVE_HOME/bin 2.3 hive-site.xml配置需要在添加一个数据库连接，如果在$HIVE_HOME/conf找不到hive-site.xml，可以自己创建一个。我使用的是mysql数据库。 hive-site.xml配置 在MySql数据库的连接url中要添加useSSL=false 遇到的问题：Unexpected character '=' (code 61); expected a semi-colon after the reference for entity 'useUnicode ...

【解决办法】 目前（v3.0.1），在映射 PostgreSQL 外部表的时候，将字段指定为 PostgreSQL 的 serial 字段类型即实现PostgreSQL自增字段的需求。但需要注意这是在 PostgreSQL 端做的序列， 跟 SequoiaDB 的自增序列无关，多个 PostgreSQL 之间也无法共享序列。

【 问题详细 描述】 在 SequoiaDB 中，在 group by 时， decimal （高精度数） 类 型的字段可以做 sum 函数 吗 ？ 【解决 办 法】 1.decimal 类型是支持在 group by 时做聚集函数的， 例如： 集合 cl 中 现 有如下数据： {"a":{"$decimal":"111.111"},"name":"zhangsan"} {"a":{"$decimal":"222.222"},"name":"zhangsan"} {"a":{"$decimal":"123.456"},"name":"lisi"} 在使用 group by 时对 decimal 类型的 'a' 字段做聚集函数db.exec("select sum(a) as 总和 from cs.cl group by name") 结果如下：{" 总和 ":{"$decimal":"123.456"}} {" 总和 ":{"$decimal":"333.333"}} 【 详 情参考】 高精度数： http://doc.sequoiadb.com/cn/S... 聚集函数： http://doc.sequoiadb.com/cn/i... 【解决 办法】 decimal 类型是支持在 group by 时做聚集函数的，例如： ...

整数类型有两种类型的数字：整数和实数。如果存储整数，可以使用这几种整数类型：TINYINT，SMALLINT，MEDIUMINT,INT,BIGINT。分别使用8，16，24，32，64位存储空间。它们可以存储的值的范围从-2^(N-1)到2(N-1)，其中N是存储空间的位数。 整数类型有可选的UNSIGNED属性，表示不允许负值，这大致可以使正数的上限提高一倍。例如TINYINT UNSIGNED可以存储的范围是-～255，而TINYINT的存储范围是-128～127。 有符号和无符号类型使用相同的存储空间，并具有相同的性能，因此可以根据实际情况选择合适的类型。 MySQL 可以为整数类型指定宽度，例如INT（11），对大多数应用这是没有意义的：它不会限制值的合法范围，只是规定了MySQL的一些交互工具（例如MySQL命令行客户端）用来显示字符的个数。对于存储和计算来说，INT（1）和INT（20）是相同的。 实数类型实数是带有小数部分的数字。 （实际工作中还没有使用过实数类型，因为，小数都可以单位换算成整数，显然在服务端使用整数比使用小数靠谱的多）。 字符串类型VARCHAR 和 CHAR 类型VARCHAR 和 CHAR 是两种最主要的字符串类型。很难精确地解释这些值是怎么存储在存储磁盘和内存中的，因为这跟存储引擎的具体实现有关。下面的描述假设使用的存储引擎是InnoDB 或者 MyISAM。如果使用的不是这两种存储引擎，请参考所使用的存储引擎的文档。 先看看VARCHAR和CHAR值通常在磁盘上怎么存储。请注意，存储引擎存储CHAR或者VARCHAR值的方式在内存中和在磁盘上可能不一样，所以MySQL服务器从存储引擎读出的值可能需要转换为另一种存储格式。 VARCHAR VARCHAR 类型用于存储可变长字符串，是最常见的字符串数据类型。它比定长类型更节省空间，因为它仅使用必要的空间。有一种情况例外，如果MySQL表使用ROW_FORMAT = FIXED创建的话，每一行都会使用定长存储，这会很浪费空间。 VARCHAR需要使用1或2个额外字节记录字符串的长度：如果列的最大长度小于或等于255字节，则只使用1个字节表示，否则使用2个字节。 VARCHAR节省了存储空间，所以对性能也有帮助。但是，由于行是变长的，在UPDATE时可能使行变得比原来更长，这就导致需要做额外的工作。如果一个行占用的空间增长，并且在页内没有更多的空间可以存储，在这种情况下，不同的存储引擎的处理方式是不一样的。例如，MyISAM会将行拆成不同的片段存储，InnoDB则需要分裂页来使行可以放进页内。其他一些存储引擎也许从不在原数据位置更新数据。 CHAR CHAR 类型是定长的：MySQL 总是根据定义的字符串长度分配足够的空间。当存储CHAR值时，MySQL会删除所有的末尾空格。CHAR值会根据需要采用空格进行填充以方便比较。 CHAR 适合存储值很短的字符串，或者所有值都接近同一个长度。例如，CHAR非常适合存储密码的MD5值，因为这是一个定长的值。对于经常变更的数据，CHAR也比VARCHAR更好，因为定长的CHAR类型不容易产生碎片。对于非常短的列，CHAR比VARCHAR在存储空间上也更有效率。例如用CHAR（1）来存储只有Y和N的值，如果采用单字节字符集只需要一个字节。但是VARCHAR（1）却需要两个字节，因为还有一个记录长度的额外字节。 慷慨是不明智的 使用VARCHAR（5）和VARCHAR（200）存储'hello'的空间开销是一样的。那么使用更短的列有什么优势吗？ 事实证明有很大的优势。更长的列会消耗更多的内存，因为MySQL通常会分配固定大小的内存块来保存内部值。尤其是使用内存临时表进行排序或操作时会特别糟糕。在利用磁盘临时表进行排序时也同样糟糕。 所以最好的策略是只分配真正需要的空间。 BLOG 和 TEXT 类型BLOG 和TEXT 都是为了存储很大的数据而设计的字符串数据类型，分别采用二进制和字符方式存储。 实际上，它们分别属于两组不同数据类型家族：字符类型是TINIYTEXT，SMALLTEXT，MEDIUMTEXT，LONGTEXT；对应的二进制类型是TINYBLOG，SMALLBLOG，BLOG，MEDIUMBLOG，LONGBLOG。BLOG是SMALLBLOG的同义词。TEXT是SMALLTEXT的同义词。 与其他类型不同，MySQL 把每个BLOG 和 TEXT 值当作一个独立的对象处理。存储引擎在存储时通常会做特殊处理。当BLOG和TEXT值太大时，InnoDB会使用专门的“外部”存储区域来进行存储，此时每个值在行内需要1～4个字节存储一个指针，然后在外部存储区域存储实际的值。 BLOG和TEXT家族之间仅有的不同是BLOG类型存储的是二进制数据，没有排序规则或字符集，而TEXT类型有字符集和排序规则。 日期和时间类型MySQL 提供两种相似的日期类型：DATETIME和TIMESTAMP。 DATETIME 这个类型能保存大范围的值，从1001年到9999年，精度为秒。它把是日期和时间封装到格式为YYYYMMDDHHMMSS的整数中，与时区无关。使用8个字节的存储空间。 默认情况下，MySQL 以一种可排序的、无歧义的格式显示DATETIME值，例如“2018-01-16 22:23:00”。这是ANSI标准定义的日期和时间表示方法。 TIMESTAMP 就像它的名字一样，TIMESTAMP类型保存了从1970年1月1日午夜（格林尼治标准时间）以来的秒数，它和UNIX时间戳相同。TIMESTAMP 只使用4个字节的存储空间，因此它的范围比DATETIME小得多：只能表示从1970年到2038年。 MySQL 4.1以及更新的版本按照DATEYTIME的方式格式化TIMESTAMP的值，但是MySQL 4.0 以及更老的版本不会在各个部分之间显示任何标点符号。这仅仅是显示格式上的区别，TIMESTAMP的存储格式在各个版本都是一样的。 除特殊行为外，通常也应该尽量使用TIMESTAMP，因为它比DATETIME空间效率更高。有时候人们会将Unix时间戳存储为整数值，但这并不会带来任何收益。用整数保存时间戳的格式通常不方便处理，所以不推荐这样做。 总结实际工作中常用的数据类型就那几种，除了了解各个数据类型之间的差异，更多的是在工作中多多积累什么情况下用什么数据类型更合适，这是一个需要衡量的问题。 欢迎关注我的公众号：荒古传说 ...

JDBC资源包 链接：https://pan.baidu.com/s/1JaZ3... 提取码：858d JDBC操作数据库流程Class.forName()加载数据库连接驱动。DriverManager.getConnection()获取数据连接对象。根据SQL语句获取会话对象，会话对象一般用PreparedStatement类型执行SQL处理结果集关闭结果集、关闭会话、关闭连接封装函数 public class SqlUtils { private static String driver = "com.mysql.jdbc.Driver"; private static String url = ""; private static String username = ""; private static String password = ""; static { //加载驱动 try { Class.forName(driver); } catch (ClassNotFoundException e) { e.printStackTrace(); } } //只产生一个连接 public static Connection getConnection() throws SQLException { System.out.println("连接数据库..."); return DriverManager.getConnection(url, username, password); } public static void release(Connection connection, Statement statement, ResultSet resultSet) { if (resultSet != null) { try { resultSet.close(); } catch (SQLException e) { e.printStackTrace(); } } if (statement != null) { try { statement.close(); } catch (SQLException e) { e.printStackTrace(); } } if (connection != null) { try { connection.close(); } catch (SQLException e) { e.printStackTrace(); } } }}测试用例 ...

Swoole MySQL Proxy一个基于 MySQL 协议，Swoole 开发的MySQL数据库连接池。 原理将数据库连接作为对象存储在内存中，当用户需要访问数据库时，首次会建立连接，后面并非建立一个新的连接，而是从连接池中取出一个已建立的空闲连接对象。使用完毕后，用户也并非将连接关闭，而是将连接放回连接池中，以供下一个请求访问使用。而连接的建立、断开都由连接池自身来管理。 同时，还可以通过设置连接池的参数来控制连接池中的初始连接数、连接的上下限数以及每个连接的最大使用次数、最大空闲时间等等。也可以通过其自身的管理机制来监视数据库连接的数量、使用情况等。超出最大连接数会采用协程挂起，等到有连接关闭再恢复协程继续操作。 特性支持读写分离支持数据库连接池，能够有效解决 PHP 带来的数据库连接瓶颈支持 SQL92 标准采用协程调度支持多个数据库连接，多个数据库，多个用户，灵活搭配遵守 MySQL 原生协议，跨语言，跨平台的通用中间件代理支持 MySQL 事务支持 HandshakeV10 协议版本完美兼容 MySQL5.5 - 8.0兼容各大框架，无缝提升性能设计初衷PHP 没有连接池，所以高并发时数据库会出现连接打满的情况，Mycat 等数据库中间件会出现部分 SQL 无法使用，例如不支持批量添加等，而且过于臃肿。所以就自己编写了这个仅支持连接池和读写分离的轻量级中间件，使用 Swoole 协程调度 HandshakeV10 协议转发使程序更加稳定，不用像 Mycat 一样解析所有 SQL 包体，增加复杂度。 版本更新新增status命令监控面板功能 修复日志目录创建失败的问题修复PHP字符串索引取值版本兼容问题开发与讨论文档：https://smproxy.louislivi.com 若被墙请访问：https://smproxy.gitee.louisli...QQ群：722124111欢迎各类 Issue 和 Pull Request。

写作原因之前在学校都是做前端，但是最后找了个Java后端的工作，框架什么的基本没用过，所以工作中遇到了很多问题，所以决定记录下来工作中遇到的问题，记录成长的点滴。正文公司使用的是现在流行的SpringBoot，数据库方面使用的是SpringData+JPA+Hibernate。这几天用的最多的就是用JPA进行查询了，简单的查询很简单，网上查一查就有一堆方案，直到遇到分页查询的时候出了问题。 网上查到的大多都是使用EntityManager通过人工拼接sql来查询的，但是今天从导师那里学到了一手，在Repository中使用@Query注解即可。代码如下 public interface StudentRepository extends JpaRepository<Student,Integer> { @Query( value = "SELECT * FROM student" + " WHERE (age = ?1 OR ?1 IS NULL)" + " WHERE (id = ?2 OR ?2 IS NULL)" + " WHERE (first_name = ?3 OR ?3 IS NULL)" + " ORDER BY ?#{#pageable}", countQuery = "SELECT COUNT(1) FROM " + "SELECT * FROM student" + " WHERE (age = ?1 OR ?1 IS NULL)" + " WHERE (id = ?2 OR ?2 IS NULL)" + " WHERE (first_name = ?3 OR ?3 IS NULL)" + " ORDER BY ?#{#pageable}", nativeQuery = true ) Page<Student> findByAgeAndIdAndFirstName(Integer age, Integer id, String firstName, Pageable pageable);}最后的Pageable可以使用PageRequest来创建。 ...

MySQL术语表A这些术语通常用于MySQL数据库服务器的信息中，这个术语表最初是作为有关InnoDB存储引擎的术语的参考，大多数定义都与InnoDB相关。 .ARM文件 ARCHIVE表的元数据，与.ARZ文件形成对比，具有此扩展名的文件总是包含在MySQL Enterprise Backup产品的mysqlbackup命令生成的备份中。.ARZ文件 ARCHIVE表的数据，与.ARM文件形成对比，具有此扩展名的文件总是包含在MySQL Enterprise Backup产品的mysqlbackup命令生成的备份中。ACID 原子性、一致性、隔离性和持久性的缩写。这些属性在数据库系统中都是需要的，并且都与事务的概念紧密相关，InnoDB的事务特性遵循ACID原则。事务是可以提交或回滚的工作的原子单位，当事务对数据库进行多次更改时，要么所有更改在提交事务时成功，要么所有更改在回滚事务时撤消。在每次提交或回滚之后，以及在事务进行期间，数据库始终处于一致的状态，如果跨多个表更新相关数据，查询将看到所有旧值或所有新值，而不是新旧值的混合。事务在进行过程中彼此受到保护（隔离），它们不能相互干扰或查看彼此未提交的数据，这种隔离是通过锁定机制实现的。经验丰富的用户可以调整隔离级别，当他们能够确保事务之间确实没有相互干扰时，就可以用更少的保护换取更高的性能和并发性。事务结果是持久的：一旦提交操作成功，该事务所做的更改就不会受到电源故障、系统崩溃、竞争条件或许多非数据库应用程序容易受到的其他潜在危险的影响。持久性通常包括对磁盘存储的写入，具有一定的冗余，以防止在写入操作期间出现电源故障或软件崩溃（在InnoDB中，双写缓冲区有助于提高持久性）。自适应冲洗 一种用于InnoDB表的算法，它可以消除检查点引入的I/O开销，MySQL不是一次性将所有修改过的页面从缓冲池刷新到数据文件，而是定期刷新一小组修改过的页面。自适应冲洗算法扩展了这一过程，根据冲洗速度和生成重做信息的速度，估计执行这些周期性冲洗的最优速度。自适应哈希索引 InnoDB表的优化，通过在内存中构造一个哈希索引，可以使用=和IN操作符加速查找，MySQL监视对InnoDB表的索引搜索，如果查询可以从哈希索引中获益，它会为经常访问的索引页自动构建一个索引。从某种意义上说，自适应哈希索引在运行时配置MySQL以利用充足的主内存，这更接近于主内存数据库的体系结构，这个特性由innodb_adaptive_hash_index配置选项控制，由于该特性对某些工作负载有好处，但对其他工作负载没有好处，而且用于哈希索引的内存保留在缓冲池中，因此通常应该使用启用和禁用该特性来进行基准测试。哈希索引总是基于表上现有的B-tree索引构建的，MySQL可以在为B-tree定义的任意长度的键的前缀上构建散列索引，这取决于对索引的搜索模式，哈希索引可以是局部的，整个B-tree索引不需要缓存在缓冲池中。在MySQL 5.6或更高版本中，利用InnoDB表快速单值查找的另一种方法是使用InnoDB memcached插件。AIO 异步I/O的缩写，你可能在InnoDB消息或关键字中看到这个缩略词。应用程序编程接口（API） 一组函数或程序，API为函数、程序、参数和返回值提供一组稳定的名称和类型。apply 当MySQL Enterprise Backup产品生成的备份不包含在备份过程中发生的最新更改时，更新备份文件以包含这些更改的过程称为apply步骤，它由mysqlbackup命令的apply-log选项指定。在应用更改之前，我们将这些文件称为原始备份，应用更改之后，我们将这些文件称为准备好的备份，更改记录在ibbackup_logfile文件中，一旦apply步骤完成，就不再需要这个文件了。异步I/O 一种I/O操作，允许在I/O完成之前进行其他处理，也称为非阻塞I/O，缩写为AIO。InnoDB对某些操作使用这种类型的I/O，这些操作可以并行运行，而不会影响数据库的可靠性，比如将没有实际请求的页面读入缓冲池，但可能很快就会需要。过去，InnoDB只在Windows系统上使用异步I/O，从InnoDB Plugin 1.1和MySQL 5.5开始，InnoDB在Linux系统上使用异步I/O，这个更改引入了对libaio的依赖。Linux系统上的异步I/O是使用innodb_use_native_aio选项配置的，该选项在默认情况下是启用的，在其他类unix系统上，InnoDB只使用同步I/O。原子 在SQL上下文中，事务是工作单元，要么完全成功（提交时），要么完全无效（回滚时），事务不可分割（“atomic”）属性是ACID中的“A”。原子DDL 原子DDL语句是将与DDL操作关联的数据字典更新、存储引擎操作和二进制日志写入组合到单个原子事务中的语句。事务要么完全提交，要么回滚，即使服务器在操作期间暂停，原子DDL支持是在MySQL 8.0中添加的。原子指令 由CPU提供的特殊指令，以确保不能中断关键的低级别操作。自动递增 表列的一个属性（由AUTO_INCREMENT关键字指定），该属性自动在列中添加升序值。它为开发人员节省了工作，不必在插入新行时生成新的惟一值，它为查询优化器提供了有用的信息，因为已知列不是null，并且具有惟一的值。此类列中的值可以在各种上下文中用作查找键，因为它们是自动生成的，所以没有理由更改它们，因此，主键列通常指定为自动递增。对于基于语句的复制，自动递增列可能会有问题，因为由于时间问题，在从服务器上重新执行语句可能不会生成与主服务器上相同的列值集。当你有一个自动递增的主键时，你只能在设置innodb_autoinc_lock_mode=1的情况下使用基于语句的复制。如果你的innodb_autoinc_lock_mode=2，它允许更高的插入操作并发性，那么使用基于行的复制而不是基于语句的复制。除非出于兼容性的目的，否则不应该使用innodb_autoinc_lock_mode=0设置。连续锁模式（innodb_autoinc_lock_mode=1）是MySQL 8.0.3之前的默认设置，从MySQL 8.0.3开始，交错锁模式（innodb_autoinc_lock_mode=2）是默认模式，它反映了从基于语句的复制到基于行复制的更改，作为默认复制类型。自动递增锁定 自动递增主键的便利性涉及到并发性的一些权衡，在最简单的情况下，如果一个事务正在向表中插入值，那么任何其他事务都必须等待它们自己插入该表，以便第一个事务插入的行接收连续的主键值。InnoDB包含优化和innodb_autoinc_lock_mode选项，这样你就可以在可预测的自动递增值序列和插入操作的最大并发性之间进行配置和优化平衡。自动提交 在每个SQL语句之后引发提交操作的设置，不推荐使用这种模式来处理具有跨多个语句的事务的InnoDB表。它可以帮助InnoDB表上的只读事务的性能，尤其是在MySQL 5.6.4及以上版本中，它将锁定和生成撤销数据带来的开销降到最低，它也适用于处理不适用事务的MyISAM表。可用性 能够处理主机上的故障，并在必要时从故障中恢复，包括MySQL、操作系统或可能导致停机的硬件和维护活动的故障，通常，可伸缩性是大规模部署的关键方面。

存储过程存储过程（Stored Procedure）是在大型数据库系统中，一组为了完成特定功能的SQL 语句集，它存储在数据库中，一次编译后永久有效，用户通过指定存储过程的名字并给出参数（如果该存储过程带有参数）来执行它。存储过程是数据库中的一个重要对象。优势可以减少程序在调用DB时候的信息传输量（其实减少的只有Request的时候）存储过程是预先优化和预编译的，节省每次运行编译的时间，所以一般情况下认为存储过程的性能是优于sql语句的。对调用者可以隐藏数据库的复杂性，将数据组装的过程封装。参数化的存储过程可以防止SQL注入式攻击，而且可以将Grant、Deny以及Revoke权限应用于存储过程。如果业务开发中，数据人员和业务代码人员是分离的，业务人员可以不用关心数据，直接调用存储过程，更加面向分层开发设计理念。劣势存储过程这种“一次优化，多次使用”的策略节省了每次执行时候编译的时间，但也是该策略导致了一个致命的缺点：可能会使用错误的执行计划。存储过程难以调试，虽然有些DB提供了调试功能，但是一般的账号根本就没有那种权限，更何况线上的数据库不可能会给你调试权限的，再进一步就算能调试效果也比程序的调试效果要差很多。可移植性差，当碰到切换数据种类的时候，存储过程基本就会歇菜。如果业务数据模型有变动，存储过程必须跟着业务代码一起更改，如果是大型项目，这种改动是空前的，是要命的。不推荐存储过程以上存储过程的优缺点，你随便一下网络就可能查到，表面看来存储过程的优势还是不少的，这也说明为什么老一辈程序员有很多喜欢写存储过程。但是随着软件行业业务日益复杂化，存储过程现在在复杂业务面前其实有点有心无力。 菜菜在业务中并不推荐使用存储过程,辩驳请留言采用存储过程操作数据在网络数据量传输上确实比直接使用sql语句要少很多，但这通常并不是操作数据系统性能的瓶颈，在一次操作数据的过程中，假设用时100毫秒，采用存储过程节省数据传输时间0.5毫秒（就算是5毫秒），我觉得这点时间基本可以忽略。存储过程是只优化一次的，这有时候恰恰是个缺陷。有的时候随着数据量的增加或者数据结构的变化，原来存储过程选择的执行计划也许并不是最优的了，所以这个时候需要手动干预或者重新编译了，而什么时候执行计划不是最优的了这个平衡点，预先无法知晓，这就导致了有些应用突然会变慢，程序员处于懵逼的状态。存储过程确实可以对调用方隐藏数据库的细节，但是这种业务代码人员和数据库设计人员是两个团队的情况又有多少呢，如果真是两个团队，那业务就需要两个团队来理解和沟通，我想沟通的成本也一定很高，而且分歧更容易产生。菜菜认为数据库就应该做它最擅长的事情：存储相关。我不止一次的看过把业务写在存储过程的情况，程序代码层面真是薄薄的贫血层，就是一个数据的透传。我不赞同这种写法，因为我就接手过这样的程序，令我头疼的不是业务，而是看着好几千行的存储过程熟悉业务，关键还没有调试的权限（线上更不能调试）。 一个业务系统的设计往往需要你从数据库的层面抽离出来，把主要精力放在业务模型的设计上，在程序层面体现业务逻辑，而不是把业务逻辑都交给数据层面的管理者。前几天我排查过一个“Bug”：存储过程是输入参数是一个主键id的列表字符串，长度居然是 nvarchar（max），主要功能是根据id列表查询数据。我想说的是就算你是max的长度，也有超长的可能性发生，因为业务方传输什么参数，参数什么长度是你DB无法控制的，所以这类的业务一定要放在程序中做处理，而不是怀着侥幸心里丢给DB。 如果是抱着存储过程性能高的心态的话，我到时觉你这是误入歧途，菜菜认为存储过程从来都不是提高性能的关键，反而系统的架构，缓存的设计，数据一致性更是系统关键问题。 存储过程通常是一种解决方案，但是通常情况下不是唯一的解决方案，在选择存储过程作为方案前，请确保他们是正确的选择。最后秀一波存储过程吧 添加关注，查看更精美版本，收获更多精彩

概述mysql里面有很多log，比如用于主从同步的bin_log，防止数据丢失的redo_log，慢查询日志slow_log等等 redo logInnoDB有buffer pool（简称bp）。bp是数据库页面的缓存，<font color="#0099ff">对InnoDB的任何修改操作都会首先在bp的page上进行，然后这样的页面将被标记为dirty并被放到专门的flush list上，后续将由master thread或专门的刷脏线程阶段性的将这些页面写入磁盘（disk or ssd）}</font>。这样的好处是避免每次写操作都操作磁盘导致大量的随机IO，阶段性的刷脏可以将多次对页面的修改merge成一次IO操作，同时异步写入也降低了访问的时延。然而，如果在dirty page还未刷入磁盘时，server非正常关闭，这些修改操作将会丢失，如果写入操作正在进行，甚至会由于损坏数据文件导致数据库不可用。为了避免上述问题的发生，Innodb将所有对页面的修改操作写入一个专门的文件，并在数据库启动时从此文件进行恢复操作，这个文件就是redo log file。 这样的技术推迟了bp页面的刷新，从而提升了数据库的吞吐，有效的降低了访问时延。带来的问题是额外的写redo log操作的开销（顺序IO，当然很快），以及数据库启动时恢复操作所需的时间。 Undo LogUndo Log是为了实现事务的原子性，在MySQL数据库InnoDB存储引擎中，还用UndoLog来实现多版本并发控制(简称：MVCC)。-事务的原子性(Atomicity)事务中的所有操作，要么全部完成，要么不做任何操作，不能只做部分操作。如果在执行的过程中发了错误，要回滚(Rollback)到事务开始前的状态，就像这个事务从来没有执行过。 bin-logbinlog有三种格式：Statement、Row以及Mixed。从安全性来看，ROW（最安全）、MIXED（不推荐）、STATEMENT（不推荐）。–基于SQL语句的复制(statement-based replication,SBR)，每一条会修改数据的sql语句会记录到binlog中。优点是并不需要记录每一条sql语句和每一行的数据变化，减少了binlog日志量，节约IO，提高性能。缺点是在某些情况下会导致master-slave中的数据不一致(如sleep()函数， last_insert_id()，以及user-defined functions(udf)等会出现问题)–基于行的复制(row-based replication,RBR)，默认不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了，修改成什么样了。而且不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题。缺点是会产生大量的日志，尤其是alter table的时候会让日志暴涨。–混合模式复制(mixed-based replication,MBR)。以上两种模式的混合使用，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog，MySQL会根据执行的SQL语句选择日志保存方式。查看binlog_formatshow variables like 'binlog_format' relay（中继） log：Mysql 主节点将binlog写入本地，从节点定时请求增量binlog，主节点将binlog同步到从节点。从节点单独进程会将binlog 拷贝至本地 relaylog中。从节点定时重放relay log。 slow-log慢查询就是通过设置来记录超过一定时间的SQL语句 开启slow-log在my.conf 中增加slow_query_log = 1 // 开启slow-loglong_query_time = 1 // 查询时间超过1s的sql会被记录分析show-logmore slow-query.log Query_time: 查询耗时Rows_examined: 检查了多少条记录Rows_sent : 返回了多少行记录(结果集)按Rows_examined 逆序，列出前100条grep Rows_examined slow-query.log | sort -g -k9 -r|uniq -u |head -100指定Rows_examined一值，查找grep -A 1 -B 2 "Rows_examined: 24460" slow-query.log看到每秒的慢查询统计awk '/^#Time:/{print $3,$4,c;c=0}/^# User /{c++}' slow-query.log >/tmp/aaa.logmysqldumpslow命令 ...

优化SQL语句数据库应用程序的核心逻辑是通过SQL语句执行的，无论是直接通过解释器发出，还是通过API在后台提交。本节中的调优指南有助于加快各种MySQL应用程序的速度，这些指导原则包括读取和写入数据的SQL操作、通常SQL操作的幕后开销以及在特定场景（如数据库监视）中使用的操作。 优化SELECT语句以SELECT语句的形式的查询执行数据库中的所有查找操作，优化这些语句是首要任务，无论是为动态web页面实现次秒级响应时间，还是缩短生成大型夜间报告的时间。 除了SELECT语句外，查询的调优技术还适用于CREATE TABLE...AS SELECT、INSERT INTO...SELECT的构造，以及DELETE语句中的WHERE子句，这些语句具有额外的性能考虑，因为它们将写操作与面向读取的查询操作结合起来。 NDB集群支持连接下推优化，其中符合条件的连接被完整地发送到NDB集群数据节点，可以在节点之间分布并并行执行。 优化查询的主要考虑因素是： 要使缓慢的SELECT ... WHERE查询更快，首先要检查的是是否可以添加索引，在WHERE子句中使用的列上设置索引，以加快计算、筛选和最终检索结果的速度，为了避免浪费磁盘空间，构造一小组索引来加快应用程序中使用的许多相关查询。索引对于引用不同表的查询尤其重要，这些查询使用连接和外键等特性，你可以使用EXPLAIN语句来确定将哪些索引用于SELECT。 隔离和调优查询的任何部分，例如一个函数调用，这会花费过多的时间。根据查询的结构，可以对结果集中的每一行调用一个函数，甚至对表中的每一行调用一个函数，这极大地提高了效率。尽量减少查询中全表扫描的次数，特别是对于大表。通过定期使用ANALYZE TABLE语句使表统计信息保持最新，这样优化器就有了构建有效执行计划所需的信息。学习与每个表的存储引擎相关的调优技术、索引技术和配置参数，InnoDB和MyISAM都有一套指导原则来支持和维持查询的高性能。为InnoDB表优化单查询事务。避免以难以理解的方式转换查询，特别是当优化器自动执行某些相同的转换时。如果某个基本准则不能很容易地解决性能问题，那么通过阅读EXPLAIN计划并调整索引、WHERE子句、join子句等，研究特定查询的内部细节。调整MySQL用于缓存的内存区域的大小和属性，由于有效地使用了InnoDB缓冲池、MyISAM键缓存和MySQL查询缓存，重复查询运行得更快，因为结果是在第二次和以后的时间从内存中检索的。即使对于使用缓存内存区域快速运行的查询，你也可以进行进一步优化，使它们所需的缓存内存更少，从而使应用程序更具可伸缩性。可伸缩性意味着你的应用程序可以同时处理更多的用户、更大的请求，等等，而不会出现性能的大幅下降。处理锁定问题，你的查询速度可能会受到同时访问表的其他会话的影响。上一篇：优化概述

介绍MySQL 是最流行的关系型数据库管理系统，在 WEB 应用方面 MySQL 是最好的 RDBMS(Relational Database Management System：关系数据库管理系统)应用软件之一。 什么是数据库？数据库（Database）是按照数据结构来组织、存储和管理数据的仓库。 每个数据库都有一个或多个不同的 API 用于创建，访问，管理，搜索和复制所保存的数据。 我们也可以将数据存储在文件中，但是在文件中读写数据速度相对较慢。 所以，现在我们使用关系型数据库管理系统（RDBMS）来存储和管理的大数据量。所谓的关系型数据库，是建立在关系模型基础上的数据库，借助于集合代数等数学概念和方法来处理数据库中的数据。 RDBMS 即关系数据库管理系统(Relational Database Management System)的特点： 数据以表格的形式出现每行为各种记录名称每列为记录名称所对应的数据域许多的行和列组成一张表单若干的表单组成databaseRDBMS 术语在我们开始学习MySQL 数据库前，让我们先了解下RDBMS的一些术语： 数据库: 数据库是一些关联表的集合。数据表: 表是数据的矩阵。在一个数据库中的表看起来像一个简单的电子表格。列: 一列(数据元素) 包含了相同的数据, 例如邮政编码的数据。行：一行（=元组，或记录）是一组相关的数据，例如一条用户订阅的数据。冗余：存储两倍数据，冗余降低了性能，但提高了数据的安全性。主键：主键是唯一的。一个数据表中只能包含一个主键。你可以使用主键来查询数据。外键：外键用于关联两个表。复合键：复合键（组合键）将多个列作为一个索引键，一般用于复合索引。索引：使用索引可快速访问数据库表中的特定信息。索引是对数据库表中一列或多列的值进行排序的一种结构。类似于书籍的目录。参照完整性: 参照的完整性要求关系中不允许引用不存在的实体。与实体完整性是关系模型必须满足的完整性约束条件，目的是保证数据的一致性。MySQL 为关系型数据库(Relational Database Management System), 这种所谓的"关系型"可以理解为"表格"的概念, 一个关系型数据库由一个或数个表格组成, 如图所示的一个表格: 表头(header): 每一列的名称;列(col): 具有相同数据类型的数据的集合;行(row): 每一行用来描述某条记录的具体信息;值(value): 行的具体信息, 每个值必须与该列的数据类型相同;键(key): 键的值在当前列中具有唯一性。MySQL数据库MySQL 是一个关系型数据库管理系统，由瑞典 MySQL AB 公司开发，目前属于 Oracle 公司。MySQL 是一种关联数据库管理系统，关联数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。 MySQL 是开源的，所以你不需要支付额外的费用。MySQL 支持大型的数据库。可以处理拥有上千万条记录的大型数据库。MySQL 使用标准的 SQL 数据语言形式。MySQL 可以运行于多个系统上，并且支持多种语言。这些编程语言包括 C、C++、Python、Java、Perl、PHP、Eiffel、Ruby 和 Tcl 等。MySQL 对PHP有很好的支持，PHP 是目前最流行的 Web 开发语言。MySQL 支持大型数据库，支持 5000 万条记录的数据仓库，32 位系统表文件最大可支持 4GB，64 位系统支持最大的表文件为8TB。MySQL 是可以定制的，采用了 GPL 协议，你可以修改源码来开发自己的 MySQL 系统。安装window下安装MySQL下载地址点击 Download 按钮进入下载页面，点击下图中的 No thanks, just start my download. 就可立即下载：下载完后，我们将 zip 包解压到相应的目录，这里我将解压后的文件夹放在 D:mysqlmysql 下 ...

【问题回复】 导入工具可以通过--hosts 参数来同时指定一个或者多个coord。当参数--coord被设置为false时（默认为true），每个job只会从用户提供的coord地址中，随机选择一个coord地址使用。当参数--coord被设置为true时，sdbImprt工具会从catalog上同步所有的coord地址，然后每个job只会从这些同步下来的coord地址中随机选择coord地址使用。 若用户不希望sdbImprt工具从catalog同步coord地址，用户应该主动将--coord设置为false，以保证sdbImprt工具使用的都是用户显式指定的coord

【问题描述】 晋商消费金融测试，客户想了解以下的内容： LOB数据读取和写入的过程以及LOB数据是如何分片进行存储的，希望有份文档能详细介绍我们LOB数据的存储结构(lobd和lobm的结构)，并用例子说明非结构化数据是如何进行进行读取，写入的。如：集合空间的LobPageSize为4096，写入一个10kb的文件，通过展示lobm以及lobd的内容，说明10kb的文件是如何被分片存储的。结构化数据读取和写入的过程以及结构化数据时如何存储的，希望有份文档能详细介绍我们的结构化数据的存储结构(.data和.idx)，并用例子说明结构化数据时如何进行读取、写入的，需要分走索引和不走索引时的两种情况。

优化概述数据库性能取决于数据库级别的几个因素，比如表、查询和配置设置，这些软件构造导致了硬件级别的CPU和I/O操作，你必须将其最小化并尽可能提高效率。在研究数据库性能时，首先要学习软件方面的高级规则和指导原则，并使用壁钟时间测量性能。 典型用户的目标是从现有的软件和硬件配置中获得最佳的数据库性能，高级用户寻找机会来改进MySQL软件本身，或者开发自己的存储引擎和硬件设备来扩展MySQL生态系统。 在数据库级进行优化使数据库应用程序快速运行的最重要因素是它的基本设计： 表的结构是否正确？特别是，列是否具有正确的数据类型，每个表是否具有适合工作类型的列？例如，执行频繁更新的应用程序常常有很多表只有很少的列，而分析大量数据的应用程序通常只有很少的表有很多列。是否有适当的索引使查询高效？你是否为每个表使用了适当的存储引擎，并利用了所使用的每个存储引擎的优点和特性？特别是，选择事务性存储引擎（如InnoDB）或非事务性存储引擎（如MyISAM）对性能和可伸缩性非常重要。 InnoDB是创建新表的默认存储引擎，在实践中，先进的InnoDB性能特性意味着InnoDB表通常比简单的MyISAM表表现得更好，特别是对于繁忙的数据库。每个表都使用适当的行格式吗？这种选择还取决于表使用的存储引擎，特别是，压缩表使用更少的磁盘空间，因此读写数据所需的磁盘I/O更少，压缩适用于所有使用InnoDB表的工作负载，也适用于只读MyISAM表。应用程序是否使用适当的锁定策略？例如，在可能的情况下允许共享访问，以便数据库操作可以并发运行；在适当的情况下请求独占访问，以便关键操作获得高优先级，同样，存储引擎的选择也很重要。InnoDB存储引擎可以在不需要你参与的情况下处理大多数锁定问题，从而提高数据库的并发性，减少代码的实验和调优量。所有用于缓存大小的内存区域都正确吗？也就是说，大到足以容纳频繁访问的数据，但又不会大到使物理内存过载并导致分页，要配置的主要内存区域是InnoDB缓冲池和MyISAM键缓存。在硬件级别进行优化随着数据库变得越来越忙，任何数据库应用程序最终都会遇到硬件限制，DBA必须评估是否可以调优应用程序或重新配置服务器以避免这些瓶颈，或者是否需要更多的硬件资源，系统瓶颈通常来自以下来源： 磁盘查找，磁盘需要时间才能找到一段数据，对于现代磁盘，这一过程的平均时间通常低于10ms，所以理论上我们可以每秒进行100次搜索。对于新磁盘，这个时间提高缓慢，并且很难对单个表进行优化，优化查找时间的方法是将数据分布到多个磁盘上。磁盘读写，当磁盘处于正确的位置时，我们需要读取或写入数据。对于现代磁盘，一个磁盘至少可以提供10-20MB/s的吞吐量，这比查找更容易优化，因为你可以从多个磁盘并行读取。CPU周期，当数据在主存时，我们必须处理它以得到我们的结果，与内存量相比，拥有较大的表是最常见的限制因素，但是对于小表，速度通常不是问题。内存带宽，当CPU需要超过CPU缓存容量的数据时，主内存带宽就会成为瓶颈，对于大多数系统来说，这是一个不常见的瓶颈，但是需要注意。平衡可移植性和性能要在可移植MySQL程序中使用面向性能的SQL扩展，可以在/*! */注释分隔符内的语句中封装特定于MySQL的关键字，其他SQL服务器忽略已注释的关键字。

数据库的巨大挑战随着我国经济的高速发展，企业的用户数量、数据量呈现爆发式增长，在这样的高速增长环境下，对数据库性能提出了严峻的考验。对于所有的数据库而言，除了记录正确的处理结果之外，还面临着以下几方面的挑战： 当数据库性能遇到问题时，是否能够横向扩展？是否拥有实时同步的副本？当数据库面临灾难时，是否可以短时间内通过故障转移的方式保证数据库的可用性？当数据丢失或损坏时，能否通过所谓的实时副本实现数据的零损失？数据库的横向扩展是否对应用程序透明？数据库集群化服务器以其高性能和低廉的价格而倍受广大客户青睐，在WEB应用或高性能计算中，为了追求更高的性能、以及可用性，我们采用计算机集群技术来实现。 高效部署MySQL多主集群我们通过URLOS可快速完成3节点MySQL数据库集群的构建，利用三个MySQL实例构建一个数据库多主集群，向客户端提供数据读写服务，支持同步复制，读写无延误，可在任意节点读写，即使其中任意一台数据库宕机，也不影响数据库服务正常运行。 下面我们演示如何在Ubuntu下利用URLOS快速部署mysql多主集群。 首先，我们准备好3台云主机，在其中1台主机上通过ssh工具执行以下命令来安装URLOS： curl -LO www.urlos.com/iu && sh iu安装完成后登录URLOS主控端，创建一个集群：设置本地存储目录，点击提交集群创建完成后，立即添加节点：按上一步的方法依次添加3个节点：OK，集群和节点都创建好以后，我们来安装mysql多主集群在基础信息中填写服务名称在集群设置里面填写数据库集群名称和数据库密码运行节点设置中，依次选择pc1、pc2、pc3完成以上步骤后，点击提交按钮，等待部署完成到这里，MySQL多主集群就部署完成了。由于MySQL多主集群的使用需要经过专门培训，因此不在本文讨论范围。感兴趣的朋友可以关注URLOS。

索引出现的主要目的是提高查询语句的执行效率。为了能够提高查询语句的性能，我们基本的做法都是在查询条件字段上合理地增加索引来实现的。 不过，你是否碰到过类似的情况，查询的条件字段明明有创建索引，可是MySQL 服务器为什么没有使用索引，而是走全表扫描呢？是否曾怀疑查询优化器生成的执行计划是不是有问题呢？ 查询优化器是根据数据表的统计信息来生成执行计划的，统计的信息会有一定的误差，所以优化器生成的执行计划是可能有问题的。 但是在怀疑优化器生成的执行计划有问题之前，可以检查一下SQL 语句是否存在一下的情况。因为如果有一下的情况的话，查询确实是不会使用索引的。 条件字段函数操作这个情况怎么理解呢？其实很好理解，就是在查询条件字段上使用了函数计算，类似于select f1,f2 form t where month(f1)=7。这种写法，即使在字段f1上有建立索引，MySQL 做查询时也是使用不上的，因为函数操作可能会破坏了索引值的有序性！ 为什么会是这样子呢？ 字段的索引是有序的，它是根据字段的值进行排序的。假如 t1 是表示时间的信息，那么用来进行索引排序的值就类似于这样的 2018-02-23 11:23:182018-05-16 01:09:252019-01-12 08:17:272019-06-08 09:37:57如果对字段进行了函数操作，如month(f1)=7,那么要到索引树中查找的值就是 7 了。很明显，MySQL数据库是无法从索引树查到对应的记录的，所以只能放弃使用索引了。 口说无凭，来看一个例子吧。 我创建了一个测试表，表结构如下： CREATE TABLE `new_t` ( `id` int(11) NOT NULL AUTO_INCREMENT, `f1` datetime NOT NULL, `f2` varchar(12) NOT NULL DEFAULT '0', PRIMARY KEY (`id`), KEY `idx_f1` (`f1`), KEY `idx_f2` (`f2`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4然后随机插入了 30 万左右的数据。 接下来测试了以下两个查询语句的执行计划。 查询 1mysql> explain select f1,f2 from new_t where year(f1) = 2019\G;*************************** 1. row *************************** id: 1 select_type: SIMPLE table: new_t partitions: NULL type: ALLpossible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 320048 filtered: 100.00 Extra: Using where1 row in set, 1 warning (0.00 sec)查询 2mysql> explain select f1,f2 from new_t where f1 = '2019'\G;*************************** 1. row *************************** id: 1 select_type: SIMPLE table: new_t partitions: NULL type: refpossible_keys: idx_f1 key: idx_f1 key_len: 5 ref: const rows: 1 filtered: 100.00 Extra: Using index condition1 row in set, 5 warnings (0.00 sec)从以上的信息可以看出，查询 1 的查询条件使用了函数操作 year()，它破坏了索引值的有序性，所以查询使用不了索引，只能走全表扫描，遍历完 32 万的记录才能得到结果。 ...