-
MySQL通过CREATEUSER和DROPUSER创建删除用户，2.使用GRANT和REVOKE授予权限与撤销权限，3.用SHOWGRANTS查看权限，4.执行FLUSHPRIVILEGES刷新权限，5.注意限制访问来源并定期审查账户以提升安全性。
-
优化GROUPBY性能的核心在于减少扫描数据量、合理使用索引并避免多余操作。1.优先让GROUPBY字段有索引，确保最左前缀匹配且覆盖WHERE条件，以跳过排序和临时表；2.避免在GROUPBY中使用函数或表达式，改用生成列加索引提升效率；3.只保留必要字段并用WHERE预过滤数据，减少分组规模；4.拆分复杂分组逻辑，用子查询或应用层合并结果，降低单条SQL复杂度。设计时考虑周全能有效避免后期调优被动。
-
在mac上安装MySQL时，可能会遇到以下问题：1.MySQL服务无法启动，可能是由于端口冲突或权限问题。2.无法连接到MySQL服务器，可能是防火墙设置或配置文件错误导致。3.安装包下载失败，可能是网络或官方服务器问题。4.密码设置问题，新安装的MySQL可能有默认密码设置或无法修改密码。
-
安全重启Redis集群的正确做法是逐个节点操作，优先处理从节点，严格等待redis-cli--clustercheck返回OK后再进行下一轮，避免脑裂、槽位丢失和连接雪崩。
-
slowlog是Redis唯一实时捕获慢命令的机制，为内存环形缓冲区，仅记录执行耗时超阈值的命令，不包含网络延迟与排队时间；默认阈值10ms，建议调至5ms，slowlog-max-len建议设为1024，并需CONFIGREWRITE持久化。
-
后台线程异步刷新热Key本质是“逻辑过期+守护任务”组合，由应用层实现定期扫描预判并更新热点数据，需嵌逻辑过期时间于value中、合理设扫描频率与范围，并加分布式锁、失败重试及错峰调度。
-
通过redis-cli、RedisInsight、Prometheus和Grafana等工具，以及关注内存使用率、连接数、集群节点状态、数据一致性和性能指标，可以有效监控Redis集群的健康状态。
-
典型现象是Redis从节点反复断连，日志出现“Clientclosedconnectionduetooutputbufferlimit”，INFOreplication中状态在connect→sync→disconnected循环；主节点因输出缓冲区超限（默认slave256MB/64MB/60s）主动断开连接。
-
配置RedisSentinel高可用集群需要以下步骤：1.配置Sentinel节点，使用sentinelmonitor指令监控主节点；2.设置主从节点，确保从节点能自动接管；3.确保网络稳定性，避免误判；4.至少配置三个Sentinel节点保证高可用性；5.谨慎配置故障转移策略，设置超时时间；6.确保数据一致性，通过配置min-slaves-to-write和min-slaves-max-lag减少数据丢失风险；7.调整sentineldown-after-milliseconds参数减少不必要的故障转移
-
用iptables模拟Redis哨兵网络分区需双向封禁节点间通信（INPUT+OUTPUT），匹配6379/26379端口，确保Quorum计算失效；恢复时须精准删除规则而非清空链，避免锁死服务器。
-
allkeys-random策略在内存超限时随机删除任意key，适合一致性要求低的缓存场景；需先配置maxmemory，且不区分key是否设过期时间。
-
sentinelmonitor三要素（master-name、IP、port）必须准确，缺一不可，否则哨兵无法发现主从拓扑；quorum是触发投票的最小同意数，非哨兵总数；密码需三端一致（requirepass/masterauth/auth-pass），ACL还需配置masteruser；down-after-milliseconds宜设3000–5000ms防误判；启动前须确保主从就绪，否则从节点被误标sdown。
-
reshard搬的是Slot而非Key，先重分配16384个Slot，再由集群自动触发Key迁移；需待“Allkeystransferred”提示才完成，且新节点须完成注册、握手、身份确认三步并满足网络与配置要求。
-
Redis主从切换后连接池未刷新导致请求超时或Connectionrefused，因Jedis/Lettuce默认不自动感知拓扑变更；需手动重建连接池或使用Lettuce6.0+内置重连机制。
-
Redis布隆过滤器不支持动态扩容，BF.RESERVE设定的capacity和error_rate不可修改；扩容需手动迁移数据并切换key，参数选错易致内存激增或OOM。
