Mysql

最近开始应用MySQL数据库进行我的项目的开发,尽管以前在大学期间有段应用MySQL数据库的经验,但再次应用Navicat for MySQL时,除了相熟感其它基本操作如同都忘了,当初把应用中的问题作为博客记录下来,也是为了本人当前再应用时比当初更相熟精通. 需要数据库中的表复制因为创立的表有很多雷同的规范字段,所以最快捷的办法是复制一个表,而后进行局部的批改增加.但尝试通过界面操作,如同不能实现通过SQL语句,在命令行对SQL语句进行批改,而后执行SQL语句,能够实现表的复制 视图中SQL语句的导出在应用PowerDesign制作数据库模型时,须要将MySQL数据库中的数据库表的SQL语句和视图的SQL语句导出数据库表的SQL语句到处右击即可即有SQL语句的导出数据库视图的SQL语句无奈通过这种办法到导出 解决办法数据库表的复制点击数据库右击即可在下拉菜单框中看到命令列界面选项,点击命令行界面选项即可进入命令列界面在命令列界面复制表的SQL语句,对SQL语句字段批改执行后就能够实现数据库表的复制 视图中SQL语句的导出首先对数据库的视图进行备份在备份好的数据库视图中提取SQL

摘要：当磁盘空间爆满后，MySQL会产生什么事呢？又应该怎么应答？本文分享自华为云社区《【MySQL 数据库救火】- 磁盘忽然爆满的解决形式》，原文作者：技术火炬手 。 大多数用户在对于磁盘进行分区的时候都是习惯性的不给系统盘预留很大空间，其实这并不是一个好习惯。因为零碎分区并不像咱们设想的那样会仅仅装置一个操作系统，零碎分区少数还是会承载操作系统次要应用软件装置工作。那么当磁盘空间爆满后，MySQL会产生什么事呢？又应该怎么应答？ MySQL 数据库磁盘爆的次要起因数据量大MySQL 磁盘爆的最常见起因之一就是数据量忽然增大导致数据库爆，这种起因往往和业务相干。比方应用程序在短时间内生成了大量的数据，如果是忽然呈现新增大量数据，也有可能是某些测试用例或者压测导致。这种起因导致的数据库磁盘暴涨能够通过清理数据的形式解决，比方革除特定时间段的数据。 倡议在测试环境等数据库，进行压力测试或者其余自动化测试时候对数据做非凡的标记，在实现测试后主动革除测试产生的垃圾数据，防止日积月来导致磁盘爆满影响数据库应用。 同时依照数据库日常应用的状况看是否须要对磁盘进行扩容，然而扩容只能缓解，不能根治。 日志文件MySQL在日常运行的时候回产生大量的日志文件，这些日志文件也会占用磁盘空间，与日俱增可能会产生几百G的日志文件。MySQL 的日志文件次要有以下几种： bin log 二进制文件通常是占用空间最大的日志类型，这和数据库的应用状况相干。error 谬误日志占用空间大的起因次要体现在长时间的与日俱增，没有定时革除导致，比方运行了一两年的数据库，产生的谬误日志往往也比拟大。慢查问日志 慢查问日志通常不会占用太多空间，然而长时间不清理也会呈现占用过多的问题，须要定时清理临时文件临时文件是数据库运行时候产生的临时性文件，这种临时性文件在运行完结当前会主动开释，然而某些异常情况下如果没有开释会造成比较严重的结果，比方短时间的慢查问语句，这种慢查问执行工夫巨长，查问的数据很多，MySQL在内存不够的状况下回长期将两头后果寄存在数据库的长期目录下。 解决日志文件导致的磁盘爆满清理日志文件导致的磁盘爆满比拟容易，在确保文件备份转存的前提下能够间接清理文件。应用 echo ‘’ >> host- XXXXX.err 等命令能够间接清理这些日志文件。 切记不要间接删除相干的日志文件查看以后数据库服务器磁盘占用状况能够应用如下命令 df -h 查看某个文件夹下的文件磁盘占中状况能够应用 du 明令 参考 # 切换到须要查看的门路下应用du -hl日志文件导致的磁盘爆满能够通过linux 命令 echo '' >> host-xxxxx.log 解决临时文件导致的磁盘爆满查看Mysql 配置的长期目录通常 MySQL 的长期目录在 mysql/temp 门路下，如果想查看配置的参数，能够应用 show variables like ‘tmpdir’ SQL命令 show variables like 'tmpdir' 临时文件产生的起因临时文件产生的次要起因是MySQL在执行的时候，对一些大数据量的操作的时候内存无奈满足存储需要的时候，MySQL会应用临时文件，比方某个长期表查问出的几百万数据，某个联结查问产生的后果集等。通常状况下MySQL产生的临时文件很小，同时也会及时开释，然而一些异常情况下，比方慢查问，会导致短时间产生大量的临时文件。 上面是一个因为慢查问导致长期目录下产生大量文件的案例。 临时文件产生过多导致磁盘爆满，造成数据库短时故障数据库解体的先兆往往是短时间呈现大量IO，CPU暴涨。呈现以上征兆的时候数据库就离解体不远了，上面这个案例就是。 这个案例中咱们发现在某个工夫点数据库忽然CPU暴涨，而且是持续性暴涨，与此对应的磁盘的IO次数暴增，内存应用暴增。这个时候根本能够判断数据库呈现了短时间大量的慢查问。 为什么慢查问会导致磁盘IO暴增？起因是下面说的，数据库在查问的时候应用的长期表或者长期数据如果内存不足以寄存的时候，数据库会将这些数据寄存在磁盘中，随着慢查问越来越多就会呈现集中踩踏的问题，问题愈演愈烈，最终导致数据库卡顿或者解体。 下面案例中通过查看数据库执行记录，咱们发现确实呈现了慢查问积压的状况，应用以下 SQL查问 能够查问以后正在执行的SQL状态 SELECT id, `state`, user,host,time,`INFO` FROM information_schema.processlist where state IS NOT NULL and state <> "" ORDER BY time desc; ...

MySQL下载教程请参考：http://xiazai.cuohei.com/ 。创立MySQL虚构用户useradd -s /sbin/nologin -M mysql 。创立目录mkdir -p /server/toolsmkdir -p /opt/mysqlmkdir -p /data/mysql/mysql3306/{data,logs}cd /server/tools 课堂小常识：疾速备份：cp a.txt{,.bak}删除文件：通过mv代替rm，将文件挪动到/tmp目录下，等确认该文件前期不再应用，能够进入/tmp目录通过rm进行删除 。上传二进制包rzyum install -y lrzsz 。解压二进制包tar xf mysql-8.0.20-linux-glibc2.12-x86_64.tar.xz 。将软件局部挪动到指定目录mv mysql-8.0.20-linux-glibc2.12-x86_64 /opt/mysql/mysql-8.0.20 。创立软连贯ln -s /opt/mysql/mysql-8.0.20/ /usr/local/mysql 。删除mariadbrpm -e --nodeps mariadb-libs 。配置文件整顿vim /data/mysql/mysql3306/my3306.cnf[mysqld]user=mysqlbasedir=/usr/local/mysqldatadir=/data/mysql/mysql3306/datasocket = /data/mysql/mysql3306/mysql.sockserver_id = 1port = 3306log_error=/data/mysql/mysql3306/logs/error.loglog_bin=/data/mysql/mysql3306/logs/mysql-binbinlog_format=rowgtid_mode=onenforce_gtid_consistency=truelog_slave_updates=1max_connections=1024wait_timeout=60sort_buffer_size=2Mmax_allowed_packet=32Mjoin_buffer_size=2Minnodb_buffer_pool_size=128Minnodb_flush_log_at_trx_commit=1innodb_log_buffer_size=32Minnodb_log_file_size=128Minnodb_log_files_in_group=2binlog_cache_size=2Mmax_binlog_cache_size=8Mmax_binlog_size=512Mexpire_logs_days=7slow_query_log=onslow_query_log_file=/data/mysql/mysql3306/logs/slow.loglong_query_time=0.5log_queries_not_using_indexes=1 。装置MySQL依赖包yum install libaio-devel -yyum install numactl -y 。更改MySQL相干目录的用户组chown -R mysql:mysql /data/* 。初始化数据库/usr/local/mysql/bin/mysqld --defaults-file=/data/mysql/mysql3306/my3306.cnf --initialize-insecure --user=mysql --basedir=/usr/local/mysql --datadir=/data/mysql/mysql3306/data 。退出环境变量vim /etc/profileexport PATH="/usr/local/mysql/bin:$PATH"source /etc/profile 。启动MySQLmysqld --defaults-file=/data/mysql/mysql3306/my3306.cnf & 。查看是否启动胜利netstat -lntup |grep mysql ...

MySQL下载教程请参考：http://xiazai.cuohei.com/ 装置MySQL5.7.26 。创立MySQL虚构用户useradd -s /sbin/nologin -M mysqlid mysql 。创立目录mkdir -p /server/toolsmkdir -p /opt/mysqlmkdir -p /data/mysql/mysql3306/{data,logs}cd /server/tools 。上传二进制包rzyum install -y lrzsz 。解压二进制包tar xf mysql-5.7.26-linux-glibc2.12-x86_64.tar.gz 。将软件局部挪动到指定目录mv mysql-5.7.26-linux-glibc2.12-x86_64 /opt/mysql/mysql-5.7.26 。创立软连贯ln -s /opt/mysql/mysql-5.7.26/ /usr/local/mysql 。删除mariadbrpm -e --nodeps mariadb-libs 。配置文件整顿vim /data/mysql/mysql3306/my3306.cnf[mysqld]user=mysqlbasedir=/usr/local/mysqldatadir=/data/mysql/mysql3306/datasocket = /data/mysql/mysql3306/mysql.sockserver_id = 1port = 3306log_error=/data/mysql/mysql3306/logs/error.loglog_bin=/data/mysql/mysql3306/logs/mysql-binbinlog_format=rowgtid_mode=onenforce_gtid_consistency=truelog_slave_updates=1max_connections=1024wait_timeout=60sort_buffer_size=2Mmax_allowed_packet=32Mjoin_buffer_size=2Minnodb_buffer_pool_size=128Minnodb_flush_log_at_trx_commit=1innodb_log_buffer_size=32Minnodb_log_file_size=128Minnodb_log_files_in_group=2binlog_cache_size=2Mmax_binlog_cache_size=8Mmax_binlog_size=512Mexpire_logs_days=7slow_query_log=onslow_query_log_file=/data/mysql/mysql3306/logs/slow.loglong_query_time=0.5log_queries_not_using_indexes=1 。装置MySQL依赖包yum install libaio-devel -yyum install numactl -y 。更改MySQL相干目录的用户组chown -R mysql:mysql /data/* 。初始化数据库/usr/local/mysql/bin/mysqld --defaults-file=/data/mysql/mysql3306/my3306.cnf --initialize-insecure --user=mysql --basedir=/usr/local/mysql --datadir=/data/mysql/mysql3306/data 。退出环境变量vim /etc/profileexport PATH="/usr/local/mysql/bin:$PATH"source /etc/profile 。启动MySQLmysqld --defaults-file=/data/mysql/mysql3306/my3306.cnf & 。查看是否启动胜利netstat -lntup |grep mysql ...

　互联网公司装置MySQL标准　MySQL装置形式：举荐应用二进制装置（其余装置形式：源码编译装置、yum、rpm）　MySQL运行用户：mysql:mysql留神该用户是虚构用户，只是用于mysql过程运行应用，不容许登录、不创立家目录　MySQL目录标准：　下载目录/server/tools　系统目录/opt/mysql/mysql-xx.xx　软连贯ln-s/opt/mysql/mysql-xx.xx /usr/local/mysql　数据目录/data/mysql/mysql+port/{data,logs}　配置文件/data/mysql/mysql+port/my+port.cnf MySQL5.7.26下载　MySQL下载教程请参考：http://xiazai.cuohei.com/　二进制装置MySQL5.7.26（该装置形式应用于MySQL5.7和MySQL8.0的各个小版本）　。创立MySQL虚构用户　useradd -s /sbin/nologin -M mysql #创立用户命令　id mysql #查看是否创立胜利　。创立目录　mkdir -p /server/tools　mkdir -p /opt/mysql　mkdir -p /data/mysql/mysql3306/{data,logs}　cd /server/tools #进入到该目录　。将下载的文件上传　rz　yum install -y lrzsz #如没有rz命令，可通过yum装置　。解压二进制包　tar xf mysql-5.7.26-linux-glibc2.12-x86_64.tar.gz　。将软件局部挪动到指定目录　mv mysql-5.7.26-linux-glibc2.12-x86_64 /opt/mysql/mysql-5.7.26　。创立软连贯　ln -s /opt/mysql/mysql-5.7.26/ /usr/local/mysql　。删除mariadb(防止与MySQL抵触)　rpm -e --nodeps mariadb-libs　。配置文件整顿（该配置参数只用于测试环境，不可在生产中应用。配置参数影响着MySQL数据库的性能及平安，谨慎！！！）　vim /data/mysql/mysql3306/my3306.cnf　[mysqld]　user=mysql　basedir=/usr/local/mysql　datadir=/data/mysql/mysql3306/data　socket = /data/mysql/mysql3306/mysql.sock　server_id = 1　port = 3306　log_error=/data/mysql/mysql3306/logs/error.log　log_bin=/data/mysql/mysql3306/logs/mysql-bin　binlog_format=row　gtid_mode=on　enforce_gtid_consistency=true　log_slave_updates=1　max_connections=1024　wait_timeout=60　sort_buffer_size=2M　max_allowed_packet=32M　join_buffer_size=2M　innodb_buffer_pool_size=128M　innodb_flush_log_at_trx_commit=1　innodb_log_buffer_size=32M　innodb_log_file_size=128M　innodb_log_files_in_group=2　binlog_cache_size=2M　max_binlog_cache_size=8M　max_binlog_size=512M　expire_logs_days=7　slow_query_log=on　slow_query_log_file=/data/mysql/mysql3306/logs/slow.log　long_query_time=0.5　log_queries_not_using_indexes=1　。装置MySQL依赖包　yum install libaio-devel -y　yum install numactl -y　。更改MySQL相干目录的用户组　chown -R mysql:mysql /data/*　。初始化数据库　/usr/local/mysql/bin/mysqld --defaults-file=/data/mysql/mysql3306/my3306.cnf --initialize-insecure --user=mysql --basedir=/usr/local/mysql --datadir=/data/mysql/mysql3306/data　（MySQL8.0 、MySQL5.7都是通过mysqld进行初始化数据）　。退出环境变量　vim /etc/profile　export PATH="/usr/local/mysql/bin:$PATH"　source /etc/profile　。启动MySQL　mysqld --defaults-file=/data/mysql/mysql3306/my3306.cnf &　。查看是否启动胜利　netstat -lntup |grep mysql　。连贯mysql　mysql -S /data/mysql/mysql3306/mysql.sock　至此MySQL装置实现 ...

　DBA和后端、运维同学在工作中少不了和MySQL打交道，为什么mysqldump备份后复原主库有数据，而从库没有数据？为什么明明我建了索引但查问打算显示没用？怎么去优化一般索引的写操作？为什么忽然我的数据就成了乱码？到底应不应该应用联表查问？吧啦吧啦一大堆。在面试中MySQL的一些常识更成为躲不过的问题，比方索引构造、MVCC、隔离级别的实现、锁的抵触、加强半同步复制、RR隔离级别怎么防止幻读产生等等等等都成为了面试考题重灾区。　MySQL在互联网公司的利用十分宽泛，传统行业公司也早开始去IOE，从oracle将数据迁徙到MySQL。我之前所在的单位电信，也早早的从oracle转到MySQL。学好MySQL对你的升职加薪起着很大的作用。　咱们的MySQL系列教程就是带着大家全面把握MySQL常识，丰盛的实战案例带你飞，将MySQL的面纱缓缓的摘下。当你学完这套教程，把握MySQL常识，你就像武林高手那样，打通任督二脉，将MySQL常识死记硬背。　合适小伙伴　刚刚学完SQL根底的学生同学们；　被数据库问题折磨的求职者们；　天天被 DBA 逼着优化 SQL 的业务开发小伙伴；　菜鸟 DBA 和不是十分菜的 DBA 小伙伴；　

你必定晓得MySQL进行CRUD是在内存中进行的，也就是在Buffer Pool中。而后你也晓得了当内存中没有MySQL须要的数据时，MySQL会从Disk中通过IO操作将数据读入内存中。读取的单位呢就是：数据页 个别数据页长上面这样 没错，数据页中存储着实在的数据，而且数据页在内存中是以双向联表的形式组织起来的！如下图 而在B+Tree的设定中，它要求主键索引时递增的，也就是说如果主键索引时递增的话，那么就要求右侧的数据页中的所有数据均比左侧数据页中的数据大。然而很显著上图并不合乎，因而须要通过页决裂来调整成上面这样。 好，当初你回忆一下，之前你必定有据说过：MySQL的B+Tree聚簇索引，只有叶子节点才存储实在的数据，而非叶子节点中存储的是索引数据，而且叶子节点之间是通过双向链表连接起来 没错，那所有的B+Tree的叶子节点就是上图中的数据页，并且它们的确是通过双向链表关联起来的！ 咱们接着往下看，如果只看上图由数据页连接起来的双向链表的话，这时如果咱们检索id=7的数据行，那会产生什么？ 很显著咱们要从头开始扫描！ 那你可能会问：刚才不是说B+Tree要求主键是递增的嘛？并且有页决裂机制保障左边的数据页中的所有数据均比它右边的数据页的索引值大。那进行二分查找不行嘛？ 答：是的，的确能够在单个数据页中进行二分查找，然而数据页之间的组织关系是链表呀，所以从头开始遍历是防止不了的。 那MySQL怎么办的呢？ 如下图：MySQL针对诸多的数据页形象出了一个索引目录 那有了这个索引目录咱们再在诸多的数据页中检索时看起来就容易多了！间接就领有了二分检索的能力！ 而且这个所以目录其实也是存在于数据页中的，不同于叶子节点的是，它外面只是存储了索引信息，而叶子节点中存储的是实在数据？ 而索引页的诞生也就意味着B+Tree的雏形曾经诞生了！ 随着用户一直的select，buffer pool中的数据页的越来越多，那么索引页中的数据也会水涨船高。当现有的索引体量超过16KB（一个数据页的容量）时就不得不搞一个新的索引页来存储新的索引信息。这时这颗B+Tree就会缓缓变得越来越胖。 那你也晓得B+Tree是B树的变种，而B树其实能够是2-3树、2-3-4数....等等M阶树的泛称，当每个节点中能存储的元素达到下限后，树就会长高 。 就像下图这样：

解决方案1. 利用Navicat 15 for MySQL从SQL Server同步到mysql步骤1：关上Navicat 15 for MySQL，最好在MySQL中新建一个和要导SQL server数据库一样名字的数据库，当然不一样也能够。 步骤2：择数据库，点击导入向导 步骤3：抉择ODBC，而后点下一步 步骤4：抉择数据源，点开导入项 步骤5：抉择SQL server，点下一步如果报错点击三个小点 步骤六填入连贯所须要的信息，其中第一个填的是你SQL server所在的IP地址（同一局域网内）。填完信息后测试连贯，胜利后点击确定。PS:如果呈现连贯失败或者回绝连贯的状况，肯定要记得关掉两边的防火墙！！填入配置信息，留神，肯定要勾选容许保留明码，没勾点确定后会呈现上面谬误 步骤七 抉择要导入的表，点击下一步 2.利用xorm-reverse工具生成数据库表构造3.构建用于存储每个表的最新ID数据库

参考资料[1] https://www.cnblogs.com/2020j...[2] mysql教程 1.装置1.1 ubuntu装置https://zhuanlan.zhihu.com/p/... 1.1.1 形式一：从 Ubuntu 仓库装置 MySQL首先，输出下列命令确保你的仓库曾经被更新： $ sudo apt update当初，装置 MySQL 5.7，简略输出下列命令： $ sudo apt install mysql-server -y就是这样！简略且高效。如果报错：E: Unable to locate package MySQL-server，尝试办法二。 1.1.2 形式二：应用官网仓库装置 MySQL咱们将应用 Curl 命令去下载这个软件包： $ curl -OL https://dev.mysql.com/get/mysql-apt-config_0.8.12-1_all.deb依据以后的 MySQL 版本，它有可能不同。应用 dpkg 去开始装置 MySQL： $ sudo dpkg -i mysql-apt-config*更新你的仓库： $ sudo apt update要理论装置 MySQL，咱们将应用像第一个办法中同样的命令来装置： $ sudo apt install mysql-server -y1.1.3 验证是否装置胜利应用root用户启动服务 $ sudo su$ service mysql start * Starting MySQL database server mysqld * su: warning: cannot change directory to /nonexistent: No such file or directory如果报su: warning: cannot change directory to /nonexistent: No such file or directory,则解决链接：https://www.cnblogs.com/cnwcl... ...

示例表信息# 作者表CREATE TABLE `test_author` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键ID', `author_name` varchar(255) NOT NULL COMMENT '作者名', `creator` int(11) NOT NULL COMMENT '创建人', `last_updater` int(11) NOT NULL COMMENT '最初更新人', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创立工夫', `last_update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新工夫', `delete_flag` int(1) NOT NULL DEFAULT '0' COMMENT '删除标记（0-默认，1-删除）', PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='作者';#书籍表CREATE TABLE `test_book` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键ID', `title` varchar(255) NOT NULL COMMENT '题目', `creator` int(11) NOT NULL COMMENT '创建人', `last_updater` int(11) NOT NULL COMMENT '最初更新人', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创立工夫', `last_update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新工夫', `delete_flag` int(1) NOT NULL DEFAULT '0' COMMENT '删除标记（0-默认，1-删除）', PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='书籍';#关系表CREATE TABLE `test_topic_paper_related` ( `book_id` int(11) NOT NULL COMMENT '书籍ID', `author_id` int(11) NOT NULL COMMENT '作者ID', PRIMARY KEY (`book_id`,`author_id`) USING BTREE) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='作者-书籍关联关系';办法一SELECT t.id, t.title, t.creator, t.last_updater, t.create_time, t.last_update_time, t.delete_flag, t2.author_name ( SELECT t.id, t.title, t.creator, t.last_updater, t.create_time, t.last_update_time, t.delete_flag FROM test_book AS t WHERE t.id IN ( SELECT book_id FROM test_author_book_related WHERE author_id IN (筛选项 ID汇合 )) AND 其余筛选条件 ORDER BY t.last_update_time DESC, t.id LIMIT 分页信息 ) t LEFT JOIN test_author_book_related t1 ON t.id = t1.book_id LEFT JOIN test_author t2 ON t1.author_id = t2.id

mysql在5.8之后增加了rownum函数，然而在此之前是没有这个函数的。咱们能够用下列形式自定义rowNum实现： SELECT t.*, @rownum := @rownum + 1 AS ranking FROM ( SELECT @rownum := 0 ) r, ( SELECT * FROM USER ) AS t

前言： 有时候咱们会遇到重命名表的需要，比如说因业务变动，须要将表 a 重命名为表 b 。这个时候能够执行 RENAME TABLE 语句或 ALTER TABLE 语句来重命名表。本篇文章咱们一起来学习下重命名表相干常识。 1.重命名表办法应用 RENAME TABLE 语句或 ALTER TABLE 语句都能够对表进行重命名，根本语法如下： # RENAME TABLE 语法：RENAME TABLE tbl_name TO new_tbl_name [, tbl_name2 TO new_tbl_name2] ... # ALTER TABLE 语法：ALTER TABLE old_table RENAME new_table;# 具体示例：mysql> show tables;+------------------+| Tables_in_testdb |+------------------+| tb1 || tb2 |+------------------+2 rows in set (0.00 sec)mysql> rename table tb1 to new_tb1;Query OK, 0 rows affected (0.03 sec)mysql> alter table tb2 rename new_tb2;Query OK, 0 rows affected (0.04 sec)mysql> show tables;+------------------+| Tables_in_testdb |+------------------+| new_tb1 || new_tb2 |+------------------+2 rows in set (0.00 sec)显然易见，在执行重命名表时，旧表(old_table_name)必须存在，而新表(new_table_name)肯定不存在。如果新表 new_table_name 的确存在，该语句将失败。 ...

必须设置外键VS不要设置外键的争执数据库表到底要不要设置外键束缚，始终具备十分大的争议。我认为齐全没有必要非黑即白，存在即正当。 这两种争执的产生本源在于它们都有各自的应用场景和理由，并不是纯理论的空想。 所以最好的形式是依据我的项目类型、业务场景进行决策，甚至能够两种形式混合应用，才是最好的。 例如对于证券、股票、保险、银行等金融行业，应该设置外键保证数据的一致性更加重要，而对于互联网行行业的衣食住行则能够采纳无外键设计，谋求更高的性能和更快的迭代速度。 数据库表不设置外键会有哪些问题？数据完整性问题 短少外键最次要的问题是数据库不能强制进行完整性束缚查看，如果在业务程序中没有正确处理，则可能会导致数据不统一。例如银行、证券、保险等金融行业，每一个账户的金额都不能出错，一旦呈现数据不统一就是灾难性的问题。 表之间的关系不清晰 无奈间接通过外键来梳理表之间的关联关系，对于新接触我的项目的人员会十分困难。对于一些大型的简单我的项目，没有外键束缚，梳理不清表之间的关系也是一种劫难。 如果数据库表不设置外键会有哪些益处？对性能具备较大的晋升 在表上领有流动的外键能够进步数据品质，但会影响插入、更新和删除操作的性能。在这些工作之前，数据库须要查看它是否违反数据完整性。这就是为什么一些架构师和DBA齐全放弃外键的起因。数据仓库和剖析数据库尤其如此，这些数据仓库和剖析数据库不以交易方式（一次一行）解决数据，而是批量解决数据。性能是数据仓库和商业智能的所有。 旧数据和脏数据更加利于存储 许多数据库在设计时须要存储来自旧数据库和遗留数据，这些数据可能对数据品质和完整性没有那么严格。为了可能包容旧的脏数据，架构师能够抉择（1）清理和转换遗留数据，这要消耗很大的人力老本。（2）放弃在数据库级别上强制执行参照完整性。一些打包的ERP和CRM应用程序也应用这种办法。 全表从新加载的时候会更加不便 一些数据库，如数据仓库，分段或接口数据库，须要常常从内部从新加载数据。这会导致从新加载时数据不统一（在父表为空的状况下，子表可能已满载）。这能够通过在从新加载时禁用外键来绕过。然而，这引入了额定的逻辑和复杂性以及另一个失败点。如上所述，对性能有负面影响。通常，老本大于收益，开发人员不必放心外键。 采纳更高层次的框架来解决束缚问题 一些应用程序应用编程框架，在物理数据库之上创立另一个逻辑层。开发人员不应用插入或更新语句来批改数据，而应用API或者框架在后盾执行所有操作。ORM（对象关系映射）框架或Ruby on Rails框架就是这种状况。这些工具负责参照完整性，并与RDBMS一起创立更高级别的数据库引擎。这些框架能够本人创立数据库表，而不总是创立外键。应用这些工具的开发人员很少会烦扰主动生成的模式，并且不须要外键。 激励翻新，对更改凋谢 这种观点认为，减少外键会升高设计者的优化欲望，因为批改过程较为麻烦，所以限度了设计人员的翻新思维。 架构师或设计师的懈怠心理失去满足 创立表的时候只有本人心里晓得他们的关联关系就好了，不须要做那么多额定的设置，并且一旦须要调整设计就会非常繁琐，所以有很多设计人员就不再设置外键了。 放弃模型的复杂度，保护集体位置 每一个设计者都心愿本人是不可代替的，设计出简单的数据模型，而不设置外键束缚，这样就只有本人分明他们的关联关系，只有本人可能进一步保护，出了问题也只有本人最分明，从而能够放弃本人的竞争力。这种想法看似邪恶，然而这样做的的确大有人在。

原创：猿天地（微信公众号ID：cxytiandi），欢送分享，转载请保留出处。读写拆散是什么？读写拆散的作用就不讲了，如果有不理解的同学能够本人去搜寻材料进行理解。或者查看我之前的文章读写拆散。 一开始的场景必定都基于主库去做增删改查的操作，等前面压力缓缓上来后才会思考加数据库的从节点，通过读写拆散的形式来进步查问的性能。 首先读写拆散默认查问都是走从节点的。 从咱们的应用习惯或者业务的场景来说，查问的场景是大于增删改的。所以咱们会在须要走主库进行数据操作的业务场景下，手动去管制这条Sql要去主库执行，这个管制的逻辑能够本人写，也能够利用框架自带的性能实现，就不细讲了。 比方咱们定义一个注解 @Master 用于标记此办法走主库操作，而后通过Aspect能够去切换数据源。这其实是很常见的实现形式，如果说你一开始就有从节点，就标准了这么做是没问题的，如果是前面新增了从节点要开始做读写拆散，这么做是存在问题的。 一旦这么做的话，对于增删改的操作没有问题，对于查的操作可能会有问题。这个问题不是说有Bug，而是有一些体验上的问题可能会导致Bug。大家都晓得主从架构其实是存在数据提早的问题，只有有提早那么就有可能呈现问题。 某些业务场景下，你新增了一条数据，而后会马上跳到详情去，此时如果数据有提早，到详情的时候去查问从节点，就查不到刚刚新增的数据，会存在这样的问题。 解决办法就是把所有业务场景都整顿下，而后让测试整体回归一遍，将须要走主库操作的查询方法都加上 @Master 注解，就不会有问题了。 看似没有任何问题，其实大家疏忽了一点就是工夫老本问题。要整顿业务场景，要整体回归测试，这些都是要花工夫的，工夫就是最大的老本。 所以咱们在前期做读写拆散的时候，基本上不会采纳下面的形式去实现，因为业务性能越多，老本越高。 真正的做法是反着来，无论实现任何新性能，咱们都要思考的点就是如何让影响最小？如何不影响之前的逻辑？ 办法就是所有的老逻辑都不动，默认还是走主库，然而咱们程序中曾经做了读写拆散的性能，默认查问就是会走从库的，所以第一步就是要将所有查问的Sql都发往主库，能够通过Aspect实现。 做完了下面这一步就能够间接上线了，因为所有的操作还是走的主库，跟以前没有任何区别，不会影响任何老的逻辑。 当初就要思考哪些查问能够走从库了，然而这个动作能够缓缓做，能够缓缓梳理。这样就会比拟轻松了，每个迭代咱们能够梳理几个走从库的查问，间接加个 @Slave 的注解让它强制走从库，这个场景咱们梳理过，验证过是没问题的。就这样缓缓的整顿，直到所有老逻辑都梳理完。 好的思路可能保障稳定性和易用性，如果有播种那就点个赞呗！ 对于作者：尹吉欢，简略的技术爱好者，《Spring Cloud微服务-全栈技术与案例解析》, 《Spring Cloud微服务 入门 实战与进阶》作者, 公众号猿天地发起人。

binlog 根本意识 MySQL的二进制日志能够说是MySQL最重要的日志了，它记录了所有的DDL和DML(除了数据查问语句)语句，以事件模式记录，还蕴含语句所执行的耗费的工夫，MySQL的二进制日志是事务平安型的。一般来说开启二进制日志大略会有1%的性能损耗(参见MySQL官网中文手册 5.1.24版)。二进制有两个最重要的应用场景: 其一：MySQL Replication在Master端开启binlog，Mster把它的二进制日志传递给slaves来达到master-slave数据统一的目标。 其二：天然就是数据恢复了，通过应用mysqlbinlog工具来使复原数据。二进制日志包含两类文件：二进制日志索引文件（文件名后缀为.index）用于记录所有的二进制文件，二进制日志文件（文件名后缀为.00000*）记录数据库所有的DDL和DML(除了数据查问语句)语句事件。 一、开启binlog日志： vi编辑关上mysql配置文件# vi /usr/local/mysql/etc/my.cnf在[mysqld] 区块设置/增加 log-bin=mysql-bin 确认是关上状态(值 mysql-bin 是日志的根本名或前缀名)；重启mysqld服务使配置失效# pkill mysqld# /usr/local/mysql/bin/mysqld_safe --user=mysql &二、也可登录mysql服务器，通过mysql的变量配置表，查看二进制日志是否已开启 单词：variable[vribl] 变量 登录服务器# /usr/local/mysql/bin/mysql -uroot -p123456mysql> show variables like 'log_%'; +----------------------------------------+---------------------------------------+| Variable_name | Value |+----------------------------------------+---------------------------------------+| log_bin | ON | ------> ON示意曾经开启binlog日志| log_bin_basename | /usr/local/mysql/data/mysql-bin || log_bin_index | /usr/local/mysql/data/mysql-bin.index || log_bin_trust_function_creators | OFF || log_bin_use_v1_row_events | OFF || log_error | /usr/local/mysql/data/martin.err || log_output | FILE || log_queries_not_using_indexes | OFF || log_slave_updates | OFF || log_slow_admin_statements | OFF || log_slow_slave_statements | OFF || log_throttle_queries_not_using_indexes | 0 || log_warnings | 1 |+----------------------------------------+---------------------------------------+三、罕用binlog日志操作命令 ...

存储和治理数据的仓库 MySql建表束缚 主键束缚：可能惟一确定一张表中的一条记录。 Primary key 惟一且不为空联结主键：只有联结的主键加起来不反复就能够自增束缚：autoincrement； id int primary key auto_increment主键束缚：建表后增加和删除增加：alter table user add primary key (id);批改：alter table user modify id int primary key;删除：alter table user drop primary key;惟一束缚：束缚修饰字段的值不能够反复 unique(name);name unique;unique(id,name);建表时增加束缚：alter add ； alter modify；非空束缚：润饰的字段不能为空 not null默认束缚：当咱们插入字段值的时候，如果没有传值，就会应用默认值。 age int default 20;外键束缚：设计到两个表，主副。check束缚：用于限度列中的值的范畴三大设计范式 第一范式1NF数据表中的所有字段都是不可分割的原子值 第二范式2NF必须满足第一范式，除主键外的每一列都必须齐全依赖于主键 第三范式3NF必须先满足第二范式，除开主键列的其余列不能有传递依赖关系 列的数据类型tinyint 非常小的数据 1个字节smallint 较小的数据 2个字节medumint 中等大小的数据 3个字节int 规范的整数 4个字节 罕用bigint 较大的数据 8个字节float 浮点数 8个字节 （精度问题）decimal 字符串模式的浮点数 金融计算的时候，个别是应用decimal

背景最近在做一个零碎 须要去爬取一些可用的车型数据。昨晚脚本跑了几小时，明天一看哇,这么多数据~(ps 还有一张同级别的英文数据的表)还好做了分表处理表数据 表构造 前端ui 零碎其中一个这个接口需要大略是这样的:swId是车的品牌id 用户进入这个页面就会开始抉择拉的数据 别离获取make车型,model零碎,year年款大略数据结构{ "code": 200, "message": "success", "data": [ "MINI", "SMART", "一汽丰田", "一汽佳宝", "一汽森雅", "一汽轿车", "一汽马自达" ]}未做任何解决查表:接口响应 大略须要27s第一步调整存储引擎MyISAM 大数据读多写少的时候 应用MyISAM会大大减少数据检索工夫此时查问工夫26.51s降落到了15.79s 建设索引留神大表数据建设索引也会占用大量的空间 所以咱们遵循从左到右的规定这个接口都波及到swId字段的查问 所以咱们先给这个字段建设一个一般索引ALTER TABLE `system_model_year` ADD INDEX sw_i(`swId`) 实现 测试果然腾飞1212 ms 在多申请几次,目前响应速度满足需要 最初稳固在100ms

1 概述在利用开发的过程中，因为后期数据量少，开发人员编写的SQL语句或者数据库整体解决方案都更器重在性能上的实现， 然而当利用零碎正式上线后，随着生成数据量的急剧增长，很多SQL语句和数据库整体计划开始逐步透出了性 能问题，对生成的影响也越来越大，此时Mysql数据库的性能问题成为零碎利用的瓶颈，因而须要进行Mysql数据库的性能优化。1.1 性能降落的体现执行工夫长等待时间长1.2 性能降落的起因查问语句写的不好，各种连贯，各种子查问导致用不上索引或者没有建设索引建设的索引生效，建设了索引,在真正执行时,没有用上建设的索引关联查问太多join服务器调优及配置参数导致，如果设置的不合理,比例不失当,也会导致性能降落,sql变慢 零碎架构的问题1.3 通用的优化计划 索引优化: 增加适当索引(index）(重点)Sql优化: 写出高质量的sql，防止索引生效 (重点)设计优化: 表的设计合理化(合乎3NF，有时候要进行反三范式操作) 配置优化: 对mysql配置优化 [配置最大并发数my.ini, 调整缓存大小 ]架构优化：读写拆散、分库分表硬件优化: 服务器的硬件优化2.索引原理2.1 概念索引是解决SQL性能问题的重要伎俩之一，应用索引能够帮忙用户解决大多数的SQL性能问题。索引就是数据结构，通过这种数据结构能够大大提高mysql的查问效率 磁盘存取示意图 每次从磁盘中查找数据称为磁盘I/O， 而磁盘IO 至多要经验磁盘寻道、磁盘旋转、数据读取等等操作，十分影响性能，所以对于读取数据，最大的优化就是缩小磁盘I/O 2.2 索引的底层实现MySql底层的数据结构次要是基于Hash 和 B+Tree 2.2.1 底层数据结构剖析2.2.1.1 二叉树 为了放慢数据的查找,能够保护二叉查找树, 每个节点别离蕴含索引键值和一个指向对应数据记录的物理地址的指针,这样就能够使用二叉查找在肯定的复杂度内获取相应的数据,从而疾速的检索出符合条件 的记录 左子树的键值小于根的键值右子树的键值大于根的键值从二叉树的查找过程了来看，最坏的状况下磁盘IO的次数由树的高度来决定。从后面剖析状况来看，缩小磁盘IO的次数就必须要压缩树的高度，让瘦高的树尽量变成矮胖的树，所以引出B-Tree强势退场 2.2.1.2 BTree自均衡多叉查找树度(Degree) 节点的数据存储个数 叶节点具备雷同的深度节点中数据key从左到右递增排列叶节点的指针为空在节点中间接存储了数据 data 疑难：二叉树的节点只存了一个数据? 而BTree的节点因为有度的概念存了多个数据？那么二叉树的节点数据量小是不是在读取的时候效率更高呢？而且读到内存中的遍历速度是不是更快些呢?预读：磁盘个别会程序向后读取肯定长度的数据(页的整数倍)放入内存局部性原理：当一个数据被用到时，其左近的数据也通常会马上被应用存储器读取数据按 磁盘块读取 每个磁盘块的大小为 扇区（页）的2的N次方每个扇区的最小单位 512B 或 4096B 不同的生产厂家不同为了晋升度的长度，还须要对这种数据结构进行优化，所以它的升华版B+Tree诞生了2.2.1.3 B+TreeB+树是B树的变体,根本与BTree雷同 特点 非叶子节点不存储data,只存储key,能够增大度叶子节点不存储指针程序拜访指针，进步区间拜访能力 B+Tree索引的性能剖析 个别应用磁盘I/O次数评估索引构造的优劣B+Tree的度个别会超过100，因而h十分小 (个别为3到5之间)，性能就会十分稳固B+Tree叶子节点有程序指针，更容易做范畴查问2.2.1.4 Hash应用hash构造存储索引，查找单行数据很快，但毛病也很显著。 1.无奈用于排序2.只反对等值查找3.存在Hash抵触Hash索引只实用于某些特定场景，咱们应用不多2.2.2 mysql的索引实现2.2.2.1 存储引擎的概念mysql的索引对于不同的存储引擎(Engine) ,索引实现各不相同MySQL中的数据用各种不同的技术存储在文件(或者内存)中。这些技术中的每一种技术都应用不同的存储机制、索引技巧、锁定程度并且最终提供宽泛的不同的性能和能力。通过抉择不同的技术，你可能取得额定的速度或者性能，从而改善你的利用的整体性能。这些不同的技术以及配套的相干性能在 MySQL中被称作存储引擎通过 show engines 能够查看以后数据库反对的引擎、默认的引擎查看以后数据库的默认引擎show VARIABLES like 'default_storage_engine'如：如果你在钻研大量的长期数据，你兴许须要应用内存存储引擎。内存存储引擎可能在内存中存储所有的表格数据。兴许须要一个反对事务处理的数据库(以确保事务处理不胜利时数据的回退能力) 抉择反对事务的存储引擎5.7 默认的引擎是innodb 可通过 SET default_storage_engine=< 存储引擎名 >更改面试时常常被问到的两个引擎：MyISAM 和 innoDB引擎 这两种引擎都是采纳B+Tree和hash 数据结构实现的索引2.2.2.2 MyISAM 和 innoDB的比照 MyISAMinnoDB事务不反对反对外键不反对反对锁表锁行锁缓存缓存索引缓存索引和数据全文索引反对不反对索引实现非聚簇索引聚簇索引总的来说： 须要事务： 那必定用innoDB 不须要事务： myisam的查问效率高，内存要求低， 但因为采纳表锁， 不适宜并发写操作， 读多写少选它 innoDB采纳行锁，适宜解决并发写操作， 写多读少选它2.2.2.3 MyISAM索引实现索引特点： 非聚簇索引 采纳B+Tree 作为数据结构 MyISAM 索引文件和数据文件是拆散的(非聚簇) 叶子节点存储的是数据的磁盘地址 非主键索引和主键索引相似 ...

导语 | 在金融行业IT零碎国产化的大背景下，国内金融行业开始推动IT基础设施国产化，逐步解脱对于传统IOE架构的依赖。微众银行自成立之初，就放弃了传统IOE架构路红，联合腾讯金融级分布式数据库TDSQL，建设了基于DCN单元化架构模式的分布式根底平台。现在这套架构承载了微众银行数亿级别的用户规模，数百套银行外围零碎，和每天数亿次的金融交易。本文由微众银行数据库平台室室经理、腾讯云TVP 胡盼盼在 Techo TVP开发者峰会「数据的冰与火之歌——从在线数据库技术，到海量数据分析技术」 的《分布式数据库在微众银行外围零碎的实际》演讲分享整顿而成，为大家着重介绍金融行业的数据库趋势、微众银行基于单元化的分布式架构，以及基于单元化的数据库架构，并分享微众银行数据库将来的演进方向。点击可观看精彩演讲视频 一、金融行业数据库趋势明天分享的次要内容蕴含四个方面：第一是介绍金融行业数据库的趋势；第二是介绍微众银行的单元化架构；第三是基于微众银行的单元化架构的数据库架构是怎么做的；第四是微众银行外部对于数据库将来架构的演进方向。 金融行业是绝对传统的行业，对于IT基础设施的选型，都是偏激进，之前始终都很稳固走传统IOE架构。然而，近几年产生了一些变动，次要有三个趋势： 第一是国产化的趋势。最近几年的国际形势家喻户晓，在金融行业这种要害的畛域，对于要害的IT基础设施的国产化，是一个国家层面在推动的方向。另一方面，得益于国产化浪潮的推动，国产数据库产品也是百花齐，使得国内的金融企业有很多能够抉择的国产数据库。 第二个趋势是去中心化。互联网行业的倒退带来数据爆炸性的增长，传统银行当初也在缓缓走互联网化和服务在线化，比方手机银行APP，原来很多业务须要到线下网点去办理，当初手机很行上就能够办理胜利，所以带来的数据量的也指数级的增长，原来中心化的架构，比方单机存储或是用共享存储的形式，不论是性能还是容量上可能都没方法承载这种爆炸性的增长。 第三个趋势是开源化。在几年前，金融行业，特地是传统的银行，对于开源这种产品模式其实是不太不信赖的，感觉开源的产品，稳定性上没有保障，也没有固定的技术团队反对。然而最近几年这个认知缓缓变动了，很多同行业的传统银行都开始去尝试一些开源数据库，比方MySQL，Redis等。把一些非核心的业务场景跑在开源数据库平台上，而且规模都不小。另外，咱们国家对整个开源软件生态建设也在逐步加大反对，国内开源社区的建设也在缓缓走向成熟。进一步促成了开源数据库在金融行业的利用。 这张图是从国内的一个数据库排名网站上截的，都是当初国内的数据库产品。咱们能够看到这张图里，有包含腾讯、阿里、华为这种大厂的数据库产品，也包含目前开源比拟风行的产品，还包含一些传统的厂商产品，能够说真的是百花齐放的时代，这在五六年前都是不可设想的。 二、微众银行单元化架构上面介绍一下微众银行外部的单元华架构到底是怎么做的。微众银行于2014年开始操办，作为国内第一家民营银行，咱们在IT基础架构方面是没有历史包袱的，能够从零去做一个全新的架构。所以过后定的路线是不会再用传统银行的IOE架构，确定了要走基于分布式架构的模式去承载整个银行的外围零碎。 最终咱们抉择了单元化作为咱们的架构根底。这里的单元化怎么了解呢？以传统的线下银行类比一下，传统银行，个别在每个省都有一个分行，每个省的分行只负责各个省的客户。微众银行的单元化，就相似这种分行的概念。咱们把所有的客户也拆成一个一个单元去治理，每个单元就是固定的用户数量。比如说一个单元外面咱们就只承载500万用户的数量，当这个单元用满了当前，就间接再整体去扩一个单元。这个单元咱们外部有一个名字：DCN，即最小化的单元化部署单位，DCN里蕴含了从应用层到中间件、到底层的数据库，能够了解为一个DCN就是一个自蕴含的小的微众银行。DCN承载的用户数量是固定的，比如说固定的500万或者800万用户，DCN用满之后，再横向扩大一个新的DCN，新的用户就放到新的DCN里。 这个DCN架构会带来两个问题。 第一个问题：比方你是微众银行的用户，要应用微众银行的服务，怎么晓得本人在哪一个DCN呢？这里就有一个要害组件：GNS，GNS是负责所有用户的DCN路由信息存储与查问。当一个用户的申请进来，会首先查问GNS，失去所在DCN的定位，再去对应的DCN做后续的申请。 第二个问题：DCN与DCN之间是隔离的，A DCN的一个用户想给B DCN的一个用户转账，转账的音讯替换要怎么实现？这里就要提到另一个要害组件：RMB，中文名为：可靠消息总线。RMB的次要性能是负责DCN之间的音讯替换，通过GNS和RMB这两个组件，基本上把整个DCN的路由和音讯替换性能解决了。 当然DCN并不能承载所有的业务场景，有些归档场景 ，可能是要从DCN汇总过去对立存储和计算，还有一些数据是全局数据，无奈进行DCN拆分，所以咱们看到上面会有一个全局数据管理和后盾治理的区域，叫ADM区。用来解决这一类业务场景。 在一直线上实际过程中，这种DCN架构带来了不少劣势： 第一个劣势是它能够升高故障的影响面。因为DCN从软件层面到硬件层面全副是独立拆分的，所以一个DCN硬件的故障影响面无限，比方微众银行最大的业务：微粒贷，当初曾经有20多个DCN，，某一个DCN的故障可能只影响整体业务的1/2，能够无效的管制故障的影响范畴。 第二个劣势是能够实现高效的扩容。目前咱们通过自动化部署的形式，能够实现一个小时内扩容一个DCN，相当于一小时内从软件到硬件层面就能够实现500万用户量的扩容。 第三个劣势是它能够实现无效的灰度变更。因为每个DCN相当于是齐全同构的，能够去设置一个专门的灰度DCN，放一小部分用户。每次的版本公布，比方数据库的DDL或者利用的版本公布，都能够在这个小DCN内先灰度，灰度验证没问题，再全量公布到其它的DCN，能够无效升高版本危险。 最初一个劣势，DCN单元化架构带了数据库架构的简化。DCN的用户规模是受限的，那么DCN内的数据库规模，包含数据库的TPS、IO/CPU负载 、数据量都是具备下限的。所以DCN内的数据库，就没有必要采纳比较复杂的分布式或说中间件架构的数据库来提供所扩展性。咱们在DCN内，采纳了最简略的TDSQL单实例架构，也不必思考分布式事务带来的数据库的复杂性。 当然这种DCN单元华架构也会带来一些毛病： 第一：DCN之间物理资源互相独立，可能每个DCN都会预留一些buff资源，可能会导致整体的资源利用率不高。 第二：DCN架构对于运维自动化的要求十分高。咱们当初生产整个DCN数量已超过100个，对于多DCN的版本治理、版本公布和日常变更都须要自动化运维去做。 第三：须要应用层去实现跨DCN的分布式事务框架，比方我在A DCN，你在B DCN，我须要给你转一笔钱，如果在原来的中心化架构下，可能就间接利用数据库的事务去保障一致性，然而在这种跨DCN的架构下，可能须要应用层去实现相似的事务框架，来保障整体事务的一致性。 三、基于单元化的数据库架构下面介绍了微众银行的DCN单元化架构，基于这个架构的前提，再介绍一下微众银行的数据库架构到底是怎么做的。在介绍数据库架构之前，须要先介绍一些背景常识。 1. 微众银行IDC架构微众银行当初IDC的建设，是2地7核心的IDC架构，咱们在深圳有5个生产机房作为生产核心，在上海有2个容灾机房作为容灾核心。咱们在深圳同城的这5个机房选址也是有规定的，两两IDC的间隔管制在10-50公里的范畴内，以此来保障IDC之间的网络提早在2毫秒左右，这是数据库多正本跨同城IDC部署的前提。 2. 微众银行TDSQL部署架构首先介绍一下TDSQL这个产品。TDSQL是腾讯推出的一款金融级分布式数据库产品，微众银行目前所有的外围零碎根本都是用TDSQL来承载的。 如下图，从横向维度来看，最右边APP申请进入，会通过一个负载平衡的组件，负载平衡的组件把申请转发到TDSQL proxy模块，这个proxy其实实现了SQL解析、读写拆散、流量管制等性能，相当于是一个中间件。TDSQL proxy接管到申请后，会把申请转发到后端对应的SET列表，TDSQL的最小单元是以SET为单位的，SET外面实质上就是MySQL，TDSQL针对MySQL内核做了一些定制化的优化。SET里个别是一主两备架构，一主两备之间会采纳TDSQL优化后强同步的机制来保证数据多正本的一致性，一个TDSQL proxy上面能够挂载多个TDSQL SET。 再看纵向维度。能够持到纵向维度上，TDSQL还有两个比拟要害的模块，一个是zookeeper，它是整个TDSQL配置的管理系统，所有的元数据信息和监控上报的统计信息，都会上报到zookeeper集群。在zookeeper之上还有一个模块叫schduler，它负责整个TDSQL工作流程调度，比方SET1当初Master节点可能宕机了，须要做一个主备切换，这个主备切换的流程就是由整个schduler模块去调度的，它会管制每一步切换的流程，直到最终切换胜利。 再补充一下TDSQL的两种应用模式，一种是NO Shard模式，也就是TDSQL的单实例模式。这种架构下，TDSQL proxy单纯做一个SQL转换的性能，到底层的SET当前，每个STE就是一个独立的单实例架构，SET之间的库是没有关系的，这种No Shard架构没有在中间件层做分库分表，所以逻辑会简略很多。但这种模式的SET须要扩容的话，就只能在SET外部去做垂直扩容。这种架构的劣势在于它不波及分布式事务，也不波及数据库的分片，所以它的语法是齐全兼容的，且架构简洁。 第二种模式是TDSQL Shard模式，Shard模式能够简略了解为一种基于中间件分库分表的模式。通过TDQSL proxy，把某一个库做成三个Shard分片，这三个分片别离散布在SET1、SET2和STE3这三个SET里。这种模式的长处是能够实现容量的程度扩容。但它带来的问题在于对语法的兼容不完满，因为须要在中间件层面实现Shard，就须要一些非凡语法的兼容，比方须要建表的时候带Share key，SQL外面可能也须要带Share key，就须要应用层做适配革新。 方才咱们提到微众银行的单元化架构，以DCN单元化架构为根底，对于数据库的性能和容量需要是可控的，所以咱们就不须要通过这种Shard模式做扩大，间接采纳No Shard模式，从而大大简化了咱们在数据库架构和运维的工作量。 基于以上背景常识，咱们来看看微众银行的TDSQL的部署架构。从竖向的维度来看，每个框里就代表一个IDC，右边有三个生产IDC，左边还有跨城容灾——上海的两个IDC。从底层来看，最上面是咱们的数据库，采纳TDSQL数据库，一主两备的架构，三个正本散布在同城的三个IDC外部，比方Master在南山机房，Slave1可能在观澜机房，Slave2可能在福田机房。Master、Slave之间采纳TDSQL强同步的机制进行数据同步，在一个DCN内咱们可能会有多个SET去承载这个数据库。 而在数据库下层，每个机房都会有独立的接入层，接入层之上会有独立的负载平衡性能，最上层是应用层。 基于这种部署架构，咱们实现了同城利用多活的概念。业务流量能够从生产IDC的任何一个IDC进来，通过应用层到负载平衡的接入层都在同机房内，然而从接入层到下面的数据库可能就波及到跨机房流量的拜访。比方从IDC1进来的业务流量，数据库的Master可能在IDC2，那么它可能就会波及到接入层到IDC2 Master这种跨机房的流量拜访。 除了生产的三个正本，咱们在上海的跨城容灾还会有两个正本：一个Master、一个Slave。跨城容灾和生产IDC的数据同步因为网络时延的起因是异步的，没有做强同步。 这种架构带来的益处是能够实现同城IDC级别的容灾。也就是同城的生产IDC，挂掉任何一个IDC，比方某一个机房断电了，整个机房失联了，那我也能够保障业务的疾速复原，因为我的数据库也能够主动切换到其它两个IDC。 ...

作者：王向 爱可生 DBA 团队成员，负责公司 DMP 产品的运维和客户 MySQL 问题的解决。善于数据库故障解决。对数据库技术和 python 有着浓重的趣味。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 本文目录： update 更新“未胜利”？ 前言 问题场景 MySQL 呈现“写了 binlog 但并没有写 redo-log” 简略看下两阶段提交的流程两阶段写日志的意义？排查陷入僵局 排查 binlog 排查这段时间内的所有和这个 id 无关的 binlog 记录总结 update 更新“未胜利”？前言笔者最近解决了一个十分波折的问题，就是业务反映有一条数据进行 update 并且胜利后，查问仍然是旧数据。于是开始一路排查，最初才完满解释了所有的景象。 在这里将整个过程写成文章记录下来，心愿可能对读者有所帮忙。（篇幅可能会有点长，急躁看完，相对物有所值~） 问题场景业务小明：有一笔订单更新，更新数据返回胜利，然而数据库里还是旧的数据。 看了这组数据后，百思不得其解：“岂但批改的数据没有失效，utime 也不一样了”。于是登录数据库进行查问，后果确实是小明同志形容的那样。怎么办呢？ 翻了一下对于这条数据的 binlog 记录的语句的确就是进行了更新，那么问题来了。这不就意味着： 写了 binlog 但并没有进行 redo-log 的更新，这不就数据不统一了？ MySQL 呈现“写了 binlog 但并没有写 redo-log”家喻户晓，MySQL 具备 WAL 机制（先写日志，再写磁盘）。咱们要搞清楚会不会呈现“写了 binlog 但并没有写 redo-log”的状况，就须要钻研这个 WAL 机制的二段提交个性。 在说两阶段提交事务之前，咱们先来说说事务。 简略看下两阶段提交的流程 两阶段提交的时序图： 粗略察看一下上图，MySQL 想要执行事务的时候会分成两个阶段 第一阶段（prepare 阶段）：写 redo-log 并将其标记为 prepare 状态。 ...

一、反常的SQL语句 某周四午休时候，我正在工位上小憩，睡梦中好像看到了本人拿着李白在光荣峡谷里大杀四方的情景，就在我刚拿完五杀筹备率领队友推对面水晶的时候，一句慌乱短促的“糟了”把我从睡梦中惊醒。 我眯开朦胧的双眼，才发现方才的发声来源于我的组长庄哥，看到他在缓和的点开日志零碎查看日志，我预感到有什么不妙的事件产生，认真一问才晓得，原来就在我眯眼的期间，线上数据库服务器的CPU被打满，同时触发了生产数据库只读提早的限定工夫并且收回告警，而且告警的过程继续了半个小时。 这让我倒吸了一口凉气，因为咱们组做的零碎很多都用的是同一个数据库服务器，日用户沉闷量有好几十万，如果服务器解体了将会使所有的零碎服务都不可用，于是咱们连忙通过SQL日志进行问题查找，最初排查进去是因为一张SQL的高量查问没有走索引导致，日志列表显示，这条sql语句的扫描行数达到了上百万，根本就是全表扫描的状况，而且半个小时的工夫查问了达上万次，每条SQL查问的耗时都在3000ms以上。 我的天啊，难怪服务器会CPU打满，这么一条耗时的SQL语句查问量这么大，数据库的资源当然是间接就解体了，这是过后那条SQL的查问状况： 二、长期解决 看了这条语句，我又倒吸一口凉气，这不就是我写的零碎调用的SQL语句吗？完了，这回逃不掉了，真是人在睡梦里，锅从天上来。 当然，因为是我本人写的SQL，所以我一看就晓得这条语句是有问题的。 依据我的代码解决，这条sql的调用还少了个重要的参数user\_fruit\_id，这个参数没有传的话是不应该走这条sql查问的，在我的设计里，该参数是数据表里一个联结索引的最左侧字段，如果该字段没有传值的话，那么索引就不会失效了。 KEY \`idx\_userfruitid\_type\` (   \`user\_fruit\_id\`,   \`task\_type\`,   \`receive\_start\_time\`,   \`receive\_end\_time\` ) USING BTREE尽管定位到了SQL语句，然而线上的问题迫不及待，总不可能找出bug改完再上线吧，所以，咱们只能做了一个长期解决，就是在原来的表上多加了一个联结索引，其实就是去掉了user\_fruit\_id 字段，让这些高量的查问都能走新的索引，就像上面这样： KEY \`idx\_task\_type\_receive\_start\_time\` (  \`task\_type\`,  \`receive\_start\_time\`,  \`receive\_end\_time\`,  \`created\_time\` ) USING BTREE加上索引后，sql的扫描行数就大幅度的升高了，重启实例后就又能失常运行了。 三、最左匹配准则 那么为什么最左侧的字段没传索引就不失效了，这是因为MySQL的联结索引是基于“最左匹配准则”匹配的。 咱们都晓得，索引的底层是B+树结构，联结索引的构造也是B+树，只不过键值数量不是一个，而是多个，构建一颗B+树只能依据一个值来构建，因而数据库根据联结索引最左的字段来构建B+树。 例如咱们用两个字段（name，age）这个联结索引来剖析， 当咱们在where条件中查找name为“张三”的所有记录的时候，能够疾速定位到ID4，并且查出所有蕴含“张三”的记录，而如果要查找“张三，10”这一条特定的数据，就能够用 name = "张三" and age = 10 获取。 因为联结索引的键值对是两个，所以只有后面的name确定的状况下就能够进一步定位到具体的age记录，然而如果你的查问条件只有age的话，那么索引就不会失效，因为没有匹配最右边的字段，前面所有的索引字段都不会失效，所以我之前写的sql语句才会因为少了最右边的user\_fruit\_id字段而走了全表扫描的查问形式。 失常来说，假如一个联结索引设计成(a,b)这样的构造的话，那么用a and b作为条件，或者a独自作为查问条件都会走索引，这种状况下咱们就不要再为a字段独自设计索引了。 但如果查问条件外面只有b的语句，是无奈应用(a,b)这个联结索引的，这时候你不得不保护另外一个索引，也就是说你须要同时保护(a,b)、(b) 这两个索引。 四、找出Bug 尽管长期做了解决，但问题并不算解决，很显著是零碎呈现了bug才会有走这样的查问条件。 因为是我本人写的代码，所以晓得是哪条SQL后我就马上定位到了代码里的具体方法，起初才发现是因为我对user\_fruit\_id字段的判空解决不失效所致。 因为该字段是从调用方传过来的，所以我在办法参数里对该字段做了非空限度的注解，也就是javax包下的@NotNull。 public class GardenUserTaskListReq implements Serializable {     private static final long serialVersionUID = -9161295541482297498L;     @ApiModelProperty(notes = "水果id")     @NotNull(message = "水果id不能为空")     private Long userFruitId;     /\*\*以下省略\*/     ..................... }尽管加上该注解来做非空校验，但我却没有在参数加上另一个注解@Validated，该注解如果没加上的话，那么调用javax包下的校验规定就都不失效，正确的写法是在controller层办法的参数后面加上注解： ...

前言： 慢日志在日常数据库运维中常常会用到，咱们能够通过查看慢日志来取得效率较差的 SQL ，而后能够进行 SQL 优化。本篇文章咱们一起来学习下慢日志相干常识。 1.慢日志简介慢日志全称为慢查问日志（Slow Query Log），次要用来记录在 MySQL 中执行工夫超过指定工夫的 SQL 语句。通过慢查问日志，能够查找出哪些语句的执行效率低，以便进行优化。 默认状况下，MySQL 并没有开启慢日志，能够通过批改 slow_query_log 参数来关上慢日志。与慢日志相干的参数介绍如下： slow_query_log：是否启用慢查问日志，默认为0，可设置为0、1，1示意开启。slow_query_log_file：指定慢查问日志地位及名称，默认值为host_name-slow.log，可指定绝对路径。long_query_time：慢查问执行工夫阈值，超过此工夫会记录，默认为10，单位为s。log_output：慢查问日志输入指标，默认为file，即输入到文件。log_timestamps：次要是管制 error log、slow log、genera log 日志文件中的显示时区，默认应用UTC时区，倡议改为 SYSTEM 零碎时区。log_queries_not_using_indexes：是否记录所有未应用索引的查问语句，默认为off。min_examined_row_limit：对于查问扫描行数小于此参数的SQL，将不会记录到慢查问日志中，默认为0。log_slow_admin_statements：慢速治理语句是否写入慢日志中，治理语句蕴含 alter table、create index 等，默认为 off 即不写入。个别状况下，咱们只需开启慢日志记录，配置下阈值工夫，其余参数可按默认配置。对于阈值工夫，可灵便调整，比如说能够设置为 1s 或 3s 。 2.慢日志实战在配置文件中，咱们能够设置以下几个慢日志相干参数： # 慢查问日志相干配置，可依据理论状况批改vim /etc/my.cnf [mysqld] slow_query_log = 1slow_query_log_file = /data/mysql/logs/slow.loglong_query_time = 1log_timestamps = SYSTEMlog_output = FILE上面咱们具体看下，慢日志会记录哪些内容？咱们执行一条较慢的查问 SQL ，来看下在慢日志中的体现。 # 该条SQL执行工夫超过阈值# Time: 2021-05-13T17:38:03.687811+08:00# User@Host: root[root] @ [192.168.85.0] Id: 2604943# Query_time: 1.099889 Lock_time: 0.000144 Rows_sent: 39 Rows_examined: 45305SET timestamp=1620898683;select * from test_table where col_name like '%测试%';如果启用了慢速查问日志，并且抉择了 FILE 作为输入指标，则写入日志的每个语句都以 # 字符结尾。对于每一组慢SQL，第一行记录的是该条 SQL 执行的时刻（如果 log_timestamps 参数为 UTC ，则改工夫会显示 UTC 时区工夫），第二行记录的是执行该语句的用户和 IP 以及链接 id ，第三行的几个字段解释如下： ...

最近在做一些对于统计方面的开发，整顿了以下对于各个时间段的查问 查问当天内各时段的XX统计(比方小时客流量) 阐明 表名：cg_event_tendency_num_hour_statistics数据库天字段：event_date数据库工夫字段：event_hour ==> 返回给前端as为name数据库以后时间段数量字段：event_num ==> 返回给前端as为valueSELECT event_hour,SUM( event_num ) as event_num FROM cg_event_tendency_num_hour_statistics WHERE date_format(event_date, '%Y-%m-%d') = DATE_FORMAT(now(), '%Y-%m-%d') GROUP BY event_hour这里会呈现一个问题，数据查问进去的可能不是残缺的时间段 然而咱们想返回给前端残缺的工夫00-23该怎么操作呢？咱们能够应用LEFT JOIN来进行操作，先应用 UNION ALL查问出00-23的全副工夫,再将实在数据进行左关联 残缺sql如下： SELECT timetable.HOUR AS NAME, ifnull(sumtable.count, 0) AS VALUEFROM ( SELECT 0 AS HOUR UNION ALL SELECT 1 AS HOUR UNION ALL SELECT 2 AS HOUR UNION ALL SELECT 3 AS HOUR UNION ALL SELECT 4 AS HOUR UNION ALL SELECT 5 AS HOUR UNION ALL SELECT 6 AS HOUR UNION ALL SELECT 7 AS HOUR UNION ALL SELECT 8 AS HOUR UNION ALL SELECT 9 AS HOUR UNION ALL SELECT 10 AS HOUR UNION ALL SELECT 11 AS HOUR UNION ALL SELECT 12 AS HOUR UNION ALL SELECT 13 AS HOUR UNION ALL SELECT 14 AS HOUR UNION ALL SELECT 15 AS HOUR UNION ALL SELECT 16 AS HOUR UNION ALL SELECT 17 AS HOUR UNION ALL SELECT 18 AS HOUR UNION ALL SELECT 19 AS HOUR UNION ALL SELECT 20 AS HOUR UNION ALL SELECT 21 AS HOUR UNION ALL SELECT 22 AS HOUR UNION ALL SELECT 23 AS HOUR) timetable LEFT JOIN ( SELECT event_hour AS HOUR, SUM(event_num) AS count FROM cg_event_tendency_num_hour_statistics WHERE date_format(event_date, '%Y-%m-%d') = DATE_FORMAT(now(), '%Y-%m-%d') GROUP BY HOUR ) sumtable ON timetable.HOUR = sumtable.HOURORDER BY NAME后果： ...

作者：马文斌 MySQL OCP 认证，PostgresSQL PGCA 认证，善于 MySQL、PostgreSQL、dble 等开源数据库相干产品的备份复原、读写拆散、SQL 调优、监控运维、高可用架构设计等。目前任职于月亮小屋(中国)有限公司。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 1. 背景本地 MySQL 数据库要拜访近程 MySQL 数据库的表中的数据，又不想用数据同步形式去实现，所以就思考 FEDERATED 存储引擎来实现。要容许这个存储引擎，当构建 MySQL 时应用 --with-federated-storage-engine 来 configure。2. FEDERATED 引擎架构：当客户端收回援用 FEDERATED 表的 SQL 语句时，本地服务器（执行 SQL 语句的中央）和近程服务器（理论存储数据的中央）之间的信息流如下： 存储引擎将遍历 FEDERATED 表具备的每一列，并结构一个援用近程表的适当 SQL 语句。该语句应用 MySQL 客户端 API 发送到近程服务器。近程服务器解决该语句，本地服务器检索该语句产生的任何后果（受影响的行数或后果集）。如果该语句产生后果集，则每一列都将转换为 FEDERATED 引擎冀望的外部存储引擎格局，并可用于将结果显示给收回原始语句的客户端。架构图如下： 3. 相干个性反对的语法：在外部，实现应用 SELECT， INSERT， UPDATE，和 DELETE，但不会 HANDLER。该 FEDERATED 存储引擎反对 SELECT， INSERT， UPDATE， DELETE， TRUNCATE TABLE，和索引。除之外，它不反对 ALTER TABLE、DROP TABLE 或任何间接影响表构造的数据定义语言语句。以后实现不应用筹备好的语句。FEDERATED 承受 INSERT ... ON DUPLICATE KEY UPDATE 语句，然而如果产生反复键抵触，该语句将失败并显示谬误。不反对的语法：FEDERATED 执行批量插入解决，以便将多行批量发送到近程表，从而进步了性能。另外，如果近程表是事务性的，则它能够使近程存储引擎在产生谬误时正确执行语句回滚。此性能具备以下限度：1） 插入的大小不能超过服务器之间的最大数据包大小。如果插入超过此大小，它将被分成多个数据包，并可能产生回滚问题。 ...

1、查看慢查问超时工夫值use performance_schema;select * from variables_by_thread where variable_name = 'long_query_time';2、查看MySQL以后线程show processlist;

大数据表构造批改随着业务的倒退。某些业务表会达到很高的量级。这时候某些业务如果牵扯到批改数据结构，就不是简略的alter table 能搞定的事件了 话不多说，间接上计划： graph LR 复制一个新表 --> 批改表构造 -->拷贝数据 --> 重命名新表 ---> 删除老表该计划：速度很快的。几百万数据不到1分钟就搞定了（跟表字段数无关，以理论为准，倡议分批拷贝） 以下以表A为例子 CREATE TABLE `A` ( `id` int(11) NOT NULL AUTO_INCREMENT, `is_delete` tinyint(1) DEFAULT NULL, `type` tinyint(4) DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;复制一个新表，表构造跟老表一摸一样 create table A_new like A;批改表构造（这里以减少字段为例） alter table A_new add column `status` tinyint(8) DEFAULT NULL;拷贝数据 insert into A_new (id, is_delete, type) select id, is_delete, type from A ps: 如果批改的表构造为减少删除字段，请应用相似下面的sql，留神插入字段和查问字段必须统一如果是增删索引，能够应用上面的sql insert into A_new select * from A如果数据量较大，能够应用条件语句，分批拷贝(这里以id为例，个别都以create_time为条件) ...

一、事务的基本要素（ACID） 1、原子性（Atomicity）：MySQL事务开始后所有操作，要么全副做完，要么全副不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有产生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质形成的根本单位。 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改完结后发现还有一条记录没有改过来，就如同产生了幻觉一样，这就叫幻读。批改过去了但又被改了，导致后果和预期不一样 小结：不可反复读的和幻读很容易混同，不可反复读侧重于批改，幻读侧重于新增或删除。解决不可反复读的问题只需锁住满足条件的行，解决幻读须要锁表

一、前言：明天遇到一个事件，两个程序员对 insert into select 着迷一晚，这到底是为神魔呢？ 上面就简略说说原由； 当天，在 MySql数据库 中，程序员A应用 insert into select 对某张表中的一部分数据做备份，而后同时程序员B应用程序对这张表做数据插入操作，最初呈现了程序员B的插入操作失败的状况，而后他们就钻研了这个问题一早晨，最终找到了导致问题呈现的起因。 上面就通过简略的模仿场景复现问题，而后并钻研呈现问题的起因，最初再找到防止问题呈现的办法； 本文主线：①、场景重现：模仿问题呈现的场景 ②、问题求解：钻研问题呈现的起因 ③、最终后果：防止问题呈现的办法 二、场景重现：模仿问题呈现的场景1、保障环境的统一：呈现问题时应用的mysql数据库的版本是 5.7.16-log ； 不分明本人应用的mysql版本的能够应用上面的语句进行查问，只有版本差不多就能够； select version();留神：创立一个新的数据库，保障这个库只有本人操作，次要是为了更加直观的重现问题及钻研呈现问题的起因，防止其它的烦扰因素； 2、创立测试的表：建表SQL如下： 日志表： DROP TABLE IF EXISTS `t_log`;CREATE TABLE `t_log` ( `id` int(11) NOT NULL AUTO_INCREMENT, `log` varchar(1024) DEFAULT NULL COMMENT '日志内容', `createts` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '创立工夫', PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;日志备份表： DROP TABLE IF EXISTS `t_log_back`;CREATE TABLE `t_log_back` ( `id` int(11) NOT NULL AUTO_INCREMENT, `log` varchar(1024) DEFAULT NULL COMMENT '日志内容', `createts` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '创立工夫', PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;3、结构用于测试备份的数据：在 t_log 表中新增 20 万 条数据，这些数据用于备份时应用； 应用存储过程在表中插入数据； ...

配置启用二进制日志[mysqld]# 启用二进制日志记录，8.0之前默认禁用，之后默认启用# 二进制日志文件名称前缀，二进制日志是具备根本名称和数字扩展名的文件序列。# 二进制日志文件的默认地位是数据目录，能够应用此选项设置log-bin=mysql-bin# 在MySQL 5.7中，启用二进制日志记录时必须指定服务器ID，否则服务器将无奈启动# 在MySQL 8.0中，服务器ID默认设置为1# 默认值未0，如果应用默认值则不能和从节点通信，这个值的区间是：1到(2^32)-1server-id=1# 禁用MySQL服务器将二进制日志同步到磁盘的性能，有操作系统管制，性能最佳，安全性最差# sync_binlog=0# 在提交事务之前启用二进制日志到磁盘的同步，性能最差，安全性最佳sync_binlog=1# 日志在每次事务提交时写入并刷新到磁盘，安全性最佳innodb_flush_log_at_trx_commit=1查看确认是否启用 mysql> show variables like 'log_bin';+---------------+-------+| Variable_name | Value |+---------------+-------+| log_bin | ON |+---------------+-------+1 row in set (0.01 sec)查看binlog内容 show binlog events \G;二进制日志文件阐明每次产生以下任何事件，服务器都会在系列中创立一个新文件： 服务器启动或重启服务器刷新日志。以后日志文件的大小达到 max_binlog_size。为了跟踪应用了哪些二进制日志文件，mysqld会创立一个二进制日志索引文件，内容中蕴含了二进制日志文件的名称。默认状况下，该文件名称与二进制日志文件具备雷同的根本名称，扩大名为 '.index'。能够应用 --log-bin-index[=file_name] 选项更改二进制日志索引文件的名称。 参考：https://dev.mysql.com/doc/ref...

MySQL报错起因当MySQL报错[Error] MySQL establishment of connection, message from server Too many connection，应该怎么解决呢？太多的连接数，登录用户过多，且配置的MySQL连接数过小，或者某些连贯没有敞开，导致连接数过大。解决方案： vim /etc/mysql/my.cnf减少代码 max_connections = 2000应用 tail 查看文件代码是否已减少 tail /etc/mysql/my.cnf已批改实现，下一步重启MySQL容器，查看MySQL是否胜利启动 docker ps// 查看MySQL是否启动docker stop mysql// 进行MySQLdocker ps// 查看是否进行docker start mysql// 重新启动MySQLdocker ps -a// 查看是否启动实现MySQL的启动

作者：耿进 爱可生 DBA 团队成员，负责公司 DMP 产品的运维和客户 MySQL 问题的解决。对数据库技术有着浓重的趣味。你见过凌晨四点 MySQL 的 error 吗？ 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 概述：咱们先来重新认识一下 mysql.user 表中对于明码过期的字段， mysql> use mysqlDatabase changedmysql> desc user;+------------------------+-----------------------------------+------+-----+-----------------------+-------+| Field | Type | Null | Key | Default | Extra |+------------------------+-----------------------------------+------+-----+-----------------------+-------+。。。。| password_expired | enum('N','Y') | NO | | N | || password_last_changed | timestamp | YES | | NULL | || password_lifetime | smallint(5) unsigned | YES | | NULL | |+------------------------+-----------------------------------+------+-----+-----------------------+-------+45 rows in set (0.01 sec)mysql> password_expired：从 MySQL 5.6.6 版本开始，增加了 password_expired 性能，它容许设置用户的过期工夫。 ...

MySQL数据库对于登录以及数据库的一些命令 登录数据库在windows操作系统中，将门路增加到环境变量后，关上命令行工具输出以下命令 C:\Users\markaini>mysql -u root -h localhost -pEnter password: ********展现以后数据库的命令如下： mysql> show databases;+--------------------+| Database |+--------------------+| ifbg_u16 || ifbg_u16_1120 || information_schema || mysql || performance_schema || sakila || study || sys || test || world |+--------------------+创立数据库的命令如下： mysql> create database segmentfalut;Query OK, 1 row affected (0.34 sec)删除数据库命令如下： mysql> drop database world;Query OK, 3 rows affected (3.23 sec)请务必上手操作！

# 以运行MySQL服务器的用户（如，mysql）登录su mysql# 进行MySQL服务器kill `cat /var/lib/mysql/host_name.pid`# 或kill `cat /var/run/mysqld/host_name.pid`# 或kill `cat /usr/local/mysql/data/host_name.pid`创立一个批改明码的启动文件 vim /home/me/mysql-initALTER USER 'root'@'localhost' IDENTIFIED BY 'MyNewPass';# 应用启动文件启动MySQL服务器mysqld --init-file=/home/me/mysql-init &# 删除启动文件rm /home/me/mysql-init# 进行MySQL服务器kill `cat /var/lib/mysql/host_name.pid`# 启动MySQL服务器systemctl start mysqld参考：https://dev.mysql.com/doc/ref...

mysql 静默复原备份文件步骤如下:1、新建一个 mysql.sh shell脚本，脚本里写： mysql -uroot -proot -hlocalhost --database=db1 < db1.sql2、回到终端执行： nohup sh mysqlimport.sh &脚本便会切换到后盾执行导入，此时能够应用 tail -f nohup.log 查看执行日志。 3、按回车回到终端界面，输出命令 exit 退出以后终端。 第3步很要害，肯定要这样执行退出终端。 如果在 nohup执行胜利后间接点关闭程序按钮敞开终端 的话，这时候会断掉该命令所对应的session，导致nohup对应的过程被告诉须要一起shutdown，起不到关掉终端后调用程序持续后盾运行的作用。

作者：赵拂晓 爱可生 MySQL DBA 团队成员，相熟 Oracle、MySQL 等数据库，善于数据库性能问题诊断、事务与锁问题的剖析等，负责解决客户 MySQL 及我司自研 DMP 平台日常运维中的问题，对开源数据库相干技术十分感兴趣。 本文起源：原创投稿 * 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 背景 什么是 exec_time 环境筹备 测试 1（binlog_format=row）论断 1注意事项 1测试 2（binlog_format=statement）论断 2注意事项 2原理剖析 故障案例 故障模拟 测试 1：模仿磁盘 IO 瓶颈的场景测试 2：模仿 CPU 瓶颈的场景测试 3：模仿网络提早的场景总结 参考文档 背景最近在解决某客户的 MySQL 数据库主从提早问题时，发现了一个与 exec_time 无关的奇怪景象，于是抽空做了一些测试，借此文分享一些心得。 什么是 exec_time此处的 exec_time 是指 binlog 中记录的值，顾名思义，它是一个执行工夫，那它是对于什么的呢？单个语句，整个事务，或是其余？咱们先来做几个测试。 环境筹备环境信息角色主机/IP数据库版本主库10.186.60.62MySQL 5.7.32从库10.186.60.68MySQL 5.7.32测试表zlm@10.186.60.62 [zlm]> show create table t\G*************************** 1. row *************************** Table: tCreate Table: CREATE TABLE `t` ( `id` int(11) NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf81 row in set (0.00 sec)zlm@10.186.60.62 [zlm]> select * from t;Empty set (0.01 sec)测试 1（binlog_format=row）提交一个事务，其中蕴含 2 个 insert 语句（GTID=xxxx:1） ...

CREATE TABLE t_vouchers (id int(10) NOT NULL AUTO_INCREMENT ,title varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '代金券题目' ,thumbnail varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '缩略图' ,amount int(11) NULL DEFAULT NULL COMMENT '抵扣金额' ,price decimal(10,2) NULL DEFAULT NULL COMMENT '售价' ,status int(10) NULL DEFAULT NULL COMMENT '-1=过期 0=下架 1=上架' ,start_use_time datetime NULL DEFAULT NULL COMMENT '开始应用工夫' ,expire_time datetime NULL DEFAULT NULL COMMENT '过期工夫' ,redeem_restaurant_id int(10) NULL DEFAULT NULL COMMENT '验证餐厅' ,stock int(11) NULL DEFAULT 0 COMMENT '库存' ,stock_left int(11) NULL DEFAULT 0 COMMENT '残余数量' ,description varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '形容信息' ,clause varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '应用条款' ,create_date datetime NULL DEFAULT NULL ,update_date datetime NULL DEFAULT NULL ,is_valid tinyint(1) NULL DEFAULT NULL ,PRIMARY KEY (id))ENGINE=InnoDBDEFAULT CHARACTER SET=utf8 COLLATE=utf8_general_ciAUTO_INCREMENT=1ROW_FORMAT=COMPACT; ...

文章简介网络上对于 MySQL 主从复制的文章很多都是解说如何实现，以及局部实现原理，不足对 MySQL 主从复制的全面介绍。例如主从复制的模式(半同步模式和异步同步模式)、同步的原理(binary log+position，GTID)、主从复制的常见问题都不足一个全面的总结。 本文针对这些局部内容做一个全面的剖析与总结。本文次要的内容有 MySQL主从复制的起因、实现原理、实现步骤、半同步模式、异步同步模式、GTID 同步、常见问题与解决方案等内容。 模式劣势在理解主从复制之前，咱们先理解一下什么是主从复制。说的简略一点就是将一台 MySQL 服务器的数据库文件同步到其余的 MySQL 服务上，使得被同步的 MySQL 服务也能读取到咱们的数据。 为什么会有主从复制呢？这里我总结了两点起因： 数据容灾、备份。当咱们的数据库只应用一台服务时，如果咱们的数据库受到毁坏，例如黑客的攻打、人为操作的失误等等状况。这时候咱们就能够在肯定水平上保障咱们数据库的复原。如果只为为了避免数据库的失落，咱们能够针对数据进行定时备份，为何还要搞什么主从复制，这样不是更麻烦嘛。如果咱们只是定时备份数据库，能够试想一下，万一在某个备份操作还未执行的阶段，数据库呈现问题，两头的这一部分数据不就没法复原了嘛。 缓解 MySQL 主服务的压力。当咱们线上利用用户量小的时候，所有的读与写操作都在一台服务器上，这时候还不会遇到什么问题。当用户量逐步减少，拜访数据库的申请也越来越多，这时候就给 MySQL 服务器减少了累赘，容易导致服务解体等问题。因而，主从复制模式能够缓解单服务器的压力，将写操作给主服务器，读操作给从服务器，从服务器能够部署多台，摊派压力。因为在一个利用中，读的操作必定是大于写的操作。 实现原理下图是 MySQL 主从复制的一个原理图： master 服务器会将 SQL 记录通过多 dump 线程写入到 binary log 中。slave 服务器开启一个 io thread 线程向服务器发送申请，向 master 服务器申请 binary log。master 服务器在接管到申请之后，依据偏移量将新的 binary log 发送给 slave 服务器。slave 服务器收到新的 binary log 之后，写入到本身的 relay log 中，这就是所谓的中继日志。slave 服务器，独自开启一个 sql thread 读取 relay log 之后，写入到本身数据中。常见模式常见的主从模式有如下几种，具体的模式也得看理论的业务须要。依据理论的状况，抉择适合的一种架构模式。 一主一从模式。 一主多从模式。 级联主从模式。 一主多从模式。 ...

查看所有二进制日志文件的列表 mysql> SHOW BINARY LOGS;确定以后二进制日志文件的名称 mysql> SHOW MASTER STATUS;查看二进制日志内容 shell> mysqlbinlog binlog_files | more# 或者将输入保留在文件中，而后在文本编辑器中查看文件shell> mysqlbinlog binlog_files > tmpfile执行批改后的二进制文件 shell> mysql -u root -p < tmpfile不批改内容间接执行二进制日志文件 shell> mysqlbinlog binlog_files | mysql -u root -p应应用单个数据库连贯来执行要解决的所有二进制日志文件的内容 shell> mysqlbinlog binlog.000001 binlog.000002 | mysql -u root -p# 将整个日志写入单个文件，而后解决该文件shell> mysqlbinlog binlog.000001 > /tmp/statements.sqlshell> mysqlbinlog binlog.000002 >> /tmp/statements.sqlshell> mysql -u root -p -e "source /tmp/statements.sql"

应用mysqldump转储SQL格局的数据转储所有数据库 shell> mysqldump --all-databases > dump.sql仅转储特定数据库 shell> mysqldump --databases db1 db2 db3 > dump.sql仅转储特定数据库，但不蕴含 CREATE DATABASE 和 USE 语句 shell> mysqldump test > dump.sql仅转储特定数据库的特定数据表 shell> mysqldump test t1 t3 t7 > dump.sql别离转储test数据库的表定义和数据 shell> mysqldump --no-data test > dump-defs.sqlshell> mysqldump --no-create-info test > dump-data.sql转储存储过程和事件 shell> mysqldump --no-data --routines --events test > dump-defs.sql从新加载SQL格局的备份复原数据 shell> mysql < dump.sql# 或mysql> source dump.sql如果文件不蕴含 CREATE DATABASE 和 USE 语句 shell> mysqladmin create db1shell> mysql db1 < dump.sql# 或mysql> CREATE DATABASE IF NOT EXISTS db1;mysql> USE db1;mysql> source dump.sql

新版本MySQL的明码批改形式 1.5.7后的版本批改明码的代码如下：ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY '批改后明码';查看本机 MySQL 的版本号：select version() from dual; 因为过后装docker版MySQL的时候没指定版本，所以装的MySQL是 8.0的新版本，导致始终更新账号密码报错 上面是5.7版本的批改形式MySQL批改初始密码三种办法： 办法一：1、应用空的初始密码登录mysql账号： mysql-uroot -p2、批改root明码： SETPASSWORD = PASSWORD('123456');办法二：1、应用空的初始密码登录mysql账号： mysql-uroot -p2、批改root明码： mysqladmin -u root password '123456'办法三：1、应用空的初始密码登录mysql账号： mysql-uroot -p2、批改root明码： mysql> update user set Password=password("123456") where User='root';Query OK, 4 rows affected (0.01 sec)Rows matched: 4 Changed: 4 Warnings: 0mysql> flush privileges;Query OK, 0 rows affected (0.04 sec)mysql> select Host,User,password from user where user='root';+-----------------------+------+-------------------------------------------+| Host | User | password |+-----------------------+------+-------------------------------------------+| localhost | root | *5626ED34B75C6C508BA2A3D0A4F6E4C58823138C || localhost.localdomain | root | *5626ED34B75C6C508BA2A3D0A4F6E4C58823138C || 127.0.0.1 | root | *5626ED34B75C6C508BA2A3D0A4F6E4C58823138C || ::1 | root | *5626ED34B75C6C508BA2A3D0A4F6E4C58823138C |+-----------------------+------+-------------------------------------------+4 rows in set (0.00 sec)

为什么须要数据字典通过Navicat等数据库管理工具，咱们也能看到数据表的结构设计，然而，如果咱们把全副的数据表的结构设计都做成可在线预览的，会不会更加清晰清朗呢，而且也更加容易比照发现问题和及时优化，更有效率。 生成数据字典的形式这里我次要利用showdoc在线文档实现数据字典的在线查看，次要说两种实现形式：别离是官网shell脚本和我写的PHP脚本； 官网shell脚本：仅反对在Linux服务器中运行，官网的文档地址：https://www.showdoc.com.cn/page/312209902620725我写的PHP脚本：不论是在Linux还是在Windows等操作系统中都反对，而且更加灵便可控官网的脚本运行形式也比较简单，看看文档即明确，我上面次要说一下我写的PHP脚本的思路和运行形式，也就是利用showdoc提供的凋谢API接口实现将数据结构的信息以Markdown的格局上传到指定我的项目，文档地址：https://www.showdoc.com.cn/page/102098 要害信息配置因为连贯数据库的配置信息以及须要上传的我的项目地址也不同，所以这些信息须要独自配置，具体我也不多说了，看上面代码及正文信息即可 // 数据库连贯配置信息private $host = '127.0.0.1';private $user_name = 'root';private $password = 'root';private $db_name = 'test';private $port = 3306;private $conn;// showdoc文档API密钥配置，获取办法：https://www.showdoc.com.cn/page/741656402509783private $api_key = '6b0ddb543b53f5002f6033cb2b00cec01908536369';private $api_token = '9da3190d0dda1118de0e8bde08907fc51712469974';连贯和敞开MySQL数据库为了不便疾速跨平台应用，我应用的都是PHP原生的写法，所以，连贯数据库以及查问数据都是应用原生的PHP写法，利用PHP类的语法个性，在构造函数中连贯数据库并且在析构函数中敞开连贯。 /** * 构造函数，连贯数据库 * GetMysqlDict constructor. */public function __construct(){ // 创立连贯 $this->conn = new mysqli($this->host, $this->user_name, $this->password, $this->db_name, $this->port); // 检测连贯 if ($this->conn->connect_error) { exit("数据库连贯失败: " . $this->conn->connect_error); } $this->echoMsg('数据库连贯胜利');}/** * 析构函数，敞开数据库连贯 */public function __destruct(){ $this->conn->close(); $this->echoMsg('已敞开数据库连贯');}查问表构造信息连贯上了数据库，那么咱们就能够查问利用Sql语句数据库信息相干信息，利用语句show table status;能够查出以后连贯库的全副数据表信息，而后再查问information_schema.COLUMNS表上具体某个表的数据结构信息，并组装数组返回应用。 ...

作者：王向 爱可生 DBA 团队成员，负责公司 DMP 产品的运维和客户 MySQL 问题的解决。善于数据库故障解决。对数据库技术和 python 有着浓重的趣味。 本文起源：原创投稿 * 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 前言MHA 进去将近 10 年的工夫，作为一个开源产品，能活这么久，还有这么多人追捧。基本上能够说是一种 mysql 中的规范解决方案。 不过 MHA 曾经不适宜这个时代了。。。然而这不影响咱们对他进行一波钻研。 产生 master crash 源码剖析上面的内容比拟淦，没有趣味的同学间接跳到：总结。 对于源码能够间接去 github.com 而后搜 MHA。 sub main { ..... eval { $error_code = do_master_failover(); }; if ($@) { $error_code = 1; } if ($error_code) { finalize_on_error(); } return $error_code; .... sub do_master_failover { my $error_code = 1; #错误码 my ( $dead_master, $new_master ); # $dead_master 逝世的master # $new_master 新生的master eval { # 第一步： 查看配置 my ( $servers_config_ref, $binlog_server_ref ) = init_config(); $log->info("Starting master failover."); $log->info(); $log->info("* Phase 1: Configuration Check Phase..\n"); $log->info(); # 初始化 Binlog server MHA::ServerManager::init_binlog_server( $binlog_server_ref, $log ); # ssh_check_simple 查看SSH的连通性 # get_node_version 获取node的版本号 # 理论应用命令拿到版本号 apply_diff_relay_logs --version # 拿到版本号 Binlog server可达，否则不可达 $dead_master = check_settings($servers_config_ref); # MHA::ManagerUtil::check_node_version($log); # 查看mha的版本信息 # 后果1：没有装置mha # 后果2： $node_version < $MHA::ManagerConst::NODE_MIN_VERSION # our $NODE_MIN_VERSION = '0.54'; # 节点版本号必须等于或者高于0.54 # $_server_manager->connect_all_and_read_server_status(); # 查看各实例是否能够连贯 # my @dead_servers = $_server_manager->get_dead_servers(); # my @alive_servers = $_server_manager->get_alive_servers(); # my @alive_slaves = $_server_manager->get_alive_slaves(); # get_dead_servers/get_alive_servers/get_alive_slaves：double check各个node的死活状态 # g$_server_manager->start_sql_threads_if(); 查看Slave_SQL_Running是否为Yes，若不是则启动SQL thread if ( $_server_manager->is_gtid_auto_pos_enabled() ) { $log->info("Starting GTID based failover."); } else { $_server_manager->force_disable_log_bin_if_auto_pos_disabled(); $log->info("Starting Non-GTID based failover."); } $log->info(); $log->info("** Phase 1: Configuration Check Phase completed.\n"); $log->info(); # 第二步：敞开以后失败的IO复制线程，并执行脚本切换VIP $log->info("* Phase 2: Dead Master Shutdown Phase..\n"); $log->info(); force_shutdown($dead_master); # 判断ssh是否可达 # MHA::HealthCheck::ssh_check_simple() # MHA::ManagerUtil::get_node_version() # my $rc = $target->stop_io_thread(); 进行所有slave复制IO线程 # force_shutdown_internal() 执行配置文件中的master_ip_failover_script/shutdown_script，如果没有就不执行 # master_ip_failover_script：如果设置了VIP，则首先切换VIP # shutdown_script：如果设置了shutdown脚本，则执行shutdown脚本 $log->info("* Phase 2: Dead Master Shutdown Phase completed.\n"); $log->info(); # 第三步 新主复原 $log->info("* Phase 3: Master Recovery Phase..\n"); $log->info(); # 获取新的主从信息 $log->info("* Phase 3.1: Getting Latest Slaves Phase..\n"); $log->info(); check_set_latest_slaves(); # $_server_manager->read_slave_status(); 获取各个slave的binlog file和position点 # my %status = $target->check_slave_status(); 执行show slave status来获取从库信息 Slave_IO_State, Master_Host, Master_Port, Master_User, Slave_IO_Running, Slave_SQL_Running, Master_Log_File, Read_Master_Log_Pos, Relay_Master_Log_File, Last_Errno, Last_Error, Exec_Master_Log_Pos, Relay_Log_File, Relay_Log_Pos, Seconds_Behind_Master, Retrieved_Gtid_Set, Executed_Gtid_Set, Auto_Position, Replicate_Do_DB, Replicate_Ignore_DB, Replicate_Do_Table, Replicate_Ignore_Table, Replicate_Wild_Do_Table, Replicate_Wild_Ignore_Table #其中重要的信息 $target->{Relay_Master_Log_File} = $status{Relay_Master_Log_File}; $target->{Exec_Master_Log_Pos} = $status{Exec_Master_Log_Pos}; $target->{Relay_Log_File} = $status{Relay_Log_File}; $target->{Relay_Log_Pos} = $status{Relay_Log_Pos}; # $_server_manager->identify_latest_slaves(); 比拟各个slave的Master_Log_File和Read_Master_Log_Pos,寻找latest的slave # $_server_manager->identify_oldest_slaves(); 比拟各个slave中的Master_Log_File和Read_Master_Log_Pos,寻找Oldest的slave if ( !$_server_manager->is_gtid_auto_pos_enabled() ) { $log->info(); # 进行binlog补充 $log->info("* Phase 3.2: Saving Dead Master's Binlog Phase..\n"); $log->info(); save_master_binlog($dead_master); # 判断dead master是否能够ssh连贯 # if ( $_real_ssh_reachable && !$g_skip_save_master_binlog ) { # 如果dead master能够ssh连贯 # MHA::ManagerUtil::check_node_version(); # my $latest_pos = ( $_server_manager->get_latest_slaves() )[0]->{Read_Master_Log_Pos}; save_master_binlog_internal( $latest_file, $latest_pos, $dead_master, ); # 应用node节点的save_binary_logs脚本在dead master上做拷贝 # save_binary_logs --command=save --start_file=$master_log_file --start_pos=$read_master_log_pos --binlog_dir=$dead_master->{master_binlog_dir} --output_file=$_diff_binary_log_remote --handle_raw_binlog=$dead_master->{handle_raw_binlog} --disable_log_bin=$dead_master->{disable_log_bin} --manager_version=$MHA::ManagerConst::VERSION"; # generate_diff_binary_log()： # $_binlog_manager->concat_all_binlogs_from($start_binlog_file, $start_binlog_pos, $out_diff_file) # dump_binlog() 拷贝binlog文件到到manage节点的manager_workdir目录下，如果dead master无奈ssh登录，则master上未同步到slave的txn失落 } $log->info(); # 确定新主 $log->info("* Phase 3.3: Determining New Master Phase..\n"); $log->info(); my $latest_base_slave; if ( $_server_manager->is_gtid_auto_pos_enabled() ) { $latest_base_slave = $_server_manager->get_most_advanced_latest_slave(); } else { $latest_base_slave = find_latest_base_slave($dead_master); #寻找最新的有所有中继日志的slave，用于复原其余slave # my $latest_base_slave = find_latest_base_slave_internal(); # my $oldest_mlf = $oldest_slave->{Master_Log_File}; # my $oldest_mlp = $oldest_slave->{Read_Master_Log_Pos}; # my $latest_mlf = $latest_slaves[0]->{Master_Log_File}; # my $latest_mlp = $latest_slaves[0]->{Read_Master_Log_Pos}; # if ($_server_manager->pos_cmp( $oldest_mlf, $oldest_mlp, $latest_mlf,$latest_mlp ) >= 0 # 判断latest和oldest slave上binlog地位是不是雷同，雷同就不须要同步relay log # apply_diff_relay_logs --command=find --latest # 查看latest slave中是否有oldest短少的relay log，若无则持续,否则failover失败 # 查找的办法：逆序的读latest slave的relay log文件，始终找到binlog file的position为止 } $new_master = select_new_master( $dead_master, $latest_base_slave ); #选出新的master节点 # 比拟master_log_file:read_master_log_pos # 辨认优先从库，在线的并带有candidate_master标记 # 辨认应该疏忽的从库，带有no_master标记、或者未开启log_bin、与最新从库相比数据提早比拟大(slave与master的binlog position差距大于100000000) # 抉择优先级顺次为：优先列表、最新从库列表、所有从库列表，但肯定排除疏忽列表 # 查看新老主库的复制过滤规定是否统一Replicate_Do_DB,Replicate_Ignore_DB,Replicate_Do_Table,Replicate_Ignore_Table my ( $master_log_file, $master_log_pos, $exec_gtid_set ) = recover_master( $dead_master, $new_master, $latest_base_slave, $binlog_server_ref ); $new_master->{activated} = 1; $log->info("* Phase 3: Master Recovery Phase completed.\n"); $log->info(); # 复原从库 相似独自复原主库的过程 $log->info("* Phase 4: Slaves Recovery Phase..\n"); $log->info(); $error_code = recover_slaves( $dead_master, $new_master, $latest_base_slave, $master_log_file, $master_log_pos, $exec_gtid_set ); # 中继弥补（生成Slave与New Slave之间的差别日志，将该日志拷贝到各Slave的工作目录下），指向新主库&启动复制（change_master_and_start_slave），清理新主库的slave复制通道（reset slave all） if ( $g_remove_dead_master_conf && $error_code == 0 ) { MHA::Config::delete_block_and_save( $g_config_file, $dead_master->{id}, $log ); } cleanup(); }; if ($@) { if ( $dead_master && $dead_master->{not_error} ) { $log->info($@); } else { MHA::ManagerUtil::print_error( "Got ERROR: $@", $log ); $mail_body .= "Got Error so couldn't continue failover from here.\n" if ($mail_body); } $_server_manager->disconnect_all() if ($_server_manager); undef $@; } eval { send_report( $dead_master, $new_master ); MHA::NodeUtil::drop_file_if( $_status_handler->{status_file} ) unless ($error_code); if ($_create_error_file) { MHA::NodeUtil::create_file_if($_failover_error_file); } }; if ($@) { MHA::ManagerUtil::print_error( "Got ERROR on final reporting: $@", $log ); undef $@; } return $error_code;}总结切换过程： ...

数据库基础知识为什么要应用数据库数据保留在内存长处： 存取速度快 毛病： 数据不能永恒保留 数据保留在文件长处： 数据永恒保留 毛病：1）速度比内存操作慢，频繁的IO操作。2）查问数据不不便 数据保留在数据库1）数据永恒保留 2）应用SQL语句，查问不便效率高。 3）治理数据不便 什么是SQL？结构化查询语言(Structured Query Language)简称SQL，是一种数据库查询语言。 作用：用于存取数据、查问、更新和治理关系数据库系统。 什么是MySQL?MySQL是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发，属于 Oracle 旗下产品。MySQL 是最风行的关系型数据库管理系统之一，在 WEB 利用方面，MySQL是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件之一。在Java企业级开发中十分罕用，因为 MySQL 是开源收费的，并且不便扩大。 数据库三大范式是什么第一范式：每个列都不能够再拆分。 第二范式：在第一范式的根底上，非主键列齐全依赖于主键，而不能是依赖于主键的一部分。 第三范式：在第二范式的根底上，非主键列只依赖于主键，不依赖于其余非主键。 在设计数据库构造的时候，要尽量恪守三范式，如果不恪守，必须有足够的理由。比方性能。事实上咱们常常会为了性能而斗争数据库的设计。 mysql无关权限的表都有哪几个MySQL服务器通过权限表来管制用户对数据库的拜访，权限表寄存在mysql数据库里，由mysql_install_db脚本初始化。这些权限表别离user，db，table_priv，columns_priv和host。上面别离介绍一下这些表的构造和内容： user权限表：记录容许连贯到服务器的用户帐号信息，外面的权限是全局级的。db权限表：记录各个帐号在各个数据库上的操作权限。table_priv权限表：记录数据表级的操作权限。columns_priv权限表：记录数据列级的操作权限。host权限表：配合db权限表对给定主机上数据库级操作权限作更粗疏的管制。这个权限表不受GRANT和REVOKE语句的影响。 MySQL的binlog有有几种录入格局？别离有什么区别？有三种格局，statement，row和mixed。 statement模式下，每一条会批改数据的sql都会记录在binlog中。不须要记录每一行的变动，缩小了binlog日志量，节约了IO，进步性能。因为sql的执行是有上下文的，因而在保留的时候须要保留相干的信息，同时还有一些应用了函数之类的语句无奈被记录复制。row级别下，不记录sql语句上下文相干信息，仅保留哪条记录被批改。记录单元为每一行的改变，根本是能够全部记下来然而因为很多操作，会导致大量行的改变(比方alter table)，因而这种模式的文件保留的信息太多，日志量太大。mixed，一种折中的计划，一般操作应用statement记录，当无奈应用statement的时候应用row。　此外，新版的MySQL中对row级别也做了一些优化，当表构造发生变化的时候，会记录语句而不是逐行记录。 数据类型mysql有哪些数据类型分类 类型名称 阐明 整数类型tinyInt 很小的整数(8位二进制)smallint 小的整数(16位二进制)mediumint 中等大小的整数(24位二进制)int(integer) 一般大小的整数(32位二进制) 小数类型float 单精度浮点数double 双精度浮点数decimal(m,d) 压缩严格的定点数 日期类型year YYYY 1901~2155time HH:MM:SS -838:59:59~838:59:59date YYYY-MM-DD 1000-01-01~9999-12-3datetime YYYY-MM-DD HH:MM:SS 1000-01-01 00:00:00~ 9999-12-31 23:59:59timestamp YYYY-MM-DD HH:MM:SS 19700101 00:00:01 UTC~2038-01-19 03:14:07UTC ...

ArchSummit2021年寰球架构师峰会于4月25日-26日在上海举办，袋鼠云运维开发技术专家沙章利（花名：浣熊）应邀出席此次峰会，并在4月26日下午的《弹性架构实际》专题会场上为大家带来《弹性云原生大数据系统架构实际》的演讲。本次演讲次要介绍袋鼠云基于数栈、联合数年大数据基础设施建设教训，打造云环境下的大数据基础设施的实际和案例，局部架构细节首次对外颁布，以下内容整顿自本次架构峰会。大家好，我是来自袋鼠云的浣熊，感激这次会议的讲师们给咱们带来了云原生技术利用的分享，感觉又关上了几个新脉门，解锁了新的武魂。在接下来的分享中，心愿大家跟着咱们的实际案例做一些探索性的思考。 首先咱们疾速回顾下大数据技术的倒退，而后重点给大家分享咱们最近几年做的一些零碎云化架构，最初再做个回归总结，心愿能给大家带去有价值的思考。 大数据技术的倒退大数据技术的发展史也是大数据架构的发展史。 云原生大数据技术是否是新一代大数据处理技术？ 1964年，IBM公布了System360，这是计算机发展史上的里程碑事件，System360上装备的磁盘驱动器(DASD)减速了数据库管理系统（DBMS）和关系型数据库的倒退，DBMS和关系型数据库的呈现使数据处理的效率大大晋升，一些规模较大的银行、航空公司开始引入数据库软件解决业务数据，这能够追溯为第一代(大)数据处理技术。 随着寰球经济的疾速倒退，须要解决的数据量也越来越大，单解决架构曾经无奈满足数据处理需要，有问题就有解决方案，针对这个问题美国Teradata公司推出了并行计算的架构，就是咱们明天常说的MPP架构，在MPP架构的技术根底上，Teradata的数据仓库建设技术一直倒退，在与过后的巨头IBM的强烈竞争之下，Teradata依靠沃尔玛建设了过后世界上最大规模的数仓。这一代技术的关键词咱们总结为MPP+数据仓库。 Hadoop生态的呈现多少有点意外（眼前一亮），Hadoop、HDFS及其开源生态圈能够应用更低廉的X86机器，通过疾速横向扩容的形式就能满足PB级别数据处理的需要。十多年的工夫，从Hadoop（MapReduce）到Spark、Flink等，开源生态的计算框架一直演进，基于内存的Spark、Flink计算架构曾经与具体的存储解耦，奠定了开源生态大数据系统计算与存储拆散架构的根底，咱们把开源生态这一系列看作是新一代大数据技术。 在云计算红利的推动下，大数据系统上云是必然的趋势，Teradata在2016年把本人的数据仓库搬到了私有云上，AWS也在2014年上架了数据仓库型产品Redshift，阿里云上的MaxCompute（晚期叫ODPS）是国内云上高性能并行大数据处理技术的里程碑。 去年9月份Snowflake的上市，把云原生数据仓库的话题推上了风口，私有云厂商开始从自家云产品的角度做出对云原生数据库、数据仓库、大数据平台等的解答。相比拟前几代大数据处理技术，云原生大数据处理技术是否能称为新一代大数据处理技术呢？带着这个问题，咱们来看下在大数据系统云化方面咱们的一些架构实际。 大数据系统云化实际私有云上的大数据产品曾经倒退成熟，因为社区倒退成熟、技术自主可控等特点，开源生态大数据体系曾经在国内外头部私有云平台上先后上架，各家私有云厂商配套上架了成熟的数据开发套件。 通过了数年大大小小生产级实际测验，间接选型私有云大数据产品，即可享受按需创立、秒级弹扩、运维托管和海量的大数据处理能力。然而因为种种限度，一些传统大型企业、金融行业等的外围业务并没有到私有云上。各行业在谋求云计算红利的过程中，又心愿把更多的业务零碎上云。在这种抵触下，公有云和混合云失去一直倒退，这类云上的产品状态也日渐丰盛，曾经由晚期的ECS自在逐步倒退成中间件自在。 大数据时代，大数据处理和剖析是企业的共性需要，以批处理和流解决为代表的数据处理平台逐步下沉为企业的大数据基础设施，若能实现大数据基础设施自在，即实现大数零碎的按需创立、按需扩缩、运维托管，即可为企业内和行业客户提供疾速可复制的大数据处理能力。 开源大数据处理系统以简单著称，以数栈为例，底层的存算层兼容支流的Hadoop发行版，两头的的计算层可凋谢集成支流的批流、算法、图计算框架，既反对传统的MapReduce计算框架，也反对存算解耦的内存计算框架，下层应用层建设在数据共享、数据资产治理、数据可视化治理等外围数据利用之上。 在VM/PM环境下，部署和运维这样一套大数据基础设施零碎，也不是一件容易的事件，晚期须要咱们1-2名中高级施行工程师，间断1-2周工夫，能力实现这样一套零碎的部署和调试。如何实现整套零碎的云上自动化交付，成为咱们零碎云化架构的第一个指标，即实现大数零碎的云上体验、按需创立。 1、第一套云化架构 第一指标达成要害是云化部署架构和自动化部署技术。 1）首先要考量的是云化模式，模式的不同如共享模式、独享模式等，将间接影响云化部署架构。 共享模式下个别以多租户的形式反对，一个机构共享一套基础设施，套内共享存储、计算和数据利用，资源之间以多租户的形式进行逻辑隔离，共享模式的长处是部署简略，毛病是租户间资源会互相抢占。 独享模式的隔离性会更好，然而按需创立的自动化部署技术是个难点。 2）第二个要考量的是公共零碎对接，例如对接IaaS获取动静IaaS资源，对接用户、降级、监控、计费等公共模块，这部分不多说。 3）第三要思考云环境下的网络环境，比方治理网（underlay）和VPC（overlay）网络划分状况，网络拜访策略在制订部署架构前须要清晰。 4）最初也是最重要的，在环境筹备好之后，如何高效的实现零碎的自动化部署、服务发现、健康检查、监控数据接入等就比拟要害了。 为实现零碎的自动化部署和监控运维，从2018年开始，咱们自研了部署运维管家EasyManager（以下简称EM），EM的外围能力之一是实现对资源的治理和服务的编排、管控。 把EM的Agent和服务编排模版打进零碎镜像是自动化部署的最佳实际，VM启动的过程就是服务启动的过程，服务启动后主动注册至EM-Agent-Server，下层管理网络通过Agent-Server以服务的粒度实现对系统服务的管控，同时基于主动的服务发现机制，配套施行监控数据主动采集汇总、供查。 零碎主动部署起来后，在独享模式下，为实现动静集群（实例零碎）的拜访，咱们引入Traefik来解决动静代理问题，Traefik是一个不错的免开候选，Traefik反对从Zookeeper、Redis等配置核心动静加载路由配置，自动化部署模块拿到集群（实例零碎）地址信息后写入配置核心，Traefik热加载配置并依据路由规定进行申请转发。联合Traefik动静路由的能力，拜访申请能够通过对立的IP或域名进入，经由Traefik依据全局惟一的集群（实例零碎）ID进行申请转发。 解决了以上几个关键问题之后，第一指标根本能够达成，配套上订购（创立）页、实例控制台，就实现了大数零碎云化架构的第一个实际摸索。这个实际的后果是能够实现5-10分钟疾速创立一套独享的（云化）大数据系统，且反对在线扩容，根本实现了上云体验、按需创立的零碎云化指标。 这套云化架构没有动业务零碎自身的架构，容易落地是长处。当然毛病也很显著，首先不是标准化的云化计划，各个依赖零碎如IaaS的对接须要依据具体云化环境定制，革新老本高；其次零碎上云后的弹性能力并没有失去晋升，勉强能够在线扩容，无奈实现闲时缩容。基于这两个毛病的思考，咱们尝试了第二个云化架构。 2、第二套云化架构 为实现IaaS层对接标准化，咱们做了零碎的容器化革新和Kubernetes部署对接，并自研了无状态利用和有状态利用部署Operator。在零碎组件全面容器化的根底上，联合一套自定义的Schema，构建面向Kubernetes的制品包，这个制品包能够通过EM一键部署到Kubernetes集群。 为实现零碎弹性能力的晋升，依靠开源社区计算框架对Kubernetes的适配，咱们做了产品层的封装，实现了把Spark和Flink的计算工作提交到Kubernetes执行。利用Kubernetes弱小的资源管理能力，实现计算资源的弹性扩缩。 这套架构的另一个特点是兼容On Yarn模式，这个点很受企业的欢送，起因是即能拥抱Kubernetes大法，又能持续应用已有的Hadoop基础设施进行生产，兼容并蓄，领导开心。 这套云化架构能够解决上一套遗留的问题，通过集成Kubernetes，实现对底层IaaS资源对接的标准化，同时晋升了计算资源的扩缩能力，实践上是秒级的。当然也产生了新的问题： 计算工作提交至Kubernetes后，计算资源的弹性失去保障，但同时计算真正意义上的远离了数据，这对计算性能是否有不良影响？计算的弹性解决了，那存储的弹性怎么办？ 第二套云化架构上，架构调整的角度曾经从部署架构转移到零碎架构层面，咱们开始调整零碎的计算架构，即用Kubernetes代替Yarn作为计算资源管理者，这是在面向云环境做零碎架构适配。 在咱们进一步思考存储架构调整的时候，咱们从新扫视零碎云化实际的过程，咱们发现咱们的实际思路产生了扭转，总结下来就是从构建云（云化）到基于云构建的思路转变。大数据系统的弹性能力也是数据的解决能力，从弹性的诉求登程 ，利用云化或者云原生技术对立治理资源池，实现大数零碎产品、计算、存储资源池化，实现全局化、集约化的调度资源, 从而实现降本增效。 咱们再回到大数零碎云化架构上，产品和计算资源曾经能够通过Kubernetes实现资源池化治理，思考云化环境下实现存储能力的弹性诉求，依靠计算框架对底层存储的解耦合，参考对象存储在私有云上的实践经验，咱们把底层存储切换成分布式对象存储，这个架构选型上次要考量以下三点： 在公有云环境下，基于OpenStack、Swift、Ceph这些能够提供对象存储服务的开源软件架构曾经在生产实践了多年;开源生态的计算框架兼容对象存储服务；兼顾数据湖存储选型，而后咱们尝试了第三种云化架构。 云原生技术驱动下的大数零碎云化架构演进 3、第三套云化架构 为满足存储的弹性和海量存储的需要，咱们引入对象存储，为兼容私有云、公有云和现有其余成熟的对象存储服务，同时尽可能进步读写性能，在计算和底层存储之间咱们加上一层缓存（选型参考JuiceFS、Alluxio）。其中存储层，在私有云环境上间接选型私有云的对象存储，在公有云环境下选型OpenStack Swift、Ceph、MinIO等成熟的开源计划。 这套架构重点是从存储的角度，尝试革新零碎的存储架构，同时兼容现有的HDFS存储，相比之下更适宜在动静的云环境中落地，实现利用、计算、存储三层弹性可扩缩。目前这套架构还在外部性能测试中，如下是们其中一组性能测试数据（大文件词频统计），加上性能和缓存优化后的存储性能合乎预期。 总结和瞻望参考云原生基金会（CNCF）对云原生的定义，“云原生技术有利于各组织在私有云、公有云和混合云等新型动静环境中，构建和运行可弹性扩大的利用”，从定义上看跟咱们大数零碎云化的需要不约而同。 利用容器化、服务网格、微服务、申明式API等云原生技术，实现在私有云、公有云和混合云等云化环境下构建和运行弹性可扩大的大数据系统，这是咱们对大数据云原生的了解，也是咱们拥抱大数据系统云原生的形式。 明天通过三个具体的大数零碎云化架构，给大家出现一个残缺的架构过程，心愿能给大家带去思考和帮忙。而后咱们再回到结尾那个问题，云原生大数据技术是否是新一代大数据处理技术，置信大家曾经有了本人的答案。 每一代大数据技术根本都是为了解决上一代技术存在的问题，云原生的方法论和技术路线符合了大数据系统云化过程中求弹性、求扩大的诉求，对大数据系统云化具备领导和实际意义。当然云原生不是银弹，只有联合本身业务零碎的倒退诉求，能力更好的享受其带来的红利。 最初做一点瞻望，因为种种限度和云化技术积攒不平衡（私有云的技术积攒大于公有云、混合云）等起因，私有云和公有云混合架构场景有待进一步摸索和实际。数据湖和大数据云原生的架构出现一种架构交融的趋势，咱们会在云原生的湖仓一体的新型交融架构上做更多的尝试，谢谢大家。 数栈是云原生—站式数据中台PaaS，咱们在github和gitee上有一个乏味的开源我的项目：FlinkX，FlinkX是一个基于Flink的批流对立的数据同步工具，既能够采集动态的数据，也能够采集实时变动的数据，是全域、异构、批流一体的数据同步引擎。大家喜爱的话请给咱们点个star！star！star！ github开源我的项目：https://github.com/DTStack/fl... gitee开源我的项目：https://gitee.com/dtstack_dev...

备份数据shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql--flush-logs, -F：转存数据文件前刷新MySQL服务日志，在数据目录生成一个新的二进制日志文件。通常与--lock-all-tables，-master-data或--single-transaction一起应用。 --master-data[=value]：使转存的数据文件蕴含 CHANGE MASTER TO 语句，该语句表明了服务器的二进制日志文件名和地位。默认值为1，该语句不以正文的模式写入，并在从新加载转存的数据文件时执行。如果值为2，则以正文的模式写入，从新加载转存的数据文件时不会执行。因而生成的 .sql 转存文件包含以下几行： -- Position to start replication or point-in-time recovery from-- CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.000007',MASTER_LOG_POS=4;--master-data选项会主动敞开--lock-tables，并且关上--lock-all-tables，除非同时指定了--single-transaction，则在转存开始时在短时间内取得全局读锁定。 --single-transaction：对于反对事务的表如InnoDB表，此选项会将事务隔离级别设置为：REPEATABLE READ。并在备份前执行 START TRANSACTION 语句，让整个数据在备份过程中保障一致性，且不会锁表和阻塞其余应用程序。然而该选项不能保障MyISAM表和MEMORY表的数据一致性。 备份过程中应防止其余链接应用以下语句：ALTER TABLE，CREATE TABLE，DROP TABLE，RENAME TABLE，TRUNCATE TABLE，事务并不能隔离以上的语句，可能会导致备份的内容不正确或失败。 该选项与--lock-tables选项互斥，要备份大表，应该将--single-transaction选项与--quick选项联合应用。 --all-databases：备份所有库和表。 --delete-master-logs：执行备份操作后，向服务器发送 PURGE BINARY LOGS 语句来删除二进制日志。此选项会主动启用--master-data。 复原数据shell> mysql < backup_sunday_1_PM.sqlshell> mysqlbinlog gbichot2-bin.000007 gbichot2-bin.000008 | mysqlshell> mysqlbinlog gbichot2-bin.000009 ... | mysql备份策略始终应用--log-bin选项或--log-bin=log_name选项运行MySQL服务器。定期应用mysqldump命令进行残缺备份。定期应用 FLUSH LOGS 或 mysqladmin flush-logs 命令刷新日志进行增量备份。参考：https://dev.mysql.com/doc/mys... ...

物理备份由存储数据库内容的目录和文件的正本组成，实用于大型数据库。 长处是备份速度快，复原速度快，体积小。 如果数据库正在运行，须要先执行锁定，避免在备份期间更改数据库内容。 InnoDB 类型的表或其余类型的表能够应用 MySQL 企业版备份的 mysqlbackup 工具，MyISAM 表能够应用文件系统的命令（如：cp, scp, tar, rsync等）。 逻辑备份通过查询数据库服务器，取得数据库建表语句和插入语句组成，实用于数据量少的数据库。 毛病是备份速度较慢，复原速度较慢，体积较大，并且须要服务器失常运行才能够执行逻辑备份。 长处是备份级别可控。 逻辑备份实用于任何存储引擎，工具包含 mysqldump 和 SELECT ... INTO OUTFILE 语句。 快照备份在给定的工夫点提供文件系统的逻辑正本，而无需整个文件系统的物理正本。 MySQL自身不提供获取文件系统快照的性能。它能够通过Veritas，LVM或ZFS等第三方解决方案取得。

作者：莫善 某互联网公司高级 DBA。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 本文目录 一、导读 二、背景 三、剖析 四、注释 五、写在最初 一、导读DBA【MySQL DBA】，其余 DBA 不在本文探讨范畴。 DDL【ALTER TABLE】，其余操作不在本文探讨范畴。 OMM【Only Modifies Metadata】。 NOMM【Not Only Modifies Metadata】。 二、背景嘟！嘟！嘟！ 你好，我今晚要上线新性能，有个改表帮我解决一下呗。 你好，我有个亿级（十亿）表，须要加个字段/索引帮我解决一下呗。 你好，我刚加了一个字段，小表半小时还没加完，而且当初如同写不了数据。 DBA 们应该常常会接到这种需要吧。 DDL 操作可能是 DBA 最头疼的一项工作之一，也是最日常的一项工作了。动不动就要加个字段，扩个长度。如果可怜后期设计不合理的零碎，那前期保护起来就真的是叫爹骂娘的问候。如果又可怜是接盘跑了八百年的业务表须要上线新性能加一两字段或者扩个长度啥的，几乎酸爽到飞。 MySQLL 5.6 开始反对 OnlineDDL，美美地敲了回车，等半天还是没反馈，撸了一把又一把，业务催了一遍又一遍，猥琐发育都二胎了，就是没完结，在三胎之后终于跑完了，而后你就躺下刷了会手机，想找点刺激辞别致力工作的一天，后果发现又是绿油油的一天，怒扔手机睡觉去了，未曾想刚酝酿了一会睡意，麻烦又来了。 业务疯狂的打电话，很不愿意的接通了。业务反馈很多订单返回的数据都有问题。机智的你猜到了必定是改表导致了提早，业务还是一顿吐槽，吧啦吧啦说一大堆，还得起来把读流量切到主库，有没有很酸爽。 为啥会这样呢，咱们就来掰扯掰扯这个问题。 MySQL 的 DDL 操作次要有两种形式 copy 和 inplace。copy 表须要全程锁表，对业务影响极大，inplace 不阻塞 dml 操作。然而 MySQL 5.6 推出 OnlineDDL 以前，根本干啥 copy，干啥啥不行，干啥啥锁表。5.6 版本推出 OnlineDDL，DBA 们几乎爱的不要不要了。然而 inplace？就真的很爱了吗。别忘了，inplace 分为 rebuild 和 no-rebuild，这就能解释了为啥很多操作还是很慢了。起因就是：【Not Only Modifies Metadata】。 既然 OnlineDDL 还是有那么多问题，那咱们该咋整呢？这还只是一个 DDL 操作，如果很多呢，几十上百个 DDL 需要，是不是要疯，枸杞红枣肾宝片是不是得搞起来了。然而别慌，还有后招。生存是很美妙的，比方骑上小电驴就能够送外卖了。 ...

主从复制解决的问题数据分布：通过复制将数据分布到不同地理位置负载平衡：读写拆散以及将读负载到多台从库备份：可作为实时备份高可用性：利用主主复制实现高可用复制原理复制的原理其实很简略，仅分为以下三步： 在主库上把数据更改记录到二进制日志binary log中，具体是在每次筹备提交事务实现数据更新前，主库将数据更新的事件记录到二进制日志中去，Mysql会依照事务提交的程序来记录二进制日志的。日志记录好之后，主库告诉存储引擎提交事务。从库会启动一个IO线程，该线程会连贯到主库。而主库上的binlog dump线程会去读取主库本地的binlog日志文件中的更新事件。发往从库，从库接管到日志之后会将其记录到本地的中继日志relay-log当中。从库中的SQL线程读取中继日志relay-log中的事件，将其重放到从库中。（在5.6版本之前SQL线程是单线程的，使得主从之间提早更大）两种复制形式日志文件中记录的到底是什么呢？mysql反对了两种日志格局，这两种日志格局也体现了各自的复制形式 基于语句复制基于语句的复制相当于逻辑复制，即二进制日志记录了操作的语句，通过这些语句在从库进行重放来实现复制。 这种形式简略，二进制日志占用空间少，使得带宽小传输效率较高。然而基于语句的更新依赖于其余因素，比方插入数据时利用工夫戳函数调用以后工夫作为工夫值也会呈现问题，因为因为主从之间的提早导致工夫值不统一。存储过程和触发器也可能呈现问题。 所以在开发当中咱们应该将逻辑尽量放在代码层，而不应放到mysql中，不易扩大。 基于行复制基于行的复制相当于物理复制，即二进制日志记录了理论更新数据的每一行。这样导致行复制的压力比拟大，因为日志占用空间较大，传输占用带宽也较高。然而比基于语句复制更加准确，能够屏蔽一些因为主库从库之间的差别导致的不统一。如方才提到的工夫戳函数。 二者比照：语句复制传输效率高，缩小提早。在从库更新不存在的记录时，语句赋值不会失败。而行复制会导致失败，从而更早发现主从之间的不统一。设表里有一百万条数据，一条sql更新了所有表，基于语句的复制仅须要发送一条sql，而基于行的复制须要发送一百万条更新记录行复制不须要执行查问打算。不晓得执行的到底是什么语句。例如一条更新用户总积分的语句，须要统计用户的所有积分再写入用户表。如果是基于语句复制的话，从库须要再一次统计用户的积分，而基于行复制就间接更新记录，无需再统计用户积分。 因为两种形式各有优缺点，所以mysql在这两种复制模式进行动静的切换。默认是语句。 配置要点# 如果在双主复制构造中没有设置ID的话就会导致循环同步问题server_id=1# 即日志中记录的是语句还是行更新或者是混合binlog_format=mixed# 在进行n次事务提交当前，Mysql将执行一次fsync的磁盘同步指令。将缓冲区数据刷新到磁盘。# 为0的话由Mysql本人管制频率。sync_binlog=n# 为0的话，log buffer将每秒一次地写入log file中并且刷新到磁盘。# mysqld过程解体会失落一秒内的所有事务。# 为1的话，每次事务log buffer会写入log file并刷新到磁盘。（较为平安）# 在解体的时候,仅会失落一个事务。# 为2的话，每次事务log buffer会写入log file，但一秒一次刷新到磁盘innodb_flush_logs_at_trx_commit=0# 阻止从库解体后主动启动复制，给一些工夫来修复可能的问题，# 解体后再主动复制可能会导致更多的问题。并且自身就是不统一的skip_slave_start=1 # 是否将从库同步的事件也记录到从库本身的bin-log中# 容许备库将重放的事件也记录到本身的二进制日志中去，能够将备库当做另外一台主库的从库log_slave_update # 日志过期删除工夫，提早重大的话会导致日志文件占用磁盘expire_logs_days=7innodb_flush_logs_at_trx_commit的三个参数很容易弄混。以下是具体的解析： mysql先将日志写到log buffer缓冲区当中，再将log buffer缓冲区的数据写到log file日志文件中，此时写入的是内存中的log file，最终仍需操作系统将内存中的数据刷写到磁盘上。参数0：mysql每秒都会将log buffer的数据写入到log file中并且刷新到磁盘。意味着mysql解体的时候将会失落一秒内的所有事务。参数1：每次事务提交都会将log buffer写入到log file并刷新到磁盘。意味着在mysql解体的时候,仅会失落一个事务。参数2：每次事务提交都会将log buffer写入到log file但不同时写入到磁盘，由mysql自行管制每秒将log file刷写到磁盘上，当mysql解体的时候操作系统没解体的时候，log_file中仅会失落一个事务，操作系统仍会将log file刷写到磁盘，而如果操作系统也解体或断电的话，则会失落一秒内的事务。举荐应用： innodb_flush_logs_at_trx_commit=2sync_binlog=500性能会较快 innodb_flush_logs_at_trx_commit=1sync_binlog=1较为平安 提早问题提早的产生当主库的TPS并发较高时，因为主库下面是多线程写入的，而从库的SQL线程是单线程的，导致从库SQL可能会跟不上主库的处理速度（生产者比消费者快，导致商品沉积）。 提早的解决网络方面：将从库散布在雷同局域网内或网络提早较小的环境中。硬件方面：从库配置更好的硬件，晋升随机写的性能。配置方面：从库配置 sync_binlog=0innodb_flush_log_at_trx_commit=2logs-slave-updates=0增大 innodb_buffer_pool_size让更多操作在Mysql内存中实现，缩小磁盘操作。或者降级Mysql5.7版本应用并行复制。 架构方面：比方在事务当中尽量对主库读写，其余非事务中的读在从库。打消一部分提早带来的数据库不统一。减少缓存升高一些从库的负载。笔者集体心得，如有谬误恳请网友评论斧正。 起源：juejin.cn/post/6844903968259178504

前言： 在平时工作中，常常会遇到数据迁徙的需要，比方要迁徙某个表、某个库或某个实例。依据不同的需要可能要采取不同的迁徙计划，数据迁徙过程中也可能会遇到各种大小问题。本篇文章，咱们一起来看下 MySQL 数据迁徙那些事儿，心愿能帮忙到各位。 1.对于数据迁徙首先援用下维基百科中对数据迁徙的解释： 数据迁徙（data migration）是指抉择、筹备、提取和转换数据，并将数据从一个计算机存储系统永恒地传输到另一个计算机存储系统的过程。此外，验证迁徙数据的完整性和服役原来旧的数据存储，也被认为是整个数据迁徙过程的一部分。数据迁徙是任何零碎实现、降级或集成的要害思考因素，通常以尽可能自动化的形式执行，从而将人力资源从繁琐的工作中解放出来。数据迁徙有多种起因，包含服务器或存储设备更换、保护或降级、应用程序迁徙、网站集成、劫难复原和数据中心迁徙。对于 MySQL 数据库，也会常常碰到数据迁徙的需要，比如说从测试库迁到开发库，或者从一台机器迁徙到另一台机器，可能只是迁徙一张表，也可能须要迁徙整个数据库实例。对于不同的需要可能要采取不同的迁徙计划，但总体来讲，MySQL 数据迁徙计划大抵能够分为物理迁徙和逻辑迁徙两类。 2.迁徙计划及留神点物理迁徙实用于大数据量下的整体迁徙。物理迁徙包含拷贝数据文件和应用 XtraBackup 备份工具两种。不同服务器之间能够采纳物理迁徙，咱们能够在新的服务器上安装好同版本的数据库软件，创立好雷同目录，倡议配置文件也要和原数据库雷同，而后从原数据库方拷贝来数据文件及日志文件，配置好文件组权限，之后在新服务器这边应用 mysqld 命令启动数据库。 应用物理迁徙计划的长处是比拟疾速，但须要停机迁徙并且要求 MySQL 版本及配置必须和原服务器雷同，也可能引起未知问题。 相比来说，逻辑迁徙适用范围更广，无论是局部迁徙还是全量迁徙，都能够应用逻辑迁徙。逻辑迁徙中应用最多的就是通过 mysqldump 等备份工具导出再导入了。 mysqldump 同样实用于不同版本不同配置之间的迁徙，不过全量迁徙时，笔者不倡议应用 -A 参数备份全副数据库，特地是对于不同版本之间迁徙，可能某些零碎库稍有不同，迁徙后容易呈现未知问题。若应用 mysqldump 进行全量迁徙，能够依照上面步骤操作： # 原库执行 失去的创立数据库语句在新库执行 (排除零碎库)SELECT CONCAT( 'CREATE DATABASE IF NOT EXISTS ', '`', SCHEMA_NAME, '`', ' DEFAULT CHARACTER SET ', DEFAULT_CHARACTER_SET_NAME, ';' ) AS CreateDatabaseQuery FROM information_schema.SCHEMATA WHERE SCHEMA_NAME NOT IN ( 'information_schema', 'performance_schema', 'mysql', 'sys' ); # 原库执行 失去的创立用户语句在新库执行 (排除零碎用户) SELECT CONCAT( 'create user \'', USER, '\'@\'', HOST, '\'' ' IDENTIFIED BY PASSWORD \'', authentication_string, '\';' ) AS CreateUserQuery FROM mysql.`user` WHERE `User` NOT IN ( 'root', 'mysql.session', 'mysql.sys' ); # 原库执行 show grants 失去用户权限 而后逐个在新库执行 （也能够复制那几张权限表到新库）show grants for 'testuser'@'%';# 至此 新环境曾经存在要迁徙的库和用户 只是没有数据# 原环境应用mysqldump备份除零碎库外的所有库 mysqldump -uroot -pxxxx -R -E --single-transaction --databases db1 db2 > db.sql# 而后导入新环境mysql -uroot -pxxxx < db.sql对于迁徙局部库和局部表，也能够采纳上方相似计划，只是备份时要按需备份，上面列举出几种常见的 mysqldump 备份场景： ...

1.drop,delete与truncate的区别相同点：truncate和不带where子句的delete,以及drop都会删除表内的数据 不同点：truncate会革除表数据并重置id从1开始,delete就只删除记录,drop能够用来删除表或数据库并且将表所占用的空间全副开释truncate和delete只删除数据不删除表的构造。drop语句将删除表的构造被依赖的约(constrain),触发器(trigger),依赖于该表的存储过程/函数将保留,然而变为 invalid 状态。速度上一般来说: drop> truncate > delete应用上,想删除局部数据行用 delete，想删除表用 drop,想保留表而将所有数据删除，如果和事务无关，用truncate即可。如果和事务无关,或者想触发trigger,还是用delete。delete是DML语句,不会主动提交。drop/truncate都是DDL语句,执行后会主动提交。2.mysql里记录货币用什么字段类型好NUMERIC 和DECIMAL 类型被MySQL实现为同样的类型，这在SQL92规范容许。他们被用于保留值，该值的精确精度是极其重要的值，例如与金钱无关的数据。 DECIMAL和NUMERIC值作为字符串存储，而不是作为二进制浮点数，以便保留那些值的小数精度。 3.MySQL中myisam与innodb的区别InnoDB反对事务，而MyISAM不反对事务InnoDB反对行级锁，而MyISAM反对表级锁InnoDB反对MVCC, 而MyISAM不反对InnoDB反对外键，而MyISAM不反对InnoDB不反对全文索引，而MyISAM反对。InnoDB不能通过间接拷贝表文件的办法拷贝表到另外一台机器， myisam 反对InnoDB表反对多种行格局， myisam 不反对InnoDB是索引组织表， myisam 是堆表4.事务的四个个性及含意数据库事务transanction正确执行的四个基本要素：ACID,原子性(Atomicity)、一致性(Correspondence)、隔离性(Isolation)、持久性(Durability)。 原子性: 整个事务中的所有操作，要么全副实现，要么全副不实现，不可能停滞在两头某个环节。事务在执行过程中产生谬误，会被回滚（Rollback）到事务开始前的状态，就像这个事务素来没有执行过一样。 一致性: 在事务开始之前和事务完结当前，数据库的完整性束缚没有被毁坏。 隔离性: 隔离状态执行事务，使它们如同是零碎在给定工夫内执行的惟一操作。如果有两个事务，运行在雷同的工夫内，执行 雷同的性能，事务的隔离性将确保每一事务在零碎中认为只有该事务在应用零碎。这种属性有时称为串行化，为了避免事务操作间的混同，必须串行化或序列化请 求，使得在同一时间仅有一个申请用于同一数据。 持久性: 在事务实现当前，该事务所对数据库所作的更改便长久的保留在数据库之中，并不会被回滚。 5.MYSQL相比于其余数据库有哪些特点？MySQL是一个小型关系型数据库管理系统，开发者为瑞典MySQL AB公司，当初曾经被Sun公司收买，反对FreeBSD、Linux、MAC、Windows等多种操作系统与其余的大型数据库例如Oracle、DB2、SQL Server等相比性能稍弱一些。其特点有： 能够解决领有上千万条记录的大型数据；反对常见的SQL语句标准；可移植行高，安装简单玲珑；良好的运行效率，有丰盛信息的网络反对；调试、治理，优化简略（绝对其余大型数据库）。6.视图的作用，视图能够更改么?视图是虚构的表，与蕴含数据的表不一样，视图只蕴含应用时动静检索数据的查问;不蕴含任何列或数据。应用视图能够简化简单的sql操作，暗藏具体的细节，爱护数据;视图创立后，能够应用与表雷同的形式利用它们。 视图不能被索引，也不能有关联的触发器或默认值，如果视图自身内有order by 则对视图再次order by将被笼罩。 7.存储过程与触发器的区别触发器与存储过程十分类似，触发器也是SQL语句集，两者惟一的区别是触发器不能用EXECUTE语句调用，而是在用户执行Transact-SQL语句时主动触发(激活)执行。 触发器是在一个批改了指定表中的数据时执行的存储过程。通常通过创立触发器来强制实现不同表中的逻辑相干数据的援用完整性和一致性。因为用户不能绕过触发器，所以能够用它来强制施行简单的业务规定，以确保数据的完整性。 触发器不同于存储过程，触发器次要是通过事件执行触发而被执行的，而存储过程能够通过存储过程名称名字而间接调用。当对某一表进行诸如UPDATE、INSERT、DELETE这些操作时，SQLSERVER就会主动执行触发器所定义的SQL语句，从而确保对数据的解决必须合乎这些SQL语句所定义的规定。 8.索引的作用？和它的长处毛病是什么？索引就是一种非凡的查问表，数据库的搜索引擎能够利用它减速对数据的检索。它很相似与现实生活中书的目录，不须要查问整本书内容就能够找到想要的数据。 索引能够是惟一的，创立索引容许指定单个列或者是多个列。毛病是它减慢了数据录入的速度，同时也减少了数据库的尺寸大小。 9.union 与union all的区别union 在进行表连贯后会筛选掉反复的记录，所以在表连贯后会对所产生的后果集进行排序运算，删除反复的记录再返回后果。union all 则会显示反复后果,只是简略的两个后果合并并返回.所以效率比union高,在保障没有反复数据的状况下用union all. 10. SQL语言包含哪几局部？每局部都有哪些操作关键字？SQL语言包含数据定义(DDL)、数据操纵(DML),数据管制(DCL)和数据查问（DQL）四个局部。 数据定义：Create Table,Alter Table,Drop Table, Craete/Drop Index等数据操纵：Select ,insert,update,delete,数据管制：grant,revoke数据查问：select起源：blog.csdn.net/Black1499/article/details/84945702

我这里下载了mysql 8 的zip版本 下载Mysql下载地址（https://dev.mysql.com/downloa...抉择操作系统 microsoft Windows有两个下载选项 Recommended Download:（下载安装版） 抉择上面的那个Other Downloads:（下载解压缩版本） 抉择第一个下载完后解压到对应目录即可 配置点击环境变量中的path：输出D:\DevEvironment\mysql-8.0.24-winx64\bin（bin目录）在D:\DevEvironment\mysql-8.0.24-winx64（装置目录）下新建my.ini文件,按正文要求批改即可 [mysql]# 设置mysql客户端默认字符集default-character-set=utf8[mysqld]#设置3306端口port = 3306# 设置mysql的装置目录basedir=D:\\DevEvironment\\mysql-8.0.24-winx64# 设置mysql数据库的数据的寄存目录datadir=D:\\DevEvironment\\mysql-8.0.24-winx64\\data# 容许最大连接数max_connections=200# 服务端应用的字符集默认为UTF8character-set-server=utf8# 创立新表时将应用的默认存储引擎default-storage-engine=INNODB留神点：门路要应用\\,不然没用 而后以管理员形式关上powershell或者cmd都能够，必须是管理员权限，否则会提醒回绝，权限不够输出 mysqld --initialize ,须要点工夫，期待即可输出mysqld install ，显示Service successfully installed.输出net start mysql，显示即胜利启动mysql 如果有失败的中央，则执行执行 mysqld -remove命令将以前的谬误装置删除，否则会提醒曾经装置，而后反复上述步骤 留神点：data目录不须要手动建，mysqld --initialize 会主动创立 批改初始密码 以管理员形式进入cmd或者powershell进入bin目录， cd D:\DevEvironment\mysql-8.0.24-winx64\bin敞开mysql服务，net stop mysql跳过Mysql明码验证，mysqld --console --skip-grant-tables --shared-memory上个窗口不要关（处于阻塞状态），以管理员形式新开一个控制台窗口进入bin目录， cd D:\DevEvironment\mysql-8.0.24-winx64\bin输出mysql -u root -p会提醒输出明码，间接回车，不必输出明码，会进入mysql脚本模式use mysql; 回车update user set authentication_string='' where user='root'; （注：‘’明码为空）而后退出quit敞开前一个窗口！！顺次输出net stop mysql、net start mysql而后输出mysql -u root -p 而后回车（明码下面曾经设置为空），再回车输出ALTER USER 'root'@'localhost' IDENTIFIED BY '新密码';（本人设定明码）quit，而后验证一下，输出mysql -u root -p新密码 （留神p和新密码没有空格）或者mysql -u root -p 而后回车，输出新密码，再回车显示mysql>就胜利了，进入了mysql脚本模式，exit即可后续待更新 ...

类型mysql的类型定义中，整形类型括号里的数字，指的是显示位数，与存储大小无关对于varchar和char，前者是可变长，后者固定，其中的数字都代表字符长度，char的长度在0~255，varchar存储字节数在0~65535.如果某个数据表里的数据行的长度是可变的，那么，为了节约存储空间，MySQL会把这个数据表里的固定长度类型的数据列转换为相应的可变长度类型． 例外：长度小于４个字符的char数据列不会被转换为varchar类型explain的应用id：查问程序是从大到小顺次查问，id雷同时从上到下查问，id能够为空，当且仅当 select_type为 UNION_RESULTtype：const和eq_ref都上用了主键或者惟一索引，它们的区别是const是只查一次就失去后果，而eq_ref要匹配屡次，因为有多条记录。possible_keys可能为null，然而key不为null，起因就是应用了全索引扫描。key_len:示意应用了索引的长度。长度由三个因素决定： 字符集长度是否为空字段类型占用字节数char(n)nvarchar(n)n+2tinyint1smallint2int4bigint8date3timestamp4datetime8如果字段容许空则还要加一个字节。如果有一个索引是联结索引 (a,b) a、b都是varchar(30)非null，编码是UTF8 那么如果索引都用上 长度为30*3+2+30*3+2=184 3是utf8占用3个字节 innodb存储引擎构造：分为聚簇索引和非聚簇索引，其中，除了主键之外，其余索引都是非聚簇索引。用的是B+树。为什么用B+树，而不是其余构造？先看看个别有什么构造：哈希表 一种以key-value键值对存储数据的构造，通过散列运算，将hash后果作为文件指针，能够从索引文件中取得数据的文件指针，再到数据文件中获取到数据，依照这种构造，咱们很快能定位进去某一条数据的地位，查问的效率十分高，那么它的问题点在哪呢，那就是不反对范畴查问，分页或者大于、小于某个范畴的查问都是无奈反对的，只能反对固定的字段名 = 目标值的场景，同样也不适宜Like这种含糊查问，所以这种算法必定是不适宜作为数据库的索引的。不同的key值通过哈希函数运算，可能会呈现雷同的值，这个时候咱们称为哈希抵触。解决哈西抵触，咱们能够用链地址法，即把所有雷同的值放到一个链表里，这样无论有多少抵触，只是减少了链表的长度而已。有序列表 查找和更新十分快，然而插入、删除代价很高，须要挪动前面的全副数据适宜做动态存储的索引，即不会批改的数据。树 二叉树二叉树的长处是查找速度十分快，工夫复杂度是O(log2(n))，然而会呈现左倾或者右倾的问题而进化成链表；其次，因为一个节点只能有两个子节点，导致树的高度会变得十分高，在查问的时候须要屡次遍历，这样磁盘扫描会十分多，导致查问所需工夫减少。均衡二叉树：红黑树 红黑树是一种均衡二叉树，它继承了二叉树的长处，由解决了二叉树遇到的自增数据索引生效的问题，因为红黑树的会对树的构造进行调整，进行左旋或者右旋及色彩变换等操作，始终保障 左子节点数<父节点数<右子节点数因为一个节点只能有两个子节点，在数据量大的时候导致树的高度会变得十分高，在查问的时候须要屡次遍历，在磁盘寻址的时候十分不利，也是相当耗时的。查问效率不稳固，查问在根节点和在子节点相差很大。节点存储的数据太少，不能很好的利用操作系统和磁盘数据交换的个性，也没有很好的利用磁盘IO预读能力。操作系统和磁盘之间一次数据交换是以页为单位的，一页等于4k，也就是每次IO交互操作系统会将4K的数据加载到内存中，然而在二叉树的每个节点的构造中只保留了一个关键字，一个数据区，两个子节点的援用，并不可能填满4K的数据量，也就是辛辛苦苦做了一次IO操作，却只加载了一个关键字，在数的高度很高，搜寻的数据又是在叶子节点，取一个关键字须要做很屡次的IOB树（多路均衡查找树（Balance Tree）） B Tree是一个相对均衡树，所有的叶子节点在同一个高度 下面的这个树是一个 2-3树（每个节点存储2个关键字，有3路），每个节点保留的关键字个数和路数关系为：关键字个数=路数-1Mysql为了能更好的利用磁盘的预读能力，将页的大小设置为16K，就是将一个节点（磁盘块）的大小设置为16K，一次IO将一个节点（16K）内容加载到内存中，假如关键字的类型是int，4个字节，每个关键字对应的数据区也为4个字节，不思考子节点利用的状况下，上图中每个节点大概可能存储（16*1000）/8 = 2000个关键字，那么对应的就是2001个路数，对于这种有2001个路数的B树，三层的高度可能搜寻到的关键字的个数是远远大于一般的二叉树的。在B树放弃树的均衡的过程中，每次关键字的变动都会导致构造产生很大的变动，这个过程是特地浪费时间的。所以创立索引肯定要创立适合的索引，而不是把所有的字段都建设索引。B+树 B+树是B树的一个变种，它不再遵循 关键字个数=路数-1 这个规定，数据的检索规定是采纳的左闭合取件，路数和关键字的个数关系为1:1 B+树中的根结点和支节点中没有数据区，关键字对应的数据只保留在叶子节点中，所以只有叶子节点中的关键字数据区才会保留真正的数据内容或者数据对应的地址，然而在B树中，如果根结点命中，是间接返回的，B+树中，叶子节点不会保留子节点的援用B+树的叶子节点是顺序排列的，并且相邻节点之间是程序援用的关系，叶子节点之间通过指针相连B树能解决的问题，B+树都能解决，且可能更好的解决，升高了树的高度，减少节点的数据存储量。B+树的扫库和扫表能力更强，如果依据索引去对数据表扫描，B树须要整颗树遍历，B+树只须要遍历所有的叶子节点B+树的磁盘读写能力更强，根结点和支节点不保留数据区，所有的根结点和支节点在同样大小的状况下，保留的关键字更多，叶子结点不存子节点的援用，所以，B+树读写一次磁盘加载的关键字更多B+树具备人造排序功能，而且查问效率更加稳固，查问IO的次数是稳固的以上就是抉择B+树的起因。而聚簇索引和非聚簇索引的区别在于，聚簇索引会把整行数据都保留，非聚簇索引只保留索引相干字段数据，还有主键的地址。因而个别状况下，如果非聚簇索引不是笼罩索引，须要回表查找，能力失去须要的后果。 事务事务隔离级别与锁 一共有以下四种隔离级别 未提交读：会呈现脏读问题，即读到别的事务没有提交的数据。提交读：解决了脏读问题，然而会呈现不可反复读，就是在事务查问前后，如果别的事务提交了数据，会失去不一样后果。可反复读：解决了不可反复读，然而会呈现幻读，即查问前后，如果别的事务插入了数据，会导致插入雷同数据的时候报错，就像查问是假的，呈现了幻觉一样。串行化：齐全串行化的读，每次读都须要取得表级共享锁，读写互相都会阻塞不可反复读和幻读的区别：前者重点在于update和delete，后者重点在于insert。锁的类型有很多，分类领域也有很多，上面依据不同的分类简略形容一下。 乐观锁和乐观锁 乐观锁 正如其名，它指的是对数据被外界（包含本零碎以后的其余事务，以及来自内部零碎的事务处理）批改持激进态度，因而，在整个数据处理过程中，将数据处于锁定状态。 在乐观锁的状况下，为了保障事务的隔离性，就须要一致性锁定读。读取数据时给加锁，其它事务无奈批改这些数据。批改删除数据时也要加锁，其它事务无奈读取这些数据。乐观锁 绝对乐观锁而言，乐观锁机制采取了更加宽松的加锁机制。乐观锁大多数状况下依附数据库的锁机制实现，以保障操作最大水平的独占性。但随之而来的就是数据库性能的大量开销，特地是对长事务而言，这样的开销往往无奈接受。 乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据减少一个版本标识，在基于数据库表的版本解决方案中，个别是通过为数据库表减少一个 “version” 字段来实现。读取出数据时，将此版本号一起读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的以后版本信息进行比对，如果提交的数据版本号大于数据库表以后版本号，则予以更新，否则认为是过期数据。共享锁与排它锁 共享锁 也叫读锁，简称S锁，原理：一个事务获取了一个数据行的共享锁，其余事务能取得该行对应的共享锁，但不能取得排他锁，即一个事务在读取一个数据行的时候，其余事务也能够读，但不能对该数据行进行增删改 设置共享锁：SELECT ... LOCK IN SHARE MODE排它锁 也叫写锁，简称x锁，原理：一个事务获取了一个数据行的排他锁，其余事务就不能再获取该行的其余锁（排他锁或者共享锁），即一个事务在读取一个数据行的时候，其余事务不能对该数据行进行增删改查 设置排他锁：SELECT ... FOR UPDATE动向共享锁和动向排它锁 动向共享锁，简称IS，其作用在于：告诉数据库接下来须要施加什么锁并对表加锁。如果须要对记录A加共享锁，那么此时innodb会先找到这张表，对该表加意向共享锁之后，再对记录A增加共享锁。 动向排他锁，简称IX，其作用在于：告诉数据库接下来须要施加什么锁并对表加锁。如果须要对记录A加排他锁，那么此时innodb会先找到这张表，对该表加意向排他锁之后，再对记录A增加排他锁。 动向共享锁和动向排他锁都是零碎主动增加和主动开释的，整个过程无需人工干预。 多个意向锁能够和行级锁共存，因为意向锁的作用是为了对须要给表加锁的时候，更高效的解决是否加锁的解决，对行锁没有影响。自增锁(AUTO-INC Locks) 非凡表锁，自增长计数器通过该“锁”来取得子增长计数器最大的计数值。在insert完结后立刻开释。咱们能够执行show engine innodb statusG来查看自增锁的状态信息。在自增锁的应用过程中，有一个外围参数，须要关注一下，即innodb_autoinc_lock_mode,它有0、1、2三个值。放弃默认就行。具体的含意能够参考官网文档。 InnoDB锁关系矩阵如下，其中：+ 示意兼容，- 示意不兼容。两段锁协定 将事务分成两个阶段，加锁阶段和解锁阶段（所以叫两段锁） 加锁阶段：在该阶段能够进行加锁操作。在对任何数据进行读操作之前要申请并取得S锁（共享锁，其它事务能够持续加共享锁，但不能加排它锁），在进行写操作之前要申请并取得X锁（排它锁，其它事务不能再取得任何锁）。加锁不胜利，则事务进入期待状态，直到加锁胜利才继续执行。解锁阶段：当事务开释了一个封闭当前，事务进入解锁阶段，在该阶段只能进行解锁操作不能再进行加锁操作。下面咱们讲到，如果查问时用到了索引，是会给数据加上行锁，然而如果查问没有用到事务，这时候就是加上表锁。然而在实际操作中，mysql做了改良，当查问时，发现不属于过滤条件时，就会调用unlock_row办法，将不满足条件的记录开释锁 (违反了二段锁协定的束缚)。 这样做，保障了最初只会持有满足条件记录上的锁，然而每条记录的加锁操作还是不能省略的。可见即便是MySQL，为了效率也是会违反标准的。（参见《高性能MySQL》中文第三版p181）行锁、gap锁和next-key锁 ...

上午刚工作10分左右，共事说在应用jira时呈现问题，具体截图如下： 通过上图的报错信息：定位为 mysql 数据库连接数的问题。 解决办法1.登录mysql进行查看 Mysql –uroot –p123456mysql> show variables like'%max_connections%';+-----------------+-------+| Variable_name | Value |+-----------------+-------+| max_connections | 151 |+-----------------+-------+1 row in set (0.00 sec)很奇怪，最大连接数怎么是151呢，mysql默认的最大连接数不是100么？ 起初想一下可能是版本不同的问题，默认连接数也不同。为了确认mysql5.5.3默认的最大连接数为151，去mysql官网查看了一下：mysql默认的最大连接数为151，下限为1000。另外，MySQL 系列面试题和答案我都整顿好了，关注公众号民工哥技术之路，在企业面试题专栏就能够查阅了。 2.批改mysql默认的最大连接数为1000 在/etc/my.cnf文件中（ 须要重启mysql服务） [mysqld]局部减少max_connections=1000mysql其余版本默认的最大连接数Mysql5.5、mysql5.6、mysql5.7：默认的最大连接数都是151，下限为：100000 Mysql 5.1 依据其小版本的不同，默认的最大连接数和可批改的连接数下限也有所不同。 批改mysql数据库默认的最大连接数办法一批改mysql的主配置文件/etc/my.cnf [mysqld]局部增加“max_connections=1000（这个依据理论的须要来进行设置即可）”重启MySQL服务 办法二mysql客户端登录，通过命令行批改全局变量来进行批改 mysql -uroot -p123456mysql> set global_max_connections = 200;mysql> show processlist;mysql> show status;批改实现后进行查看，mysql的最大连接数 mysql> show variables like '%max_connections%';+-----------------+-------+| Variable_name | Value |+-----------------+-------+| max_connections | 1000 |+-----------------+-------+1 row in set (0.00 sec)办法三解开mysql源代码，进入外面的SQL目录批改mysqld.cc找到上面一行： {"max_connections", OPT_MAX_CONNECTIONS, "The number of simultaneous clients allowed.", (gptr*) &max_connections, (gptr*) &max_connections, 0, GET_ULONG, REQUIRED_ARG, 100, 1, 16384, 0, 1, 0}, 把它改为： {"max_connections", OPT_MAX_CONNECTIONS, "The number of simultaneous clients allowed.", (gptr*) &max_connections, (gptr*) &max_connections, 0, GET_ULONG, REQUIRED_ARG, 1500, 1, 16384, 0, 1, 0},保留退出，而后./configure ;make;make install能够取得同样的成果 ...

一、数据库主从配置1.原理阐明1）当数据库主库执行更新操作时，会将更新的内容写入到二进制日志文件中，并且写日志的过程是一个异步的过程。2）从库会开启I/O线程去读取主库的二进制日志文件，之后写入到中继日志文件中（长期存取）3）从库开启SQL线程去读取中继日志文件，之后将数据同步到从库中。[注]上述操作是由从库向主库获取数据，所以实践上能够配置为无数个从库（一主多从）。

来自：21cto.com/article/2093当你意识到你在我的项目开始时做的轻量、简略的构想居然齐全错了时，你曾经用了六个月的工夫投入到这个我的项目上。当初你须要解决这些问题，能力让这个零碎持续运行上来，你发现你用在这个我的项目上的精力远远超出了你的预期，如果一开始就用正确的形式来做，就不会产生这样的事。明天，我要通知你的是一个常常犯的谬误，一个会给你带来无穷无尽的问题的单词，那就是“users”。这个单词有两个最根本的谬误： 对你的需要来说 “User” 简直素来都不是一个好的形容。“User” 会导致一个根本的设计平安缺点。“user” 的概念是模糊不清的，应用更精准的术语简直总是能起到更好的成果。你没有使用者最开始，没有任何一个软件系统真的有使用者存在。乍一看“user”是一个好的形容，然而你略微一想就会意识到你的业务逻辑实际上比这要简单的多。我会应用三个例子，从一个极其的状况登程。 机票预订零碎没有“users”我已经给机票预订零碎写过访问控制逻辑，上面只是一小部分需要： 旅客能够应用预约记录码通过网站查看预约信息。购买者能够通过信用卡号后四位数在网站上批改预订信息。旅行社能够查看和批改他们的预订。航空公司的值机人员能够依据角色和航空公司来查看和批改预订信息，这须要旅客提供身份信息。不再一一列举。一些与人类相干的基本概念是“旅客”，“代理”（网站也可是看作代理）和“购买者”。“user”这个概念基本没用，并且在许多申请中我基本不会应用这个单词，举个例子，咱们的申请必须包含旅客和代理人的证件，而不是使用者的证件。Unix 没有 “users”咱们看一个不太一样的例子。Unix （这些天被称为POSIX）有用户，他们能够登录并执行代码。这样看起来很不错吧？咱们深刻看一下。如果咱们把所有都当作“users”的话，咱们将会有：应用终端或者图形界面登录的人 像邮件或者web服务器这种零碎服务也会以“users”的身份运行，例如nginx能够以httpd用户运行。在服务器上常常会有多人共享一个管理员账号用来SSH登录（例如，亚马逊的Ubuntu虚拟机默认SSH账号就是‘ubuntu’)root 身份，和下面其余身份都不同。下面四个是简直不同的概念，然而在POSIX上他们都是 “users”. 一会儿咱们就会看到，把这些概念都称为‘user’会导致很多平安问题。在操作上，因为POSIX的用户模型边界存在，咱们甚至不能找到一种形式说“只能让 Alice 和 Bob 通过这个账号登录”。SaaS 服务提供商没有 “users”Jeremy Green 最近就用户模型在SaaS中的利用在推特上发文，它第一次揭示了我写下这篇文章，他的根本观点是SaaS 服务简直总是： 某个组织中的一个人领取服务费用。一个或多集体独特应用这个服务。如果你一开始就把这些人作为一个用户，你将会陷入一个苦楚的世界。你无奈建设团队模型，你无奈组建同时为多人领取的模型，而后你就会开始革新你的零碎。当初你在SaaS案例中学到了一课，咱们来看一看你的生存。然而这只是泛滥例子中的一个：“users”的概念太含糊了。如果你开始狐疑“user”这个词，最终你可能发现最终你其实只须要两个概念：团队（用来组织关系和领取）和成员（理论应用服务的人）。“Users” 是一个平安问题“user” 这个单词不仅是业务逻辑的问题，它也导致了一系列平安问题。“user” 这个单词如此的含糊以至于从根本上将两个概念合并了： 一个人。他们在软件中的代表性。为了阐明这个问题，假如你正在拜访一个居心不良的网站，在它服务器上的图片导致了你的浏览器内存溢出。近程网站管制着你的浏览器，并且开始将你的文件上传到他的服务上。为什么它能这样做？因为浏览器是以零碎用户的身份运行的，它被认为与人类身份的你雷同，实际上你们是不同的。 你作为’user’，不想上传文件。然而零碎的账号也是‘user’，可能上传文件，如果浏览器运行在你的账号之下，他所有的行为会被当作是你的用意，也就是说是你让它这么做的，实际上不是。这就是被称为Confused Deputy的问题。如果你应用“用户”这个词来形容两个基本不同的货色，那么这个问题就更有可能成为你设计的一部分。后期设计的价值花更少的功夫解决雷同的问题是成为高产程序员的要害。应用模糊不清的概念比方“用户”来组织你的软件，将会话费大量工夫和精力来解决将来产生的问题。一上来就开始编码看起来是高产的，事实恰好相反。下次你开始一个新的软件我的项目时，花几个小时预先确定你的术语和概念：你依然不会完全正确，但你会做得更好。将来的你将感激你所做的所有预防节约的工作。

1.下载MariaDB数据库测试: 以后虚拟机是否能够正确的链接外网.ping www.baidu.com跳转到指定目录（cd /usr/local/src） yum install mariadb-server 装置mariadb数据库yum clean all 清空已安装文件 如果下载失败之后执行的.2.数据库命令（基于centOS7） 1. 启动命令 systemctl start mariadb2. 重启命令 systemctl restart mariadb3. 敞开命令 systemctl stop mariadb4. 设定开机自起 systemctl enable mariadb 5. 敞开开机自起 systemctl disable mariadb 3.执行命令1,4之后，数据库服务启动。间接输出mysql。即可进入MySQL数据库没有用户名和明码：因而咱们要进行数据库初始化操作。mysql_secure_installation4.应用用户名，明码登录数据库5.查看数据库版本登录mysqlselect @@versionselect version()status未登录mysql --versionmysql -V6.Mysql数据库近程拜访配置阐明: 如果须要近程链接数据库必须通过防火墙如果近程链接数据库,数据库中必须开启近程拜访权限才行,否则回绝链接.登录mysql，而后应用mysql数据库，找到user表查问user表将host=“localhost” 改为 “%”update user set host = "%" where host ="localhost";刷新权限flush privileges;关上防火墙端口

MySQL定时备份数据库文章：https://www.jianshu.com/p/a8e...脚本执行失败的可能起因：https://blog.csdn.net/weixin_...查看备份时发现，cron中定时备份mysql的脚本备份失败，然而手动自行mysql备份脚本却能失常胜利，查看cron的环境变量： # cat /etc/crontab...SHELL=/bin/shPATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin...网上说能够查看零碎的Path，而后看看mysql的门路，而后用绝对路径执行muysqldump就行了，网上的命令：查看root用户的环境变量： # echo $PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/app/mysql/bin网上说比拟能够发现cron的环境变量少了/app/mysql/bin 解决办法：　在脚本中，对mysqldump命令应用绝对路径。 我查看root用户的环境变量并没有找到mysql相干bin的地位： echo $PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games于是通过whereis命令查找mysql相干内容的地位。找到之后批改配置文件.sh如下： #!/bin/bash#保留备份个数，备份2天数据number=2#备份保留门路backup_dir=/var/back#日期dd=`date +%Y-%m-%d-%H-%M-%S`#备份工具(重点留神)tool=/usr/bin/mysqldump#用户名username=root#明码password=****#将要备份的数据库database_name=article#如果文件夹不存在则创立if [ ! -d $backup_dir ]; then mkdir -p $backup_dir; fi#简略写法 mysqldump -u root -p123456 users > /root/mysqlbackup/users-$filename.sql$tool -u $username -p$password $database_name > $backup_dir/$database_name-$dd.sql#写创立备份日志echo "create $backup_dir/$database_name-$dd.dupm" >> $backup_dir/log.txt#找出须要删除的备份delfile=`ls -l -crt $backup_dir/*.sql | awk '{print $9 }' | head -1`#判断当初的备份数量是否大于$numbercount=`ls -l -crt $backup_dir/*.sql | awk '{print $9 }' | wc -l`if [ $count -gt $number ]then #删除最早生成的备份，只保留number数量的备份 rm $delfile #写删除文件日志 echo "delete $delfile" >> $backup_dir/log.txtfi而后crontab里配置定时工作 ...

场景介绍本场景介绍如何开明属于你的收费云数据库，在RDS-MySQL中实现对学生问题的详情 查问，执行指定类型SQL。 相干体验实验室开发者通过场景化试验把握云计算的what和how。收费云资源，实在云环境，丰盛实际场景 地址：https://developer.aliyun.com/adc/labs/ 背景信息数据库实验室是DMS打造的一站式数据库体验馆，DMS-数据库实验室面向宽广学生、开发者等全副阿里云用户提供收费数据库产品， 在数据库实验室，您能够同时收费开明多款不同类型的数据库，并对数据库进行摸索和应用。 开明RDS-MySQL数据库在数据库实验室中，您能够收费开明不同类型的数据库，并对数据库进行摸索和应用。首先须要您登录DMS数据库实验室。在登录DMS数据库实验室后，零碎会自动弹出创立数据库的窗口。 在弹窗中单击选中RDS-MySQL数据库类型，能够应用默认的数据库名称也能够在数据库名称文本框中输出自定义的数据库名称。单击收费开明数据库按钮即可收费开明数据库。进入SQL Console在上一步单击收费开明数据库按钮后，零碎会创立指标数据库（默认创立courses、stedents、student_courses三张表），并主动跳转至 SQLConsole页面，同时显示一段示例SQL。 您能够在SQLConsole中通过执行SQL语句来进行一系列的数据操作，也能够通过可视化编辑性能进行数据操作，详情请参见数据库实验室帮忙手册。 实现对学生问题的详情查问单击SQLConsole页面左上角的执行按钮，即可查问示例SQL语句，对学生问题进行详情查问。您也能够输出F8快捷键进行查问。在页面下方执行后果区域，查看查问后果。在页面下方执行后果区域，查看查问后果。常见问题QAQ：在数据库实验室我能够做什么？A：在数据库实验室，你能够一键开明数据库，创立、编辑和删除表，对表里的数据进行增删改查。你还能够收费体验DMS的高阶性能，例如跨库查问、测试数据构建、数据库导出、批量数据导入和导出、敏感列设置、操作日志治理等。 Q：在哪里能够看到数据库实验室目前反对的数据库类型？A：你能够在数据库实验室左侧的导航栏里看到不同类型的实例名称，这些都是数据库实验室目前曾经反对的数据库类型（目前有PolarDB for MySQL、RDS for MySQL、RDS for SQL Server、PostgreSQL、MongoDB、AnalyticDB For MySQL、AnalyticDB For PG等）。接下来数据库实验室也会一直去反对更多的数据库类型，敬请期待！ Q：怎么开明数据库？A：你能够在左侧导航栏点击你想开明的实例，或者右击实例名称，抉择“开明实验室数据库”，就能够开明实验室数据库啦～呈现在左侧导航栏里的所有实例你都能够收费开明数据库喔～ Q：我能够在哪里对数据进行操作？A：数据库开明后，会帮你主动关上SQL Console，你也能够在左侧导航栏双击数据库名称，进入SQL Console。 SQL Console是一个集成了泛滥重要性能的藏宝地。在这里，你能够通过图形化操作、写SQL等形式创立、编辑、删除表，对数据进行增删改查。你还能够一键导出数据库、批量导入导出数据、主动生成测试数据。你能够关上命令窗口，也能够间接对后果集进行编辑保留。这里还有很多很多丰盛而弱小的性能，快来亲自体验一下吧！ Q：什么是跨库查问？A：跨库查问性能能够让你用一条SQL实现不同类型数据库之间的关联查问。你能够点击数据库实验室顶部菜单栏的SQLConsole > 跨库查问进入查问页面。 Q:数据库实验室的资源有应用期限吗？A:原则上数据库实验室是能够无限期收费应用的。你每进入一次实验室，就能够收费续期30天。如果间断30天都没有进入到实验室，会回收之前的资源，再次进入时会重新分配资源。 Q:数据库实验室的应用有什么限度吗？A:目前每个人每个库的应用空间下限为512M，每个数据库创立的表数量下限为1000个。如果你有特地的需要，能够分割咱们！

本文介绍MySQL与Redis缓存的同步的两种计划 计划1：通过MySQL主动同步刷新Redis，MySQL触发器+UDF函数实现计划2：解析MySQL的binlog实现，将数据库中的数据同步到Redis计划1（UDF）场景剖析：当咱们对MySQL数据库进行数据操作时，同时将相应的数据同步到Redis中，同步到Redis之后，查问的操作就从Redis中查找过程大抵如下：在MySQL中对要操作的数据设置触发器Trigger，监听操作客户端（NodeServer）向MySQL中写入数据时，触发器会被触发，触发之后调用MySQLUDF函数UDF函数能够把数据写入到Redis中，从而达到同步的成果 计划剖析：这种计划适宜于读多写少，并且不存并发写的场景因为MySQL触发器自身就会造成效率的升高，如果一个表常常被操作，这种计划显示是不适合的演示案例上面是MySQL的表 上面是UDF的解析代码 定义对应的触发器 计划2（解析binlog）在介绍计划2之前咱们先来介绍一下MySQL复制的原理，如下图所示： 主服务器操作数据，并将数据写入Bin log从服务器调用I/O线程读取主服务器的Bin log，并且写入到本人的Relay log中，再调用SQL线程从Relay log中解析数据，从而同步到本人的数据库中 计划2就是： 下面MySQL的整个复制流程能够总结为一句话，那就是：从服务器读取主服务器Bin log中的数据，从而同步到本人的数据库中咱们计划2也是如此，就是在概念上把主服务器改为MySQL，把从服务器改为Redis而已（如下图所示），当MySQL中有数据写入时，咱们就解析MySQL的Bin log，而后将解析进去的数据写入到Redis中，从而达到同步的成果。（搜寻公众号民工哥技术之路，回复“1024”，送你一份技术宝典） 例如上面是一个云数据库实例剖析： 云数据库与本地数据库是主从关系。云数据库作为主数据库次要提供写，本地数据库作为从数据库从主数据库中读取数据本地数据库读取到数据之后，解析Bin log，而后将数据写入写入同步到Redis中，而后客户端从Redis读数据 这个技术计划的难点就在于：如何解析MySQL的Bin Log。然而这须要对binlog文件以及MySQL有十分深刻的了解，同时因为binlog存在Statement/Row/Mixedlevel多种形式，剖析binlog实现同步的工作量是十分大的 Canal开源技术canal是阿里巴巴旗下的一款开源我的项目，纯Java开发。基于数据库增量日志解析，提供增量数据订阅&生产，目前次要反对了MySQL（也反对mariaDB） 开源参考地址有：https://github.com/liukelin/c...\_mysql\_nosql\_sync 工作原理（模拟MySQL复制）：canal模仿mysql slave的交互协定，假装本人为mysql slave，向mysql master发送dump协定mysql master收到dump申请，开始推送binary log给slave（也就是canal）canal解析binary log对象（原始为byte流） 架构： eventParser (数据源接入，模仿slave协定和master进行交互，协定解析)eventSink (Parser和Store链接器，进行数据过滤，加工，散发的工作)eventStore (数据存储)metaManager (增量订阅&生产信息管理器)server代表一个canal运行实例，对应于一个jvminstance对应于一个数据队列 （1个server对应1..n个instance)instance模块 大抵的解析过程如下： parse解析MySQL的Bin log，而后将数据放入到sink中sink对数据进行过滤，加工，散发store从sink中读取解析好的数据存储起来而后本人用设计代码将store中的数据同步写入Redis中就能够了其中parse/sink是框架封装好的，咱们做的是store的数据读取那一步 更多对于Cancl能够百度搜寻 上面是运行拓扑图 MySQL表的同步，采纳责任链模式，每张表对应一个Filter。例如zvsync中要用到的类设计如下： 上面是具体化的zvsync中要用到的类， 每当新增或者删除表时，间接进行增删就能够了 附加本文下面所介绍的都是从MySQL中同步到缓存中。然而在理论开发中可能有人会用上面的计划：客户端有数据来了之后，先将其保留到Redis中，而后再同步到MySQL中 这种计划自身也是不平安/不牢靠的，因而如果Redis存在短暂的宕机或生效，那么会失落数据 作者 | 江南、董少起源 | https://dongshao.blog.csdn.ne...

作者：余振兴 爱可生 DBA 团队成员，相熟 Oracle、MySQL、MongoDB、Redis，最近在盘 TiDB，善于架构设计、故障诊断、数据迁徙、灾备构建等等。负责解决客户 MySQL 及我司自研 DMP 数据库治理平台日常运维中的问题。热衷技术分享、编写技术文档。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 1. import_table介绍上期技术分享我介绍了 MySQL Load Data 的 4 种将文本数据导入到 MySQL 的罕用的办法。 这一期咱们持续介绍另一款更加高效的数据导入工具 —— MySQL Shell 工具集中的import_table。该工具的全称是 Parallel Table Import Utility，顾名思义：反对并发数据导入。 该工具在 MySQL Shell 8.0.23 版本后，性能更加欠缺，以下列举该工具的外围性能。 根本笼罩了 MySQL Data Load 的所有性能，能够作为替代品应用默认反对并发导入（反对自定义 chunk 大小）反对通配符匹配多个文件同时导入到一张表（十分实用于雷同构造数据汇总到一张表）反对限速（对带宽应用有要求的场景，十分适合）反对对压缩文件解决反对导入到 5.7 及以上 MySQL2. Load Data 与 import table 性能示例该局部针对 import table 和 Load Data 雷同的性能做命令示例演示，咱们仍旧以导入 employees 表的示例数据为例，演示 MySQL Load Data 的综合场景 数据自定义程序导入数据函数解决自定义数据取值## 示例数据如下[root@10-186-61-162 tmp]# cat employees_01.csv"10001","1953-09-02","Georgi","Facello","M","1986-06-26""10003","1959-12-03","Parto","Bamford","M","1986-08-28""10002","1964-06-02","Bezalel","Simmel","F","1985-11-21""10004","1954-05-01","Chirstian","Koblick","M","1986-12-01""10005","1955-01-21","Kyoichi","Maliniak","M","1989-09-12""10006","1953-04-20","Anneke","Preusig","F","1989-06-02""10007","1957-05-23","Tzvetan","Zielinski","F","1989-02-10""10008","1958-02-19","Saniya","Kalloufi","M","1994-09-15""10009","1952-04-19","Sumant","Peac","F","1985-02-18""10010","1963-06-01","Duangkaew","Piveteau","F","1989-08-24"## 示例表构造 10.186.61.162:3306 employees SQL > desc emp;+-------------+---------------+------+-----+---------+-------+| Field | Type | Null | Key | Default | Extra |+-------------+---------------+------+-----+---------+-------+| emp_no | int | NO | PRI | NULL | || birth_date | date | NO | | NULL | || first_name | varchar(14) | NO | | NULL | || last_name | varchar(16) | NO | | NULL | || full_name | varchar(64) | YES | | NULL | | -- 表新增字段,导出数据文件中不存在| gender | enum('M','F') | NO | | NULL | || hire_date | date | NO | | NULL | || modify_date | datetime | YES | | NULL | | -- 表新增字段,导出数据文件中不存在| delete_flag | varchar(1) | YES | | NULL | | -- 表新增字段,导出数据文件中不存在+-------------+---------------+------+-----+---------+-------+2.1 用 Load Data 形式导入数据具体参数含意不做阐明，须要理解语法规定及含意可查看系列上一篇文章《MySQL Load Data 的多种用法》load data infile '/data/mysql/3306/tmp/employees_01.csv'into table employees.empcharacter set utf8mb4fields terminated by ','enclosed by '"'lines terminated by '\n'(@C1,@C2,@C3,@C4,@C5,@C6)set emp_no=@C1, birth_date=@C2, first_name=upper(@C3), last_name=lower(@C4), full_name=concat(first_name,' ',last_name), gender=@C5, hire_date=@C6 , modify_date=now(), delete_flag=if(hire_date<'1988-01-01','Y','N'); ...

导读：作为凤睛晚期的接入方、前期的核心成员，笔者经验了整个我的项目前后四年的变迁，看过我的项目的艰巨开始、中期的默默积攒以及前期的蓬勃发展。每一次架构的变迁都带着技术浪潮的烙印，也看到我的项目成员利用无限资源来解决理论问题而继续一直的翻新。 凤睛是百度商业业务零碎的性能监控零碎（APM），它侧重于对Java利用的监控，根本接入了百度绝大部分Java利用（笼罩数千个业务利用，数万个容器）。它可能对支流中间件框架（ Spring Web、RPC、数据库、缓存等）进行主动埋点，实现全栈式性能监控和全链路追踪诊断，为百度各业务线提供微服务零碎性能指标、业务黄金指标、健康状况、监控告警等。 △凤睛产品流程图 数据采集：凤睛探针技术可能主动植入到业务过程中去，采集相干性能信息，业务过程齐全无感知。数据计算和剖析：依照类型，时序数据存储在百度SIA智能监控平台的时序数据库 TSDB，用来生成可视化报表和异样报警。调用链数据会被存入Palo（ 开源名为Doris） 大数据仓库，用来拓扑剖析和调用链检索。利用场景：如上所述，凤睛提供稳定性报表、异样报警、谬误堆栈剖析、服务耗时剖析、调用拓扑剖析、业务日志关联剖析等。 △凤睛的架构变迁工夫线 01  凤睛立项 我的项目发动在2016年，百度凤巢广告业务零碎中间件 (分布式RPC框架 Stargate等、配置核心、数据库中间件等)曾经欠缺。随着单体服务拆分的深刻，整体Java在线上部署规模逐步变多，同时，裸露的问题也越来越多。 典型的问题有： 外围服务问题定位周期长。多个模块大量报错后，破费了很长时间才定位问题。集群日志获取代价十分高，不足日志调用链关系等起因导致定位代价很高，甚至有些问题无奈定位。异样日志须要登录具体的线上实例查看。而线上部署实例数目多，排错工夫长。凤巢业务端急需一个分布式追踪零碎来实现整个业务端日志的“大串联”。所以百度商业平台基础架构组发动了凤睛的我的项目，名曰“凤巢之眼”。 02  凤睛1.0 在分布式链路追踪畛域，探针采集这个环节次要存在侵入式和无侵入式。1.0探针走的侵入形式。业务开发人员首先引入探针相干的依赖 jar 包，通过拦截器主动收集调用关系以及性能数据；而后，增加硬编码补充业务数据。 △编码示例 探针采集的数据会被打印到磁盘，通过kafka收集走。底层的数据处理和数据存储采纳了Storm、 Hbase等过后风行的数据处理系统。后端架构比较复杂。 △凤睛1.0架构示意图 03  凤睛2.0 凤睛2.0版本中，首先是升高探针接入老本。2.0版本中，探针改用java agent技术联合cglib 做AOP注解，把依赖引入的jar 包从N个升高到1个。从编写大段的调用链填充代码改为尽量走AOP。探针端传输层采纳了更高效的传输协定（protobuffer+gzip）, 间接通过 HTTP 协定发送到 kafka，大大了升高磁盘IO开销。 2.0探针较1.0接入不便，传输也更快。然而仍需业务方增加AOP代码。对于业务端数以百计的利用来说，接入依然是大工程，推广仍然艰难。 04  凤睛3.0 凤睛3.0架构设计中，我的项目组成员始终在思考两个问题： 如何让业务方疾速接入，尽量少改变，甚至“无感知接入”？如何升高架构运维难度，既能解决海量数据，又能低成本运维？为了解决问题1，探针3.0 决定齐全放弃侵入式形式，改为无侵入即字节码加强形式。 对过后几种风行的监控诊断工具进行了调研： △Newrelic，pinpoint，greys监控探针调研 3.0探针参考了Greys反对运行时加强的特点以及 pinpoint、Newrelic基于插件扩大开发的设计理念。最终成果是探针可能主动对业务过程植入监控代码，监控具体工作交由插件体系实现，齐全面向切面监控。 △探针被动加载示意图 后端存储系统转而依靠Doris。Doris是百度自研的基于 MPP 的交互式 SQL 数据仓库，兼容mysql协定，学习成本低。既能够做存储又能够做剖析计算，初期防止引入spark，storm等技术，升高零碎复杂度。 △架构设计如图所示 架构降级后，作为小团队，也能疾速批量部署探针，计算存储能力也能满足需要。截止2017年，凤睛3.0上线了100多个利用，跑在1000多个容器下面。 05  凤睛4.0 ...

一、SQL语句分类 DQL 数据查询语言 SELECTDML 数据增删改语言 INSERT,DELETE,UPDATEDDL 表构造增删改语言 CTEATE，DROP，ALTERTCL 事务管制语句 (Transection) COMMIT,ROLLBACKDCL 数据管制语言 受权等二、SQL脚本文件以.sql结尾，并且该文件中编写了大量的SQL语句。执行sql脚本在DOS命令窗中应用语句：source 文件门路 三、 导入数据DOS命令窗口－＞　登录：mysql -uroot -p33　查看数据库：show databases;(不是SQL语句，是MySQL命令语句)　创立：creat database 数据库名称;(MySQL命令语句)　应用：use 数据库名称；　导入数据，执行sql脚本：source sql脚本文件门路、　删除表：drop database 数据库名称　四、查问表查问表数据：show tables(MySQL命令语句)查问表构造：desc 表名称 五、常用命令查问以后应用的数据库：select database();查看mysql版本：select version();终止一条正在编写的语句：\c退出mysql:\q (或者ctrl+c)

SQL根底数据类型运算符及常见函数存储引擎概述InnoDB文件

MySQL 数据库中常见的日志文件有： 谬误日志（error log）二进制日志（binlog）慢查问日志（slow query log）查问日志（log）谬误日志谬误日志文件对 MySQL 的启动、运行、敞开过程进行了记录。该文件不仅记录了所有的错误信息，也记录了一些正告信息或正确的信息。 能够通过 show variables like 'log_error' 来定位该日志文件。 慢查问日志慢查问日志中记录的是语句执行工夫超过阈值(long_query_time)的SQL。该阈值默认是10，代表10秒。 默认状况下，MySQL 数据库并不启动慢查问日志。能够通过批改 long_slow_queries 参数来开启。 慢 SQL 日志中还能够记录没有应用索引的 SQL，通过参数 log_queries_not_using_indexes 参数来开启。 查问日志查问日志中记录了所有对 MySQL 数据库申请的信息，无论这些申请是否失去了正确的执行。 二进制日志二进制日志（bin log）记录了对 MySQL 数据库执行更改的所有操作，然而不包含 SELECT 和 SHOW 这类操作。 二进制日志次要有以下几种作用：’ 复原复制审计二进制日志文件在默认状况下没有启动，须要手动指定参数(log-bin)来启动。依据 MySQL 官网手册中的测试示意，开启二进制日志会使性能降落 1% 二进制日志文件中， 有几个参数影响二进制日志记录的信息和行为： max_binlog_size：指定了单个二进制日志文件的最大值，如果超过该值，则产生新的二进制日志文件，后缀名 +1，并记录到 .index 文件。binlog_format：指定了记录二进制日志的格局。该参数可设的值有 STATEMENT、ROW 和 MIXED。 STATEMENT：二进制日志文件记录的是日志的逻辑 SQL 语句。ROW：二进制日志记录的不再是简略的 SQL 语句了，而是记录表的行更改状况。当一行数据产生扭转后，记录的是以后行最新状态的值。在此状态下，日志文件占内存最大。MIXED：默认采纳 STATEMENT 格局进行二进制日志文件的记录，然而在一些状况下，会应用 ROW 格局。以后参数的设置能够通过命令：SET GLOBAL binlog_format='ROW' InnoDB 存储引擎文件下面的文件是 MySQL 数据库自身的文件，和存储引擎无关，InnoDB 存储引擎还有本人独有的文件，这些文件包含重做日志文件、表空间文件。 表空间文件InnoDB 将存储的数据按表空间（tablespace）进行寄存的设计。在默认配置下会有一个初始大小为 10MB，名为 ibdata1 的文件。 ...

文章为转载，原文地址：https://blog.wangmao.me/mysql... 间接上图，查问limits为2的记录 怎么查？like？like是不合乎预期的SELECT * FROM users WHERE limits LIKE '%2%';后果是下面蕴含2的两条记录都会查问进去，不合乎预期 mysql 函数 find_in_set() 能达到咱们的预期SELECT * FROM users WHERE FIND_IN_SET(2,limits); 留神find_in_set是准确匹配，字段值必须是以英文逗号(,)分隔

前言： 上篇文章，咱们介绍了 MySQL 权限治理相干常识。当数据库实例中存在大量的库或用户时，权限治理将会变得越来越繁琐，可能要频繁进行权限变更。MySQL 8.0 新增了 role 性能，使得权限治理更加不便，本篇文章咱们来看下 8.0 下的 role 性能。 1. role 简介role 角色性能对于 Oracle 数据库来说不算是什么非凡，在 Oracle 中常常被用到。MySQL 8.0 版本终于新增了 role 性能，为数据库用户权限治理提供了一种新思路。 role 能够看做一个权限的汇合，这个汇合有一个对立的名字 role 名。能够给多个数据库用户授予同个 role 的权限，权限变更可间接通过批改 role 来实现，不须要每个用户一个一个的去变更，不便运维和治理。role 能够创立、删除、批改并作用到它治理的用户上。 上面咱们具体来体验下 role 角色性能： # 创立rolemysql> create role 'dev_role';Query OK, 0 rows affected (0.15 sec)# 给role授予权限mysql> grant select on db1.* to 'dev_role'@'%';Query OK, 0 rows affected (0.12 sec)# 查看role的权限mysql> show grants for 'dev_role'@'%';+-------------------------------------------+| Grants for dev_role@% |+-------------------------------------------+| GRANT USAGE ON *.* TO `dev_role`@`%` || GRANT SELECT ON `db1`.* TO `dev_role`@`%` |+-------------------------------------------+# 创立用户 并赋予角色权限mysql> create user 'dev1'@'%' identified by '123456';Query OK, 0 rows affected (0.68 sec)mysql> grant 'dev_role' to 'dev1'@'%';Query OK, 0 rows affected (0.38 sec)# 查看用户权限mysql> show grants for 'dev1'@'%';+------------------------------------+| Grants for dev1@% |+------------------------------------+| GRANT USAGE ON *.* TO `dev1`@`%` || GRANT `dev_role`@`%` TO `dev1`@`%` |+------------------------------------+2 rows in set (0.63 sec)# 应用dev1用户登录root@localhost ~]# mysql -udev1 -p123456mysql> show databases;+--------------------+| Database |+--------------------+| information_schema |+--------------------+1 row in set (0.34 sec)mysql> select CURRENT_ROLE();+----------------+| CURRENT_ROLE() |+----------------+| NONE |+----------------+1 row in set (0.59 sec)什么状况？貌似和咱们设想不同，赋予用户某个角色权限后，该用户并没有取得相应权限。 ...

写在后面周末，我与阿里P9资深技术专家（这里就不说名字了），聊起了MySQL这个话题，为啥会聊这个呢？因为他看到我出版了一部《MySQL技术大全：开发、优化与运维实战》，对书籍的评估也是不错的。随后，咱们聊了对于MySQL的几个话题，其中一个就是MySQL的日志机制。明天，我就把大略聊的一些内容以书面文章的模式分享给大家。心愿可能为小伙伴们带来实质性的帮忙！ 文章已收录到： https://github.com/sunshinelyz/technology-binghe https://gitee.com/binghe001/technology-binghe MySQL日志说起MySQL的日志，有三种类型的日志对于MySQL来说是至关重要的，这三种日志别离为：Binlog、Undo Log 和 Redo Log。 因为Binlog和UndoLog有相似的中央，所以，咱们依照如下程序顺次介绍MySQL中的三大日志原理：Undo Log——> Redo Log ——> Binlog。 Undo Log日志什么是Undo Log顾名思义，Undo Log的字面意思就是撤销操作的日志，指的是使MySQL中的数据回到某个状态。 在MySQL数据库中，事务开始之前，MySQL会将待批改的记录保留到Undo Log中，如果数据库解体或者事务须要回滚时，MySQL能够通过利用Undo Log日志，将数据库中的数据回滚到之前的状态。 MySQL新增、批改和删除数据时，在事务开始前，就会将信息写入Undo Log中。事务提交时，并不会立即删除Undo Log， InnoDB存储引擎会将事务对应的Undo Log放入待删除列表中，之后会通过后盾的purge thread看待删除的列表进行删除解决。这里，值得注意的是：Undo Log是一种 逻辑日志， 记录的是一个变动过程。比方，MySQL执行一个delete操作，Undo Log就会记录一个insert操作；MySQL执行一个insert操作，Undo Log就会记录一个delete操作；MySQL执行一个update操作，Undo Log就会记录一个相同的update操作。 Undo Log以段的形式来治理和记录日志信息，在InnoDB存储引擎的数据文件中，蕴含了一种叫做rollback segment的回滚段，其外部蕴含了1024个undo log senment。 Undo Log作用Undo Log对于MySQL实现事务来说，起着至关重要的作用，它实现了事务的原子性和多版本并发管制，也就是咱们常常说的MVCC。 实现事务的原子性Undo Log可能实现MySQL事务的原子性，在事务的处理过程中，如果MySQL呈现了谬误或者用户手动执行了事务的回滚操作（执行了rollback操作），MySQL能够利用Undo Log日志将数据库中的数据恢复到之前的状态。 实现MVCC机制Undo Log在MySQL的InnoDB存储引擎中实现了多版本并发管制（MVCC）机制。事务未提交前，Undo Log保留了未提交之前的版本数据，Undo Log中的数据能够作为旧版本数据的正本或者快照以便其余并发事务进行读取操作。 事务A手动开启事务后，对goods数据表中id为1的数据进行更新操作，首先会把更新命中的数据写入到Undo Buffer中。在事务A未提交之前，此时，事务B手动开启事务，对goods数据表中的id为1的数据进行查问操作，此时的事务B会读取Undo Log中的数据并返回给客户端，这就是MySQL中的MVCC机制。 能够在MySQL中通过上面的命令来查看管制Undo Log日志的参数。 show variables like '%innodb_undo%';Redo Log日志说了MySQL中的Undo Log，咱们再来看看MySQL中的Redo Log日志。 什么是Redo Log顾名思义Redo Log的字面意思就是重做日志，指的是在数据库出现意外状况时可能对从新执行某种操作。在MySQL中，事务中批改的任何数据，都会将最新的数据写入Redo Log中进行备份。 在MySQL中，随着事务操作的执行，就会产生Redo Log日志，在事务提交时会产生Redo Log并将其写入Redo Buffer，Redo Buffer也并不是随着事务的提交就会被立即写入到磁盘中，而是等事务操作的脏页写入到磁盘之后，Redo Log的使命也就实现了，此时，Redo Log日志占用的空间能够从新利用，会被后续产生的Redo Log日志笼罩。 ...

作者：秦广飞 爱可生 DBA 团队成员，负责我的项目日常问题解决及公司平台问题排查，对数据库有趣味，对技术有想法。一入 IT 深似海，从此节操是路人。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 本文目录 前言 测试目标 环境信息 测试场景 mysqlbackup 工具XtraBckup 工具总结 参考链接 前言昨天，分享了《mysqlbackup 能够近程备份吗》一文，明天再给大家分享一篇备份相干的文章。 咱们曾经晓得了，物理备份无奈备份近程的 MySQL，那么，反过来呢，是否能够间接备份到近程 MySQL 服务器？ 答案天然也是必定的，不然我这篇文章就没法写了。 测试目标为什么咱们要备份到近程服务器呢，通常有上面几种起因： 灾备，将备份放在远端服务器。缩小本地磁盘占用，如果本地曾经没有多余的磁盘空间了，这时就能够间接备份到远端，而不用在本地保留备份文件。验证备份文件可用性，通常，咱们须要定期检验下备份文件可用性，那么就能够采纳这种形式，间接备份到近程 MySQL 服务器并复原。增加从实例，间接备份到近程并复原出一个实例，与主库建设复制。接下来，就是测试过程了... 环境信息老规矩，先介绍下环境信息，本文我会从两种罕用的物理备份工具 mysqlbackup 和 XtraBackup 来讲。 每种工具，都会筛选一个场景，将备份文件复原出数据，并建设复制。 其实，还是之前的环境，这里我就间接摘抄了。 主机名主机 IP实例版本端口备份用户mysqlbackup版本XtraBackup版本qin_210.186.64.13MySQL A5.7.253306user_A4.1.42.4.5qin_410.186.64.16MySQL B5.7.253306无4.1.42.4.5测试场景mysqlbackup 工具介绍 mysqlbackup 能够将备份数据通过流式传输到近程服务器，也能够传输到近程后间接复原出数据。 流式传输到近程，须要借助管道和 ssh 等命令。 为了将备份文件传到规范输入，须要应用 backup-to-image 选项，并且令 --backup-image=- 测试过程 场景一 将备份文件流式传输到近程主机 备份命令 -- 备份命令shell> mysqlbackup --defaults-file=/opt/mysql/etc/3306/my.cnf --user=user_A --password=password_A --socket=/opt/mysql/data/3306/mysqld.sock --backup-image=- --backup-dir=/tmp/backup1 backup-to-image | ssh root@10.186.64.16 'cat > /root/backups/my_backup.img'-- 备份参数 backup-image=- ：将备份数据发送到stdout backup-dir=/tmp/backup1 ：指定用于存储临时文件的目录（须要是不存在的目录） 近程主机上须要提前创立/root/backups目录 ...

引言置信每一个后盾开发工程师在面试过程中，都已经被问到过“MySQL的默认存储引擎是什么？MySQL索引是什么数据结构？”这样的问题。置信准备充分（熟读八股文）的大家都能很容易的答复出“MySQL的默认存储引擎是InnoDB，MySQL索引应用的是B+树。”这样的答案。然而为什么当初写MySQL的程序员大叔要这样子来设计呢？ 概述首先须要明确一点，MySQL跟B+树没有间接的关系，真正与B+树有关系的是MySQL的默认存储引擎InnoDB，MySQL中存储引擎的次要作用是负责数据的存储和提取，除了InnoDB之外，MySQL中也反对MyISAM等引擎作为表的底层存储引擎。然而不论是InnoDB或是MyISAM，其实索引的数据结构都是B+树。只是InnoDB采纳的是聚簇索引，理论数据就在B+树叶子节点上；而MyISAM会独自为表的主键创立一个索引，叶子节点保留指向理论数据的指针。 那么接下来，咱们就来探讨一下，为什么MySQL应用B+树？ 一、从磁盘I/O说起1. 磁盘基本概念让咱们把工夫回退到程序员大叔设计MySQL的年代。大叔们设计数据库那必定是须要介质来存储数据的，说到存储介质，那咱们能想到的就是两类：磁盘、SSD硬盘。SSD硬盘必定香啊，然而也贵，而且数据库是要反对上T数据的存储，2021年想想这条路都太贵啦，大叔们还是乖乖用磁盘吧～ 传统的硬盘盘构造如上图所示。它有一个或多个盘片，每个盘片能够有两面，用于存储数据。两头有一个主轴，所有的盘片都绕着这个主轴转动。一个组合臂下面有多个磁头臂，每个磁头臂下面都有一个磁头，负责读写数据。 如上图所示，每个盘片的盘面被划分成多个狭隘的同心圆环，数据就存储在上图这样的同心圆环下面，咱们将这样的圆环称为磁道 (Track)。依据硬盘的规格不同，磁道数能够从几百到成千上万不等。每个磁道能够存储数 Kb 的数据，然而计算机不必要每次都读写这么多数据。 因而，再把每个磁道划分为若干个弧段，每个弧段就是一个扇区 (Sector)。扇区是硬盘上存储的物理单位，当初每个扇区可存储 512 字节数据曾经成了业界的约定。也就是说，即便计算机只须要某一个字节的数据，然而也得把这个 512 个字节的数据全副读入内存，再抉择所须要的那个字节。 柱面是形象进去的一个逻辑概念，简略来说就是处于同一个垂直区域的磁道称为柱面 。如上图所示，各盘面上雷同地位磁道的汇合属于同一柱面。 须要留神的是，磁盘读写数据是按柱面进行的。磁头读写数据时，从盘片的起始数据柱面开始，读取完后，顺次向下在同一柱面的不同盘面上进行操作。只有在同一柱面所有的磁头全副读写结束后磁头才转移到下一柱面。之所以读写这么设计是因为选取磁头（数据从哪个磁头获取）只需通过电子切换即可，而选取柱面则必须通过机械切换（挪动磁头地位）。而机械切换的速度必定远远不如电子切换。为了读写的更快，数据的读写是按柱面进行的，而不是按盘面进行。正因为如此，数据存到同一个柱面是很有价值的。 依据上文的信息，咱们能够得出磁盘容量的计算公式为： 硬盘容量 = 盘面数 × 柱面数 × 扇区数 × 512字节2. 磁盘读写古代硬盘寻道都是采纳CHS(Cylinder Head Sector)的形式。咱们能够把磁盘读写数据分3个局部来看。 硬盘读取数据时，读写磁头沿径向挪动，移到要读取的扇区所在磁道的上方，这段机械切换的工夫称为寻道工夫(seek time)。因读写磁头的起始地位与指标地位之间的间隔不同，寻道工夫也不同。磁头达到指定磁道后，通过盘片的旋转，使得要读取的扇区转到读写磁头的下方，这段时间称为旋转延迟时间(rotational latencytime)。读写数据也须要工夫，这段时间称为传输工夫（transfer time）。通过介绍，大家能很容易的了解寻道工夫和旋转延迟时间耗时特地多。因为计算机的指标是更高、更快、更强。数据库依赖于计算机存储，那么Mysql大叔设计数据结构式必定也得思考磁盘读写的特点，去设计一个让查问更快的数据结构。 3. 间断I/O于随机I/O大家都晓得，MySQL这类数据库软件，性能其实就分为存数据和查问数据。查问数据依赖于存数据，存数据的形式必定也影响着查问的快慢。因为数据是存储在磁盘上的，那么计算机内存必定是要和磁盘打交道的，而这个打交道的过程，就随同着磁盘I/O。咱们能够依据查问磁盘的形式，将磁盘I/O分为以下两种： 间断I/O ：本次 I/O 给出的初始扇区地址和上一次 I/O 的完结扇区地址是齐全间断或者相隔不多的。随机I/O：本次 I/O 给出的初始扇区地址和上一次 I/O 的完结扇区相差很大，则算作一次随机 I/O。因为在做间断 I/O 的时候，磁头简直不必换道，或者换道的工夫很短；而对于随机 I/O，如果这个 I/O 很多的话，会导致磁头不停地换道，造成效率的极大升高。这也就是间断 I/O 比随机 I/O 效率高的起因。 因为读写是依赖于存储的，并且查问往往带有条件，导致查问的数据不间断。所以MySQL大叔们就想，能不能设计一个存储形式，防止随机I/O或者缩小随机I/O的次数，来进步查问效率呢？ 二、更快的查找——树作为一名程序员，“树”这个名词大家肯定是熟知的（啥？你居然不熟？面壁去）。树的数据结构经常在算法题中波及到。树的品种大抵有： 二叉（搜寻/排序）树：BST均衡二叉查找树：BBST红黑树：BRTB-树（也叫B树）B+树B*树R树本文不会把各种树的个性介绍一遍啦，后续会从新开一篇文章去具体介绍这些树及其个性。因为咱们是一篇老少皆宜的文章，所以咱们先从树查找的原理开始～ 1. 二叉（搜寻/排序）树的查找二叉树大家都听过，个别就是一个根结点，根结点下挂一个左子节点，一个右子节点。而左子节点和右子节点又能作为子树的根结点。如果在这个根底上略微加一点点要求，就变成了二叉搜寻树（BST）。二叉搜寻树定义如下： 若它的左子树不空，则左子树上所有结点的值均小于它的根结点的值；若它的右子树不空，则右子树上所有结点的值均大于它的根结点的值；它的左、右子树也别离为二叉搜寻树。 从上图中咱们能够看到，根结点5左子树的任何节点的值都小于5，根结点5右子树下面的所有节点值都大于5，并且咱们以2或者7来作为根结点，仍然能够得出“左子树上所有结点的值均小于它的根结点的值，右子树上所有结点的值均大于它的根结点的值”这一论断。 因为二叉搜寻树具备这样的个性，假如咱们查找一个数据3。咱们的算法门路为： ...

背景测试mysql5.7和mysql8.0 别离在读写、只读、只写模式下不同并发时的性能（tps，qps） 前提测试应用版本为mysql5.7.22和mysql8.0.15sysbench测试前先重启mysql服务，并清空os的cache（防止屡次测试时命中缓存）每次进行测试都是新生成测试数据后再进行mysql5.7和mysql8.0的测试每次测试时保障mysql5.7和mysql8.0的配置参数统一环境机器`cat /etc/redhat-release | xargs echo '版本 ' && dmidecode -s system-product-name | xargs echo '是否虚拟化 ' && cat /proc/cpuinfo |grep "processor"|wc -l | xargs echo 'cpu核数 '`版本 CentOS Linux release 7.5.1804 (Core)是否虚拟化 KVMcpu核数 4myql5.7.22`5.7.22-log``innodb_buffer_pool_size 128M``innodb_log_buffer_size  64M``innodb_log_file_size    48M``binlog_format   ROW``log_bin ON``transaction_isolation   REPEATABLE-READ`mysql8.0.15`8.0.15``innodb_buffer_pool_size 128M``innodb_log_buffer_size  64M``innodb_log_file_size    48M``binlog_format   ROW``log_bin ON``transaction_isolation   REPEATABLE-READ`sysbench`sysbench -V``sysbench 1.1.0 (using bundled LuaJIT 2.1.0-beta3)`测试在不同的长久化策略下（binlog, redo log长久化）mysql5.7和mysql8.0 在读写模式、只读模式、只写模式（oltp\_read\_write，oltp\_read\_only，oltp\_write\_only）下的性能体现sysbench 测试工夫为60s，测试的表数量为20测试别离在双1模式（安全性）和0 2模式（高性能）下进行参数 任选值 意味着 sync\_binlog 0 binlog刷盘长久化由操作系统实现，性能好，存在失落binlog的危险 sync\_binlog 1个 事务提交后刷盘长久化，最平安 sync\_binlog ñ 在每N个事务提交后进行刷盘长久化 innodb\_flush\_log\_at\_trx\_commit 0 每秒钟写redo log并刷盘长久化 innodb\_flush\_log\_at\_trx\_commit 1个 事务提交后写redo log并刷盘长久化，最平安 innodb\_flush\_log\_at\_trx\_commit 2 事务提交后写redo log，两次刷盘长久化 双1模式下`SHOW GLOBAL  VARIABLES WHERE Variable_name IN('sync_binlog','innodb_flush_log_at_trx_commit');``+--------------------------------+-------+``| Variable_name                  | Value |``+--------------------------------+-------+``| innodb_flush_log_at_trx_commit | 1     |``| sync_binlog                    | 1   |``+--------------------------------+-------+`5.7和8.0 在读写模式下的体现双1 配置，读写模式下，mysql5.7.22 和mysql8.0.15 tps 、qps 性能差不多，mysql8.0.15 在120 线程并发时，性能呈现了降落抖动 5.7和8.0 在只读模式下的体现双1 配置，只读模式下，mysql5.7.22 的tps、qps比mysql8.0.15 好1/3 左右；并发线程数减少后，tps、qps并没有随着减少，反而呈现了降落的趋势 5.7和8.0 在只写模式下的体现双1 配置，只写模式下，随着并发数的回升，mysql5.7.22 的性能比mysql8.0.15 好1/4左右 0 2 模式下`SHOW GLOBAL  VARIABLES WHERE Variable_name IN('sync_binlog','innodb_flush_log_at_trx_commit');``+--------------------------------+-------+``| Variable_name                  | Value |``+--------------------------------+-------+``| innodb_flush_log_at_trx_commit | 2     |``| sync_binlog                    | 0   |``+--------------------------------+-------+`5.7和8.0 在读写模式下的体现0 2配置，读写模式下，并发数低时，mysql5.7.22性能好于mysql8.0.15; 并发数比拟高时，mysql8.0.15 性能好于mysql5.7.22；在80 线程的并发以上时，性能开始降落 ...

上午刚工作10分左右，共事说在应用jira时呈现问题，具体截图如下：通过上图的报错信息：定位为mysql数据库连接数的问题 解决办法： 1.登录mysql进行查看 Mysql –uroot –p123456mysql> show variables like'%max_connections%';+-----------------+-------+| Variable_name | Value |+-----------------+-------+| max_connections | 151 |+-----------------+-------+1 row in set (0.00 sec)很奇怪，最大连接数怎么是151呢，mysql默认的最大连接数不是100么？起初想一下可能是版本不同的问题，默认连接数也不同。为了确认mysql5.5.3默认的最大连接数为151，去mysql官网查看了一下：mysql默认的最大连接数为151，下限为1000 2.批改mysql默认的最大连接数为1000 在/etc/my.cnf文件中[mysqld]局部减少max_connections=1000，重启mysql服务，问题解决。 补充1:mysql其余版本默认的最大连接数 Mysql5.5 mysql5.6 mysql5.7：默认的最大连接数都是151，下限为：100000Mysql5.1依据其小版本的不同，默认的最大连接数和可批改的连接数下限也有所不同图片Mysql5.0版本：默认的最大连接数为100，下限为16384补充2：批改mysql数据库默认的最大连接数 办法一：批改mysql的主配置文件/etc/my.cnf，[mysqld]局部增加“max_connections=1000（这个依据理论的须要来进行设置即可）”，重启mysql服务。 办法二：mysql客户端登录，通过命令行批改全局变量来进行批改 mysql -uroot -p123456mysql> set global_max_connections = 200;mysql> show processlist;mysql> show status;批改实现后进行查看，mysql的最大连接数mysql> show variables like '%max_connections%';+-----------------+-------+| Variable_name | Value |+-----------------+-------+| max_connections | 1000 |+-----------------+-------+1 row in set (0.00 sec)办法三：解开mysql源代码，进入外面的SQL目录批改mysqld.cc找到上面一行： {"max_connections", OPT_MAX_CONNECTIONS, "The number of simultaneous clients allowed.", (gptr*) &max_connections, (gptr*) &max_connections, 0, GET_ULONG, REQUIRED_ARG, 100, 1, 16384, 0, 1, 0}, 把它改为： {"max_connections", OPT_MAX_CONNECTIONS, "The number of simultaneous clients allowed.", (gptr*) &max_connections, (gptr*) &max_connections, 0, GET_ULONG, REQUIRED_ARG, 1500, 1, 16384, 0, 1, 0}, 保留退出，而后./configure ;make;make install能够取得同样的成果办法四：通过批改mysqld_safe来批改mysql的连接数 ...

https://www.cnblogs.com/LBSer...

作者：秦广飞 爱可生 DBA 团队成员，负责我的项目日常问题解决及公司平台问题排查，对数据库有趣味，对技术有想法。一入 IT 深似海，从此节操是路人。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 本文目录 背景介绍 测试环境 备份命令 测试场景 1.A 服务器本地备份 MySQL A2.A 服务器近程备份 MySQL B测试后果 总结 题外话 背景介绍最近在我司客户现场遇到一个乏味的景象，对于应用 mysqlbackup 工具，近程备份其余服务器上的实例，跟大家分享一下。 mysqlbackup 反对近程备份吗？答案天然是不反对的。 那这篇文章？且缓缓往下看。 测试环境两台服务器，咱们假如就叫 A 和 B，各装有一个 MySQL 实例，端口都是 3306。 为了接下来的测试，咱们在 A 实例上创立备份用户 user_A@'%'，明码 password_A，测试库 a1、a2、a3。 同样，咱们在 B 实例上创立备份用户 user_B@'%'，明码 password_B，测试库 b1、b2、b3。 对了，备份工具放弃跟客户现场统一：MySQL Enterprise Backup version 4.0.0。 好了，我的测试环境如下： 主机名主机 IP实例版本端口用户明码测试库备份工具版本qin_210.186.64.13MySQL A5.7.253306user_A@'%'password_Aa1 a2 a3mysqlbackup4.0.0qin_410.186.64.16MySQL B5.7.253306user_B@'%'password_Bb1 b2 b3mysqlbackup4.0.0备份命令咱们晓得 mysqlbackup 属于物理备份工具。备份的是数据文件，因而也只能本地备份拷贝文件，这就表明了物理备份不能近程备份。 但咱们能够应用 --host 选项指定服务器 IP。 因为本次测试，不是为了具体钻研 mysqlbackup 备份参数的影响，因而，应用最简略的备份命令如下： ...

什么是 Mysql 主从主从是蕴含一个主库和一个或多个从库，主库中的数据会同步到各个从库当中。 主从复制原理1、当 master 节点进行 insert、update、delete 操作时，会按程序写入到 binlog 中。2、salve 从库连贯 master 主库，master 有多少个 slave 就会创立多少个 binlog dump 线程。3、当 Master 节点的 binlog 发生变化时，binlog dump 线程会告诉所有的 salve 节点，并将相应的 binlog 内容推送给slave节点。4、I/O 线程接管到 binlog 内容后，将内容写入到本地的 relay-log。5、SQL 线程读取 I/O 线程写入的 relay-log，并且依据 relay-log 的内容对从数据库做对应的操作。主从的作用实现读写拆散读写拆散可进步数据库的并发能力当备份数据应用适当中间件能够实现数据库的高可用搭建主从环境主库搭建拉取数据库镜像，这里应用的是 Mysql5.7镜像创立主库容器 docker run -d --name master -p 3307:3306 -v /www/m2/master/conf/:/etc/mysql/conf.d -v /www/m2/master/data:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=root mysql:5.7主库配置 my.conf # mysql 配置项[client]port=3306user=mysqldefault-character-set=utf8mb4[mysql]default-character-set=utf8mb4[mysqld]port=3306user=mysqlcharacter-set-server = utf8mb4default-time_zone = '+8:00'server_id=1log_bin=mysql-binbinlog_format=ROWslow-query-log-file=/logs/slow-query.loglong_query_time=1进入容器链接上mysql并新增test用户用于从库同步 docker exec master -it /bin/bashmysql -uroot -proot# 配置test用户和权限（明码也为test）grant replication slave on *.* to 'test'@'%' identified by 'test';flush privileges;#这里的grant replication slave是一个命令格局，示意赋予前面的账户以复制的权限。查看master节点的binlog状态 ...

InnoDB 是第一个残缺反对 ACID 事务的 MySQL 存储引擎，其特点是行锁设计 反对 MVCC、反对外键、提供一致性非锁定读。 缓冲池缓冲池简略来说就是一块内存区域，通过内存的速度来补救磁盘速度较慢对数据库性能的影响。 在数据库中进行读取页的操作，首先将从磁盘读到的页寄存在缓冲池中，这个过程称为将页 “FIX” 在缓冲池中。下一次再读取雷同的页时，首先判断该页是否在缓冲池中。若在缓冲池中，称该页在缓冲池中被命中，间接读取该页。 对于数据库中页的批改操作，则首先批改在缓冲池中的页，而后再以肯定的频率刷新到磁盘上。 缓冲池的大小，是通过参数 innodb_buffer_pool_size 来设置的。缓冲池中缓存的数据页类型有：索引页、数据页、undo 页、插入缓存、自适应哈希索引、InnoDB 存储的锁信息、数据字典信息等。 通常来说，数据库中的缓冲池是通过 LRU（Latest Recent Used）算法来进行治理的。即最频繁应用的页在 LRU 列表的前端，而起码应用的页在 LRU 列表的尾端。当缓冲池不能寄存新读取到的页时，将首先开释 LRU 列表中尾端的页。 但采纳这种算法时，会导致一个问题：当一次查问操作须要拜访表中许多页时，依据缓存的机制，会将这些页放到缓存 LRU 的首部，那么，其余操作频繁的页会被刷出，从而影响缓冲池的效率。 为了解决这个问题，InnoDB 的 LRU 列表进行了优化，退出了 midpoint 地位。 新读取到的页，尽管是新拜访的页，但并不是间接放到缓存列表的首部，而是放入到缓存列表的 midpoint 地位。 midpoint 是通过 innodb_old_blocks_pct 参数来配置的。在 InnoDB 存储引擎中，把 midpoint 之后的列表称为 old 列表，之前的列表称为 new 列表。 同时，InnoDB 引入了另一个参数 —— innodb_old_blocks_time ，用来示意页读取到 midpoint 地位后，须要期待多久才会被退出到 LRU 列表的 new 列表中。 在理论的利用过程中，能够通过命令 show engine innodb status ，变量 Buffer pool hit rate 示意缓冲池的命中率。这个比率越大，阐明缓冲池运行状态越好，当过低时，须要察看是否因为全表扫描引起的缓冲池被净化。 ...

作者：孙祚龙 爱可生南区交付服务部团队 DBA，负责客户 MySQL 的故障解决以及我司数据库集群治理平台 DMP 的日常运维。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 背景该问题来自于在给客户部署 MySQL 前进行服务器环境配置时，波及到服务器配置项敞开 numa，客户对此配置项的必要性产生了疑虑。针对这一疑虑，进行了以下对于 numa 的钻研。 一、NUMA 简介NUMA（Non-Uniform Memory Access，非一致性内存拜访）NUMA 服务器的基本特征是 Linux 将零碎的硬件资源划分为多个软件形象，称为节点（Node），每个节点上有独自的 CPU、内存和 I/O 槽口等。CPU 拜访本身 Node 内存的速度将远远高于拜访远地内存（零碎内其它节点的内存）的速度，这也是非统一内存拜访 NUMA 的由来。 二、NUMA 与 MySQL 剖析NUMA 的 4 种内存调配策略： 缺省（default）：总是在本地节点调配（以后过程运行的节点上）绑定（bind）：强制调配到指定节点上穿插（interleavel）：在所有节点或者指定节点上穿插分配内存优先（preferred）：在指定节点上调配，失败则在其余节点上调配NUMA 的内存调配策略对于过程来说，并不是乐观的。因为 NUMA 默认是应用 CPU 亲和的内存调配策略，即申请过程会从以后所处的 CPU 的 Node 申请分配内存。当某个须要耗费大量内存的过程耗尽了所处的 Node 的内存时，就会导致产生 swap，不会从近程 Node 分配内存，这就是 swap insanity 景象。 MySQL 数据库是单过程多线程的架构，在开启的 NUMA 服务器中，内存被调配到各 NUMA Node 上，而 MySQL 过程只能耗费所在节点的内存。所以在开启 NUMA 的服务器上，某些非凡场景中容易呈现零碎领有闲暇内存但产生 SWAP 导致性能问题的状况。 比方专用的 MySQL 单实例服务器，物理内存为 40GB，MySQL 过程所在节点的本地内存为 20G，而 MySQL 配置 30GB 内存，超出节点本地内存局部会被 SWAP 到磁盘上，而不是应用其余节点的物理内存，引发性能问题。 ...

MySQL 数据库区别于其余数据库的最重要的一个特地就是其插件式的表存储引擎。MySQL 存储引擎提供了一系列规范的治理和服务反对，每个存储引擎是底层物理构造的实现。 须要留神的是，存储引擎是基于表的，而不是数据库。 InnoDBInnoDB 存储引擎反对事务，其特点是行锁设计、反对外键、并反对相似于 Oracle 的非锁定读，即默认读取操作不会产生锁。 从 MySQL 数据库 5.5.8 开始，InnoDB 存储引擎是默认的存储引擎。InnoDB 通过应用多版本并发管制（MVCC）来取得高并发性，并且实现了 4 种隔离级别，默认是 REPEATABLE （可反复读）级别。同时，应用一种被称为 next-key-locking 的策略来防止幻读（phantom）景象的产生。除此之外，InnoDB 存储引擎还提供了插入缓存（insert buffer）、二次写（double write)、自适应哈希索引（adaptive hash index）、预读（read ahead）等高性能和高可用的性能。 对于表中数据的存储，InnoDB 存储引擎采纳了汇集的形式，因而每张表的存储都是按主键的程序进行寄存。如果没有显式地在表定义时指定主键，InnoDB 存储引擎会为每一行生成一个 6 字节的 ROWID，并认为作为主键。 MyISAMMyISAM 存储引擎不反对事务、表锁设计，反对全文索引。在 MySQL 5.5.8 版本之前，MyISAM 是默认的存储引擎。 此外，MyISAM 存储引擎的另一个不同凡响的中央是它的缓冲池只缓存索引文件，而不缓冲数据文件，这点和大多数的数据库都十分不同。 MyISAM 存储引擎表由 MYD 和 MYI 组成，MYI 用来存放数据文件，MYI 用来寄存索引文件。

前言性能调优，无疑是个宏大的话题，也是很多我的项目中十分重要的一环，性能调优难做是家喻户晓的，毕竟性能调优涵盖的面切实是太多了，在这里我就大略的讲一下企业中最罕用的四种调优——JVM调优、MySQL调优、Nginx调优以及Tomcat调优，一家之言，有什么说的不对的还请多包涵补充。 篇幅所限，有些货色是必定写不到的，所以本文只是挑了一些重要局部来分析，如果须要残缺具体的把握性能调优，能够来支付零碎整顿的性能调优笔记和相干学习材料 话不多说，坐稳扶好，发车喽！ 一、Jvm性能调优1、JVM类加载机制详解如下图所示，JVM类加载机制分为五个局部：加载，验证，筹备，解析，初始化，上面咱们就别离来看一下这五个过程。 1.1 加载在加载阶段，虚拟机须要实现以下三件事件： 1）通过一个类的全限定名来获取定义此类的二进制字节流。留神这里的二进制字节流不肯定非得要从一个Class文件获取，这里既能够从ZIP包中读取（比方从jar包和war包中读取），也能够从网络中获取，也能够在运行时计算生成（动静代理），也能够由其它文件生成（比方将JSP文件转换成对应的Class类）。 2）将这个字节流所代表的动态存储构造转化为办法区的运行时数据结构。 3）在Java堆中生成一个代表这个类的java.lang.Class对象，作为办法区这些数据的拜访入口。 绝对于类加载过程的其余阶段，加载阶段（精确地说，是加载阶段中获取类的二进制字节流的动作）是开发期可控性最强的阶段，因为加载阶段既能够应用零碎提供的类加载器来实现，也能够由用户自定义的类加载器去实现，开发人员们能够通过定义本人的类加载器去管制字节流的获取形式。 1.2 验证这一阶段的次要目标是为了确保Class文件的字节流中蕴含的信息是否合乎以后虚拟机的要求，并且不会危害虚拟机本身的平安。 1.3 筹备筹备阶段是正式为类变量分配内存并设置类变量的初始值阶段，即在办法区中调配这些变量所应用的内存空间。留神这里所说的初始值概念，比方一个类变量定义为： public static int v = 8080;实际上变量v在筹备阶段过后的初始值为0而不是8080，将v赋值为8080的putstatic指令是程序被编译后，寄存于类结构器<client>办法之中，这里咱们前面会解释。 然而留神如果申明为： public static final int v = 8080;在编译阶段会为v生成ConstantValue属性，在筹备阶段虚构机会依据ConstantValue属性将v赋值为8080。 1.4 解析解析阶段是指虚拟机将常量池中的符号援用替换为间接援用的过程。符号援用就是class文件中的： CONSTANT_Class_infoCONSTANT_Field_infoCONSTANT_Method_info等类型的常量。 上面咱们解释一下符号援用和间接援用的概念： 符号援用与虚拟机实现的布局无关，援用的指标并不一定要曾经加载到内存中。各种虚拟机实现的内存布局能够各不相同，然而它们能承受的符号援用必须是统一的，因为符号援用的字面量模式明确定义在Java虚拟机标准的Class文件格式中。间接援用能够是指向指标的指针，绝对偏移量或是一个能间接定位到指标的句柄。如果有了间接援用，那援用的指标必然曾经在内存中存在。1.5 初始化初始化阶段是类加载最初一个阶段，后面的类加载阶段之后，除了在加载阶段能够自定义类加载器以外，其它操作都由JVM主导。到了初始阶段，才开始真正执行类中定义的Java程序代码。 初始化阶段是执行类结构器<clint>办法的过程。<clint>办法是由编译器主动收集类中的类变量的赋值操作和动态语句块中的语句合并而成的。虚构机会保障<clint>办法执行之前，父类的<clint>办法曾经执行结束。p.s: 如果一个类中没有对动态变量赋值也没有动态语句块，那么编译器能够不为这个类生成<clint>()办法。 留神以下几种状况不会执行类初始化： 通过子类援用父类的动态字段，只会触发父类的初始化，而不会触发子类的初始化。定义对象数组，不会触发该类的初始化。常量在编译期间会存入调用类的常量池中，实质上并没有间接援用定义常量的类，不会触发定义常量所在的类。通过类名获取Class对象，不会触发类的初始化。通过Class.forName加载指定类时，如果指定参数initialize为false时，也不会触发类初始化，其实这个参数是通知虚拟机，是否要对类进行初始化。通过ClassLoader默认的loadClass办法，也不会触发初始化动作。1.6 类加载器虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取形容此类的二进制字节流”这个动作放到Java虚拟机内部去实现，以便让应用程序本人决定如何去获取所须要的类。实现这个动作的代码模块被称为“类加载器”。 对于任意一个类，都须要由加载它的类加载器和这个类自身一起确立其在Java虚拟机中的唯一性。这句话能够表白得更艰深一些：比拟两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提之下才有意义，否则，即便这两个类是来源于同一个Class文件，只有加载它们的类加载器不同，那这两个类就必然不相等。这里所指的“相等”，包含代表类的Class对象的equals()办法、isAssignableFrom()办法、isInstance()办法的返回后果，也包含了应用instanceof关键字做对象所属关系断定等状况。如果没有留神到类加载器的影响，在某些状况下可能会产生具备迷惑性的后果。 JVM提供了3品种加载器： 启动类加载器(Bootstrap ClassLoader)：负责加载 JAVA_HOME\lib 目录中的，或通过-Xbootclasspath参数指定门路中的，且被虚拟机认可（按文件名辨认，如rt.jar）的类。扩大类加载器(Extension ClassLoader)：负责加载 JAVA_HOME\lib\ext 目录中的，或通过java.ext.dirs零碎变量指定门路中的类库。应用程序类加载器(Application ClassLoader)：负责加载用户门路（classpath）上的类库。JVM通过双亲委派模型进行类的加载，当然咱们也能够通过继承java.lang.ClassLoader实现自定义的类加载器。 双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都该当有本人的父类加载器。这里类加载器之间的父子关系个别不会以继承（Inheritance）的关系来实现，而是都应用组合（Composition）关系来复用父加载器的代码。 双亲委派模型的工作过程是：如果一个类加载器收到了类加载的申请，它首先不会本人去尝试加载这个类，而是把这个申请委派给父类加载器去实现，每一个档次的类加载器都是如此，因而所有的加载申请最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈本人无奈实现这个加载申请（它的搜寻范畴中没有找到所需的类）时，子加载器才会尝试本人去加载。 采纳双亲委派的一个益处是比方加载位于rt.jar包中的类java.lang.Object，不论是哪个加载器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保障了应用不同的类加载器最终失去的都是同样一个Object对象。 在有些情境中可能会呈现要咱们本人来实现一个类加载器的需要，因为这里波及的内容比拟宽泛，我想当前独自写一篇文章来讲述，不过这里咱们还是略微来看一下。咱们间接看一下jdk中的ClassLoader的源码实现： protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException { // First, check if the class has already been loaded Class c = findLoadedClass(name); if (c == null) { try { if (parent != null) { c = parent.loadClass(name, false); } else { c = findBootstrapClass0(name); } } catch (ClassNotFoundException e) { // If still not found, then invoke findClass in order // to find the class. c = findClass(name); } } if (resolve) { resolveClass(c); } return c;}首先通过Class c = findLoadedClass(name);判断一个类是否曾经被加载过。如果没有被加载过执行if (c == null)中的程序，遵循双亲委派的模型，首先会通过递归从父加载器开始找，直到父类加载器是Bootstrap ClassLoader为止。最初依据resolve的值，判断这个class是否须要解析。而下面的findClass()的实现如下，间接抛出一个异样，并且办法是protected，很显著这是留给咱们开发者本人去实现的，这里咱们当前咱们独自写一篇文章来讲一下如何重写findClass办法来实现咱们本人的类加载器。 ...

前言咱们前几篇讲了索引是什么，如何应用explain剖析索引应用状况，如何去优化索引，以及show profiles剖析SQL语句执行资源耗费的学习。明天咱们来讲讲MySQL的各种锁，这里存储引擎咱们应用InnoDB 筹备工作创立表 tb\_innodb\_lock`drop table if exists test_innodb_lock;``CREATE TABLE test_innodb_lock (` `a INT (11),` `b VARCHAR (20)``) ENGINE INNODB DEFAULT charset = utf8;``insert into test_innodb_lock values (1,'a');``insert into test_innodb_lock values (2,'b');``insert into test_innodb_lock values (3,'c');``insert into test_innodb_lock values (4,'d');``insert into test_innodb_lock values (5,'e');`创立索引`create index idx_lock_a on test_innodb_lock(a);``create index idx_lock_b on test_innodb_lock(b);`MySQL 各种锁演示先将主动提交事务改成手动提交：set autocommit=0;咱们启动两个会话窗口 A 和 B，模仿一个抢到锁，一个没抢到被阻塞住了。行锁（写&读）A 窗口执行`update test_innodb_lock set b='a1' where a=1;````````SELECT * from test_innodb_lock;`咱们能够看到 A 窗口能够看到更新后的后果 B 窗口执行`SELECT * from test_innodb_lock;`咱们能够看到 B 窗口不能看到更新后的后果，看到的还是老数据，这是因为 a = 1 的这行记录被 A 窗口执行的 SQL 语句抢到了锁，并且没有执行 commit 提交操作。所以窗口 B 看到的还是老数据。这就是 MySQL 隔离级别中的"读已提交"。 窗口 A 执行 commit 操作`COMMIT;`窗口 B 查问`SELECT * from test_innodb_lock;`这个时候咱们发现窗口 B 曾经读取到最新数据了 行锁（写&写）窗口 A 执行更新 a = 1 的记录`update test_innodb_lock set b='a2' where a=1;`这时候并没有 commit 提交，锁是窗口 A 持有。 窗口 B 也执行更新 a = 1 的记录`update test_innodb_lock set b='a3' where a=1;`能够看到，窗口 B 始终处于阻塞状态，因为窗口 A 还没有执行 commit，还持有锁。窗口 B 抢不到 a = 1 这行记录的锁，所以始终阻塞期待。 ...

本文分享自华为云社区《Pt-osc工具连贯rds for mysql 数据库失败》，原文作者：云技术搬运工 。【景象】主机能够telent 通rds 端口，并且应用mysql-client 连贯失常； 如下图所示：应用pt-osc工具连贯时，始终没有响应，始终卡在哪里 等了4-5分钟左右后，会有响应，如下图所示：提醒不能连贯到x.x.x.x,而这个ip地址查到是备节点的ip。 【排查】在rds侧查看工作流如下图：发现pt-osc先连进来执行了一下show full processlist，而后卡了4-5分钟左右。联合下面截图中卡了4-5分钟后客户端的返回看，pt-osc工具先show full processlist失去备库的ip，而后去连贯备库了，然而备库因为作为高可用性而做的备份，不间接提供内部服务，所以是连贯不上的。 【解决】Pt-osc有一个参数：-recursion-method 【type：array; 默认值：processlist,host 用于判断是否存在从库的形式，能够的形式有： processlist：show processlist; hosts：show slave hosts dsn=DSN：DSNs from a table none：不查找从库】 pt-osc连贯时 加上--recursion-method=none 意为不查找从库，就失常了。具体命令为 #pt-online-schema-change --user=root --password=xxxxx --host=xx.xx.xx.xx P=3306,D=xx,t=xx --charset=utf8 --alter="ENFINE=InnoDB" --nocheck-replication-files --alter-foreign-keys-method=auto --recursion-method=none --execute。 【总结】Pt-osc工具连贯数据库时会先通过sql失去备库的ip，而后连贯备库。然而咱们rds的备库是无奈连贯的，因而会卡住。而连贯单机类型的rds for mysql 则失常。 点击关注，第一工夫理解华为云陈腐技术~

《MySQL面试小抄》索引考点一面总结我是肥哥，一名不业余的面试官！ 我是囧囧，一名踊跃找工作的小菜鸟，囧囧示意：面试最怕的就是面试官问的知识点太抽象，本人无奈疾速定位到关键问题点！！！ 本期次要面试考点 面试官考点之谈谈你对索引的了解？面试官考点之解释一下计算机层面索引快的起因？面试官考点之为什么不应用哈希构造作为索引构造？面试官考点之为什么不应用二叉树作为索引构造？面试官考点之为什么不应用B-Tree，而是B+Tree？面试官考点之索引是减速查问，那么是否应该给表尽可能建设多的索引列？ 面试官考点之谈谈你对索引的了解？谈到索引，最先联想到的大略就是字典目录，依据MySQL官网定义，索引是用来帮忙MySQL高效获取数据的一种数据结构。 实质上：索引是一种有序的疾速查找的数据结构，用来疾速高效的查找数据。 简略来说，能够类比字典目录，火车车次表。 面试官考点之解释一下计算机层面索引快的起因？计算机从磁盘获取数据，加载到内存期间，个别都要经验3个惯例的耗时过程： 1、寻道（工夫）：确定要读的数据在哪个磁道消耗的工夫2、旋转提早（工夫）：确定要读的数据在磁道上的哪个扇区消耗的工夫3、数据传输（工夫）：数据加载到内存消耗的工夫 每次加载数据，咱们称其为一次磁盘IO，每一次IO操作消耗工夫 = 寻道 + 旋转提早 + 数据传输（工夫短暂，能够忽略不计）。 事实上理论加载数据到内存的工夫十分短暂，一次IO操作次要的耗时来自寻道和旋转提早。 总体来说，个别一次IO操作，耗时大略只有几ms。如果是4ms，尽管看起来很短暂，然而数据库百万级别的数据加载一遍，就须要4000s，对于一个零碎来说，几乎是覆灭级别的。 咱们须要的就是缩小磁盘IO的次数，这也是应用索引的意义所在！！！索引可能保障在亿级别的数据，只须要2~4次磁盘IO，这无疑是个福音！ 面试官考点之为什么不应用哈希构造作为索引构造？个别失常的业务场景中，通常查问少数是范畴查问 相似： select id, name, age from sys_user where age between 18 and 28;哈希构造作为索引，那么存储引擎就会为每一行表记录计算出哈希值，哈希索引存储的就是HASH码； HASH码间接随机生成，并没有法则 没有法则的HASH码，导致数据随机散布存储，这就导致即便是两个很相近的行记录，极大可能也会被调配到不同的桶（磁盘块）中。 最坏的状况下每查找一条记录，都要进行一次磁盘IO （可怕）。 长处，哈希构造这样key-val 键值对的模式对于准确查找十分敏感，对全值匹配很敌对，所以单条记录查问效率十分高，工夫复杂度为 1，然而咱们日常业务来说，最罕用的还是范畴搜寻，所以不哈希构造适宜。 记住一点即可：Hash索引适宜准确查找，全值匹配，不适宜范畴查找。 MySQL目前有Memory引擎和NDB引擎反对Hash索引。 面试官考点之为什么不应用二叉树作为索引构造？首先察看一下二叉树构造 二叉树最多有两个子节点，这种构造导致树的高度会很高，减少IO次数，非凡状况下可能化为链表构造，相当于全表扫描，全量磁盘IO。 假如二叉树构造作为索引，现实状况下是一颗齐全二叉树，那么具备n个节点的齐全二叉树深度为log2x+1 （其中x示意不大于n的最大整数） 如果一个数据在二叉树构造的100层，那么为了查找到此数据，须要进行100次磁盘IO。更蹩脚状况下，二叉树会进化成链表构造，既，斜二叉树。 相似的均衡二叉树，高度也很高。 面试官考点之为什么不应用B-Tree，而是B+Tree？既然二叉树构造树高度很高，导致查问时磁盘IO减少，那B-Tree 呢？B-Tree能够存储更多的数据，高度更低，为什么不抉择？而是B+Tree？ B-Tree是多路均衡搜寻树，相比二叉树构造，能够极大的优化磁盘IO次数，然而B-Tree每个节点中不仅蕴含数据的key（索引值），还有data（整行记录），应用B-Tree构造，长处是找到索引就代表找到了数据记录。 既然如此为什么不应用B-Tree构造？还是老问题，磁盘IO数！！！ 咱们晓得MySQL读取数据是以页为单位（磁盘块），每页（或者说每个磁盘块）的存储空间是无限的 如果data 很大，将会导致每页存储的索引数量很小 所以数据表存储的数据量很大的时候同样会导致 B-Tree的深度很大，增大查问时的磁盘I/O次数，进而影响查问效率。 再说到B+Tree，B+Tree是对B-Tree 的一种优化结构，使其更适宜实现外存储索引构造 1、非叶子节点只存储键值信息(索引信息)2、所有的数据记录都依照键值大小程序寄存在同一层的叶子节点上益处：B+Tree的非叶子节点只存储键值信息，那么每一页能存储更多的索引，树的高度被压缩到很低，磁盘IO次数更小，个别状况下2~4次IO，即可查问到想要的记录。 而且因为表数据都是顺序存储在B+Tree构造的叶子节点，所以对于范畴查找很敌对，效率高！ 面试官考点之索引是减速查问，那么是否应该给表尽可能建设多的索引列？尽管索引的劣势是放慢查问效率，缩小磁盘IO次数，然而自觉创立过多索引，大大增加了保护索引的工夫老本和空间老本。 首先说一下索引的益处 1、缩小IO次数，进步-检索效率2、升高数据排序老本，能够缩小CPU耗费工夫老本 因为索引是有序的疾速查找构造，要保护索引的这个疾速查找且有序个性，须要一直的进行调整，而调整就须要工夫老本。 创立索引和保护索引要消耗工夫，当对表中的数据进行减少、删除和批改的时候，索引也要动静地保护，这样就升高了数据的保护速度。 而且这种工夫老本随着数据量的减少而减少！ ...

索引下推（INDEX CONDITION PUSHDOWN，简称 ICP）是 MySQL 5.6 公布后针对扫描二级索引的一项优化改良。总的来说是通过把索引过滤条件下推到存储引擎，来缩小 MySQL 存储引擎拜访基表的次数以及 MySQL 服务层拜访存储引擎的次数。ICP 实用于 MYISAM 和 INNODB，本篇的内容只基于 INNODB。 MySQL ICP 里波及到的知识点如下：1.MySQL 服务层：也就是 SERVER 层，用来解析 SQL 的语法、语义、生成查问打算、接管从 MySQL 存储引擎层上推的数据进行二次过滤等等。 2.MySQL 存储引擎层：依照 MySQL 服务层下发的申请，通过索引或者全表扫描等形式把数据上传到 MySQL 服务层。 3.MySQL 索引扫描：依据指定索引过滤条件（比方 where id = 1) ，遍历索引找到索引键对应的主键值后回表过滤残余过滤条件。 4.MySQL 索引过滤：通过索引扫描并且基于索引进行二次条件过滤后再回表。 ICP 就是把以上索引扫描和索引过滤合并在一起解决，过滤后的记录数据下推到存储引擎后的一种索引优化策略。这样做的长处如下： 1.缩小了回表的操作次数。 2.缩小了上传到 MySQL SERVER 层的数据。 ICP 默认开启，可通过优化器开关参数敞开 ICP：optimizer_switch='index_condition_pushdown=off' 或者是在 SQL 层面通过 HINT 来敞开。 接下来，具体看下不实用 ICP、应用 ICP 的具体示例来理清 ICP 的概念。 在不应用 ICP 索引扫描的过程：MySQL 存储引擎层只把满足索引键值对应的整行表记录一条一条取出，并且上传给 MySQL 服务层。 ...

MYSQL的联结索引，任意一列的值为NULL时，即便其余的字段雷同，也不会引起惟一索引抵触

数栈是云原生—站式数据中台PaaS，咱们在github和gitee上有一个乏味的开源我的项目：FlinkX，FlinkX是一个基于Flink的批流对立的数据同步工具，既能够采集动态的数据，也能够采集实时变动的数据，是全域、异构、批流一体的数据同步引擎。大家喜爱的话请给咱们点个star！star！star！ github开源我的项目：https://github.com/DTStack/fl... gitee开源我的项目：https://gitee.com/dtstack_dev... 随着数智化时代的到来，企业须要汇聚各业务板块数据，提供一个弱小的中间层为高频多变的业务场景提供撑持。基于此类需要，“数据中台”应运而生，将数据提炼为数据资产，转换成业务须要的数据「血液」。 数据中台的建设与经营，通常蕴含如下流动：数据汇聚、数据加工与提炼、对外提供数据服务这3局部。其中的数据汇聚、数据加工与提炼能力，是由作为数据中台建设基座的离线开发平台提供的。 一、利用场景例如，某服装企业须要统计最近3个月在全国不同城市中，不同样式的服装的销量状况/库存状况，用于领导下一步的销售流动和样式设计，这些数据须要每天更新，这就是典型的离线计算场景。为了实现上述流程，数据部门须要进行如下解决动作： 将最近3个月的销售数据、库存数据从业务零碎中抽取进去，要反对每天的增量抽取；联合统计需要，编写SQL进行统计；数据每天更新，须要以天为周期，触发数据抽取、SQL统计的脚本，每天进行数据更新；监控工作的运行状况，当产生异常情况时，须要进行排错、重刷历史数据等操作；为解决以上场景的问题，须要在数据采集、存储、加工等方面进行各种选型比照，通常可归类为以下2类： 1、基于MySQL、Greenplum等关系型或MPP类数据库： 数据采集：可采纳开源的Kettle、DataX等组件，配合shell脚本实现数据抽取；数据开发：本地文本编辑器、Navicat等工具，配合Shell脚本实现数据开发+周期调度；数据运维：人工察看后果数据产出，没有成熟的运维工具，通常都是业务方发现数据问题反馈给技术人员，响应滞后；集群运维：集群监控、告警、扩缩容均手动进行。2、基于Hadoop体系的技术计划 Hadoop体系通常会采纳HDFS+YARN作为基座，再配合Hive、Spark、Impala等引擎作为扩大；数据采集、开发、调度，均有多种可选，例如Sqoop、Hue、Oozie/Azkaban/AirFlow等，再配合Shell进行各类组件的买通与配置管理集群运维：可采纳开源的Cloudera Manager等工具。3、以上2类场景存在以下几种问题： 采集、开发、调度、运维的工具都比拟原始，由各种开源组件拼凑组合造成，没有对立高效的治理形式，实用于小规模团队，无奈满足大规模、团队合作化的数据中台建设；在数据采集方面，DataX、Kettle等组件个别都是单点应用，无奈满足大吞吐量、高并发的数据同步场景；在数据开发、任务调度方面，通常只能采纳文本编辑器+Navicat+Shell的原始计划，数据开发体验较差，在零碎参数、调度买通、函数治理、元数据查看等方面存在各种体验问题；调度引擎与工作运维方面，开源的Azkaban、AirFlow尽管反对根本的调度逻辑，但与开发环节彼此割裂，没有实现无缝买通。在工作运维方面，只有根本的状态监控，在重刷历史数据、工作异样解决、告警配置等方面均有所欠缺；在数据管理方面，开源的Hue只有根本的元数据查看，在数据权限、生命周期、元数据扩大等方面均难以满足。二、BatchWorks次要性能BatchWorks提供的各项性能，残缺笼罩上述场景中的各种需要，蕴含的功能模块如下： 1、数据同步： 分布式系统架构：基于自研分布式同步引擎（FlinkX），用于在多种异构数据源之间进行数据同步，具备高吞吐量、高稳定性的特点；丰盛的数据源反对：反对关系型数据库、半结构化存储、大数据存储、剖析性数据库等20余种不同的数据源；可视化配置：次要包含同步工作抉择源表、指标表、配置字段映射、配置同步速度等步骤，2分钟即可实现配置；断点续传：零碎自动记录每次的同步点位，下一周期运行时，主动从上次的读取地位持续同步，既能够加重源库的压力，又能够保障同步的数据无脱漏、无反复；整库同步：疾速、批量配置大量同步工作，节俭大量初始化精力。脏数据管理：在读取、写入阶段产生异样的数据，零碎可将这部分数据保留下来，便于用户及时排查脏数据问题。2、数据开发： 丰盛的工作类型：反对SparkSQL、HiveSQL、Python、Shell等10余种不同的工作类型，满足不同场景下的数据处理需要；丰盛的零碎参数：内置多个零碎参数，可依据须要指定自定义零碎参数，反对常量、变量，可指定丰盛的工夫格局和工夫计算模式；优良的开发体验：反对代码高亮、关键字/表名/字段名智能提醒、语法检测、编辑器主题、快捷键等性能，为用户提供优良的编码体验；本地文件导入：反对本地csv、txt文件导入至数据表，用于临时性数据分析；函数治理：反对Hive、Spark等计算引擎的函数查看、UDF函数的注册。3、调度引擎： 基于自研散布式调度引擎，满足工作的周期性、依赖性调度，反对百万级别任务调度；零碎可智能辨认当前任务的代码与依赖信息，并主动举荐上游工作；依据用户的调度配置，智能辨认超出有效期的工作，主动勾销运行，节约计算资源。4、运维核心： 主动监控并统计每日跑批进度、异常情况等信息，汇总易出错工作，帮助用户排查代码品质、平台运行状况等问题；实时监控实例运行状况，进行查看日志、重跑、终止、复原调度等操作；通过指定工夫范畴，疾速重刷历史数据，操作简略、便捷；可依据失败、超时等多种条件触发告警规定，通过短信、邮件等形式将异样信息发送给指定人员。5、平安保障： BatchWorks采纳多种形式保障数据安全和性能操作的平安，次要涵盖集群平安、数据安全和性能平安3局部： 集群平安：可对接开源Kerberos组件，保障平台平安拜访。数据安全：反对用户跨我的项目权限申请，可指定须要的具体操作内容和字段信息，经管理员审批通过后可拜访。性能平安：内置管理员等多种角色，不同的角色有不同的操作权限，保障性能平安。三、产品劣势1、全生命周期笼罩： 笼罩数据采集、数据处理、调度依赖、工作运维等场景，充沛满足离线数据开发过程中的各项需要，相比传统的开源工具，能够节俭80%数据开发工夫。 2、多引擎、异构对接： 兼容开源、Cloudera、Hortonworks、星环、华为Fusion Insight等各种Hadoop体系或MPP类数据库作为计算引擎；一套离线开发平台反对同时对接多套云环境的异构引擎，例如：一套BatchWorks同时对接阿里云 EMR、AWS EMR、本地机房TiDB引擎；3、自主知识产权：2大外围模块100%自研，把握全副知识产权 批流一体数据同步引擎FlinkX：基于Flink框架自主研发的分布式、插件化、批流一体数据同步引擎FlinkX，具备全量/增量/实时数据抽取全栈能力。该引擎曾经在Github上开源高性能散布式调度引擎DAGScheduleX：自主研发的分布式DAG调度引擎，反对百万级任务并发，具备周期性、依赖性、优先级等多种调度配置4、在线化、可视化操作： 产品通过Web页面为用户提供服务，屏蔽底层简单的分布式计算引擎，在线化开发平台，进步开发效率。

先说论断：能够。 我就是自学的Java，而后间接求职去的外包某软。15年中旬，因为不甘心年纪轻轻毫无激情的生存（其实就是钱太少），从原来的招商经营工作到职后，呆了三个多月，期间去了一趟北京，幻想着通过金融改变命运，入职了一家理财公司（前年的新闻曾经被查封），干了一个月，没有资源没有业绩，兴冲冲的回到老家信阳，就这样，根本没有路可选，这是前提。 想我堂堂本科毕业，连本人能干什么都不晓得，过后情绪十分丧气和挫败感激烈（过了那一段才发现，大部分人都跟我一样，不晓得本人适宜干什么，只有去尝试后能力发现）。幸好那时候我的一个大学同学，电话的时候跟我说了一句话：咱们这种家庭，除了技术，没有别的路。而后本人就决定了，做程序员！开发工资高！ 问题立马就来了，培训班费用两万多，我拿不起（是真拿不进去），只有一个方法了，自学！从网上下载了黑马程序员的根底视频，每天早上八点半开始看视频，对着敲代码，啥也不懂啊，看啥都陈腐，看啥都懵逼。就这样，学了三个月，至今都记得很分明，从七月十七开始，到十月十五找到工作，胜利转行。这有一个前提，我至今想起来都感觉这是一个必须的前提：得有人反对你。你想啊，起码三个月没有任何支出，得有一个人关照你吃穿用，而且不打击你，最好能给你激励和勇气，很难得，我很侥幸。第二个小前提，刚开始工作最好有个缓冲工夫，就是不是立马让你干活，因为一干你就露馅儿了，得有个工夫让你晓得开发到底是个什么事儿，这一点我也有点运气成分，第一份工作前三个月连电脑都没有，就天天在那看书，听人家聊开发的事件，缓缓也就懂了一点，不那么慌了。 再比照下当初的状况，15年的时候，市场极其火爆，基本上会写个九九乘法表，背点面试题，什么单例模式、Java关键字啥的有个理解，外包的面试运气好也就过了。真的不夸大，我那时候面试是纯正靠背面试题的，感觉学了三个月还是门都没入。而当初呢，就算是面试个高级，先不说根底，就一堆框架都能绕死你，什么Spring、Mybatis，能问的货色太多了，当初你问我我还是说不明确原理（手动微笑脸），而后还有数据库啥的，培训的工夫都得至多四到六个月。当初的面试比之前高了很多，而且也是寒冬，我的共事们连跳槽都不敢了。 提出这个问题的人关注于可行性，然而每个人状况又不一样，如果能满足第一个前提，而且自学工夫能够到六个月左右，而且本人真的认真在学而不是看起来致力，这样的话能够一试，否则还是不要浪费时间了。 如果大家对于学习Java有任何的问题，对于如何晋升学习Java以及学习办法、学习技巧、疾速达到待业的技术水平，都能够随时来问我，这是我建设了5年的Java学习交换QQ群：634930465。有不懂的问题能够随时在外面问，须要Java各个阶段的学习材料也能够在外面进行下载。对于前端和Python的问题也能够问。

①. Ubuntu上装置MySQL：sudo apt install mysql-server ②. 验证 MySQL 服务器正在运行：systemctl status mysql mysql.service - MySQL Community Server Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2020-04-28 20:59:52 UTC; 10min ago Main PID: 8617 (mysqld) Status: "Server is operational" ...③. 查看MySQL和服务器的版本：mysqladmin --version ④. 设置root明码：学习在 MySQL8.0 上，root 用户默认通过auth_socket插件受权。auth_socket插件通过 Unix socket 文件来验证所有连贯到localhost的用户。这意味着你不能通过提供明码验证root。如果你想以 root 身份登录 MySQL 服务器，应用其余的程序，验证办法如下： sudo mysqlALTER USER 'root'@'localhost'IDENTIFIED WITH mysql_native_password BY 'xxx明码';# mysql_native_password 本机明码算法加密exit;⑤. 重启MySQL：service mysql restart⑥. 测试一下：mysql -u root -p ...

前几天，有读者在后盾留言问我可有基于Gtid的Mysql主从同步的文章，我记得历史文章应该有提及过，也有可能是只是提及，可能没有具体的过程介绍，所以，明天，民工哥就给大家安顿一波。 什么是GTID？1、全局惟一，一个事务对应一个GTID2、代替传统的binlog+pos复制；应用master_auto_position=1主动匹配GTID断点进行复制3、MySQL5.6开始反对4、在传统的主从复制中，slave端不必开启binlog；然而在GTID主从复制中，必须开启binlog5、slave端在承受master的binlog时，会校验GTID值6、为了保障主从数据的一致性，多线程同时执行一个GTID组成Master_UUID:序列号举例：ceb0ca3d-8366-11e8-ad2b-000c298b7c9a:1-5ceb0ca3d-8366-11e8-ad2b-000c298b7c9a其实就是master的uuid值；1-5是序列号，每次一个事务实现都会自增1，也就是说下一次为1-6。工作原理1、master更新数据时，会在事务前产生GTID，一起记录到binlog日志中。2、slave端的i/o 线程将变更的binlog，写入到本地的relay log中。3、sql线程从relay log中获取GTID，而后比照slave端的binlog是否有记录。4、如果有记录，阐明该GTID的事务曾经执行，slave会疏忽。5、如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。6、在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全副扫描GTID主从配置版本：MySQL5.7 配置mastervim /etc/my.cnf [client] socket=/usr/local/mysql/mysql.sock [mysqld] basedir=/usr/local/mysql datadir=/usr/local/mysql/data user=mysql pid-file=/usr/local/mysql/data/mysqld.pid log-error=/usr/local/mysql/data/mysql.err socket=/usr/local/mysql/mysql.sock port=3306 server-id=1 gtid-mode=ON enforce-gtid-consistency=ON server-id=1 binlog_format=row log-bin=/usr/local/mysql/data/mysql-binsystemctl restart mysqldfirewall-cmd --add-port=3306/tcp --permanentfirewall-cmd --reload配置slavevim /etc/my.cnf [client] socket=/usr/local/mysql/mysql.sock [mysqld] basedir=/usr/local/mysql datadir=/usr/local/mysql/data user=mysql pid-file=/usr/local/mysql/data/mysqld.pid log-error=/usr/local/mysql/data/mysql.err socket=/usr/local/mysql/mysql.sock port=3306 server-id=2 gtid-mode=ON enforce-gtid-consistency=ON server-id=2 binlog_format=ROW log-bin=/usr/local/mysql/data/mysql-bin log_slave_updates=ON skip-slave-start=1systemctl restart mysqldfirewall-cmd --add-port=3306/tcp --permanentfirewall-cmd --reloadmaster受权配置mysql -uroot -pmysql> grant replication slave on *.* to 'rep'@'10.0.0.%' identified by '123';mysql> flush privileges;slave配置同步mysql -uroot -pmysql> change master to master_host='10.0.0.132', master_user='rep',master_password='123',master_port=3306,master_auto_position=1;mysql> start slave;查看slave的状态mysql> show slave status\G;*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 10.0.0.132 Master_User: rep Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000003 Read_Master_Log_Pos: 635 Relay_Log_File: slave-relay-bin.000005 Relay_Log_Pos: 848 Relay_Master_Log_File: mysql-bin.000003 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 635 Relay_Log_Space: 1308 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 1 Master_UUID: ceb0ca3d-8366-11e8-ad2b-000c298b7c9a Master_Info_File: /usr/local/mysql/data/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: ceb0ca3d-8366-11e8-ad2b-000c298b7c9a:1-4 Executed_Gtid_Set: ceb0ca3d-8366-11e8-ad2b-000c298b7c9a:1-4 Auto_Position: 1 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: 1 row in set (0.00 sec) ...

mysql的优化切实太多，这里仅仅列一些常见的，不可能齐全概括，后续有新学习的内容会继续更新。 explain 剖析select语句次要字段select_type查问类型 eg：SIMPLE 简略查问，UNION 联结查问，SUBQUERY 子查问table 查问的表partitions：type 索引查问类型 const：应用主键或者惟一索引进行查问的时候只有一行匹配 ref：应用非惟一索引 range：范畴查问 all：扫描全表 index：和all的区别是扫描的是索引树 system表只有一行或空表，const的特例 fulltext：全文索引，优先级很高 等等possible_keys 可能用到的索引key 理论应用的索引key_len 查问用到的索引长度（字节数）ref 等值查问会显示constrows 扫描的行数filtered 示意存储引擎返回的数据在server层过滤后，剩下多少满足查问的记录数量的比例extra ： Using index 查问不须要回表，并且where筛选条件是索引的是前导列Using where Using index 查问不须要回表，并且where筛选条件是索引列之一然而不是索引的不是前导列，或者是前导列的一个范畴查找NULL 查问须要回表，并且where筛选条件是索引的前导列Using where 查问须要回表，where筛选条件非索引的前导列，或者筛选条件非索引列 等等索引优化（1）建设联结索引，讲选择性强唯一性高的字段放在后面，范畴查找字段放在最初（2）索引笼罩，尽量避免回表（3）正当利用前缀索引，防止长字段索引过长，占用空间 索引下推ICP这是mysql5.6版本之后外部对于索引过滤数据做的优化，实用于比方范畴查问，含糊查问，因为最左前缀准则，导致联结索引生效的状况。以前的查问都是在存储引擎层先返回条件字段索引相干的数据，而后间接回表，在server层再对where后生效的索引查问条件进行过滤，在5.6之后，在引擎层会对where索引条件进行筛选，进一步缩小了对记录的过滤（用艰深的话就是5.6版本之前联结索引中生效的索引字段会回表再去判断，ICP会让判断条件从服务层下推至存储引擎层，对生效的索引字段在存储引擎层进行判断）。此时explain select语句的extra为Using index condition（查找应用了索引，并且须要回表查问数据）。 读写拆散将数据库分为主表和从表，主表作为写表，用于解决数据增删改和数据表操作，而从表作为读表个别会有多个，用于同步主表的批改，并且解决读操作。主表master和从表slave通过binlog来同步。咱们晓得，对于主表的批改会写入binlog，此时主表会开启一个binlog dump线程，将批改的binlog发送给从表的IO线程，从表会将binlog写入relay log，之后sql线程会将批改的局部同步到从表。 读写拆散带来的主从表数据不统一问题怎么解决？能够采纳 1.从主表读取未同步的数据 2.提早读 等等办法。 分库分表分表 垂直分表依照字段进行分表，应用频率高的字段放在一张表，应用频率低的放另一张表，同时，两张表都要有雷同的主键id。垂直分表的意义在于，表的最大尺寸是和字段数相干的，如果垂直拆分字段成不同的表，字段数降落了，表的最大尺寸则变大了，能包容更多数据。程度分表依据一个规定或字段（分片键）将数据分到不同的表里，保障所有表的字段都雷同，数据平均划分。分库 业务模块分库依据不同的业务模块来分库，将不同业务的数据库操作分隔开来按表分库对于上述程度分表产生的多个子表来说，能够将不同的子表分到不同的数据库中分库分表也会带来一些问题，比方： 不同库表关联查问问题首先设计初须要防止这种状况，如果呈现这种状况1.设计冗余字段，防止跨库的join2.增加全局表，保留一些全局数据等很少批改的数据分布式事务问题基于两阶段提交的XA事务分布式id问题能够利用雪花算法，或者专门的id生成服务解决数据扩容因业务量减少须要减少子表，这个时候须要从新设置分片规定，并且做数据迁徙，保证数据均匀分布跨表排序分页分片键作为排序字段，则失常应用排序；反之，则须要在不同子表中别离查问后果并汇总，再次排序ER分片对于一些关联表，能够正当设置它们的分片字段，使得雷同分片数据的表在同一个数据分片上，防止跨库join。比方员工表和公司表，假如他们以公司id关联，能够以公司id来分片，这样能保障同一个库内，公司表和员工表的公司id都是一样的。此外，这些问题能够利于一些市面上成熟的中间件来解决，比方ShardingSphere，mycat，Sharding-JDBC，DRDS等等。

XAMPP应用本地MySQL装置XAMPP时不要勾选MySQL 因为XAMPP装置好后，它自带的MySQL和我以前装置的MySQL有抵触，即便在XAMPP的控制面板里批改了端口也没有成果，导致我用不了MySQL 然而我又不想删掉本人以前装置的MySQL，那么罗唆不必它的，咱们装置的时候就不装置MySQL XAMPP下载：https://cloud.189.cn/t/qiMzyefqyARr 配置Apache装置好后，配置Apache端口，默认80，你不抵触不批改也行，而后批改httpd.conf文件，我间接Ctrl+F，搜寻所有的80，而后批改成了8081 还有把httpd-ssl.conf文件里的所有443批改成4433 配置MySQL来到你的XAMPP装置目录的phpMyAdmin下，我的是D:\SoftWare\XAMPP\phpMyAdmin，而后编辑config.inc.php文件 而后进入D:\SoftWare\XAMPP\phpMyAdmin\libraries，编辑config.default.php文件 运行后果在XAMPP开启服务 而后浏览器拜访：localhost:8081，显示如下，而后点击phpMyAdmin，胜利拜访 我是分割线 实际上，我下面没有下拉，下拉就呈现下图的谬误 这时候持续去phpMyAdmin上面的config.inc.php配置下，把上面截图所示的User for advanced features 这部分的用户pma批改成root用户 刷新页面，就没有报错了，如果还有报错，显示phpMyAdmin高级性能尚未齐全设置局部性能未激活的话，那就按它来，点查找起因，之后会新建进去一个名为phpmyadmin的数据库，而后就OK了 参考资料：https://jingyan.baidu.com/article/48b558e3ede7747f39c09a55.html

简介该篇文章对MySQL中的日志进行总结与简略介绍，不会波及的太深。次要的目标是为了对MySQL中的日志文件有一个体系化的理解。前面会对每一种日志文件做具体的剖析与总结。 日志分类MySQL中的日志文件，配置文件、谬误日志文件、二进制文件(binary log)、慢查问日志(slow-query-log)、全量日志(genera log)、审计日志(audit log)、数据库文件&数据表文件、存储引擎文件、中继日志(relay log)、过程文件(PID)和Socket文件。 参数文件参数文件就是MySQL中的配置文件，在Linux下的my.cnf文件、Windows下的my.ini文件。文件内容次要分为server和client两个模块。server模块配置的是无关MySQL的服务信息，例如慢查问日志。client模块配置的是无关MySQL客户端连贯信息，例如客户端连贯的端口号。文件格式大抵如下: [client]port = 3306default-character-set = utf8mb4[mysqld]user = mysqlport = 3306sql_mode = ""default-storage-engine = InnoDBdefault-authentication-plugin = mysql_native_passwordcharacter-set-server = utf8mb4collation-server = utf8mb4_unicode_ciinit_connect = 'SET NAMES utf8mb4'slow_query_loglong_query_time = 3slow-query-log-file = /var/lib/mysql/mysql.slow.loglog-error = /var/lib/mysql/mysql.error.logdefault-time-zone = '+8:00'谬误日志文件谬误日志文件记录了MySQL从启动、运行和敞开几个环节中的日志信息。例如连贯MySQL连贯失败、查问命令谬误、SQL执行流程等等。对于定位MySQL谬误有着很大的帮忙。文件大抵内容如下: Version: '5.7.28-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server (GPL)2021-04-17T21:23:00.865868Z 3 [Note] Aborted connection 3 to db: 'exam_wechat' user: 'root' host: '172.18.0.1' (Got timeout reading communication packets)2021-04-17T21:23:00.865969Z 2 [Note] Aborted connection 2 to db: 'exam_wechat' user: 'root' host: '172.18.0.1' (Got timeout reading communication packets)2021-04-19T22:33:24.137143Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 18415ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)2021-04-20T07:03:21.765208Z 79 [Note] Access denied for user 'root'@'172.18.0.1' (using password: NO)2021-04-20T07:03:23.825044Z 81 [Note] Aborted connection 81 to db: 'unconnected' user: 'root' host: '172.18.0.1' (Got an error reading communication packets)2021-04-20T07:14:25.033983Z 82 [Note] Access denied for user 'root'@'172.18.0.1' (using password: NO)2021-04-20T07:14:27.442608Z 84 [Note] Aborted connection 84 to db: 'unconnected' user: 'root' host: '172.18.0.1' (Got an error reading communication packets)2021-04-20T07:27:13.971644Z 83 [Note] Aborted connection 83 to db: 'unconnected' user: 'root' host: '172.18.0.1' (Got timeout reading communication packets)2021-04-20T07:41:02.916249Z 85 [Note] Aborted connection 85 to db: 'unconnected' user: 'root' host: '172.18.0.1' (Got timeout reading communication packets)如何开始谬误日志。只有在MySQL中的配置文件中配置动向log_error即可。 ...

装置: go get -u github.com/go-sql-driver/mysql GO语言的操作数据库的驱动原生反对连接池, 并且是并发平安的 规范库没有具体的实现 只是列出了一些须要的第三方库实现的具体内容 //第一次连贯MySQL胜利package mainimport ( "database/sql"_ "github.com/go-sql-driver/mysql" // _想当于init()初始化"log")func main() { // root 用户名 1qa2ws3ed是明码 后边的书ip:port gouse 库名dsn := "root:1qa2ws3ed@tcp(127.0.0.1:3306)/gouse"db, err := sql.Open("mysql", dsn) if err != nil { panic(err)} // ping是尝试连贯MySQL数据库 if err = db.Ping(); err != nil{ panic(err)}log.Fatalln("Mysql数据库连贯胜利") }Go调用MySQL封装成函数 package mainimport ( "database/sql""encoding/json""fmt"_ "github.com/go-sql-driver/mysql")var db *sql.DBfunc InitDB() (err error) {dsn := "root:1qa2ws3ed@tcp(127.0.0.1:3306)/gouse" db, err = sql.Open("mysql", dsn)CheckErr(err) err = db.Ping()CheckErr(err)fmt.Println("数据库连贯胜利...") // 设置数据库连接池最大连接数db.SetConnMaxLifetime(10) //设置最大闲置连接数db.SetMaxIdleConns(5) return}type data struct {Username string json:"username"Password string json:"password"}func main() {err := InitDB()CheckErr(err) ...

简介指标是让云上数据仓库用户及开发者通过简略的步骤体验基于AnalyticDB MySQL版和DMS构建云原生数据仓库的次要流程，场景将通过实例的开明、构造与数据的初始化、报表的开发、报表可视化等环节，用3个具体的利用场景来体验AnalyticDB MySQL版在新批发场景下的交互查问和ETL计算速度，以及通过DMS进行数据仓库数据报表开发的流程。 提供的数据集是一个批发场景的模仿数据，包含客户信息、订单记录、货物信息、国家地区信息等内容，数据总量10GB，最大数据表记录数为5999万条。 产品简介云原生数据仓库AnalyticDB MySQL版是一种反对高并发低延时查问的新一代云原生数据仓库，高度兼容MySQL协定以及SQL:2003 语法规范，能够对海量数据进行即时的多维分析透视和业务摸索，疾速构建企业云上数据仓库。 数据管理DMS是基于阿里巴巴团体十余年的数据库服务平台的云版本，提供免装置、免运维、即开即用、多种数据库类型与多种环境对立的web数据库治理终端；能够为企业用户疾速复制搭建与阿里团体等同平安、高效、标准的数据库DevOps研发流程、数仓开发解决方案。 创立高权限账号ADB集群详情页，按需自定义高权限的账号与明码 每个集群仅限1个高权限账号，可批改明码； 后续可通过DMS新建一般账号（ADB实例在DMS上间接以收费的自在操作管控模式应用即可）地址：https://ads.console.aliyun.co... 抉择已创立ADB实例所在的地区，并点击实例名称。 创立数据库数据库库名可按需自定义。 地址：https://ads.console.aliyun.co... 抉择已创立ADB实例所在的地区，并点击实例名称。 创立OSS表面阐明： 下列建表语句须要依据ADB的地区别离替换endpoint和URL参数中的字符串。例如ADB在北京区域。须要将endpoint ”oss-cn-shenzhen-internal.aliyuncs.com“ 替换成”oss-cn-beijing-internal.aliyuncs.com“，须要将URL中的”oss://adb-tpch-shenzhen“ 替换成”oss://adb-tpch-beijing“各个地区替换的代码： 深圳：shenzhen北京：beijing杭州：hangzhou上海：shanghai张家口：zhangjiakou留神：下列建表语句须要依据您云账号的accessid、accesskey 替换前方执行。 地址：https://dms.aliyun.com/ 门路：全副性能-数据计划-数据导入初始化表构造语句如下：（注，脚本须要本地编辑替换相干信息后，保留为一个.sql后缀的文本用于工单的提交） ####1、CUSTOMER 表面CREATE TABLE `OSS_CUSTOMER` ( `C_CUSTKEY` int NOT NULL, `C_NAME` varchar NOT NULL, `C_ADDRESS` varchar NOT NULL, `C_NATIONKEY` int NOT NULL, `C_PHONE` varchar NOT NULL, `C_ACCTBAL` decimal(12, 2) NOT NULL, `C_MKTSEGMENT` varchar NOT NULL, `C_COMMENT` varchar NOT NULL ,`dummy` varchar) engine='oss'TABLE_PROPERTIES='{ "endpoint":"oss-cn-shenzhen-internal.aliyuncs.com", "accessid":"xxxxxxxx", "accesskey":"xxxxxxxx", "delimiter":"|", "URL":"oss://adb-tpch-shenzhen/tpch/10g/customer/customer.tbl"}';####2、ORDERS表面CREATE TABLE `OSS_ORDERS` ( `O_ORDERKEY` bigint NOT NULL, `O_CUSTKEY` int NOT NULL, `O_ORDERSTATUS` varchar NOT NULL, `O_TOTALPRICE` decimal(12, 2) NOT NULL, `O_ORDERDATE` date NOT NULL, `O_ORDERPRIORITY` varchar NOT NULL, `O_CLERK` varchar NOT NULL, `O_SHIPPRIORITY` int NOT NULL, `O_COMMENT` varchar NOT NULL ,`dummy` varchar) engine='oss'TABLE_PROPERTIES='{ "endpoint":"oss-cn-shenzhen-internal.aliyuncs.com", "accessid":"xxxxxxxx", "accesskey":"xxxxxxxx", "delimiter":"|", "URL":"oss://adb-tpch-shenzhen/tpch/10g/orders/orders.tbl"}';####3、LINEITEM表面CREATE TABLE `OSS_LINEITEM` ( `L_ORDERKEY` bigint NOT NULL, `L_PARTKEY` int NOT NULL, `L_SUPPKEY` int NOT NULL, `L_LINENUMBER` bigint NOT NULL, `L_QUANTITY` decimal(12, 2) NOT NULL, `L_EXTENDEDPRICE` decimal(12, 2) NOT NULL, `L_DISCOUNT` decimal(12, 2) NOT NULL, `L_TAX` decimal(12, 2) NOT NULL, `L_RETURNFLAG` varchar NOT NULL, `L_LINESTATUS` varchar NOT NULL, `L_SHIPDATE` date NOT NULL, `L_COMMITDATE` date NOT NULL, `L_RECEIPTDATE` date NOT NULL, `L_SHIPINSTRUCT` varchar NOT NULL, `L_SHIPMODE` varchar NOT NULL, `L_COMMENT` varchar NOT NULL ,`dummy` varchar) engine='oss'TABLE_PROPERTIES='{ "endpoint":"oss-cn-shenzhen-internal.aliyuncs.com", "accessid":"xxxxxxxx", "accesskey":"xxxxxxxx", "delimiter":"|", "URL":"oss://adb-tpch-shenzhen/tpch/10g/lineitem/lineitem.tbl"}';####4、NATION表面CREATE TABLE `OSS_NATION` ( `N_NATIONKEY` int NOT NULL, `N_NAME` varchar NOT NULL, `N_REGIONKEY` int NOT NULL, `N_COMMENT` varchar ,`dummy` varchar) engine='oss'TABLE_PROPERTIES='{ "endpoint":"oss-cn-shenzhen-internal.aliyuncs.com", "accessid":"xxxxxxxx", "accesskey":"xxxxxxxx", "delimiter":"|", "URL":"oss://adb-tpch-shenzhen/tpch/10g/nation/nation.tbl"}';####5、PART表面CREATE TABLE `OSS_PART` ( `P_PARTKEY` int NOT NULL, `P_NAME` varchar NOT NULL, `P_MFGR` varchar NOT NULL, `P_BRAND` varchar NOT NULL, `P_TYPE` varchar NOT NULL, `P_SIZE` int NOT NULL, `P_CONTAINER` varchar NOT NULL, `P_RETAILPRICE` decimal(12, 2) NOT NULL, `P_COMMENT` varchar NOT NULL ,`dummy` varchar) engine='oss'TABLE_PROPERTIES='{ "endpoint":"oss-cn-shenzhen-internal.aliyuncs.com", "accessid":"xxxxxxxx", "accesskey":"xxxxxxxx", "delimiter":"|", "URL":"oss://adb-tpch-shenzhen/tpch/10g/part/part.tbl"}';####6、PARTSUPP表面CREATE TABLE `OSS_PARTSUPP` ( `PS_PARTKEY` int NOT NULL, `PS_SUPPKEY` int NOT NULL, `PS_AVAILQTY` int NOT NULL, `PS_SUPPLYCOST` decimal(12, 2) NOT NULL, `PS_COMMENT` varchar NOT NULL ,`dummy` varchar) engine='oss'TABLE_PROPERTIES='{ "endpoint":"oss-cn-shenzhen-internal.aliyuncs.com", "accessid":"xxxxxxxx", "accesskey":"xxxxxxxx", "delimiter":"|", "URL":"oss://adb-tpch-shenzhen/tpch/10g/partsupp/partsupp.tbl"}';####7、REGION表面CREATE TABLE `OSS_REGION` ( `R_REGIONKEY` int NOT NULL, `R_NAME` varchar NOT NULL, `R_COMMENT` varchar ,`dummy` varchar) engine='oss'TABLE_PROPERTIES='{ "endpoint":"oss-cn-shenzhen-internal.aliyuncs.com", "accessid":"xxxxxxxx", "accesskey":"xxxxxxxx", "delimiter":"|", "URL":"oss://adb-tpch-shenzhen/tpch/10g/region/region.tbl"}';####8、SUPPLIER表面CREATE TABLE `OSS_SUPPLIER` ( `S_SUPPKEY` int NOT NULL, `S_NAME` varchar NOT NULL, `S_ADDRESS` varchar NOT NULL, `S_NATIONKEY` int NOT NULL, `S_PHONE` varchar NOT NULL, `S_ACCTBAL` decimal(12, 2) NOT NULL, `S_COMMENT` varchar NOT NULL ,`dummy` varchar) engine='oss'TABLE_PROPERTIES='{ "endpoint":"oss-cn-shenzhen-internal.aliyuncs.com", "accessid":"xxxxxxxx", "accesskey":"xxxxxxxx", "delimiter":"|", "URL":"oss://adb-tpch-shenzhen/tpch/10g/supplier/supplier.tbl"}';创立ADB表创立ADB表 ...

运算符算术运算符运算符作用a + b加法a - b减法a * b乘法a / b，DIV(a,b)除法a % b, MOD(a,b)除余比拟运算符运算符作用=等于，不能比拟 Null<> 或 !=不等于，不能比拟 Null<=>NULL 的平安的等于<小于<=小于等于>大于>=大于等于BETWEEN存在于指定范畴IN存在于指定汇合IS NULL为 NULLIS NOT NULL不为 NULLLIKE通配符匹配REGEXP 或 RLIKE正则表达式匹配当应用比拟运算符时，满足条件则返回 1，否则返回 0。 逻辑运算符逻辑运算符又称为布尔运算符，用来确认表达式的真和假。 运算符作用NOT 或 !逻辑非AND 或 &&逻辑与OR 或 ` `逻辑或XOR逻辑异或罕用函数字符串函数函数性能CONCAT(s1,s2,...,sn)连贯 s1,s2,...,sn 为一个字符串INSERT(str,x,y,instr)将字符串 str 从第 x 地位开始，y个字符长的子串替换为字符串 instrLOWER(str)将字符串 str 中所有的字符变为小写UPPER(str)将字符串 str 中所有字符变为大写LEFT(str,x)返回字符串 str 最右边的 x 个字符RIGHT(str,x)返回字符串 str 最左边的 x 个字符LPAD(str,n,pad)用字符串 pad 对 str 最右边进行填充，直到长度为 n 个字符长度RPAD(str,n,pad)用字符串 pad 对 str 最左边进行填充，直到长度为 n 个字符长度LTRIM(str)去掉字符串 str 左侧的空格LTRIM(str)去掉字符串 str 行尾的空格REPEAT(str,x)返回 str 反复 x 次的后果TRIME(str)去掉字符串行尾和行头的空格SUBSTRING(str,x,y)返回从字符串 str x 地位起 y 个字符长度的子串数值函数函数性能ABS(x)返回 x 的绝对值CEIL(x)返回大于 x 的最小整数值FLOOR(x)返回小于 x 的最大整数值MOD(x,y)返回 x/y 的模RAND()返回 0~1 内的随机数ROUND(x,y)返回参数 x 的四舍五入的有 y 位小数的值TRUNCATE(x,y)返回数字 x 截断为 y 位小数的后果日期函数函数性能CURDATE()返回以后日期CURTIME()返回以后工夫NOW()返回以后的日期和工夫WEEK(date)返回日期 date 为一年中的第几周YEAR(date)返回日期 date 的年份HOUR(time)返回 time 的小时值MINUTE(time)返回 time 的分钟值MONTHNAME(date)返回 date 的月份名DATE_FORMAT(date,fmt)返回按字符串 fmt 格式化日期 date 值DATE_ADD(date,INTERVAL expr type)返回一个日期或工夫加上一个工夫距离的工夫值DATEDIFF(expr,expr2)返回起始工夫 expr 和完结工夫 expr2 之间的天数流程函数函数性能IF(value, t, f)如果 value 是真，返回 t，否则返回 fIFNULL(value1, value2)如果 value1 不为空， 返回 value1，否则返回 value2CASE WHEN [value1] THEN [result1] ELSE [default] END如果 value1 为真，返回 result1，否则返回 defaultCASE [expr] WHEN [value1] THEN [result1] ... ELSE [default] END如果 expr 等于 value1 ，返回 result1，否则返回 default

数值类型整数类型字节最小值最大值TINYINT1有符号 $-2^7$无符号 0有符号 $2^7-1$无符号 $2^8-1$SMALLINT2有符号 $-2^{15}$无符号 0有符号 $2^{15}-1$无符号 $2^{16}-1$MEDIUMINT3有符号 $-2^{23}$无符号 0有符号 $2^{23}-1$无符号 $2^{24}-1$INT、INTEGER4有符号 $-2^{31}$无符号 0有符号 $2^{31}-1$无符号 $2^{32}-1$BIGINT8有符号 $-2^{63}$无符号 0有符号 $2^{63}-1$无符号 $2^{64}-1$浮点数类型字节最小值最大值FLOAT4$\pm1.175494351E-38$$\pm3.402823466E+38$DOUBLE8$\pm2.2250738585072014E-308$$\pm1.7976931348623157E+308$定点数类型字节形容DEC(M,D),DECIMAL(M,D)M+2最大取值范畴与 DOUBLE 雷同，给定 DECIMAL 的无效取值范畴由M和D决定整数类型在整数类型中，依照取值范畴和存储形式不同，分为 tinyint 、smallint、mediumint、int 和 bigint 这 5 个类型。如果超出类型范畴的操作，会产生 “Out of range” 谬误提醒 对于整型数据，MySQL 还反对在类型名称前面的小括号内指定显示宽度，例如int(5)示意当数值宽度小于 5 位的时候在数字后面填满宽度，如果不显式指定宽度则默认为 int(11)。如果配合 zerofil 应用时，数字位数不够的空间用字符 0 填满。 设置宽度后，如果插入大于宽度限度的值，不会对插入的数据有任何影响，还是依照类型的理论精度进行保留，这时，宽度格局理论曾经没有意义。 很多的整数类型都有一个可选属性 UNSIGNED（无符号），如果须要在字段外面保留非正数或者须要较大的上限值时，能够用此选项，它的取值范畴是正常值的上限取 0，下限取原值的 2 倍。如果一个列指定为 zerofill，则 MySQL 主动为该列增加 UNSIGNED 属性。 另外，整数类型还有一个属性：AUTO_INCREMENT。在须要产生惟一标识符或程序值时，可利用此属性，这个属性只用于整数类型。值个别从 1 开始，每行减少 1。一个表中最多只能有一个 AUTO_INCREMENT 列。对于任何想要应用 AUTO_INCREMENT 的列，应该定义为 NOT NULL，并定义为 PRIMARY KEY 或者定义为 UNIQUE 键。 ...

把一些mysql的罕用语法进行下汇总 1.简略语句/*websites 表名 NAME alexa url country 字段*/SELECT * FROM websites; /* 查问表所有数据 */SELECT NAME FROM websites; /* 查问表字段数据 */SELECT * FROM websites where name = "广西"; /* 查问表字段下条件数据 */SELECT * from websites where name like "_o%"; /* 含糊查问表下数据 */SELECT * FROM websites where id BETWEEN "1" AND "5"; /* 查问表下字段范畴数据 */SELECT * FROM websites WHERE name in ("广西","百度"); /* 查问表字段下固定条件数据 */SELECT DISTINCT country FROM Websites; /* 查问去重值 */SELECT * FROM Websites WHERE country = "CN" AND alexa > 50; /*查问表下范畴条件数据*/SELECT * FROM Websites WHERE country = "USA" OR country="sh"; /* 查问表下条件不同值 */SELECT * FROM Websites ORDER BY alexa; /* 查问表下值排序后果 */SELECT * FROM Websites ORDER BY alexa DESC; /* 查问表下排序后果降序 */SELECT * FROM Websites LIMIT 2; /* 查问表下范畴数据 */SELECT name as zzz from websites; /*别名查问表下数据*/2.分页select _column,_column from _table [where Clause] [limit N][offset M]select * : 返回所有记录limit N : 返回 N 条记录offset M : 跳过 M 条记录, 默认 M=0, 独自应用仿佛不起作用limit N,M : 相当于 limit M offset N , 从第 N 条记录开始, 返回 M 条记录实现分页： ...

引子最近看一些文章的时候，看到事务的概念，只记得在很早的时候接触过，想不起来有什么用，查问了材料后发现还是挺有用的。 OriginMy GitHub介绍事务处理（Transaction processing）是计算机科学中的信息处理，它被分成单个不可分割的操作，称为事务（transaction）。每个事务作为一个残缺的单元必须胜利或者失败，绝不可能局部实现。事务处理通过确保零碎上相互依赖的操作，全副胜利实现或者全副胜利勾销，在已知的统一状态上维持零碎的完整性。 举个例子，一个典型的银行交易：将 100 从客户的储蓄账户转移到客户的支票账户。这个交易波及至多 2 个独立的操作：借记储蓄帐户 100，记入支票账户 100。如果一个操作胜利，另外一个操作失败，银行的账簿最初会不均衡。这里必须要有一个形式去保障所有操作都胜利或都失败，这样在银行的整个数据库中才不会前后矛盾。 在事务中链接了多个操作时，确保所有的操作没有谬误的实现，或者都失败。如果其中的一些操作实现但在尝试其它操作时产生了谬误，则事务处理零碎会“回滚（rolls back）” 事务的所有操作（包含曾经胜利的操作），从而打消事务的所有痕迹，并将零碎复原到处理事务开始之前所处的统一的已知状态。如果一个事务的所有操作都胜利的实现，这个事务会被零碎提交（committed），所有对数据库的更改将会是永久性的，一旦事务实现不能被回滚。 通常，事务是同时公布的，如果它们重叠，可能会产生抵触。例如一个客户的储蓄账户上有 150，尝试转账给另外一个人 100，同时转移 100 到支票账户，那么只有其中的一个能够胜利。然而，强制事务依照程序执行是低效的。因而事务处理的并发编程实现，保障最终后果没有抵触，与任何程序执行事务时达到的后果雷同。在这个例子中，这就意味着不论那个事务先公布，不论是先转账给另外一个人还是转移到支票账户胜利了，另外一个操作就会失败。 办法所有事务处理零碎的根本准则都一样。然而，术语可能因事务处理零碎而异，上面应用的术语不肯定通用。 Rollback事务处理零碎通过在批改数据库时，记录数据库的中间状态来确保数据库完整性，而后如果一个事务无奈提交，应用这些记录将数据库复原到已知状态。 Rollforward能够保留对数据库管理系统的所有批改的独自日志。这个对回滚并不需要，但在数据库产生故障时更新数据管理系统很有用，因而有些事务处理零碎提供这个性能。如果数据库管理系统齐全失败，则必须从最近的备份中复原。备份不会反映自备份以来所提交的事务。然而，一旦数据库管理系统复原了，就能够将日志利用于数据库（rollforward）以使数据库管理系统放弃最新。 Deadlock在一些状况下，两个事务可能在解决的过程中，同时尝试拜访数据库的同一部分，从而阻止它们持续运行。例如，事务 A 拜访了数据库的 X ，事务 B 拜访了数据库的 Y。如果此时，事务 A 尝试拜访数据库的 Y ，事务 B 尝试拜访数据库的 X ， 则一个死锁（Deadlock）产生了，并且两个事务都不能继续下去。 事务处理零碎旨在检测这些死锁何时产生。通常，两个事务都将被勾销并回滚，而后它们将以不同的程序主动再次启动，以便不再产生死锁。或者有些时候，只有其中的一个死锁事务将会被勾销和回滚，在短暂的提早后主动重启。 死锁可能波及 3 个或更多的事务。波及的事务越多，它们检测的难度就越大，因而事务处理零碎能够检测到的死锁，在理论中是有限度的。 Compensating transaction在提交和回滚机制不可用或不冀望的零碎中，弥补事务常常用来撤销失败的事务，并且将零碎复原到之前的状态。 ACID 规范Jim Gray 在 20 世纪 70 年代定义了一个牢靠事务零碎的特质，缩写为 ACID —— atomicity（原子性）、consistency（一致性）、 isolation（独立性）、durability（耐久性） 。 Atomicity事务对状态的扭转是原子的：要么全副产生，要么都不产生。 Consistency一个事务是状态的一种正确转换。作为一组采取的行为不违反跟状态相干的任何完整性的束缚。 Isolation即便事务并发执行，对于每个事务 T ，其余事务看起来在 T 之前或 T 之后执行，但不是两者同时执行。 Durability一旦事务胜利实现（提交），它对数据库的更改，将在数据库失败后持续存在并保留其更改。 长处事务处理有上面的长处： 它容许用户之间共享计算机资源它将作业处理的工夫正当转换它防止了在没有人工交互和监督的状况下闲置计算资源它被用在低廉的计算机上，通过放弃对这些低廉资源的高利用率来帮忙摊派老本毛病事务处理有上面的毛病： ...

MySql - 一条语句是怎么插入磁盘的MySql - 多条语句是怎么存入磁盘的MySql - 怎么从磁盘查找数据MySql - 对select是怎么解决的MySql - 对update是怎么解决的MySql - 对事务是怎么解决的 浅谈ACID

undo日志链表这个要从MySql - 对update是怎么解决的的undo日志文件说起。咱们对数据进行批改之前，都会把数据写入到undo日志中，如果对一条数据做了屡次批改，那这些数据就会通过链表关联起来。MySql - 一条语句是怎么插入磁盘的提到了一条数据的构造，咱们这里就用DB_TRX_ID事务ID，DB_ROLL_PTR事务回滚以及具体的数据DATA来简化一条数据，上面用简略的例子解说一下这个undo日志链表。 步骤一：插入一条数据DATA为，AAA，此时的DB_TRX_ID为1，DB_ROLL_PTR为空，如下图： 步骤二：批改这个数据DATA为BBB，此时的DB_TRX_ID为2，DB_ROLL_PTR指向批改前的数据，如下图： 步骤三：批改这个数据DATA为CCC，此时的DB_TRX_ID为3，DB_ROLL_PTR指向批改前的数据，如下图： ReadView机制MySql是反对多线程的，所以当多个事务提交的时候，其中一个事务就会创立一个ReadView。ReadView的构造如下： m_ids：以后未提交的事务creator_trx_id：创立ReadView的事务min_trx_id：m_ids中最小的事务idmax_trx_id：最大的事务id+1咱们同样用一个例子来阐明这个机制。假如事务1插入了DATA为AAA后，事务2和事务3对这条数据进行了查问和批改。 步骤1：事务2创立了ReadView。所以ReadView如下： m_ids为2和3。creator_trx_id为2。min_trx_id为2。max_trx_id为4。 步骤2：事务2查问了这条语句。事务2首先会判断min_trx_id（2）和这条数据的DB_TRX_ID（1），此时2比1大，阐明ReadView里的事务都是在以后数据的事务后创立的。咱们当然能够读取之前的事务提交的数据。此时事务2间接读取这条数据的DATA，AAA。 步骤3：事务3批改了这条语句，DATA改为BBB。事务3也会判断min_trx_id（2）和这条数据的DB_TRX_ID（1），发现是之前事务提交 的数据，所以他就间接批改了此数据。 步骤4：事务2持续查问了这条语句。事务2发现DB_TRX_ID（3）比min_trx_id（2）大，然而比max_trx_id（4）小，同时在m_ids（2,3）中，所以晓得了这个批改数据的事务是跟本人在同一个ReadView中的，那他就不能读取以后事务的数据，就依据DB_ROLL_PTR读取上一个数据。所以又读到了DB_TRX_ID（1）的DATA的值AAA。这就是可反复读。 步骤5：事务4批改了这条语句，DATA改为CCC。事务4会生成新的ReadView，而后发现DB_TRX_ID（3）是之前事务提交 的数据，所以他就间接批改了此数据。 步骤6：事务2持续查问这条语句，他比照DB_TRX_ID（4）和max_trx_id（4），发现这个数据被比本人前面的事务提交了，所以他也不能看到这个事务提交的数据，于是他就顺着链表找到DB_TRX_ID（3），判断同步骤6，最终还是找到了DB_TRX_ID（1）的DATA为AAA的数据。以上例子能够看到，ReadView机制能够保障能够读取到之前提交事务的数据，然而读取不到一起执行的事务以及之后的事务提交的数据。

TreeOne一个适用性功能性极佳的多层级树型数据库存储结构设计模型最佳实际，可宽泛用于我的项目开发工作中。 （以下示例环境默认均为MySQL） 表的字段数据结构CREATE TABLE `tree` ( `id` int(11) NOT NULL, `name` varchar(30) NOT NULL, `level` mediumint(4) NOT NULL DEFAULT '1', // 层级地位 `branch` mediumint(4) NOT NULL DEFAULT '1', // 分支code `path` varchar(50) NOT NULL DEFAULT '1' // 先辈门路) ENGINE=InnoDB DEFAULT CHARSET=utf8; 个性十分精美的外围数据表构造很强的灵便扩展性高效性能不便简略的SQL查问简直反对全副的树状分类构造的利用场景数据记录示例idnamelevelbranchpath1----cate-11113--------cate-1-1211.14------------cate-1-1-1311.1.15--------cate-1-2211.26------------cate-1-2-1311.2.12----cate-21227--------cate-2-1222.19------------cate-2-1-1322.1.110------------cate-2-1-2322.1.28--------cate-2-2222.2查问实例一条查问渲染整颗树 SELECT * FROM `tree` ORDER BY `branch`, `path`;获取树的最大深度/层级 SELECT MAX(`level`) FROM `tree`;获取某个分支的根 SELECT * FROM `tree` WHERE `branch` = 1 ORDER BY `path` ASC LIMIT 1;获取某节点的下级父节点 ...

这一周线上碰到一个诡异的BUG。 线上有个定时工作，这个工作须要查问一个表几天范畴内的一些数据做一些解决，每隔十分钟执行一次，直至胜利。 通过日志发现，从凌晨5：26分开始到5：56工作执行了三次，三次都因为SQL查问超时而执行失败，而诡异的是，工作到凌晨6：00多就执行胜利了。 每天都是凌晨五点多失败，凌晨六点执行胜利。 点开异样日志一看是这样的： 总结来说就是MySQL查问超时。 像这种稳固复现的BUG，我原以为只需三分钟能定位，没有想到却消耗了我半天的工夫。 排查之路Explain看到超时SQL，大多数人第一反馈就是这个SQL没有走索引，我也不例外，我过后的第一反馈就是这条SQL没有走索引。于是，我将日志外面的SQL复制了进去，脱敏解决一下大略是这样的一条SQL： select * from table_a where status_updated_at >= ? and status_updated_at < ? SQL外面有两个日期参数，这两个起始日期是某种商品的可交易工夫区间，相隔三到五天，我取了17天的工夫距离的激进值，Explain了一下这条SQL。 从图上能够看到这条SQL的执行还是走了索引的。走的是依据status_updated_at字段建设的索引。 执行了一下也只耗时了135毫秒。 依据Explain后果，我过后的推断是：这条SQL必定走了索引，如果没有走索引，那六点多钟的查问必定也会超时，因为这个表的数据是千万级别的。 为了验证这一推断，我找DBA帮我导出了一下凌晨5点到早上7点对于这个表的慢SQL，DBA通知我那个时间段没有对于这个表的慢SQL。 这也进一步验证了我说推断：这条SQL走了索引，只是在五点多的时候因为一些神秘起因导致了超时。 接下来，须要做的就是找出这个神秘的起因。 依照以往的教训，我认为有这几点因素会导致查问超时 MySQL资源竞争数据库备份网络MySQL资源竞争首先，我通过监控零碎查看了那段时间MySQL的运行状况，连接数和CPU负载等指标都十分失常。所以，因为MySQL负载导致超时首先就能够被排除。 那会不会是其余业务操作这个表影响的呢？ 首先，咱们线上数据库事务隔离级别设置的是RR（可反复读），因为MVCC的存在，简略的批改必定是不会影响查问至超时的。 要想影响惟一的可能性就是别的业务在update这个表数据的时候，更新条件没有走索引，导致行锁升级成表锁，并且，这个操作要刚好在凌晨5点多执行，且继续了半个小时。 这个条件十分刻薄，我查看了相干的代码，问了相干负责人，并没有这种状况，所有的更新都是依据Id主键更新的。要害是，如果更新SQL的更新条件没有走索引，必定会是一个慢SQL的，那么，咱们在慢SQL日志文件外面就能找到它，实际上并没有。 备份是不是因为凌晨5点多，数据库在备份的起因呢？ 首先备份锁表不会锁这么久，这个工作是前前后后半个小时都执行失败了； 其次咱们是备份的从库，并不是备份的主库； 最初，咱们的备份工作都不是凌晨五点执行的。 所以，因为备份导致超时能够排除了。 网络是不是网络稳定的起因呢？ 我找运维同学帮忙看了一下执行工作的那台机器那段时间的网络状况，十分平缓没有丝毫问题，机房也没有呈现什么网络抖动的状况。 再者，如果是网络问题，必定会影响其余工作和业务的，事实上，从监控零碎中查看其余业务并没有什么异样。 所以，因为网络稳定导致超时也能够排除了。 转折我先后排除了索引、网络、备份、业务竞争MySQL资源等因素，在脑海里模仿了N种状况，脑补了一条SQL整个执行过程，想不到会有什么其余起因了。 这个事件变得诡异了起来，DBA劝我临时放弃，倡议我把工作执行工夫延后，加一些监控日志再察看察看。毕竟，又不是不能用。 放弃是不可能放弃的，我是一个铁头娃，遇到BUG不解决睡不着觉。 理清思路，从头来过，我向DBA要了一份线上五点到六点的慢SQL的文件，本人从新找了一遍，还是没有找到这个表相干的慢SQL。 在我忽然要放弃的时候，我忽然发现SQL日志记录外面的时区都是标准时区的，而我那个工作执行的时候是北京工夫，要晓得标准时区和北京时区是差了8个小时的！ 好家伙！我都要想到量子力学了，后果发现时区没对上？ 会不会是DBA找慢SQL的时候工夫找错了啊？ 我将这个“重大发现”通知了DBA，DBA帮我从新跑一份慢SQL，好家伙，呈现了我想要那个表的慢SQL。 从日志下面能够看到，查问的日期区间从2020年9月到2021年4月，时间跨度7个月。MySQL成本计算的时候认为区间太大，走索引还不如间接扫描全表，最终没有走索引扫描了1800W条数据。 说好的工夫区间最多七天呢？怎么变成了七个月？ 连忙定位代码，定位发现底层在取工夫区间时，调了一个RPC接口，这个接口预期返回的工夫区间只有几天，后果返回了七个月的工夫区间。这段逻辑是18年上线的。 于是分割提供这个RPC接口的相干人员，通过查找验证确定这是底层数据的问题，应该返回几天后果返回了几个月。 最初修复了相干数据，减少了相应的校验和监控，从新公布零碎，这个存在了两年的BUG也就得以解决了。 这个故事到这里也就完结了。 再回顾一下，还有几个问题须要答复一下： 不走索引，那为什么六点多执行就没有超时呢？起因就是六点基本上没有业务在调用MySQL，那个时候的MySQL的资源是十分短缺的，加上MySQL的机器也配置十分的高，所以这条SQL硬生生跑胜利了。听起来有点离谱，但的确是这样的。 为什么这个BUG在线上这么久了，当初才发现？这个工夫区间底层数据用的不多，目前只发现只有这个超时SQL工作在调用。 原来业务量没有这么大，加上机器配置高，扫描整个表也花不了多久工夫。凌晨五六点执行，没有对线上的服务造成影响。 工作失败是很失常的，因为还依赖一些其余数据，其余数据提供的工夫不确定，所以工作会始终跑直到胜利。 总结复盘一下整个过程，对于这个查问超时SQL问题的排查，我从索引、网络、备份、业务竞争MySQL资源等方面一一剖析，却疏忽了最重要的因素——执行的到底是哪一条SQL。 我想当然的认为执行的SQL就是我设想中的那样并对此深信不疑，前面的致力也就成了徒劳。 ...