Go语言技术文章
-
数据库 · MySQL | 1个月前 | binlog · 故障恢复 · 备份恢复 · MySQL教程 · DBA实战 · mysql DBA binlog 备份恢复 mysqlbinlog MySQL 8.4 PITR
从误删订单数据的恢复演练切入，讲清 MySQL 8.x 完整备份、binlog 保留、mysqlbinlog 按时间点/位置回放、校验与上线检查。432 收藏 -
RedisPub/Sub不直接产生内存碎片，但未清理的订阅连接、消息积压或缓冲区配置不当会推高used_memory_rss，导致mem_fragmentation_ratio偏高，形成“假性碎片”；真实碎片源于键值对频繁增删改，而Pub/Sub缓冲区不受active-defrag影响。430 收藏 -
CLUSTERKEYSLOT仅执行CRC16(key)mod16384计算，返回0–16383的槽号，不查询集群拓扑或节点信息；定位具体实例需配合CLUSTERSLOTS或CLUSTERNODES查找槽所属节点。429 收藏 -
通过转账场景复现 MySQL InnoDB 死锁，演示如何查看死锁信息、理解反向加锁原因，并用固定加锁顺序、缩短事务和重试机制降低问题概率。429 收藏 -
本文用一套可复用工作流讲清 MySQL 深分页优化：先识别 OFFSET 大扫描，再选择游标翻页、延迟关联和覆盖索引，最后用执行计划和响应耗时验证结果。429 收藏 -
Redis6.2+需用--cluster参数运行redis-benchmark，否则MOVED/ASK重定向导致QPS归零；低版本需手动固定槽位或升级。428 收藏 -
allkeys-random并非真正无差别：它只在内存达限且写入触发时，从永不过期的主字典key中伪随机删除，不考虑访问频次、大小或热度，易误删热图；应改用allkeys-lru或ZSET+定时清理。427 收藏 -
XREADGROUP能自动负载均衡，因Redis服务端按轮询策略将新消息分发给组内不同消费者，确保同条消息仅投递一次；未ACK消息超时后可被其他消费者XCLAIM接管，实现故障转移。424 收藏 -
数据库 · MySQL | 1个月前 | 性能优化 · 执行计划 · 生产实践 · MySQL教程 · 数据库运维 · mysql 直方图 EXPLAIN ANALYZE Histogram 优化器统计信息
从 MySQL 8.4 直方图统计信息入手，讲清数据分布倾斜如何影响优化器行数估算，以及如何创建、验证和回滚 histogram。419 收藏 -
必须分片，因单keyGEOADD底层ZSET会导致查询O(logN+M)延迟、RDB/AOFfork超时、无法水平扩展；应按Geohash前4-5位分key，查时用邻区算法并发查最多9个key并合并去重排序。418 收藏 -
直接调大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 收藏 -
Pub/Sub是无存储的实时广播机制，消息断连即丢，适合允许丢失的在线通知；Stream是带ACK的持久化消息队列，支持回溯、消费者组和精确控制，但需手动管理XACK与MAXLEN。412 收藏