哈希游戏- 哈希游戏平台- 哈希游戏官方网站

　　Redis Cluster 将所有数据划分为 16384 个 slots(槽位)，每个节点负责其中一部分槽位。槽位的信息存储于每个节点中。当 Redis Cluster 的客户端来连接集群时，它也会得到一份集群的槽位配置信息并将其缓存在客户端本地。这样当客户端要查找某个 key 时，可以直接定位到目标节点。同时因为槽位的信息可能会存在客户端与服务器不一致的情况，还需要纠正机制来实现槽位信息的校验调整。

　　经过分析操作记录如下： 1.10.8号加的delete语句：delete from alpha_aging_product_info_no_degrade_v2 where create_time 2022-10-19 00:00:00; 主从延迟小于30分钟，可接受 2.10.18号添加了一个组合索引（仓+地址） 3.10.18号delete表数据的时候，导致主从延迟慢。根本原因：因为上面的sql增加了索引加剧了主从延迟，如果 delete 的数据是大量的数据，则会：1.如果不加 limit 由于需要更新大量数据，从而索引失效变成全扫描导致锁表，同时由于修改大量的索引，产生大量的日志，导致这个更新会有很长时间，锁表锁很长时间，期间这个表无法处理线.由于产生了大量 binlog 导致主从同步压力变大。3.由于标记删除产生了大量的存储碎片。由于 MySQL 是按页加载数据，这些存储碎片不仅大量增加了随机读取的次数，并且让页命中率降低，导致页交换增多。改进点：1.由于该数据库只为promise给路由推数不降级数据使用，数据库只有增加操作，故可让大数据抽主库 2.truncate table（VtDriver驱动是不支持truncate语法），truncate操作需要慎用，需要根据业务场景评估。 truncate表都是高危操作，特别是在生产环境要更加小心，下面列出几点注意事项，希望大家使用时可以做下参考。 1.truncate无法通过binlog回滚。 2.truncate会清空所有数据且执行速度很快。 3.truncate不能对有外键约束引用的表使用。 4.执行truncate需要drop权限，不建议给账号drop权限。 5.执行truncate前一定要再三检查确认，最好提前备份下表数据。思考点：1. MySQL单表记录数过大，思考是否一定要用MYSQL？比如JDQ数据传输等 2.当MySQL单表记录数过大时，增删改查性能都会急剧下降，任何的sql操作都不能根据常规思维去操作（比如加字段，加索引，删除语句，Select查询语句等） 3.XBP的SQL审批工单添加备注：表记录数，比如同一个sql 表数据10万和1千万是不一样的。

　　解决方案： 1）首先本地缓存是一方面，但没有从根源解决。 2）如果某个关键被确认为热点，一个简单方法在关键字开头或者结尾添加一个随机数（比如两位数），这样就可以将关键字分布到100个不同的关键字上，从而分配到不同的分区上。比如上面key对应改造为 promise:xxx:yyy:zzz:01 ...... promise:xxx:yyy:zzz:50 ...... promise:xxx:yyy:zzz:99