首页
AI Coding
数据标注
NEW
沸点
课程
直播
活动
APP
插件
搜索历史
清空
创作者中心
写文章
发沸点
写笔记
写代码
草稿箱
创作灵感
查看更多
登录
注册
确定删除此收藏集吗
删除后此收藏集将被移除
取消
确定删除
确定删除此文章吗
删除后此文章将被从当前收藏集中移除
取消
确定删除
编辑收藏集
名称:
描述:
0
/100
公开
当其他人关注此收藏集后不可再更改为隐私
隐私
仅自己可见此收藏集
取消
确定
数据库
订阅
落风雪
更多收藏集
微信扫码分享
微信
新浪微博
QQ
14篇文章 · 0订阅
宕机了,Redis 如何避免数据丢失?
如果有人问你:"你会把 Redis 用在什么业务场景下?" 我想你大概率会说:"我会把它当作缓存使用,因为它把后端数据库中的数据存储在内存中,然后直接从内存中读取数据,响应速度会非常快。"
避免回表,引入索引下推|提高索引命中率 | 提前下班啦
为什么这么设计索引 如果你仔细阅读了上一部分,那么你一定知道为什么数据库索引采用的是B+Tree, 说白了就是为了提高查询效率。因为只有B+Tree
图解Redis的主从同步原理
Redis为了保证服务高可用,其中一种实现就是主从模式,即一个Redis服务端作为主节点,若干个Redis服务端作为主节点的从节点,从而实现即使某个服务端不可用时,也不会影响Redis服务的正常使用
详细分析MySQL中的三大日志
本篇文章讨论的MySQL中的三大日志,指用于数据恢复的redo log,用于事务回滚的undo log,以及用于数据恢复和主从同步的binlog
select for update加了行锁还是表锁?
大家,我是田螺。 最近在开发需求的时候,用到了select......for update。在代码评审的时候,一位同事说 ,唯一索引+一个非索引字段,是否可能会锁全表呢?本文田螺哥将通过9个实验证明
索引数据结构千千万 , 为什么B+Tree独领风骚
索引的由来 大数据时代谁掌握了数据就是掌握了流量,就是掌握的号召力。面对浩瀚的数据如何存储并非难事, 难点在于如何在大数据面前查询依旧快如闪电! 这
刨根问底 Redis, 面试过程真好使
充满寒气的互联网如何在面试中脱颖而出,平时积累很重要,八股文更不能少!下面带来的这篇 Redis 问答希望能够在你的 offer 上增添一把🔥
三个经典的MySQL问题
大家好,今天给大家上3个经典的MySQL问题,希望能对大家有帮助!但是因为笔者计算机水平有限,可能会存在一些错误,烦请指出、斧正!谢谢!
select for update是行锁还是表锁,还真得看情况
背景 看到许多写select for update是行锁还是表锁的文章,但每篇文章的结论好像都不太一样。同时,是行锁还是表锁的问题直接影响着系统的性能,所以特意为大家调研一番,也就有了本篇文章,一共为
🔥我说MySQL每张表最好不超过2000万数据,面试官让我回去等通知?
面试官:麻烦你好好看看这篇文章,再告诉我,每张表到底能存多少数据? 实际情况下,每张表由于自身的字段不同、字段所占用的空间不同等原因,它们在最佳性能下可以存放的数据量也就不同,需要手动计算才行。