Go语言技术文章
-
本文用一套可复用工作流讲清 MySQL 深分页优化：先识别 OFFSET 大扫描，再选择游标翻页、延迟关联和覆盖索引，最后用执行计划和响应耗时验证结果。429 收藏 -
Redis6.2+需用--cluster参数运行redis-benchmark，否则MOVED/ASK重定向导致QPS归零；低版本需手动固定槽位或升级。428 收藏 -
allkeys-random并非真正无差别：它只在内存达限且写入触发时，从永不过期的主字典key中伪随机删除，不考虑访问频次、大小或热度，易误删热图；应改用allkeys-lru或ZSET+定时清理。427 收藏 -
LFU频率计数器非线性增长，由lfu-log-factor和lfu-decay-time共同调控：访问按概率递增且增幅随当前值增大而衰减，初始值为5、上限255；衰减每lfu-decay-time分钟执行一次右移1位。424 收藏 -
Redis卡顿是设计使然，因其单线程模型下Lua脚本原子独占主线程，执行长耗时操作会阻塞所有请求，包括过期、AOF、心跳等；复杂聚合应迁出至应用层。424 收藏 -
XREADGROUP能自动负载均衡，因Redis服务端按轮询策略将新消息分发给组内不同消费者，确保同条消息仅投递一次；未ACK消息超时后可被其他消费者XCLAIM接管，实现故障转移。424 收藏 -
RedisCluster故障转移由主节点失联且多数主节点投票确认触发；从节点需满足复制偏移量达标、获多数主节点投票才能当选新主。423 收藏 -
dump.rdb文件越积越多是因为Redis默认不自动清理旧快照，每次bgsave生成新文件但保留旧文件，需依赖外部脚本按时间戳安全清理。422 收藏 -
数据库 · MySQL | 3星期前 | 性能优化 · 执行计划 · 生产实践 · MySQL教程 · 数据库运维 · mysql 直方图 EXPLAIN ANALYZE Histogram 优化器统计信息
从 MySQL 8.4 直方图统计信息入手，讲清数据分布倾斜如何影响优化器行数估算，以及如何创建、验证和回滚 histogram。419 收藏 -
必须分片，因单keyGEOADD底层ZSET会导致查询O(logN+M)延迟、RDB/AOFfork超时、无法水平扩展；应按Geohash前4-5位分key，查时用邻区算法并发查最多9个key并合并去重排序。418 收藏 -
Redis6.0+的Pub/Sub不阻塞主线程，因消息分发改由独立客户端上下文异步处理；而5.x及更早版本中publish同步遍历订阅者，网络慢或缓冲区满时会阻塞主线程。417 收藏 -
直接调大save触发阈值是最有效、最安全的手段，通过修改redis.conf中save配置项（如将save6010000改为save30050000），可降低RDB快照频率，缓解磁盘IO压力，但需结合数据丢失容忍度与写入节奏合理设置。417 收藏 -
cluster-node-timeout合理值需根据网络P95延迟×2～3倍设定，局域网常见5000～8000ms，跨机房12000～15000ms，容器环境不低于8000ms；须全节点一致，CONFIGSET仅内存生效，持久化需改配置文件并重启；扩缩容前应临时调大，且tcp-keepalive需配合设置。417 收藏 -
RedisPub/Sub不支持自动消息压缩，因PUBLISH内容直写输出缓冲区，绕过LZF等内存压缩逻辑；需客户端自行压缩/解压，并统一算法；高频短消息推荐LZ4/Snappy；长期应改用Stream替代。415 收藏 -
MySQL中常见的Join类型包括INNERJOIN、LEFTJOIN、RIGHTJOIN和CROSSJOIN，INNERJOIN性能最佳。INNERJOIN返回两表匹配行，LEFTJOIN返回左表全部记录，RIGHTJOIN返回右表全部记录，CROSSJOIN返回笛卡尔积。Join查询慢的原因主要有：缺少索引导致全表扫描、字段类型不一致无法使用索引、表数据量过大、Join层级或字段过多、驱动表选择不合理。优化方法包括：1.为Join字段加索引，尤其是主键和外键；2.控制Join规模，提前过滤减少数据量；414 收藏