5个月倒计时：MySQL 8.0明年停止支持 IT之家 11 月 26 日消息，科技媒体 BornCity 今天（11 月 26 日）发布博文，报道称开源数据库 MySQL 8.0 将于 2026 年 4 月 30 日停止支持，然而数据库服务商 Percona 的数据显示，目前仍有超过 58% 的 MySQL 实例运行在该版本上，大量应用面临潜在安全风险。Percona 公司的 Peter Zaitsev 对此发出警告，敦促 IT 负责人正视这一问题并立即着手制定升级或替换方案。IT之家援引博文介绍，除了大量在用的 MySQL 8.0 版本，数据显示还有 18.8% 的实例仍在使用已于 2023 年停止支持的 MySQL 5.7 版本。这些过时的数据库系统构成了严重的安全隐患，可能成为黑客攻击的突破口。对于仍在犹豫的用户，Zaitsev 特别指出，此次升级的复杂度已显著降低。相较于过去从 MySQL 5.7 升级到 8.0 的巨大工作量，从 MySQL 8.0 迁移至当前最新的稳定版本 8.4，其过程要简单得多，为受影响的用户提供了一条相对平滑的升级路径。返回搜狐，查看更多

MySQL 8.0即将停止支持，用户面临迁移挑战 MySQL 8.0的支持期限即将结束，用户只有六个月时间进行迁移，否则将面临安全和可靠性风险。开源数据库支持服务和数据库即服务提供商Percona警告称，超过半数的MySQL实例仍在使用MySQL 8.0版本，而该版本的支持将于2026年4月30日结束。Percona联合创始人Peter Zaitsev表示："每个复杂软件都有可能存在尚未发现的错误，其中一些还可能是安全漏洞。这些是最棘手的问题：当软件不再受到支持和维护时，意味着这些错误将不会再得到修复。"来自Percona开源数据库管理工具PMM的数据显示，58%的MySQL和MariaDB实例运行MySQL 8.0版本，而18.8%仍在运行5.7版本，后者已于2023年停止支持。虽然用户可能因为迁移带来的干扰而推迟数据库升级，但他们应该了解，从MySQL 8.0升级到8.4（最新稳定版本）的难度远不如从5.7升级到8.0那样艰难。Zaitsev表示："那次升级是一个非常大且痛苦的跳跃。"近年来，MySQL的受欢迎程度有所下降，其在对数DB-Engines排行榜上的评分下滑，PostgreSQL可能在不久的将来超越它，尽管MySQL目前仍位居第二，仅次于Oracle。微软SQL Server排名第三，与MySQL一样，其受欢迎程度也在下降。在Stack Overflow开发者调查中，MySQL仍保持第二位，约40%的专业开发者使用它，但远落后于PostgreSQL的55%使用率。Sun Microsystems于2008年收购了MySQL，Oracle在次年同时收购了两家公司。尽管Oracle被视为这个开源数据库的合理管理者，MySQL在2000年代是流行的LAMP技术栈的支柱，但最近Oracle对该系统的长期投入受到质疑，因为其重点转向基于MySQL的分析型数据库即服务HeatWave。据报道，Oracle在9月份对MySQL工程团队进行了大规模裁员。当时Oracle拒绝对此发表评论。Zaitsev声称："Oracle是否在减少对开源MySQL的投资，减少功能等等？我认为这种情况一直在加剧，真的很残酷。我与一些离职人员交谈过，其中一些人估计工程团队已经走了60%到70%的人。"虽然用户可能考虑迁移到2009年从MySQL分叉出来的MariaDB，或者PostgreSQL，但迁移是有成本的。Zaitsev说："MariaDB和MySQL 8.0之间的差异比8.0和8.4之间的差异要大得多，所以你应该准备做更多工作。"Q&AQ1：MySQL 8.0什么时候停止支持？A：MySQL 8.0将于2026年4月30日停止支持，用户只有大约六个月的时间进行迁移到受支持的版本。Q2：从MySQL 8.0升级到8.4困难吗？A：从MySQL 8.0升级到8.4的难度远不如从5.7升级到8.0那样艰难。5.7到8.0的升级被描述为"非常大且痛苦的跳跃"，而8.0到8.4的升级相对容易得多。Q3：为什么要尽快从MySQL 8.0迁移？A：继续使用不受支持的MySQL 8.0版本会面临安全和可靠性风险，因为发现的漏洞和错误将不再得到修复，特别是安全漏洞问题最为严重。返回搜狐，查看更多

为什么不建议在 MySQL 中使用 utf8 ？ 今天在知乎上看到这样一个问题："为什么不建议在MySQL 中使用 utf8？"问题地址：https://www.zhihu.com/question/630892089网友 1：灵狐技术MySQL当年在支持utf8的时候，自作聪明整了些优化措施。结果，大家使用过一段时间后，发现了这些优化措施，不能完整地支持utf8。MySQL后面想修正这个bug。但是，这个优化版utf8已经在外面大量使用了。所以，MySQL只好保留了bug版的优化utf8，然后整了个utf8mb4来重新支持utf8标准。……MySQL的这个教训说明：对于标准化的东西，别瞎捉摸；你的理解再怎么自认为有道理，没用！只会闯祸！你做的题，只要对不上公开的标准答案，就是零分又甜又甜：这个吃过大亏，现在很多订单里面会有表情符号，如果直接保存订单内容会直接从表情符号后截断，没有后面的内容风之帆：因为MySQL的utf8是阉割版的utf8，utf8mb4才是真正的utf8。邵NewBee：被坑过一次，项目开发上线了发现不支持表情回复。精灵福将马国成：我们公司最开始一个项目，当时MySQL数据库设置utf8，项目使用了半年，然后录入了广东那边一个人身份证名称带有生僻字，导致入库报错，后来我们把utf8改成utf8mb4就好了。展开全文又甜又甜：这个吃过大亏，现在很多订单里面会有表情符号，如果直接保存订单内容会直接从表情符号后截断，没有后面的内容风之帆：因为MySQL的utf8是阉割版的utf8，utf8mb4才是真正的utf8。邵NewBee：被坑过一次，项目开发上线了发现不支持表情回复。精灵福将马国成：我们公司最开始一个项目，当时MySQL数据库设置utf8，项目使用了半年，然后录入了广东那边一个人身份证名称带有生僻字，导致入库报错，后来我们把utf8改成utf8mb4就好了。网友2：写代码和简谈人文MySQL的utf8只支持每个字符最多三个字节，而我们需要的是最多四个字节，从而我们在操作字符串时，会遇到一些很难溯源的bug(比如表情存储)。MySQL在2010发布了utf8mb4来支持四个字节，可以说MySQL的utf8mb4是我们真正意义上的UTF-8。MySQL本意是想在utf8上保持空间和速度，但是在使用utf8的char列时，实际使用的空间比预期更大，速度也慢，而且无法保存“”这样的字符，MySQL发布了utf8mb4来绕过了这个问题。网友3：CoderJia在MySQL 8.0中，推荐使用的编码是utf8mb4。这种编码方式完全兼容utf8，每个字符最多占4个字节，就可以支持更多的字符，原来的utf8编码只能存储最多三个字节的字符，这在存储某些国家的文字或罕见字时有些困难了。从MySQL 8.0版本开始，其默认的连接字符集从latin1改为了utf8mb4，同时字符序也从latin1_swedish_ci改为了utf8mb4_0900_ai_ci。当使用utf8mb4字符集时，通常推荐使用utf8mb4_unicode_ci或utf8mb4_general_ci排序规则。SQL乱码问题查看编码my.ini配置文件网友4：爱可生云数据库官方在后续的 MySQL 版本也会逐渐删除 utf8。在深入探讨 utf8mb4 的好处之前，我们先澄清一下 utf8mb4 代表什么。在 MySQL 中，“utf8”是指支持 Unicode 字符集的字符编码，每个字符最多使用三个字节。然而，MySQL 中原始的 utf8 实现并没有涵盖所有 Unicode 字符。另一方面，utf8mb4 是 utf8 的修改版本，它支持完整的 Unicode 字符集，包括表情符号和其他补充字符，每个字符最多使用四个字节。MySQL 中原始的 utf8 实现仅支持基本多文种平面（BMP）中的字符，大约占所有 Unicode 字符的 90%。另一方面，utf8mb4 支持整个 Unicode 字符集，包括表情符号和其他补充字符。它通过每个字符最多使用四个字节而不是 utf8 使用的三个字节来实现此目的。下表显示了 utf8 和 utf8mb4 之间的区别：注意：历史上，MySQL 使用字符集 utf8 作为 utf8mb3 的别名。但是，从 MySQL 8.0.28 开始，utf8mb3 仅在 SHOW 语句的输出和信息架构表中引用该字符集时使用。未来，utf8 有望成为 utf8mb4 的参考。为了避免任何歧义，建议在引用该字符集时显式指定 utf8mb4。如您所见，utf8、utf8mb3 和 utf8mb4 之间的主要区别在于每个字符的最大字节数。utf8 和 utf8mb3 只能存储 BMP 中的字符，而 utf8mb4 还可以存储补充平面（Supplementary Plane）中的字符。这意味着 utf8mb4 可以支持更广泛的字符，包括表情符号、数学符号和其他特殊字符。这三个字符集之间的另一个区别是它们在 MySQL 中的默认状态。utf8 是 MySQL 5.7 及更早版本中的默认字符集，而 utf8mb3 是 MySQL 8.0 中的默认字符集。但是，utf8mb4 是 MySQL 8.0.28 及更高版本中的默认字符集。最后，MySQL 8.0 中已弃用 utf8 和 utf8mb3。这意味着它们最终将从 MySQL 中删除，因此建议使用 utf8mb4 代替。因此，如果您需要存储所有 Unicode 字符，包括表情符号和其他补充字符，那么您应该使用 utf8mb4。但是，如果您只需要存储 BMP 中的字符，那么 utf8 可能就足够了。网友5：春秋的呓语用不等式秒杀MySQL utf8 ≠ utf8网友6：学好逻辑再来辩MySQL经典冷笑话：我的 utf8 不是 utf8，我的 utf8mb4 才是 utf8！返回搜狐，查看更多

MySQL自增id超过int最大值怎么办？ 一、故事背景今天运维那边反馈有一个设备在后台查不到，我第一时间怀疑可能是数据出了问题，导致服务报错了没有入库。我拿着日志去本地请求接口，发现程序是没有报错的，我们的逻辑是先把唯一id放到redis里面，如果redis没有值就insert，有就update，做了一层缓存，估计是这样的话批量插入和更新数据库会快一点。然后我看redis是有值的，以为是redis和数据库数据不一致问题，我就把redis的key删了，重新再跑一下，结果打印了insert语句，但是没有插入到数据，看来事情并没有那么简单- -二、问题分析因为数据表很大，有5E+数据，我第一反应是mysql表数据量可能爆了，但是查了下好像没有太大限制再认真看了下表的自增id，这个数字让人有点熟悉的：2147483647 这个不就是int的最大值吗。意思是因为自增id超过了int，所以插入失败了，id设的就是int类型，还有个小彩蛋，目前数据库设的int长度是50，但是根本没什么鸟用。展开全文知道了问题在哪，但是这个问题处理起来很麻烦，因为数据量太大了，先请教一下deepseek吧。三、方案处理deepseek给我提供了三个方案，第一个是最简单粗暴的改BIGINT，不用迁移数据，但是会全程锁表。第二个分布式ID需要重新设计表，需要把数据迁移到新表，而且还要redis等支撑。第三个分库分表就更麻烦了，分库分表需要引入框架，不按照分片查询还需要引入ES，引入了ES还需要引入同步mysql和ES的中间件logstash等。但是改bigint估计锁表太久，我先看看有没有其他办法先紧急处理下数据。但是按理说int最大值是21E+，数据表数据才5E+，按理说是用不完的。结果我看到自增的id值居然是不连续的按理说自增id应该是一个接着一个，不会有空隙的，后面查了一下由于数据库自增id有个高性能策略，设置了id就不一定连续。后面又查了下有没有一键把数据表id重排的方法，结果也是没有的。最后我是写了一个存储过程先把最后100万的id清理出来，可以先顶个几天，后面再想办法处理。BEGINDECLARE start_id INT DEFAULT 1;DECLARE end_id INT DEFAULT 100000;DECLARE current_batch INT DEFAULT 0;WHILE start_id <= end_id DO-- 更新临时表中的IDUPDATE tableSET id = start_id + 1WHERE id = (select original_id from (SELECT id AS original_idFROM tableORDER BY id DESCLIMIT 1) as test);SET start_id = start_id + 1;END WHILE;END最后重新设置自增值，如果自增值已经存在，则会跳到max(id)+1-- 重置自增值ALTER TABLE your_table AUTO_INCREMENT = max(id)+1;清理了大概500万的id段出来，然后我怀疑id间隔这么大是因为并发太高导致的。一开始程序是单线程，消费到500条就批量入库，但是后面发现单线程消费比较慢，数据量太多消费有点延迟。后面改成java批量消费，配置了30个消费者。接着我尝试了一下减少消费者数量，设置成15个，id的间隔真的变小了。四、设置BIGINT节后回来发现id还剩200万，讨论到最后还是把id的数据类型从int改成bigintALTER TABLE xxx MODIFY id BIGINT UNSIGNED NOT NULL AUTO_INCREMENTUNSIGNED 无符号位，不算负数，可以增加一倍数据，NOT NULL 非空 AUTO_INCREMENT自增在测试环境有一亿数据，修改id的类型大概用了一个小时，现网我估计也是用6-7个小时也差不多了。结果改了一晚上都还没改好，然后我找了一个可以查询sql进度的语句......SELECT EVENT_NAME, WORK_COMPLETED, WORK_ESTIMATED, ROUND(WORK_COMPLETED/WORK_ESTIMATED*100, 2) AS "Progress (%)" FROM performance_schema.events_stages_current;不查不知道，一查吓一跳，跑了十几个小时居然还不到50%，而且还越跑越慢。对比了一下测试环境和现网环境的buffer_pool等数据也是设置正常。估计是索引树变大插入的数据要花多不少时间，还有一个就是现网数据库还有其他线程会抢占CPU导致速度缓慢。统计了一下后面的数据大概是1个小时完成1.5%左右最后我是周一晚上执行的，周四早上上班的时候才跑完，用了2天多一点的时间~五、总结之前刷到一篇文章《字节面试：MySQL自增ID用完会怎样？》，评论区都说有没有用完的，结果我真用完了，就感觉有点不可思议。总结一下有几个原因吧：1、数据量确实很大，有5E多数据，然后并发也很高。其实当初他们设计的时候也预料过这个问题，所以设了个int长度50，但是这个长度没起作用- -所以设计数据库的时候一定要做好，不然几亿数据改个字段类型要2天2、数据库的自增id策略选了高性能策略，导致并发高的时候id间隔很大。30个消费者异步处理，10条数据大概用了100个id的间隔，消耗太快了。所以这里存在一个时间和空间的取舍，使用多线程还是挺危险的操作，要谨慎一点。还有一个小插曲，因为系统两天没消费数据，kafka的数据堆积了很多，然后我把消费者数量从30个改成50个，跑了两天，kafka还是有1天的延迟，看来麻木添加消费者数量已经没啥提升的作用了，想起八股文说多线程弄太多反而增加上下文切换的时间浪费，跟这个同理。最后我弄成sql批量消费，消费速度马上提上去了。程序的消费策略：单线程批量500个开始消费 ——> 30个线程单个消费 ——> 30个线程批量50个开始消费所以说多线程异步+批量操作的策略还是很重要的！不过多线程一定要注意异步问题~作者丨玛奇玛丶来源丨网址：https://juejin.cn/post/7494167764917305379dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn返回搜狐，查看更多

Ubuntu 16.04 安装 MySQL 5.7 MySQL 是一款开源的关系型数据库管理系统，广泛应用于 LAMP 架构（Linux、Apache、MySQL、PHP/Python/Perl）中。它通过结构化查询语言（SQL）对数据进行存储、查询和管理，具有高效、稳定和易于使用的特点，是当前最流行的数据库系统之一，适用于各类Web应用和信息系统开发。1、 先确认Ubuntu系统版本，本文以16.04为例，其他版本可作参考。2、 查看Ubuntu系统版本信息的方法及步骤说明。3、 在 Ubuntu 16.04 系统中，APT 软件源默认仅提供最新版 MySQL。若需安装 MySQL 5.7，只需更新系统的包索引，随后通过 apt-get 命令安装默认的 MySQL 软件包即可完成部署，操作简便且无需额外配置。4、 运行指令5、 安装时系统会提示设置root密码，请选择一个安全且便于记忆的密码，后续操作将需要用到。随后，我们将继续完成MySQL的配置步骤。6、 安装MySQL后需执行安全配置脚本，以修正默认设置中的安全隐患，如禁用远程root登录和删除示例用户。相比旧版本需手动初始化数据目录，MySQL 5.7及以上版本已自动完成该步骤，用户只需运行安全脚本即可提升数据库安全性，确保基本防护措施生效。7、 系统会提示您输入在步骤3中设定的root密码。对于后续出现的所有问题，您可以直接按Y键并回车，采用默认设置。当询问是否需要修改root密码时，由于已在步骤3中完成设置，此处无需更改。我们将对MySQL的安装进行测试，确保其正常运行。8、 安装完成后，MySQL通常会自动启动。可通过检查服务状态来验证其是否正常运行。9、 通过 mysqladmin 工具可连接数据库并执行管理操作。该工具作为客户端，支持运行各类管理命令。例如，使用-u root以 root 用户身份登录 MySQL，配合-p提示输入密码，即可连接并获取数据库版本信息。