敏捷灰度--select 代替 update、delete的灰度策略

本文介绍了一种灰度发布的策略,并通过实例演示了如何在微服务系统中实施此策略以减少因代码更新导致的问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

        本文讲述的是一种灰度策略,在讲灰度策略之前,先说一下线上数据库的delete,update操作。

程序员删除线上数据时运行以下示例语句:

        delete from table where id=xxx and name=’xxx’;

        如果忘记加where条件或者where条件少了一个and或者or,将会删除很多数据。

        稍微有经验的程序员,会分两步操作:

        1. select * from table where id=xxx andname=’xxx’; 观察满足删除条件的数据情况

        2.用“delete”替换第一点语句的“select*”

        第一点可以理解为“灰度发布观察”,第二点可以理解为“全量发布”。

        那么接下来讲的就是在微服务中实现上面思路的灰度发布。


        举个例子:

        
       某个微服务系统中,要对A表添加一个uid字段,插入数据时填写上uid数据,update数据时where再加上“uid=xxx”的条件。系统的服务杂性,无法预料到插入的uid和update的uid是否一致,如果存在大量不一致,将导致大量数据无法被update更新,引起大面积报障。

        
       该改造要上线,就是要先摸清不一致的情况有多少。

       按以下步骤上线:

       1.      线上数据表增加uid字段

       2.      上线程序,上线的程序有insert uid的功能,update逻辑先不加上uid=xxx的过滤条件。再加多几行程序,程序执行”select * from table where condition=yyy and uid=xxx”,当返回的结果集为0时,打印日志并且上报到统计系统中,通过日志或者统计系统监控将要update的影响记录条数。

       3.      第二点灰度观察一天,正常无误后把”select * from table where condition=yyy and uid=xxx”的执行语句去掉,再到原来的update语句加上uid=xxx,再上线灰度一台服务器

       4.      第三点的一台服务器灰度一天无误后,再继续灰度其他机器。

 

 

        
<think>嗯,用户现在问的是MySQL的不可见索引(invisible index)。让我先回忆一下相关的知识。不可见索引是MySQL 8.0引入的新特性,允许将索引设置为对优化器不可见,但实际索引结构仍然存在。这样可以在不删除索引的情况下测试删除索引后的性能影响,或者临时禁用某些索引。 用户可能的需求是什么?他们可能遇到了性能问题,想测试删除某个索引是否有效,但又不确定,所以想用不可见索引来暂时关闭,观察效果。或者他们在维护数据库时,需要暂时禁用某个索引,但不想重建索引,这时候不可见索引就很有用。 接下来要考虑用户的身份。很可能是数据库管理员或开发人员,负责优化数据库性能。他们可能已经对索引有一定的了解,但需要更高级的功能来处理特定场景。 需要详细解释不可见索引的定义、作用、使用场景、如何操作以及注意事项。同时,用户可能需要具体的SQL示例来实际操作,比如如何创建、修改索引的可见性,如何查看状态等。 另外,用户可能会关心不可见索引和删除索引的区别,以及使用时的限制,比如主键索引不能设置为不可见,或者如何评估影响后再决定是否删除。这些点都需要在回答中涵盖,确保信息全面。 还要注意检查是否有遗漏的细节,比如版本要求,必须是MySQL 8.0以上,这对用户来说可能是一个前提条件,如果他们的版本较低,可能需要先升级。这也是需要注意的地方,避免用户在不支持的版本中使用该特性。 最后,要结构清晰,分点说明,让用户能够一步步理解,并且提供验证方法,确保他们能正确应用这些操作。同时,常见问题部分可以预先解答用户可能遇到的疑问,比如为什么优化器仍然使用不可见索引,或者如何处理权限问题等。</think>以下是对MySQL不可见索引(Invisible Index)的详细介绍: --- ### 一、不可见索引的定义 MySQL 8.0+ 新增特性,允许将索引标记为"对优化器不可见": - 索引物理结构仍然存在 - 查询优化器会忽略该索引 - 支持动态切换可见性(无需重建表) --- ### 二、核心作用 1. **安全测试**:临时禁用索引观察性能变化,验证索引是否有必要存在 2. **灰度验证**:在不影响生产查询的情况下测试索引删除的后果 3. **平滑迁移**:分阶段禁用索引,避免一次性删除导致性能抖动 4. **调试工具**:诊断优化器是否误用某些索引 --- ### 三、使用场景示例 | 场景 | 传统方式 | 不可见索引方案 | |------|----------|----------------| | 验证索引必要性 | 删除索引 → 性能下降需重建 | 设为不可见 → 可快速恢复 | | 多索引调优 | 需要反复删除/重建索引 | 动态切换可见性测试 | | 索引维护 | 维护期间需停用索引 | 临时设为不可见,维护后恢复 | --- ### 四、操作命令 #### 1. 创建不可见索引 ```sql -- 新建索引时直接指定 CREATE INDEX idx_name ON table(col) INVISIBLE; -- 修改现有索引 ALTER TABLE table ALTER INDEX idx_name INVISIBLE; ``` #### 2. 查看索引状态 ```sql SHOW INDEX FROM table_name; /* 输出示例: | Key_name | Visible | |----------|---------| | idx_col | NO | */ ``` #### 3. 切换可见性 ```sql -- 设为可见 ALTER TABLE table ALTER INDEX idx_name VISIBLE; -- 设为不可见 ALTER TABLE table ALTER INDEX idx_name INVISIBLE; ``` --- ### 五、重要注意事项 1. **主键限制**:主键索引(PRIMARY KEY)不能设为不可见 2. **唯一约束**:唯一索引(UNIQUE)设为不可见后,仍会强制唯一性约束 3. **DDL操作**: ```sql -- 重建表会保留不可见状态 OPTIMIZE TABLE table_name; -- 导出导入时需注意: mysqldump 默认包含所有索引 ``` 4. **性能影响**: - 写操作仍需维护不可见索引(INSERT/UPDATE/DELETE- 磁盘空间不会被释放 --- ### 六、效果验证方法 1. **执行计划检查**: ```sql EXPLAIN SELECT * FROM table WHERE col = 'value'; -- 确认未使用不可见索引 ``` 2. **性能对比**: ```bash # 测试不可见状态查询耗时 time mysql -e "SELECT ..." # 切换为可见后重复测试 ``` 3. **监控指标**: - QPS(Queries Per Second) - 慢查询数量 - 锁等待时间 --- ### 七、与删除索引的对比 | 特性 | 不可见索引 | 删除索引 | |-------------------|------------|----------| | 物理存储 | 保留 | 释放 | | 维护成本 | 需要 | 不需要 | | 恢复速度 | 即时 | 需重建 | | 唯一约束 | 保留 | 移除 | | 对优化器的影响 | 完全忽略 | 不存在 | --- ### 八、最佳实践建议 1. **生命周期管理**: - 新索引创建后,可先设为不可见进行验证 - 旧索引废弃前,先设为不可见观察1-2个业务周期 2. **组合策略**: ```sql -- 禁用旧索引并创建新索引 ALTER TABLE t ALTER INDEX old_idx INVISIBLE, ADD INDEX new_idx (col) VISIBLE; ``` 3. **监控指标**: ```sql -- 通过performance_schema跟踪 SELECT * FROM performance_schema.table_io_waits_summary_by_index_usage WHERE OBJECT_SCHEMA = 'db_name' AND OBJECT_NAME = 'table_name'; ``` --- ### 九、常见问题解答 **Q1:为什么优化器仍然使用了不可见索引?** A:检查是否启用了`use_invisible_indexes`优化器开关: ```sql SELECT @@optimizer_switch; -- 若包含use_invisible_indexes=on,需关闭: SET optimizer_switch='use_invisible_indexes=off'; ``` **Q2:如何批量管理不可见索引?** ```sql -- 生成修改语句 SELECT CONCAT('ALTER TABLE ', table_name, ' ALTER INDEX ', index_name, ' INVISIBLE;') AS sql_statement FROM information_schema.statistics WHERE is_visible = 'NO'; ``` **Q3:权限要求是什么?** - 需要`INDEX`权限(对ALTER TABLE操作) - 需要`SELECT`权限(对performance_schema查询) --- 通过合理使用不可见索引,可以在保证数据完整性的前提下,更安全高效地进行索引优化工作。建议结合业务负载特征制定索引管理策略
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值