DB-MySQL - 文章分类 - xibuhaohao

MySQL - 备份恢复 - 使用 XtraBackup 远程备份与恢复单库或单表

摘要：MySQL 5.7 中 Percona XtraBackup (包含 innobackupex 工具) 支持远程备份。它可以通过流备份技术，直接将数据从本地服务器备份到远程服务器，无需在目标服务器安装 xtrabackup，特别适合本地磁盘空间有限的情况。 1. 远程备份操作步骤 1.1. 准备工作阅读全文

posted @ 2025-09-29 14:09 xibuhaohao 阅读(1) 评论(0) 推荐(0)

MySQL-SQL-优化：全文索引

摘要：1. 全文索引类型与选择 MySQL主要提供两种全文索引解析器，适用于不同场景：特性标准全文索引NGRAM全文索引适用语言西方语言（英语、法语等）任何语言（包括中文、日文、韩文）和无空格分隔的字符串（如商品码、身份证号）分词原理基于空格、标点进行分词，有停用词列表。基于固定的字符长度（阅读全文

posted @ 2025-09-19 16:16 xibuhaohao 阅读(4) 评论(0) 推荐(0)

MySQL-脚本- 统计MySQL 中表数据行数与字段个数超过指定值脚本

摘要：1 统计MySQL 中表数据行数与字段个数超过指定值脚本 [root@wx-yunwei-auto-front-162-151 soft]# cat get_eligible_tables_pro.sh #!/bin/bash # 配置变量 - 可根据需要调整 LARGE_TABLES_FILE=" 阅读全文

posted @ 2025-09-03 10:38 xibuhaohao 阅读(9) 评论(0) 推荐(0)

大数据方法论（二）：让大数据变得“轻快准”：商超行业的三大数据处理秘诀

摘要：对于商超行业的大数据业务处理，我总结了三点方法论： 1、大批次数据分批次处理（从大变小） 2、小批次数据汇合处理（从小变大） 3、预计算提前处理（以空间换时间） 1. 大批次数据分批次处理（从大变小）核心思想：化整为零，分而治之。将单个巨大的、难以处理的任务拆分成多个小而可控的子任务。为什么在商阅读全文

posted @ 2025-08-28 18:09 xibuhaohao 阅读(4) 评论(0) 推荐(0)

大数据方法论（一）：三大核心方法论（从大变小 / 从小变大 / 以空间换时间）

摘要：对于商超行业的大数据业务处理，我总结了三点方法论： 1、大批次数据分批次处理（从大变小） 2、小批次数据汇合处理（从小变大） 3、预计算提前处理（以空间换时间）你总结的这三点方法论，精准契合了商超行业大数据的 **“海量、高频、多维度” 特性 **（如采购库存数据、实时订单、会员消费、促销报表等场阅读全文

posted @ 2025-08-28 18:07 xibuhaohao 阅读(2) 评论(0) 推荐(0)

MySQL-问题-从库的复制线程或内部引擎出现了严重问题，导致了一个“自我毁灭”的写入风暴

摘要：1. 问题现象 1.1监控现象 1.1.1 CPU 1.1.2 内存 1.1.3 网络 1.1.4 shard poll 1.1.5 磁盘读写 1.2 error log 大量并行复制产生的告警内容 1.3 binlog 量主库在问题期间，没有大批量的写库动作，仅产生少量binlog 2. 问题提阅读全文

posted @ 2025-08-27 20:12 xibuhaohao 阅读(5) 评论(0) 推荐(0)

MySQL-用户权限冲突与覆盖问题全面解析：基于用户、主机、DB与权限的视角

摘要：1. 核心问题概述今天遇到的问题本质是：在MySQL中，由于手动操作与平台化工单并行，对同名用户但不同主机-DB范围的账户进行了权限分配，导致来自特定网段的连接因MySQL的账户匹配优先级规则而使用了非预期的权限，造成权限被“屏蔽”或“缩小”的现象。 2. 四个维度的详细总结维度初始状态 (手动阅读全文

posted @ 2025-08-26 19:56 xibuhaohao 阅读(7) 评论(0) 推荐(0)

MySQL-SQL-优化：分页-深度分页痛点-COUNT(*)

摘要：1. 分页痛点COUNT(*) 深度分页场景下的另一个核心痛点。计算 COUNT(*) 确实可能成为一个巨大的性能瓶颈，尤其是在多表关联和复杂查询条件下。以下是优化总条数计算的几种策略，从根本性规避到技术性优化，您可以根据业务场景选择最适合的方案。 2. 终极方案——规避 COUNT(*) 这是最阅读全文

posted @ 2025-08-23 14:44 xibuhaohao 阅读(11) 评论(0) 推荐(0)

MySQL-SQL-优化：分页-多对多分页案例

摘要：1. 场景介绍假设我们正在为一个在线教育平台构建后台，需要分页展示所有课程，并且每展示一门课程，都要同时列出选修了该课程的所有学生。这是一个典型的多对多关系。 2. 表结构与测试数据我们先创建三张表并插入一些示例数据。表 1: courses (课程表) 存储课程的基本信息。 sql CREA 阅读全文

posted @ 2025-08-23 14:34 xibuhaohao 阅读(3) 评论(0) 推荐(0)

MySQL-大事务-5.6/5.7 大事务查询

摘要：好的，在 MySQL 5.7 中查询正在运行的实时大事务和分析历史大事务是 DBA 常见的性能诊断任务。下面我将为你提供详细的方法和 SQL 语句。 1. 查询实时运行的大事务实时大事务通常指那些运行时间过长、占用资源多（如未提交事务持有大量锁、产生大量 undo log）的事务。主要通过查询阅读全文

posted @ 2025-08-22 09:03 xibuhaohao 阅读(19) 评论(0) 推荐(0)

mysql - 问题 - 警惕版本陷阱：MySQL 8.0.43 与 ShardingSphere 5.1.2 的权限兼容性问题解决方案

摘要：1. 问题 java服务使用图片中的驱动，查询mysql8.0.43报错： SELECT command denied to user 'replenishment_admin'@'10.10.21.144' for table 'st_billno_rule' 1）用户 replenishment 阅读全文

posted @ 2025-08-14 11:26 xibuhaohao 阅读(70) 评论(0) 推荐(0)

Oracle-SQL-优化：NULL 空值优化

摘要：在Oracle、PostgreSQL（PG）和MySQL中，NULL值是否被索引取决于数据库类型、索引类型及具体设计。以下是综合分析： 📊 1. Oracle 的 NULL 值索引规则单列索引：若列包含 NULL，默认不记录到B树索引中（即 WHERE col IS NULL 无法走索引）13 阅读全文

posted @ 2025-07-18 17:05 xibuhaohao 阅读(18) 评论(0) 推荐(0)

MySQL-SQL-优化：in 、not in 、exists 、not exists 都优化改写为join 形式

摘要：以下是在商超环境（商品表 products，销售表 sales）中，将 IN、NOT IN、EXISTS、NOT EXISTS 优化改写为 JOIN 形式的完整方案，包含空值处理和验证测试： 1 优化改写方案汇总表 1.1 join汇总原查询类型改写方案空值处理执行计划优化性能对比 IN 内连接阅读全文

posted @ 2025-07-18 16:08 xibuhaohao 阅读(8) 评论(0) 推荐(0)

MySQL-SQL-优化：子查询 in 改写为 join

摘要：1 结论 select ... from a where a.id in (select b.id from b)；这种SQL，如果要改成表关联，不是select distinct .... from a,b where a.id=b.id; 两者是不等价的（除非b.id 是主键或唯一值）。等价阅读全文

posted @ 2025-07-18 15:55 xibuhaohao 阅读(6) 评论(0) 推荐(0)

MySQL 字符集：MySQL 的字符集继承规则

posted @ 2025-07-17 09:42 xibuhaohao 阅读(13) 评论(0) 推荐(0)

TPC-H PG vs MySQL

摘要：1 2 下载 https://gitcode.com/gh_mirrors/pg/pg_tpch 阅读全文

posted @ 2025-03-18 17:00 xibuhaohao 阅读(5) 评论(0) 推荐(0)

TPC-C PG vs MySQL

摘要：1 TPC-C测试简介 1.1 测试场景与目标‌ ‌基准测试‌‌场景类型‌‌核心目标‌‌典型事务复杂度‌ ‌TPC-B‌ OLTP（简单事务）衡量系统每秒处理简单事务的吞吐量，不模拟真实业务逻辑‌ 事务由简单 SQL 构成（如插入、更新混合操作）‌ ‌TPC-C‌ OLTP（复杂事务）模拟真实批阅读全文

posted @ 2025-03-18 10:26 xibuhaohao 阅读(36) 评论(0) 推荐(0)

MySQL-SQL遇到元数据锁或行锁时，等待时间不计入SQL的执行时间

摘要：问题提出在 MySQL 5.7 中，如果一条 UPDATE 语句因等待行级锁阻塞了 5 秒后成功执行，但未记录到慢查询日志中（假设 long_query_time 设置为 1 秒），该现象是可能存在的。其根本原因在于慢查询日志的触发机制和锁等待时间是否计入执行时间阅读全文

posted @ 2025-03-06 17:34 xibuhaohao 阅读(85) 评论(0) 推荐(0)

文章分类 - DB-MySQL

公告