记录 PT-Online-Schema-Change 在线优化内存碎片失败 , 大表生产优化方案
1.2亿数据量 , 删除到2w条后
异步的修复内存碎片失败 , 最后只能使用老办法 , rename table 了
执行方案如下 :
- 对外公告维护
- 关闭所有写入脚本和接口
- 确认待维护表无新增数据
- rename table
table_nametonew_table_name
这一步非常快 就算有非常大的数据量更换也只用了1秒不到 - 导出从库中的
table_name表记录, 在主库创建 新的table_name,新创建表 子增ID + 10w 保证ID 唯一 , insert 从库数据.
为什么不使用 INSERT INTO table_name SELECT * FROM new_table_name ?
因为执行太慢了, 在维护公告之前 我就已经测试了 上面的 sql 执行时间 , 非常的漫长 还搞不定. 维护时间肯定不能等那么久. 所以采用上面的老方案 替换表从库导入.
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 Leon！
相关推荐
2025-06-03
MySQL 索引区分度（Cardinality）详解及优化实践
在 MySQL 中，索引是否有效，不仅取决于是否存在索引，还要看这个索引是否具有高区分度（Cardinality），也就是它能否快速筛选出目标数据。 本文将介绍什么是索引区分度、如何查看与分析它，以及在实际工作中如何应用这一概念来优化索引设计。 📌 什么是索引区分度？索引区分度是指： 索引列中不重复的值的数量 与 表中总记录数 的比例。 ✅ 区分度高： 唯一性强 查询效率高 MySQL 更倾向于使用该索引 ❌ 区分度低： 重复值多（例如 gender, status 等字段） 索引过滤效果差 MySQL 可能会选择全表扫描 🔢 公式：索引区分度（选择性） = COUNT(DISTINCT column) / COUNT(*) 数值越接近 1，表示索引区分度越高，效果越好。 🧪 查看索引区分度方法一：通过 SHOW INDEXSHOW INDEX FROM table_name; 重点字段： 字段名含义Key_name索引名称Seq_in_index在联合索引中的字段顺序Column_name字段名Cardinality估算的不同值的数量（即区分度） ...
2024-09-22
[转载] MySQL为什么”错误”选择代价更大的索引
原文地址 : MySQL为什么”错误”选择代价更大的索引 1. 问题描述群友提出问题，表里有两个列c1、c2，分别为INT、VARCHAR类型，且分别创建了unique key。 SQL查询的条件是 WHERE c1 = ? AND c2 = ?，用EXPLAIN查看执行计划，发现优化器优先选择了VARCHAR类型的c2列索引。 他表示很不理解，难道不应该选择看起来代价更小的INT类型的c1列吗？ 2. 问题复现创建测试表t1： [root@yejr.run]> CREATE TABLE `t1` ( `c1` int NOT NULL AUTO_INCREMENT, `c2` int unsigned NOT NULL, `c3` varchar(20) NOT NULL, `c4` varchar(20) NOT NULL, PRIMARY KEY (`c1`), UNIQUE KEY `k3` (`c3`), UNIQUE KEY `k2` (`c2`)) ENGINE=InnoDB; 利用 mysql_random_data_load 写入一万行...
2015-09-01
Mysql 强制使用索引
在 MySQL 中，你可以使用 FORCE INDEX 或 USE INDEX 关键字来强制查询优化器使用特定的索引。 FORCE INDEX在 MySQL 中，你可以使用 FORCE INDEX 或 USE INDEX` 关键字来强制查询优化器使用特定的索引。 FORCE INDEX 关键字用于强制 MySQL 使用指定的索引。你可以在 SELECT 语句中使用它，如下所示： SELECT * FROM your_table FORCE INDEX (index_name); 这将导致 MySQL 忽略查询优化器的选择，而强制使用名为 index_name 的索引来执行查询。请将 your_table 替换为你的表名，index_name 替换为你想要强制使用的索引的名称。 另一种方式是使用 USE INDEX 关键字，它类似于 FORCE INDEX，但允许MySQL在给定的索引之间进行选择。你可以在 SELECT 语句中使用它，如下所示： SELECT * FROM your_table USE INDEX (index_name); 这将告诉 MySQL 在可能的...
2018-04-01
Mysql 解除正在死锁方法
今天线下测试 for update 结果把 测试机mysql 锁了 上网找了篇文章 亲测可用 # 查询是否锁表 mysql> show OPEN TABLES where In_use > 0; +-----------------+------------+--------+-------------+ | Database | Table | In_use | Name_locked | +-----------------+------------+--------+-------------+ | xx_trade_xx | trust | 47 | 0 | | xx_trade_xx | user_xx | 3 | 0 | +-----------------+------------+--------+-------------+ 找到了 user_xx 锁了三...
2026-04-12
事务隔离级别深度解析：PostgreSQL vs MySQL
事务隔离级别是数据库并发控制的核心概念，直接影响系统的数据一致性与并发性能。SQL 标准（SQL-92）定义了四种隔离级别，但 PostgreSQL 和 MySQL（InnoDB）在实现细节上存在显著差异，理解这些差异是写出正确、高效 SQL 的关键。 一、并发问题：为什么需要隔离级别？在多事务并发执行时，可能出现以下四类问题： 1. 脏读（Dirty Read）事务 A 读取了事务 B 尚未提交的数据。若 B 回滚，A 读到的就是”幻觉数据”。 -- 事务 B（未提交）UPDATE accounts SET balance = 9999 WHERE id = 1;-- 事务 A（脏读）SELECT balance FROM accounts WHERE id = 1; -- 读到 9999（B 未提交） 2. 不可重复读（Non-Repeatable Read）事务 A 两次读取同一行，期间事务 B 修改并提交了该行，导致两次结果不同。 -- 事务 A 第一次读SELECT balance FROM accounts WHERE id = 1; -- 1000-- ...
2025-05-30
PHP 报错 “Error while sending STMT_PREPARE packet” 故障分析与排查经验
🧩 问题背景在某日凌晨，线上服务的 PHP 日志中频繁出现如下报错： \[01-May-2024 06:07:27 Asia/Shanghai] PHP Warning: Error while sending STMT\_PREPARE packet. PID=26439 该错误由 mysqli->prepare() 方法抛出，影响到了部分数据库相关的服务逻辑。 📌 初步分析方向根据历史经验和网上资料，造成该错误的可能性较多，主要包括： MySQL 连接超时 数据库连接数过多 max_allowed_packet 配置过小 wait_timeout 超时断开连接 网络波动 数据库崩溃或 mysqld 崩溃重启 PHP 连接实例未关闭或未重连 🧪 运维排查流程（DBA 配合）运维同学按以下顺序排查和调整配置： ✅ 检查并调整 MySQL 参数： max_allowed_packet增大至 64M，防止 SQL 包体积过大造成 STMT_PREPARE 失败。 wait_timeout 和 interactive_timeout从默认 28800 秒（8...
评论
