在 MySQL 的常见规范里面，每个表都要设置主键，一般来说都会推荐自增列作为主键，这和 MySQL 属于聚簇索引表有关，顺序增长的主键比较合适。而自增列中比较常遇见的问题就是自增列的空洞。原生的 MySQL 自增列也存在一个 BUG，可能会影响到数据一致性，本文也会详细介绍，在自建 MySQL 的时候尽量不要踩到这个坑。
群里一网友这两天刚入职新公司，遇到一个重启 MySQL 服务后，自动增长值丢失问题，差点背锅走人。下面我们一起来回顾一下这个问题。
今天工作中遇到特殊的一个任务，就是将两个自增列值的进行对调变更。 SQL Server 平台修改自增列值 由于之前处理过sql server数据库的迁移工作，尝试过其自增列值的变更，但是通过SQL 语句修改自增列值，是严格不允许的，直接报错（无法更新标识列 ’自增列名称‘）。sql server我测试是2008、2012和2014，都不允许变更自增列值，我相信SQL Server 2005+的环境均不允许变更字段列值。 如果非要在SQL Server 平台修改自增列值的，那就手动需要自增列属性，然后修改该列
MySQL里面有一个问题尤其值得注意，那就是自增列的重复值问题，之前也简单分析过一篇MySQL自增列的重复值问题(r12笔记第25天)，但是在后续我想了下，还有很多地方需要解释，一个就是从库的自增列是如何维护的，是否重启从库，自增列会受到影响。 我们继续来测试一下。首先复现这个问题。 创建表t1，插入3行数据。 use test; [test]> drop table if exists t1; Query OK, 0 rows affected, 1 warning (0.01 sec
《MySQL删除数据的三种方式》中的作业题，99%的人答错，有点出乎意料。 画外音：评论中不乏嘲笑知识点简单的小伙伴。 今天简单说下作业题中的答案，以及知识点。 作业题是这样的： 实验步骤如上图： 第一步：建表，设定自增列； 第二步：指定id=1插入，锚定第一行是id是1； 第三步：不指定id，依赖自增机制，插入3行； 画外音：此时id应该变为2，3，4了？ 第四步：delete删除所有记录； 画外音：坑就容易出在这里。 第五步：指定id=0插入； 第六步：指定id=1插入； 第七步：不指定id，依赖自
自增列可使用 auto_increment 来实现，当一个列被标识为 auto_increment 之后，在添加时如果不给此列设置任何值，或给此列设置 NULL 值时，那么它会使用自增的规则来填充此列。
当然基于MySQL自增列的实现，确实是不够优雅，在新的版本还在持续引入新的特性。比如MGR里面，自增列的步长大了许多，默认是7了，这是在设计的时候考虑了MGR的节点数，提前做了预留，大多数情况下我们可以避免大量的预留值浪费。
前几天偶然看到大家在讨论一道面试题，而且答案也不够统一，我感觉蛮有意思，在此就做一个解读，整个过程中确实会有几处反转。
MySQL主键约束是一种用于确保表中每行数据的唯一性的限制。每个表只能有一个主键，它可以是一个或多个列。
MySQL版本 select version(); +------------+ | version() | +------------+ | 5.7.21-log | +------------+ 1 row in set (0.00 sec)
使用MYSQL有一段时间了，由于公司使用SQLSERVER和MYSQL，而且服务器数量和数据库数量都比较多
关于发号器的使用，其实有一个大背景，那就是关于主键的一些设计问题，在MySQL中如果一张表没有主键，实际的数据处理就有点麻烦了。
自增列（auto_increment）是数据库中常见的一项功能，它提供一种方便高效的方式为行分配唯一标识符，极大简化数据管理的复杂性。当新行插入到表中时，数据库系统会自动选取自增序列中的下一个可用值，并将其分配给指定的列，无需用户手动干预。这种自动化的机制不仅简化了数据管理的流程，更确保了标识符的唯一性，让数据库维护变得更加便捷和可靠。
昨天的一篇文章MySQL自增列主从不一致的测试(r12笔记第37天)，今天有不少网友向我确认一些细节，我想最近正好在看GTID的东西，可以揉在一起来说说。 GTID这个概念看似简单，实际上还是有
MySQL的自增列问题其实很有意思，在重启数据库之后，会按照max(id)+1的方式来计算，这样一个看起来有些别扭的实现方式在早期版本就饱受诟病，在MySQL 5.7都没有解决掉，终于在8.0松口了，计划在这个版本中修复。 而重启会带来自增列一类的潜在问题，而如果不重启其实也有可能会有自增列的不一致问题。和两个参数table_definition_cache和table_open_cache还是密切相关的。 主要的原因是什么呢，引用阿里数据库内核团队的解释（https://www.kancl
在不久前有位客户在进行数据迁移时发现。自己使用pt-archiver备份时总是会少一条数据；如源数据库中某表数据为2333，导入目的数据库后select结果只有2332。
之前有碰到过开发同事指出一张InnoDB表的自增列 AUTO_INCREMENT 值莫明的变大，由于这张表是通过MySQLdump导出导入的。
在 MySQL 中，删除的方法总共有 3 种：delete、truncate、drop，而三者的用法和使用场景又完全不同，接下来我们具体来看。
我们在设计表结构的时候，经常会对某一列设置自增长的值，它的作用是可以帮助我们自动递增某一列的值，自增长的属性经常被设置在主键列上，原因是主键必须具有唯一性，而自动增长可以避免重复，二者结合恰到好处。除此之外，自增长的属性还可以避免在数据插入的时候，出现大量的数据页分裂操作，关于这一点，后面说到索引的时候，会着重介绍，现在我们只需要知道，主键一般设置成自增长的即可。
MGR这个方案之前写了一些文章来讨论，其实要在你的业务中落地，需要考虑的细节就很多了。
在前面的章节中，我们已经学习了Mybatis基本的增删改查操作，并且通过ResultMap将查询结果映射为Java对象。但是，对于Insert操作而言，我们通常需要获取新插入记录的自增索引值，以便于后续的操作和处理。
爱可生 DBA 团队成员，一位会摄影、会铲屎、会打球、会骑车、生活可以自理的 DBA
一个朋友接到一个需求，从大数据平台收到一个数据写入在20亿+，需要快速地加载到MySQL中，供第二天业务展示使用。
近期，线上有个重要Mysql客户的表在从5.6升级到5.7后，master上插入过程中出现"Duplicate key"的错误，而且是在主备及RO实例上都出现。
长期以来，我的博客数据库中连续文章的主键编号一直都不是连续的，让我这个强迫症晚期患看着很不舒服。在忍受了这么长时间以后，趁着给博客换域名的时机，我把所有的文章编号全部改成了连续的，可算是舒服多了。
今天是《MySQL核心知识》专栏的第4章，今天跟大家一起聊聊MySQL的简单语法。好了，开始今天的正题。
今年，这种情况，有时候不找好下家还真不敢跳，这不，前段时间刚跳到新东家，刚办入职那天，就遇上事了，真的是吓出一身冷汗（老大一直盯着我，说要快速解决这个问题），差点被（背）开（锅）了....
自增id是整型字段，我们常用int类型来定义增长id，而int类型有上限 即增长id也是有上限的。
提示：公众号展示代码会自动折行，建议横屏阅读 问题描述 近期，线上有个重要Mysql客户的表在从5.6升级到5.7后master上插入过程中出现"Duplicate key"的错误，而且是在主备及RO实例上都出现。以其中一个表为例，迁移前通过“show create table” 命令查看的auto increment id为1758609， 迁移后变成了1758598,实际对迁移生成的新表的自增列用max求最大值为1758609。用户采用的是Innodb引擎，而且据运维同学介绍，之前碰到过类似问题，重启
如果需要把一台MySQL中的数据定期归档到另外一台MySQL历史库中，那么很可能会发现会有重复值的问题，导致数据导入会失败，而这个问题其实是和自增列的重复值有关，我们来简单看看。 这方面丁奇大师也做了很多详细的说明，还定制了参数，具体可以参见 http://www.csdn.net/article/2015-01-16/2823591 我们来看看这个问题，由此做一个简单的总结。 我们创建一个表t1，指定存储引擎为InnoDB use test; [test]> drop table
提示：公众号展示代码会自动折行，建议横屏阅读 问题描述 近期，线上有个重要Mysql客户的表在从5.6升级到5.7后master上插入过程中出现"Duplicate key"的错误，而且是在主备及RO实例上都出现。以其中一个表为例，迁移前通过“show create table” 命令查看的auto increment id为1758609， 迁移后变成了1758598,实际对迁移生成的新表的自增列用max求最大值为1758609。用户采用的是Innodb引擎，而且据运维同学介绍，之前碰到过类似问题，重启即
注意一点： 如果原来的字段是空，那么你就不能把该字段修改成可以为空，当然你修改也会报错
在MySQL 8之前，当你不再需要某个索引时，你必须显式地删除它。然而，在某些情况下，你可能不确定删除索引是否会对查询性能产生负面影响。为了解决这个问题，MySQL 8引入了隐藏索引的特性。隐藏索引允许你将索引设置为不可见，而不是完全删除它。这样，你可以在不实际删除索引的情况下评估查询的性能。如果发现性能下降，你可以轻松地使索引再次可见。
使用过inception的人对SQL审核这块获取都比较熟悉，作为DBA，审核SQL是日常工作中的很重要的一块内容，审核好SQL对于后期项目以及数据库维护上起着至关重要的作用，好比一座大厦没有坚实的地基支撑，也就无法长期屹立不倒。
插入InnoDB自增列，居然是表锁？
作者：赵黎明，爱可生 MySQL DBA 团队成员，熟悉 Oracle、MySQL 等数据库，擅长数据库性能问题诊断、事务与锁问题的分析等，负责处理客户 MySQL 及我司自研 DMP 平台日常运维中的问题，对开源数据库相关技术非常感兴趣。
今儿做了很多的业务需求，对接了几个接口，算是比较充实吧。想起了同事说的那句话，越忙的时候，越要停下来好好思考，抽空整理整理，不然就会很快陷入一个死循环里面去，最近也要好好整理整理之前学的一些东西了，一个清晰的条理，才能让你事半功倍。今天就补充一点之前遗漏的内容吧。
MySQL 有很多存储引擎（也叫数据引擎），所谓的存储引擎是指用于存储、处理和保护数据的核心服务。也就是存储引擎是数据库的底层软件组织。在 MySQL 中可以使用“show engines”来查询数据库的所有存储引擎，如下图所示：
在InnoDB中我们可能会遇到死锁，一般情况下我们对于死锁无需关注，MySQL会自己处理，不过如果我们在error日志中发现大量的死锁，就需要我们检查应用并进行相应的处理
在计算机系统中，锁（Lock）是一种同步机制，用于控制对共享资源的访问。它确保在任何给定时间内只有一个线程能够访问受保护的共享资源，从而避免了由并发访问导致的数据竞争和不一致问题。
作者简介： 少强，网名无衣蒹葭，阿里云资深工程师，主要做分布式存储和搜索相关的工作。 摘要： 介绍如何设计一个稳定、高并发、消息保序的IM系统，以及如何通过使用存储层的高级功能来优化系统架构。 在构建社交IM和朋友圈应用时，一个基本的需求是将用户发送的消息和朋友圈更新及时准确的更新给该用户的好友。为了做到这一点，通常需要为用户发送的每一条消息或者朋友圈更新设置一个序号或者ID，并且保证递增，通过这一机制来确保所有的消息能够按照完整并且以正确的顺序被接收端处理。当消息总量或者消息发送的并发数很大的时候，我们通
DDL（ Data Definition Language，数据定义语言）用在定义或改变表的结构数据类型、表之间的链接和约束等初始化工作上。常用的语句关键字包括 CREATE、 DROP、 ALTER 等。
关于MySQL里的change和modify，总是看到两种不同的语法，在Oracle中语法有modify，如果修改表名有rename。 alter table change,modify的语法如下: | ALTER [COLUMN] col_name {SET DEFAULT literal | DROP DEFAULT} | CHANGE [COLUMN] old_col_name new_col_name column_definition [FIRST|AFTER co
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
