nihao2q的博客

摘要：文章分析了一个数据库时间精度问题：用户禁言2天后本应在23:59:59解封，但约半数记录被错误地存入次日00:00:00。通过排查发现，Java的Timestamp对象保留毫秒精度，而MySQL的DATETIME(0)字段会四舍五入秒数，当毫秒≥500时就会进位到第二天。解决方案有两种：1)升级数据库精度为DATETIME(3)保留毫秒（推荐）；2)在代码中主动清零毫秒数（临时方案）。这个问题揭示了Java与数据库在时间精度处理上的差异，提醒开发者要注意不同系统间的数据精度匹配问题。

明明服务器 CPU、内存都很空闲，🔸🔸别再盲目加缓存、拆库拆表了！80% 的数据库性能问题，其实出在 MySQL 默认配置上。只需调整几个关键参数 + 规范 SQL 写法，轻松支撑 5000+ QPS，告别“数据库背锅侠”！✅ 适用于 MySQL 5.7 / 8.0✅ 无需改代码✅ 生产环境已验证⚠️ 为什么需要优化？MySQL 默认配置为 1GB 内存的小型机设计，而如今随便一台云服务器都是 8 核 16G 起步。🔧 必调的 6 个 MySQL 参数（附详解）

Canal 指的是阿里巴巴开源的数据同步工具，用于数据库的实时增量数据订阅和消费。它可以针对 MySQL、MariaDB、Percona、阿里云 RDS、Gtid 模式下的异构数据同步等情况进行实时增量数据同步。当前的 canal 支持源端 MySQL 版本包括 5.1.x、5.5.x、5.6.x、5.7.x、8.0.x.「Canal 是如何同步数据库数据的呢？Canal 通过伪装成 MySQL 从服务向主服务拉取数据，所以先来了解一下 MySQL 的主从复制吧。

IPv4-only→（配合INET_ATONINET_NTOAIPv6-only→BINARY(16)（配合INET6_ATONINET6_NTOA通用方案→BINARY(16)或，一表解决 IPv4 和 IPv6老铁们，下次设计数据库表的时候，就可以考虑不用去存 IP 了，用这种方式，性能和优雅度都会大幅提升！🚀 赶紧用起来吧～如果对你有帮助，帮忙点个关注，支持一下呗～

京东集团采用TiDB分布式数据库构建PB级数据底座，支撑1.1588万亿年营收业务。作为分库分表替代方案，TiDB解决了MySQL扩展性瓶颈，并通过TiFlash实现实时HTAP分析。在物流财务（100亿级单表）、零售（100TB数据）等场景中，迁移后性能显著提升：QPS达50万，延迟控制在20ms内。京东基于K8s容器化部署数百套集群，未来将持续推广TiDB应用，探索敏捷部署模式，强化供应链数字化基座。TiDB的高兼容性、扩展性和易运维特性，成为京东应对海量数据挑战的核心技术选择。

MySQL执行计划优化实战指南：深入解析EXPLAIN命令的核心要点与优化策略。文章首先剖析了EXPLAIN的关键字段，包括type（访问方式）、key（实际索引）、rows（扫描行数）等核心指标，特别指出type=ALL表示全表扫描需紧急处理。其次详细介绍了索引优化技巧，包括避免隐式转换、函数计算等失效场景，以及联合索引的设计原则。通过多个典型优化案例（全表扫描、连接查询、子查询、排序分组）展示如何改写SQL并验证效果。最后提出系统化优化流程：从慢SQL捕获到验证提升，强调索引是核心，需持续监控调整。适用

MySQL查询执行流程主要分为权限校验、查询缓存、分析器、优化器、执行器和引擎等步骤。分析器负责语法检查和解析查询语句，优化器生成最优执行计划。执行器调用存储引擎接口执行查询并返回结果。更新语句还需记录UndoLog和RedoLog，采用两阶段提交确保数据一致性。MySQL架构分为连接层、服务层、存储引擎层和文件系统层。连接器管理连接和权限验证，查询缓存在8.0版本后被移除。解析器构建语法树，优化器基于成本模型选择执行计划，执行器最终执行查询并返回结果。整个过程确保SQL查询高效安全地执行。

MySQL 9.4.0版本发布摘要：该版本主要包含字符集支持优化、编译配置改进、组件功能增强等多项更新。核心变更包括：修复IFNULL()函数在LIKE子句中的排序规则问题；升级内置ICU库至77-1版本；改进InnoDB内存管理和外键检查机制；新增mysql客户端--commands选项控制命令执行；弃用MD5()和SHA1()加密函数；解决组复制网络延迟问题；优化全文搜索性能。同时修复了多个漏洞，包括Windows安装程序、触发器执行、子查询处理等方面的问题。此版本还对编译要求进行了调整，最低CMake

摘要： InnoDB选用B+树而非跳表，因其多路平衡特性适合磁盘存储：节点对齐16KB页面减少I/O，叶子节点链表优化范围查询，并支持事务锁机制。而Redis作为内存数据库，跳表的动态更新效率（O(logn)）、简单实现及内存友好性更契合其需求，尤其适合有序集合的高频操作。关键差异在于B+树针对磁盘I/O和稳定查询优化，跳表则胜在内存场景的灵活性与轻量级。二者分别适配了关系型数据库与内存数据库的核心场景需求。

MySQL表结构变更方案摘要：针对不同场景推荐三种方案：1. MySQL8.0+优先使用INSTANT算法（秒级完成，仅修改元数据）；2. 不满足条件时采用pt-online-schema-change工具（无锁表，支持暂停）；3. 低版本或复杂修改需临时表重建（需停服）。亿级数据建议预分区，新增字段应允许NULL值并避免NOT NULL约束。关键注意事项包括：检查磁盘空间、监控主从延迟、业务低峰期操作，并准备好回滚方案。各方案执行时间从秒级到小时级不等，需根据MySQL版本、数据量和业务需求选择。

MySQL自增主键耗尽问题解析及解决方案 当MySQL的自增主键达到INT UNSIGNED上限（4294967295）时，系统会因主键冲突而拒绝新数据插入。问题本质是InnoDB引擎在达到最大值后不再自增，而是复用当前值导致冲突。 解决方案： 升级字段类型：将INT改为BIGINT，支持更大数据量 分布式ID架构：采用雪花算法或号段模式生成全局唯一ID 数据管理：实施分库分表和定期归档策略 预防建议： 定期监控自增ID使用率，提前规划扩展方案，避免业务中断。大表操作需使用在线工具，确保系统平稳过渡。

摘要：本文介绍了CQRS（命令查询职责分离）架构在电商系统中的应用价值。通过将读写操作分离，分别优化处理逻辑，可有效解决高并发场景下的性能问题。文章详细解析了CQRS的核心思想、三大优势（模型分离、技术栈自由搭配、事件驱动架构），并提供了Java企业级应用的落地指南，包括领域模型设计、数据同步策略、技术选型建议等。同时指出CQRS适用于读写负载差异大的场景，但对一致性要求极高的系统需谨慎采用。

本文整理了30个高频SQL面试考点，涵盖基础查询、聚合函数、表连接、子查询、窗口函数等核心内容。SQL作为数据岗位的必备技能，超过85%相关职位要求应聘者熟练掌握。文章通过具体示例详细解析了SELECT筛选、GROUP BY分组、JOIN连接等基础操作，以及窗口函数、日期处理、性能优化等进阶技巧，并包含用户留存率、销售漏斗等实战案例。这些知识点能帮助求职者系统掌握SQL技能，有效应对90%以上的企业考核要求。

MySQL主从复制是数据库架构设计中的关键技术，主要用于提升系统的高可用性、性能优化和数据安全性。其核心功能包括：1. 高可用性保障，主库故障时可快速切换从库为主；2. 读写分离与负载均衡，主库处理写操作，从库处理读请求；3. 数据安全与灾备恢复，从库作为异步备份防止数据丢失；4. 性能扩展性突破，通过增加从库数量提高读性能；5. 业务解耦与数据分析，从库用于独立运行离线任务。实现原理基于二进制日志的异步同步，主库将写操作记录到binlog，从库通过I/O线程拉取并存储为relaylog，再由SQL线程执行

文章摘要：本文主要介绍了在MySQL 8.0.36环境下处理数据库连接问题的过程。首先，通过gdb工具紧急修改了max_connections参数，从500增加到1000，以解决连接数过多的问题。尽管在修改过程中出现了一些DwarfError报错，但最终成功修改了参数。接着，通过赋予SERVICE_CONNECTION_ADMIN权限，解决了连接失败的问题。文章还提到，在生产环境中使用gdb工具可能存在风险，建议定期检查并控制使用root用户的情况，以避免类似问题的发生。最后，文章总结了处理过程中的思路和教

easy-data-scope 是一个通过动态注入 SQL 实现数据权限的项目，支持 MyBatis、MyBatis-plus 和 MyBatis-flex。它简化了数据权限的实现，仅需通过注解即可完成配置，无需复杂的设置。项目搭建包括导入基础依赖和核心依赖，配置数据库连接，并编写启动类。通过实现 DataScopeFindRule 接口并交由 Spring 管理，easy-data-scope 会根据 find() 方法返回的 DataScopeInfo 列表构建 SQL。使用 @DataScope 注解

快速排序是一种高效的分治排序算法，由Tony Hoare于1960年提出。它通过递归地将数据集划分为较小和较大的两个子序列来实现排序，平均时间复杂度为O(n log n)，在处理大规模数据时表现优异。算法核心包括选择基准元素、分区和递归排序。优化策略有随机化基准选择和三数取中法，以减少最坏情况的发生概率。快速排序在工程应用中广泛使用，如Python的sorted()函数和C++ STL的sort()实现。尽管最坏时间复杂度为O(n^2)，但通过优化，快速排序在大多数实际场景中保持最优性能。

Easy-Data-Scope 是一个通过动态注入SQL实现数据权限控制的项目，支持MyBatis、MyBatis-plus和MyBatis-flex。其核心特点是使用简单，仅需通过注解即可实现复杂的数据权限控制，无需繁琐配置。项目通过@DataScope注解，结合DataScopeFindRule接口，动态生成SQL语句，实现对数据的精确权限管理。例如，可以通过注解实现仅查看特定ID或年龄范围的用户数据，并支持多条件合并（如IN操作）。项目还提供了灵活的模板和逻辑符配置，支持多种复杂场景下的数据权限控制。

技术总是要进步的。分库分表，不是错，它在那个年代，解决了实际问题，是很多系统撑起流量的支柱。但如今，分布式数据库已经逐步走入正轨，成为更成熟、更底层的解决方案。要说分库分表会不会彻底消失？我觉得不会。就像今天你还会看到写纯 SQL 的人，虽然 ORM 很香；你还会看到有人坚持手撸 Redis 连接池，虽然 Spring Data Redis 一键搞定。该退出的角色，终究会被历史“温柔劝退”。就像你不会再买诺基亚 3310，虽然它电池真能用十天；你也不会坚持用 IE 浏览器，虽然它当年也登过顶峰。

- 拿到要删除的最大主键 ID-- 每次只删 20000 条然后在应用层做个循环，每次删完睡 0.5 秒，看是不是为 0，为 0 就退出循环。说实话，这种小批量删除法，不仅减轻了主库压力，还让从库同步更顺畅，凌晨 Sentry 报警直接“消失”。

我们现在有一个驱动表customer，它存储客户id、姓名以及出生日期，默认情况下id是主键，没有任何索引，对此我们给出DDL语句： customer有一张关联表，c_id记录着与其关联数据的id，并用available_balance记录客户余额，对应DDL如下，可以看到此时我们没有添加任何索引： 假设此时数据库大约有2000w的数据，我们希望查出姓名为if2vbdr1kzk47rdmulrxix48tl2r9finmonxpl25cfrqvv7m0t的用户的出生日期和可用余额，如果没

通过引入主从数据库同步系统，可以显著提升电商平台的性能和稳定性，同时保证数据的一致性和安全性。Druid连接池也提供了强大的监控和安全防护功能，使得整个系统更加健壮和可靠。

Redis Cluster 是 Redis 提供的分布式解决方案，其核心思想是通过分片（Sharding）将数据分布到多个节点上，从而实现高可用性和水平扩展。今天，我们来深入剖析 Redis Cluster 的分片策略与扩容方案，并结合实际案例给出代码示例，帮助大家在设计系统时轻松应对海量数据的挑战。通过 Redis Cluster 的分片策略，系统能够高效地存储和查询商品的热点数据，同时支持动态扩容，满足了业务快速增长的需求。欢迎在评论区分享你的经验！每个槽位对应一部分数据，槽位的分布决定了数据的分布。

（以左边的为准，数据保持不变，取关联右边表的数据，有则关联，没有则返回。子查询：子查询是嵌套在另一个查询中的查询。内连接：只输出两个表中匹配字段都存在的记录行，取的是交集。左外连接：输出左表所有记录行，右表没有匹配项的自动用空值。提供了一种定义临时结果集的方法，这些结果集可以在后续的。右外连接：输出右表所有记录行，左表没匹配项的自动用空值。- distinct：用于返回唯一不同的值，通常。：于在查询中实现条件逻辑，类似于编程语言中的。排序：通过某个字段进行排序，升序或者降序。用于去除查询结果中的重复记录。

今天分享一下Prometheus如何监控MySQL数据库实验环境：数据库服务器：10.0.0.41prometheus服务器：10.0.0.104默认数据库和prometheus都已部署好！下面演示安装mysql_exporter过程。

MySQL的锁定主要分为全局锁、表锁和行锁。现在我们来看看MySQL全局锁。MySQL全局锁是针对整个数据库的锁。最常用的全局锁是读锁和写锁。读锁（共享锁）：它阻止其他用户更新数据，但允许他们读取数据。这在你需要在一段时间内保持数据一致性时很有用。写锁（排他锁）：它阻止其他用户读取和更新数据。这在你需要修改一些大量的数据，并且不希望其他用户在这段时间内干扰时很有用。MySQL全局锁的典型使用场景是，进行一些需要确保整个数据库一致性的操作，例如全库备份、全库导出等。在MySQL中，可以使用。

SQL调优是一个复杂的过程，需要根据具体情况进行具体分析。本文介绍的11个问题只是SQL调优中的冰山一角，实际工作中还会遇到各种各样的问题。我们需要不断学习和积累经验，才能成为一名优秀的SQL调优专家。

通过这 5 种方案，我们完全可以解决 MySQL 深分页的性能问题。其中延迟关联方案在生产环境中表现最为稳定可靠，建议作为首选方案。

上周，有个小伙伴参加了美团的面试。面试官给他出了一个很经典的问题：两个数据库各有一百万条数据，如何在20秒内完成数据比对？小伙伴没有答到点子上，面试官不满意，最终面试挂了这个问题看似简单，但实际上却需要高效的算法设计。今天，我们就来详细解析一下这个问题，并给出一些实用的解决方案。接下来我分享一下具体细节。为了实现高效的比对，可以选择HashSet作为主要的数据结构。HashSet的显著特点是利用哈希表实现，保证了元素的唯一性和查询速度。在此场景下，HashSet将提供接近O(1)的查询性能，大大缩短比对时间

in查询在进行cost代价计算时（代价 = 元组数 * IO平均值），是通过将in包含的数值，一条条去查询获取元组数的，因此这个计算过程会比较的慢，所以MySQL设置了个临界值(eq_range_index_dive_limit)，5.6之后超过这个临界值后该列的cost就不参与计算了。在应用开发的早期，数据量少，开发人员开发功能时更重视功能上的实现，随着生产数据的增长，很多SQL语句开始暴露出性能问题，对生产的影响也越来越大，有时可能这些有问题的SQL就是整个系统性能的瓶颈。在索引上，避免使用NOT、!

/ 定义Calcite模型JSON字符串" {\n" +" }\n" +" }\n" +" ]\n" +"}";// 创建Calcite连接// 获取根模式并添加子模式@Override// 返回表映射，这里不需要额外处理。

最近在重构一个老项目时，被一段SQL查询卡得死死的，排查下来才发现是 IN 和 NOT IN 惹的祸。虽然这两个关键字看着挺顺手，写起来也方便，但我今天就来说说为啥真正的开发老司机都悄悄抛弃了它们。

本文，我们分析了如何处理 MySQL 的主从复制延时问题，处理 这个问题需要综合考虑多方面因素，包括主从服务器性能、网络环境、复制配置及数据操作模式等。通过系统化的监控、深入的原因分析和针对性的优化措施，可以有效减少复制延迟，确保数据库系统的高可用性和数据一致性。

手机屏幕的蓝光在黑暗里格外刺眼。我揉了揉眼睛，盯着监控图表——明明加了分布式锁限制60秒一次，为什么短短10秒内连续执行了3次任务？逻辑看似完美，但现实却狠狠打脸。我翻身下床，打开电脑，一场与“幽灵锁”的战争就此开始……••查询日志，发现是相同的，也就是说锁Key是一样的，非动态变化。在20秒内一共请求了26次，这手速...不是，大半夜运营小姐姐还在加班？杯具。。。：锁Key正确，Redis服务正常，但新请求却能获取锁。

1. ngx_stream_core_module模块从1.9.0版本开始出现，默认不包含此模块，需要通过。3. 地址和端口配置的另外几种形式。IPv6地址需要用方括号括起来，如。监听所有网络接口(IP)可以配置监听的端口范围，用。连接符号分割起止端口，如。只设置端口号，相当于。

你可能遇到过这些问题：• 明明加了索引，查询还是卡得像蜗牛？• 一到高峰期，数据库就疯狂报警？• 索引建得越多，写入反而越慢？大多数性能问题都源于。盲目建索引、迷信“最佳实践”，却忽略业务场景和数据分布，是新手甚至老司机常踩的坑。1. 搞懂索引设计的核心逻辑（比如三星索引），。2. 掌握高性价比的优化技巧，用最少索引解决80%的性能问题。3. 避开“看似正确实则坑爹”的设计误区（比如乱用联合索引顺序）。• 被慢查询折磨到崩溃的开发者• 想从CRUD进阶到调优的SQL学习者。

1. 优化口诀•高区分度打头阵：索引列重复值要少。•最左前缀不能丢：联合索引条件从左到右。•覆盖索引是王道：能少回表就少回表。•函数计算是大忌：索引列上别搞花里胡哨。2. 终极检查工具：EXPLAIN重点关注以下字段：•typeALL表示全表扫描，ref/range表示走索引。•key：实际使用的索引。•rows：扫描行数估算。•Extra表示覆盖索引。

日志类型目的存储内容写入时机生命周期归属层级Undo Log回滚事务、实现 MVCC修改前的数据副本事务修改数据时事务结束后异步清理InnoDB 存储引擎层Redo Log崩溃恢复、保证持久性物理修改操作事务提交前覆盖循环使用InnoDB 存储引擎层Binlog主从复制、数据恢复逻辑操作（SQL/行）事务提交时长期保留（可配置）MySQL Server 层。

在实际的项目开发与运维过程中，MySQL 常常扮演着业务数据库的核心角色，以其强大的事务处理能力和数据完整性保障，支撑着系统的稳定运行。然而，随着数据量的急剧增长和查询复杂度的不断提升，单一依赖 MySQL 进行高效的数据检索显得日益吃力，尤其是在面对海量数据的复杂查询场景时，性能瓶颈愈发凸显。为了有效缓解这一挑战，我们通常采用读写分离的策略，将 Elasticsearch（简称 ES）引入作为专门的查询数据库。ES 以其卓越的搜索性能、灵活的数据模式以及强大的可扩展性，成为处理复杂查询需求的理想选择。

发现事故根源竟是一个看似平常的查询——用户中心的历史订单分页查询。这背后隐藏的正是的典型问题——数据越往后查，速度越让人抓狂。这样的查询，会让数据库像逐页翻阅千页文档的抄写员，机械地扫描前 10 万条记录再丢弃。当数据量突破千万级时，这种暴力扫描不仅造成 I/O 资源的巨大浪费，更会导致关键业务查询的链式阻塞。本文将深入拆解深度分页的技术黑箱，通过电商订单表等真实场景，揭示 B+树索引与分页机制的碰撞奥秘，并给出 6 种经过实战检验的优化方案。