-
数据库 · MySQL | 5天前 | 高并发 · 故障排查 · MySQL教程 · 事务隔离 · InnoDB锁 · mysql innodb 高并发 锁等待 MySQL 8.4 NOWAIT SKIP LOCKED
围绕高并发工单抢占和库存预占，讲清 MySQL 8.x InnoDB locking read 中 NOWAIT、SKIP LOCKED 的适用边界、复现方法、SQL 改写、锁等待诊断和上线检查。439 收藏 -
直接看INFOclients的qbuf、qbuf-free、obl、oll、omem字段可判断单个客户端流量压力：qbuf高说明命令积压，omem>2MB或qbuf>1MB且持续高位表明高频写入或返回大数据；CLIENTLIST才能定位具体异常客户端，需重点关注qbuf与omem同时偏高、idle小但qbuf大的连接。438 收藏 -
RedisLua脚本原生不支持复杂正则匹配，仅提供基础模式匹配（如%d+），不支持\d、(?i)、.*?、分组捕获等；禁止动态加载外部库（如lrexlib-pcre）；推荐在客户端处理或使用RediSearch的FT.SEARCHREGEX。438 收藏 -
数据库 · MySQL | 5天前 | binlog · 故障恢复 · 备份恢复 · MySQL教程 · DBA实战 · mysql DBA binlog 备份恢复 mysqlbinlog MySQL 8.4 PITR
从误删订单数据的恢复演练切入，讲清 MySQL 8.x 完整备份、binlog 保留、mysqlbinlog 按时间点/位置回放、校验与上线检查。432 收藏 -
allkeys-random并非真正无差别：它只在内存达限且写入触发时，从永不过期的主字典key中伪随机删除，不考虑访问频次、大小或热度，易误删热图；应改用allkeys-lru或ZSET+定时清理。427 收藏 -
XREADGROUP能自动负载均衡，因Redis服务端按轮询策略将新消息分发给组内不同消费者，确保同条消息仅投递一次；未ACK消息超时后可被其他消费者XCLAIM接管，实现故障转移。424 收藏 -
数据库 · MySQL | 1星期前 | 性能优化 · 执行计划 · 生产实践 · MySQL教程 · 数据库运维 · mysql 直方图 EXPLAIN ANALYZE Histogram 优化器统计信息
从 MySQL 8.4 直方图统计信息入手，讲清数据分布倾斜如何影响优化器行数估算，以及如何创建、验证和回滚 histogram。419 收藏 -
直接调大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 收藏 -
Redis6.0多线程不加速命令执行，仅I/O多线程+pipeline组合可提升导入效率；需客户端用pipeline打包发送，且主线程不饱和时才有效。406 收藏 -
Redis连接空闲后收不到数据主因是防火墙/NAT静默丢包，须主从节点均配置tcp-keepalive300并重启生效；该参数控制空闲300秒后发首探，不读取内核参数，需ss-tnp验证timer列是否显示keepalive。403 收藏 -
volatile-lru不适合社交关系链，因其仅淘汰带过期时间的key，而关系数据作为主数据映射不应设TTL；强行加EXPIRE会引发雪崩与CPU升高；allkeys-lfu更匹配二八流量特征，配合调大maxmemory-samples和合理配置LFU衰减可提升淘汰精准度。403 收藏
