MySQL Online DDL 功能从 5.6 版本开始正式引入，发展到现在的 8.0 版本，经历了多次的调整和完善。本文主要就 Online DDL 的发展过程，以及各版本的区别进行总结。其实早在 MySQL 5.5 版本中就加入了 INPLACE DDL 方式，但是因为实现的问题，依然会阻塞 INSERT、UPDATE、DELETE 操作，这也是 MySQL 早期版本长期被吐槽的原因之一。
先讲一下写该文章的原因，首先，工作中又遇到一条很熟悉的MySQL报错信息 Cause: java.sql.SQLException: Incorrect string value:Cause: java.sql.SQLException: Incorrect string value… （emoji表情存储导致），原因是MySQL的字符集导致的；其次，因为一直听说数据库变更可能锁表，但是一直不知道到底哪些操作会导致锁表。所以今天对相关知识做一个系统的整理。
在数据库中，除传统的计算资源的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的问题，锁冲突也是影响数据库并发访问性能的一个重要的因素。
大家在日常工作中，往往需要对数据库的表结构做变更，一般涉及到增删字段，修改字段属性等ALTER的操作。
锁表的原因： 当多个连接（数据库连接）同时对一个表的数据进行更新操作，那么速度将会越来越慢，持续一段时间后将出现数据表被锁的现象，从而影响到其它的查询及更新。 例如： 存储过程循环30次更新操作（cycore_file_id 为唯一标识）
MySQL 大表数据添加新字段 有时候我们在测试环境给一个表添加字段,但是在线上环境添加一个字段,却极其的慢。原因是线上的数据库一般会存有大量的数据(百万级,千万级),基本的添加字段方式在线上数据库已经不太合适了。 > alter table user add column flag tinyint(1) default 0; 基本添加方式,大量数据的表不推荐。执行加字段操作就会锁表，这个过程可能需要很长时间甚至导致服务崩溃。 解决方案 扩展新表方案 创建一个新表user_ext(id,user_id,f
增加字段相信大家应该都不陌生，随手就可以写出来，给 MySQL 一张表加字段执行如下 sql 就可以了：
作为产品DBA，经常被开发问，修改字段长度锁表吗？然后凭借"经验"给出回答：如果字段长度超过256个字符就会锁表。
这个问题之前遇到过一次，但是由于不知道导致锁表的原因，也没细想，就知道表被锁了，然后让别人把表给解锁了。但是前天的一次操作，让我亲眼见证了导致锁表的过程，以及如何给lock的表解锁。
MySQL各存储引擎使用了三种级别的锁定机制：table-level（表级锁定），row-level（行级锁定）和page-level（页级锁定）此处只介绍使用InnoDB存储引擎行过程中经常常遇到的问题以及解决方法。
软件行业唯一不变的就是变化，比如功能上线之后，客户或 PM 需要对已有的功能增加一些合理的需求，完成这些工作必须通过添加字段解决，或者某些功能的实现需要通过增加字段来降低实现的复杂性等等。这些问题都会改动线上的数据库表结构，一旦改动就会导致锁表，会使所有的写入操作一直等待，直到表锁关闭，特别是对于数据量大的热点表，添加一个字段可能会因为锁表时间过长而导致部分请求超时，这可能会对企业间接造成经济上的损失。
修改Varchar 的大小的时候。不用锁表，就可以进行操作DDL。这个还得具体查看版本，还有具体情况。下来我们来看一下INnoDB中的Online DDL各个操作请求。
经常会遇到这种情况，我们的业务已经稳定地运行一段时间了，并且流量渐渐已经上去了。这时候，却因为某些原因（比如功能调整或者业务扩展），你需要对数据表进行调整，加字段 or 修改表结构。 可能很多人说 alter table add column … / alter table modify …，轻轻松松就解决了。 这样其实是有风险的 ，对于复杂度比较高、数据量比较大的表。调整表结构、创建或删除索引、触发器，都可能引起锁表，而锁表的时长依你的数据表实际情况而定。 本人有过惨痛的教训，在一次业务上线过程中没有评估好数据规模，导致长时间业务数据写入不进来。 那么有什么办法对数据库的业务表进行无缝升级，让该表对用户透明无感呢？下面我们一个个来讨论。
数据库如下图所示，所有字段都是int(方便测试)，id为主键索引，name为普通索引（唯一索引），age没有索引
最近在灰度环境中遇到一个问题：某项业务在创建数据时耗时异常长，但同样的代码在预发环境中并未出现此问题。起初我们以为是调用第三方接口导致的性能问题，但通过日志分析发现第三方接口的响应时间正常。最终，我们发现工单表的数据入库SQL一直处于等待状态。深入分析后，问题的核心暴露出来：另一业务流程中对工单表执行更新（UPDATE）操作的SQL，其where子句中涉及的字段缺少必要的索引，导致其他业务在操作表中的数据时需要等待该更新完成。今天就和大家分享一下这个经验。
在上文我们曾小小的提到过，在索引失效的情况下，MySQL会把所有聚集索引记录和间隙都锁上，我们称之为锁表，或叫行锁升表锁.
常见的MySQL数据导出有三种形式 SELECT ... INTO OUTFILE ---- SELECT * FROM person INTO OUTFILE '/var/lib/mysql-files/person.data'; LOAD DATA INFILE LOAD DATA INFILE是SELECT ... INTO OUTFILE的逆操作 常用选项 FIELDS TERMINATED BY ','：字段分隔符 ENCLOSED BY '"'：包围字段的符号 LINES TER
访问了几个页面都是正常的，唯独某几个页面查询实时监控数据时无法加载出来，F12查看接口发现有几个业务相似的接口长时间不返回数据。
大型项目对备份尤为关注，一般有双机备份，热备冷备，异地灾备等等… 今天来说一下两台服务器上的 MySQL 主从复制备份，需求比较简单：从要同步主的数据，但也不用太频繁，保持 15 分钟的数据差即可，意思就是每 15 分钟去同步一次修改过的数据。
2020-01-20：mysql中，一张表里有3亿数据，未分表，要求是在这个大表里添加一列数据。数据库不能停，并且还有增删改操作。请问如何操作？
如果数据量特别特别大，那么锁表时间很长，期间所有表更新都会阻塞，线上业务不能正常执行。
由于业务发展，DB表结构难免因为需求发生变动，这时会产生修改字段类型，增加字段等变更需求。
① 从连接数来看，根据官方文档，5.1.17以上版本，单台mysql数据库的连接数默认是151，上限为10w，虽然可以在上限范围内人为的设置最大连接数，或者建立连接池进行一定程度优化，但单台数据库的性能总是有瓶颈的，当请求量过大的时候，若连接数不够，则会处于阻塞状态
导语 | 本文是MySQL谬误集系列文章的第二篇，该系列旨在纠正一系列似是而非的说法。比如关于MySQL DDL操作，有很多同学认为会锁表，那是不是一定会锁表呢？是锁读还是锁写呢？锁多长时间？不同的DDL操作有差别吗？MySQL从5.5到8.0，对这个问题有什么改进呢？本文做了一个简单的总结。
从字面的意思，应该很直白了，一般出现在INSERT语句，指定的字段数据和数据库表的字段类型不同。
选表类型： mysql的myisam表适合读操作大，写操作少;表级锁表 innodb表正好相反；行级锁表 互联网服务，不算支付性的服务外，互动产品，新闻系统等等一般都是读多，写少。用myisam表比较合适。 表的设计 定长表:所有列的字段长度都是定长的。可以去查mysql的手册不定长字段是VARCHAR、BLOB或TEXT。int char都是定长的，定长表占用空间会大。 动态表:就是字段不是都定长的。 定长表要比动态表检索速度快。 软件系统的设计习惯是把每张表都分清很明确的功能，比如用户表都是用户信息，如
上篇文章我们简单的了解了一大堆锁相关的概念，然后只是简单的演示了一下 InnoDB 和 MyISAM 之间 表锁 与 行锁 的差别。相信大家还是意犹未尽的，今天我们就来用代码说话，实际地操作一下，看看如何进行手动的加 表锁 与 行锁 ，并进行一些相关的实验测试。
1.库名、表名、字段名必须使用小写字母，并采用下划线分割。 a)MySQL有配置参数lower_case_table_names，不可动态更改，Linux系统默认为 0，即库表名以实际情况存储，大小写敏感。如果是1，以小写存储，大小写不敏感。如果是2，以实际情况存储，但以小写比较。 b)如果大小写混合使用，可能存在abc，Abc，ABC等多个表共存，容易导致混乱。 c)字段名显示区分大小写，但实际使⽤用不区分，即不可以建立两个名字一样但大小写不一样的字段。 d)为了统一规范， 库名、表名、字段名使用小写字母。
2021-01-19：mysql中，一张表里有3亿数据，未分表，其中一个字段是企业类型，企业类型是一般企业和个体户，个体户的数据量差不多占50%，根据条件把个体户的行都删掉。请问如何操作？
索引主要是用于提高数据检索速度的一种机制，通过索引数据库可以快速定位到目标数据的位置，而不需要遍历整个数据集，它就像书籍的目录部分，有它的存在，可以大大加速查询的效率。
随着业务的发展，用户对系统需求变得越来越多，这就要求系统能够快速更新迭代以满足业务需求，通常系统版本发布时，都要先执行数据库的DDL变更，包括创建表、添加字段、添加索引、修改字段属性等。
昨天在微信群中有个朋友也是无意中问了一下，说数据库中的表字段想保持一种相对规范的顺序，怎么办？要知道Oracle中这个操作就比较纠结了，因为是按照追加的方式来处理的。没法在已有的字段1，字段2中间添加一个字段3。但是MySQL却可以，这个方面MySQL看起来要灵活的多，这个是什么原因呢，他们在设计上有什么差别呢。 MySQL中对每个表存在一个定义文件，即frm文件，我们来取出一个表，看看能不能简单解析一下。 比如一个表字段的内容如下： > desc zd_warshrine_prostate; +----
删除一条记录，首先锁住这条记录，数据原有的被废弃，记录头发生变化，主要是打上了删除标记。也就是原有的数据 deleted_flag 变成 1，代表数据被删除。但是数据没有被清空，在新一行数据大小小于这一行的时候，可能会占用这一行。这样其实就是存储碎片。
在程序员的职业生涯中，总会遇到数据库表被锁的情况，前些天就又撞见一次。由于业务突发需求，各个部门都在批量操作、导出数据，而数据库又未做读写分离，结果就是：数据库的某张表被锁了！
说起在线 DDL，最常见的操作莫过于在线加一个字段或者索引，不过如果数据量比较大的话，伴随而来的往往是长时间的等待，更要命的是系统在操作期间很可能会出现不可用的情况，所以一般只能等到凌晨操作，简直就是梦魇一般的存在。
近期开发与钱相关的项目，在高并发场景下对数据的准确行有很高的要求，用到了for update，故总结一波。
数据库设计规范 命名规范 基本设计规范 索引设计规范 字段设计规范 SQL开发规范 操作行为规范 命名规范 对象名称使用小写字母并用下划线分割 禁止使用MySQL保留关键字 见名识义，最好不超过32个
本文深入介绍枚举类型EUNM和集合类型SET。测试基于InnoDB存储引擎上，对MySQL数据库枚举类型ENUM的字段进行DDL变更操作，是否需要重新创建表呢？对数据库的事务处理有何影响？对数据库的数据服务提供有何性能影响？通过本文了解下。
1、将经常要用到的字段（比如经常要用这些字段来排序，或者用来做搜索），则最好将这些字段设为索引 2、字段的种类尽可能用int或者tinyint类型。另外字段尽可能用not null 3、当然无可避免某些字段会用到text，varchar等字符类型，最好将text艾段的单独出另外一个表出来（用主键关联好） 4、 字段的类型，以及长度，是一个很考究开发者优化功力的一个方面。如果表数据有一定的量了，不妨用PROCEDURE ANALYSE()命令来取得字段的优化建议！（在phpmyadmin里可以在查看表时，点
结论 如果不清楚自己应该用什么引擎，那么请选择InnoDB，Mysql5.5+的版本默认引擎都是InnoDB，早期的Mysql版本默认的引擎是MyISAM ---- MyISAM 和 InnoDB的适用场景 MyISAM适合：(1)做很多count 的计算；(2)插入不频繁，查询非常频繁；(3)没有事务。 InnoDB适合：(1)可靠性要求比较高，或者要求事务；(2)表更新和查询都相当的频繁，并且表锁定的机会比较大的情况。 ---- MyISAM 和 InnoDB的区别 1)MyISAM类型不支持事务处理等
死锁是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等的进程称为死锁进程。
首先通过搜索词匹配倒排表得到一个只有id的结果集，然后通过id匹配正排索引拿到对应的文档字段，最后返回结果，这样的好处是：
MySQL中DDL语句，即数据定义语言，用于创建、删除、修改、库或表结构，对数据库或表的结构操作。常见的有create，alter，drop等。这类语句通常会耗费很大代价，特别是对于大表做表结构变更。本篇文章会揭露各类DDL语句执行的详细情况。
在新增列的时候，数据量大的时候，使用ALGORITHM=INPLACE, LOCK=NONE语法。 大家可以再深入理解一下 onlineDDL 官方文档： https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html
MySQL中的alter table操作对于大表来讲，是一个比较严重的问题，MySQL执行大部分alter table的操作步骤是：
DDL 操作一直是我们的 MYSQL 的一个软肋，从MYSQL 5.6 其实相关的alter 语句已经有了改变，也就是题目的的inplace 和 copy 。其实很多人都知道，但用的比较少，因为有pt-OSC 工具呀，还有另外一个工具gh-ost
MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。
在应用的的开发过程中，由于初期数据量小，开发人员写 SQL 语句时更重视功能上的实现，但是
数据库的操作越来越成为整个应用的性能瓶颈，这对于Web应用尤其明显。关于数据库的性能，这并不只是DBA需要关心的，而更是后端开发需要去关注的事情。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
