关于随机恢复，最近做了一些改进和整理，发现有些细节的工作比想象中要复杂得多，原本我提出了成功率达到1个9，这个目标相对容易，但是要达到2个9就很难了，假设每天随机测试10次，那么连续10天只要失败1...次，那么就到了2个9的边缘了。...所以我重新梳理了下随机恢复的流程，如下: ? 通过完整的流程梳理，结合当前知道的一些问题。我发现了如下的问题，也做了修正。 ?...各大平台都可以找到我 微信公众号：杨建荣的学习笔记 Github：@jeanron100 CSDN：@jeanron100 知乎：@jeanron100 头条号：@杨建荣的学习笔记 网易号：@杨建荣的数据库笔记...大鱼号：@杨建荣的数据库笔记 腾讯云+社区：@杨建荣的学习笔记
当出现线上case后，团队需要组织故障复盘，故障复盘不要搞成批斗会，复盘的目的是想着改进，并将焦点聚焦如何从故障中提升和改进。 第一，故障根因到底什么？...然后不断反复的重复三个问题，直至团队成员认为找到了改进的措施。 当然，还有 5Why 分析法，就是针对故障至少问 5 个为什么。通常也可以找到比较深层次的原因，或许不是根因，但它比较有针对性。...业务优先还是稳定优先 从运维、SRE 或基础平台的同事的角度看，稳定一定是优先的，任何时候都不能放弃稳定，但是从业务同事的角度看，业务发展肯定是第一位的，没有发展，光有稳定会有什么用呢。...这个过程中也会遇到大大小小的故障，但面临一个取舍问题：到底是减缓业务开发的节奏，投入一定的时间和人力，针对一个个故障作分析、改进，做好定责和绩效绑定，还是保障业务继续往前冲，提高容忍度？...耽误的业务发展收益怎么算？管理不好，对员工的积极性有打击，为竞争对手培养了人才，又怎么办？ 还有某个广告业务，虽然跟游戏比算不上最大的印钞机，但是也很赚钱。
此问题已在MySQL 8.0.21中修复。 首先，让我们了解可用于防止UNDO表空间过大的两种方法。 隐式截断 默认情况下，隐式方法在MySQL 8.0中为ON。...8.0.21的改进 在一个非常繁忙的系统上，我们注意到实际的截断会导致性能下降，因为它会将UNDO表空间中的所有页面从缓冲池中清除出来。...改进的另一部分是新的UNDO表空间进行了完整的重做日志，这意味着作为截断操作的一部分，UNDO表空间的最初129页不必刷新到磁盘。...这些改进缓解了QA小组在UNDO截断处于活动状态时，在极为繁忙的服务器上的遇到的周期性停顿。 InnoDB对单个UNDO表空间使用512个唯一表空间ID范围。...因此，为避免这种情况，InnoDB不再允许在两个检查点之间发生超过64个相同的撤消表空间的截断。 这种小小的性能改进是InnoDB不断提高的另一种方式。
关于发号器的使用，其实有一个大背景，那就是关于主键的一些设计问题，在MySQL中如果一张表没有主键，实际的数据处理就有点麻烦了。...自增列的问题很多，有些几句话还说不清楚，大体有如下的一些问题 自增列没有业务含义 过度依赖自增列 自增列和状态值主键并存，反而影响业务逻辑和性能 MySQL历史遗留bug，在MySQL 8.0该问题才修复...id的初始化： replace into test_inc(flag) values('1'); 数据结果为： mysql> select *from test_inc; +------+------+...假设从库的id当前值为1002，在从库切换后，会提升为主库，即可以实现读写，那么在新主库上执行replace into语句结果就会让人奇怪，完整的模拟过程如下： mysql> select * from...mysql> insert into sequence values(last_insert_id()); Query OK, 1 row affected (0.01 sec) 接下来需要做两类场景的测试
昨天帮一个朋友看了MySQL数据清理的问题，感觉比较有意思，具体的实施这位朋友还在做，已经差不多了，我就发出来大家一起参考借鉴下。...rename table，这是MySQL归档数据的一大利器，在其他商业数据库里很难实现。 但是为了保险起见，我说还是得看看表结构再说。结果看到表结构，我发现这个问题和我预想的完全不一样。...mysql> select max(Id) from test_data; +---------+ | max(Id) | +---------+ | 1603474 | +---------+ 1 row...mysql> select round(sum(data_length+index_length)/1024/1024) as total_mb, -> round(sum(data_length...mysql> select current_date-'20171001'; +-------------------------+ | current_date-'20171001' | +----
另外一类情况更偏于主观，做任务的人感觉一切都妥当了，但是验收的时候，发现不是设计理念的问题就是任务的精细度上面比较粗糙，如果本着差不多就行的态度其实也能过去，但是显然以后的事情谁能说的了，真要用到的时候...所以在这件事情上面，我发现以前对自己，对团队成员的要求有些松散，以至于稍微带点要求和质量标准，就会感到大家有些吃力，其实对于职业发展来说是有害的，从0到1的构建主要为了效率和快速迭代，可能在一些质量标准上面可以打折扣...，过度要求会有些刻薄，但是守江山更难，技术维护也是，都希望时间的边际成本能够越来越低，在已有的基础上构建和改进，那得下真功夫。...MySQL 8.0已经推出了几年，也在内部做了一些测试和总结，而且早期我们直接入主MySQL 5.7版本，也算是积累了3年多的经验，所以果断决定新业务都按照MySQL 8.0的基线来推广。...4）把原来文件夹的脚本结构重构为一个单一的脚本 5）修改前端的配置，去掉冗余无效的配置项，修改调用逻辑 6）团队内部做了简单演示，团队提了一些改进建议，修正后发布 这些工作经过了很多的测试和整理之后
通过I_S获取MySQL的一些元数据信息 获取表的数据文件、索引文件的大小、碎片情况、表行数、自增列增长情况等 获取正在运行的事务有那些，是否有阻塞等 获取当前mysql的连接processlist等等...mysql8.0 之前的查询方式 会在查询information_schema 某个表时创建临时表 来自文件的元数据，扫描文件系统获取FRM文件的表定义 存储引擎的详细信息，例如动态表统计信息 来自MySQL...时创建的临时表 扫描文件系统目录以查找FRM文件 改进 利用MySQL优化器的全部功能，使用数据字典表上的索引来更好的查询 mysql5.7中表文件 ll test* Jul 10 10:52 testse.frm...mysql占用的内存暴涨，出现OOM） mysql8.0 中I_S中tables表以视图的形式存在（查询该视图，不会创建临时表，会使用到视图中表的索引） mysql5.7中获取表大小情况 SELECT...访问I_S.tables不会创建临时表，这减少了内存暴涨的可能，但访问I_S.tables的qps大约是mysql5.7.22的1/5，访问速度没有mysql5.7.22的快 mysql8.0 访问I_S.tables
，比如其他的10张表在实时复制，而新增的表会产生新的GTID,在数据没有应用过来之前，会有一系列的GTID无法自动修复。...如果把这个图画的更全面一些，其实是这样的结构，默认是有数据的容灾节点的，中间节点是直接从主库进行数据复制的。...要解决现在的这个问题，导出导入5个小时显然是不合理的，而相对来说理想的方式便是基于物理数据的处理模式。...一种是传输表空间，直接把ibd文件拷贝到中间节点，然后修复数据的差异，这个时候有两种修复差值的模式，一种是基于表中的增量时间来处理，相对不够通用，第二种则是更严谨的模式，则是修改数据的复制链路，基于从库级联复制即可...综上，数据复制是一个很好的数据开关，能够灵活的适配和处理很多偏向于业务需求的数据逻辑，在这个过程中，基于系统层，物理的处理模式要远比逻辑处理要高效的多。
---- 一、UNION 的作用： UNION 可以将多个 SELECT 查询语句的结果合并成一个结果集，在 MySQL 8.0 中又增添了一些新的功能，我们一起来看下。...举例如下： // 新增 table 语句的使用，由于取的是全表，对于单一字段的去重就不便使用了 mysql> table t1 union select * from t2; +------+-----...8.0 和 5.7 对 union 的处理 在 MySQL 8.0 中，对 SELECT 和 UNION 的解析器规则被重构进而变得更加一致，且减少了重复。...与 MySQL 5.7 相比，某些语句可能需要重写: 对比标准 SQL ，NATURAL JOIN 允许一个可选的 INNER 关键字（NATURAL INNER JOIN）。...，支持标准化上线流程，原生支持 MySQL 审核且数据库类型可扩展的 SQL 审核工具。
Redis MySQL发展历史 MySQL的单机时代 ? 90年代这时候，一个网站的访问量不算太大，单个数据库就足够了。 而且更多的是静态网页，服务器没有太大的压力。...这种情况下，整个服务架构的瓶颈是： 1、数据量太大一个机器放不下 2、访问量（读写混合），一个服务器承受不了 Memcached(缓存)+MySQL+垂直拆分（读写分离） 网站80%的情况都是读数据，每次都要查询数据库的话就十分麻烦...发展过程：优化数据结构和索引（数据本身）->文件缓存（IO）->Memcached 分库分表+水平拆分+MySQL集群 ?...如今 如今数据类型和数据量暴增，比如定位，音乐，热榜都是数据类型，MySQL等关系型数据库已经不够用了。...如果用MySQL存储博客，图片等数据，数据库表很大，效率比较低，要有一种专门的数据库来存储这些数据。NoSQL数据库就是专门存储这些数据的。 目前的一个互联网项目架构 ?
NLP发展到Transformer相关及改进模型 0. NLP 0.1 发展 https://www.jianshu.com/p/d35a2fd593eb 0.2 训练流程 1....RNN和LSTM 单词的先后顺序会影响句子的意思，RNN擅长捕捉序列关系，不过对于翻译来说，句子间的单词数量不是一一对应的。...通过计算Q与K之间的相关性，得出不同的K对输出的重要程度，再与对应的V相乘求和，就得到了Q的输出。...Transformer的每个参数是动态变化的；而CNN学习参数一旦学习完后就固定了fixed。Transformer对每张图的参数都是不一样的、随时变化的，就可以有无限的参数空间来做一件事。...优点 提高训练速度 改进效果(模拟真实环境下噪声情况，让模型鲁棒性更强) NCE(噪声对比估计)：通过学习数据样本分布和噪声样本分布的区别，从而发现样本的特性。
MySQL8.0里引入了不少关于权限的改动，从这些改动可以看出来，权限管理更加的规范和遍历了，这和我们之前为rds mysql增加了大量权限管理很类似，想来Oracle也是通过这些改动为其云业务服务的吧...当前版本为8.0.16 Atomic ACL Statement 由于实现了新的数据词典表，所有的权限相关的信息都存储在innodb mysql tablespace里。...其中restrictions_list存储在mysql.user表中，主要是引入Partial revoke, 可以revoke部分库上的权限，例如mysql库，这实际上对于云业务而言是非常重要的功能：...另外最近也修复了一个有趣的bug#94394，当mysql.user表损坏时，实例启动时仅仅打印了一条错误信息，并以skip-grant-tables的方式启动了。...从MySQL8.0.14开始了增加了一个新的权限位session_variables_admin, wl#12217列出了一些需要该权限位的变量: The following vairables need
重要改进 MySQL8.0 的死锁日志可以看到事务1持有的锁信息了： 这对我们分析死锁无疑是个很好的帮助，而在 MySQL5.7 是没有这个信息的，一直饱受诟病： 注意事项 但是这在某些情况下可能会产生一些误会...X locks rec but not gap； session1 插入时，发生唯一键冲突，需要对 c2 索引 10 这一记录加 S Lock，带 gap 属性，即锁的范围为 (4,10]。...但是由于 session2 已经对记录加了 X Lock，与 S Lock 互斥，所以必须等待 session 2 先释放锁，也就是死锁日志中的lock mode S waiting； session2...再次插入 9，在 (4,10] 范围内，这个位置有 session1 的 gap 锁（虽然还在锁队列中，没有加上），插入意向锁会被 gap 锁阻塞，即死锁日志中的 lock_mode X locks...session1 等待获取的锁 S Lock 阻塞了 session2 将要获取的锁，这在 MySQL8.0 中就会显示成 session1 持有的锁，同时也是 session1 等待的锁。就是这样。
在MySQL8.0中执行器部分代码发生了较大改变，新的执行器向经典的Iterator模型更接近了一步，我们暂时叫它iterator执行器。接下来我们分析一下这个新的执行器。...非常容易扩展为多进程、线程的并发执行。 目标 MySQL8.0执行器改进的目的是创建一个新的用于迭代访问记录的API，它足够通用，可以替换MySQL中所有原有的记录迭代器，并逐步替代掉原有的执行器。...可以认为，MySQL现有执行器的实现方式也限制了它的演进。...，MySQL就会回退到旧的执行器去执行。...未来展望 基于新的执行器，MySQL将支持更多代数查询操作，支持更丰富的功能。
DDL发展 DDL online DDL 工具化时代 1、DDL（锁表阶段） ALGORITHM=COPY ALGORITHM=inplace ALTER TABLE xxxx ADD xxx, ALGORITHM...LOCK=DEFAULT mysql自己去判断是否加锁，原则是是少加锁 LOCK=EXCLUSIVE 读写加锁 注意：8.0 ALGORITHM新增INSTANT，这里LOCK需要等于DEFAULT，...，默认128M 如何查看进度： 在MySQL 5.7需要先开启，然后才能查看 UPDATE setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE...当对包含 instant 列的表进行 rebuild 时，所有的数据在 rebuild 的过程中重新以旧的数据格式（包含所有列的内容） 2....，binlog已经提交，但是redo还未commit，从而导致读到的数据和binlog已提交数据不符 最后，本篇文章更多是总结一些DDL的使用，更偏向于一些介绍，汇总，可以帮助开发同学来了解下DDL的发展以及工具使用
数据库练习题 七、MySQL数据库密码修改 ---- 一、数据库简介 数据库(Database，DB)是按照数据结构来组织，存储和管理数据的仓库。...主流的关系型数据库产品：Oracle(Oracle)、DB2(IBM)、SQL Server(MS)、MySQL(Oracle)。...二、MySQL数据类型(5.5版本) MySQL中除了字符串类型需要设置长度,其他类型都有默认长度....,权限n ON 数据库名.* FROM 用户名@IP; revoke select on mysql.* from Fox@localhost; -- 4.查看用户的权限:SHOW GRANTS FOR....ename,e2.ename FROM emp e1 LEFT JOIN emp e2 ON e1.mgr = e2.empno; 六、MySQL数据库练习题 单表练习 七、MySQL数据库密码修改
福哥答案2020-01-26： 2020-01-26：mysql8.0做了什么改进？ 帐户管理增加了对角色的支持。 支持原子数据定义语句（atomic DDL）。 支持utf8mb4字符集。...MySQL 8.0的十大新特性 今天，让我们看一下MySQL8.0提升数据库管理员工作效率的十大改进。...7.原子DDL 8.更快、性能更好的Schema和Information Schema 9.角色管理 10.加密表空间中的REDO日志和UNDO日志都将被加密 1.临时表的改进 在MySQL5.7中，所有的临时表都被创建在一个叫...在MySQL8中，我们改进了磁盘格式来使得每个UNDO表有大量的UNDO段。 此外，现在默认为两个单独的UNDO表空间（而非InnoDB系统表空间（最小为2，大小动态变化））中创建UNDO段。...在MySQL 8.0中，我们通过为UNDO和REDO日志添加加密来完成此功能。 除此以外，还有很多改进我没有列完。 还有很多其他不错的功能。
一、虚拟列的发展 在早期的MySQL版本中，开发者通常需要为经常需要计算的字段创建额外的物理列，并在数据插入或更新时手动计算这些列的值。这种方法虽然可行，但它增加了数据冗余和应用程序的复杂性。...为了解决这个问题，MySQL 5.7版本引入了虚拟列（也称为生成列）的概念。虚拟列允许开发者在表中定义一个基于其他列的计算公式，而不需要实际存储这些计算的结果。...当查询虚拟列时，MySQL会根据公式动态计算其值。 在后续的版本中，MySQL进一步增强了虚拟列的功能，允许开发者选择是否将虚拟列的结果实际存储在磁盘上（即存储列），以提高查询性能。...总结 MySQL的虚拟列是一个强大而灵活的特性，它允许开发者在表中定义基于其他列的计算结果，而无需实际存储这些计算的值。...随着MySQL的不断发展，我们可以期待虚拟列在未来版本中继续得到增强和优化，为开发者提供更多便利和功能。在设计和优化数据库时，不要忘记考虑使用虚拟列来提高性能和简化应用程序逻辑。
广泛应用：PHP是广泛应用于Web开发的脚本语言。它可以与各种服务器软件（如Apache、Nginx等）以及大多数数据库（如MySQL、Oracle等）无缝集成，为构建动态网站提供了良好的支持。...良好的兼容性：PHP与各种操作系统（如Windows、Linux、Mac等）和数据库系统（如MySQL、PostgreSQL、SQLite等）兼容性良好。...通过采用安全编码实践，如输入验证、输出过滤和维护最新的PHP版本，可以确保PHP应用程序的安全性。PHP语言的发展趋势：更高的性能和卓越的扩展性： 近年来，PHP不断致力于提高性能和扩展性。...新的语法糖和语法改进：PHP 7引入了许多新的语法糖和语法改进，例如null合并运算符、太空船操作符、标量类型提示等。这些改进简化了开发人员的编码过程，并提供了更多的便利性和表达能力。...这些改进简化了开发人员的编码过程，提高了代码的可读性和表达能力。总结PHP语言的发展趋势是朝着更高的性能、更好的可扩展性、更强的类型支持和更好的安全性方向发展。
这是学习笔记的第 2228篇文章 读完需要 5 分钟 速读仅需3分钟 最近在改进一套环境的延迟问题，做了业务层的优化之后，问题得到了基本的解决，但是离我预想中的结果还是有距离，毕竟高峰期的延迟还是有20...于是乎，在最近的一次高可用改造中，我们借着这个机会对这套数据库进行了升级，原本是MySQL 5.7.16版本，通过复制的模式配置了MySQL 8.0.19的Slave....从第二天的数据来看，对于延迟的改进效果是很明显的，如下是近6天的数据延迟情况，我仅统计了数据处理中的延迟数据，最右边的是基于MySQL 8.0的writeset的模式，Slave的延迟情况。 ?...实际的数据都是1~4秒之内的延迟，而在前几天基于MySQL 5.7的模式基本延迟是在2~24秒之间。 当然抓取一天的数据进行分析，确实有些过急了，于是我又抓取了几天的数据。 ?...）如果需要回退到MySQL 5.7版本，是否有预案，预案如何设计？
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
