选redis还是memcache,源码怎么说?
memcache和redis是互联网分层架构中,最常用的KV缓存。不少同学在选型的时候会纠结,到底是选择memcache还是redis。画外音:不鼓励粗暴的实践,例如“memcache提供的功能是redis提供的功能的子集,不用想太多,选redis准没错”。虽然redis比memcache更晚出来,
进程内缓存,究竟怎么玩?
除了常见的redis/memcache等进程外缓存服务,缓存还有一种常见的玩法,进程内缓存。什么是进程内缓存?答:将一些数据缓存在站点,或者服务的进程内,这就是进程内缓存。进程内缓存的实现载体,最简单的,可以是一个带锁的Map。又或者,可以使用第三方库,例如leveldb。进程内缓存能存储啥?答:r
InnoDB,能将数据存储在DVD里?
MySQL5.6,应该实现在最流行的版本吧?很遗憾有一些功能一直没有,例如:哈希索引T-tree索引原生高可用auto-sharding...画外音:你最希望看到支持什么特性?但,5.6版本中,InnoDB有些有意思的特性,或许是大伙还不清楚的。1.从这个版本开始,可以支持全文索引了。2.alter
InnoDB,5项最佳实践,知其所以然?
缓存讲了一个月《缓存架构,一篇足够》。今天,开始写数据库。第一篇,说说MySQL两个最常用的存储引擎,MyISAM和InnoDB。照自己的理解,把一些知识点总结出来,不只说知识点,多讲“为什么”。一、关于count(*)知识点:MyISAM会直接存储总行数,InnoDB则不会,需要按行扫描。潜台词是
MySQL不为人知的主键与唯一索引约束
今天和大家简单聊聊MySQL的约束主键与唯一索引约束:PRIMARYKEYandUNIQUEIndexConstraints文章不长,保证有收获。触发约束检测的时机:insertupdate当检测到违反约束时,不同存储引擎的处理动作是不一样的。如果存储引擎支持事务,SQL会自动回滚。例子:creat
超赞,InnoDB调试死锁的方法!
近期写了不少InnoDB锁相关的文章,不少小伙伴问,如何在MySQL终端模拟并发事务,如何复现之前文章中的案例。今天,咱们一起动起手来,模拟并发事务的互斥与死锁。【事前准备】安装MySQL服务端安装MySQL客户端安装能够模拟多个并发事务的终端画外音:楼主使用的是MySQL5.6,官方客户端mysq
别废话,各种SQL到底加了什么锁?
这个月花了一些功夫写InnoDB:并发控制,MVCC,索引,锁...有朋友留言:你TM讲了这么多,锁分了这么多类型,又和事务隔离级别相关,又和索引相关,究竟能不能直接告诉我,一个SQL到底加了什么锁!?我竟无言以对。好吧,做过简单梳理之后,今天尝试着直接回答,尽量做到不重不漏,各种SQL语句究竟加了
4种事务的隔离级别,InnoDB如何巧妙实现?
事务ACID特性,其中I代表隔离性(Isolation)。什么是事务的隔离性?隔离性是指,多个用户的并发事务访问同一个数据库时,一个用户的事务不应该被其他用户的事务干扰,多个并发事务之间要相互隔离。一个事务怎么会干扰其他事务呢?咱们举例子来说明,假设有InnoDB表:t(idPK,name);表中有
InnoDB,select为啥会阻塞insert?
MySQL的InnoDB的细粒度行锁,是它最吸引人的特性之一。但是,如《InnoDB,5项最佳实践》所述,如果查询没有命中索引,也将退化为表锁。InnoDB的细粒度锁,是实现在索引记录上的。一,InnoDB的索引InnoDB的索引有两类索引,聚集索引(ClusteredIndex)与普通索引(Sec
InnoDB并发插入,居然使用意向锁?
《插入InnoDB自增列,居然是表级别锁?》介绍了InnoDB所使用的七种锁中的一种,自增锁。今天,将要介绍InnoDB另外三种:共享/排他锁,意向锁,插入意向锁。一,共享/排它锁(SharedandExclusiveLocks)《InnoDB并发为何这么高?》一文介绍了通用的共享/排它锁,在Inn
插入InnoDB自增列,居然是表锁?
《挖坑,InnoDB的七种锁》初步说明了InnoDB中,会使用七种不同类型的锁,今天就介绍其中的第一种,自增锁(Auto-incLocks)。一,案例说明MySQL,InnoDB,默认的隔离级别(RR),假设有数据表:t(idAUTO_INCREMENT,name);数据表中有数据:1,shenji
InnoDB,快照读,在RR和RC下有何差异?
昨天挖了一个坑《InnoDB的快照读,到底和什么相关?》,今天来填坑。为了保证文章知识体系的完整性,先简单解释下快照读,读提交,可重复读。快照读(SnapshotRead)MySQL数据库,InnoDB存储引擎,为了提高并发,使用MVCC机制,在并发事务时,通过读取数据行的历史数据版本,不加锁,来提
InnoDB并发如此高,原因竟然在这?
《InnoDB行锁,如何锁住一条不存在的记录?》埋了一个坑,没想到评论反响剧烈,大家都希望深挖下去。原计划写写InnoDB的锁结束这个case,既然呼声这么高,干脆全盘系统性的写写InnoDB的并发控制,锁,事务模型好了。体系相对宏大,一篇肯定写不完,容我娓娓道来,通俗地说清楚来龙去脉。一、并发控制
1分钟了解MyISAM与InnoDB的索引差异
《数据库索引,到底是什么做的?》介绍了B+树,它是一种非常适合用来做数据库索引的数据结构:(1)很适合磁盘存储,能够充分利用局部性原理,磁盘预读;(2)很低的树高度,能够存储大量数据;(3)索引本身占用的内存很小;(4)能够很好的支持单点查询,范围查询,有序性查询;数据库的索引分为主键索引(Prim
数据库索引,到底是什么做的?
近期写数据库,不少朋友留言问MySQL索引底层的实现,今天简单聊一聊,少讲“是怎么样”,更多说说“为什么设计成这样”。问题1.数据库为什么要设计索引?图书馆存了1000W本图书,要从中找到《架构师之路》,一本本查,要查到什么时候去?于是,图书管理员设计了一套规则:(1)一楼放历史类,二楼放文学类,三
58到家MySQL军规升级版
一、基础规范表存储引擎必须使用InnoDB表字符集默认使用utf8,必要时候使用utf8mb4解读:(1)通用,无乱码风险,汉字3字节,英文1字节(2)utf8mb4是utf8的超集,有存储4字节例如表情符号时,使用它禁止使用存储过程,视图,触发器,Event解读:(1)对数据库性能影响较大,互联网
“同起点,同终点,打车价格不同”秒懂
前几天被一条消息刷屏了,据说还上了新闻联播:相同起点,相同终点的两个手机打车,价格不一样。去年也有新闻引起过激烈的讨论:相同的起点,相同终点的两个用户买飞机票,机票价格不一样。今天接着用通俗的语言说说此类“个性化价格”是如何实现的。方式一:“用户分级”对用户进行分级,不同类型的用户会有不同的补贴,定
1分钟了解相似性推荐
前几天聊的“协同过滤(CollaborativeFiltering)”和“基于内容的推荐(Content-basedRecommendation)”,都必须分析用户的历史行为数据(例如电影点击数据,职位查看数据等),针对不同的用户进行个性化推荐。如果系统没有用户的历史行为数据积累,如何实施推荐呢?今
3分钟了解“关联规则”推荐
“把啤酒放在尿布旁,有助于提升啤酒销售量”是关联规则推荐的经典案例,今天,和大家聊聊“关联规则推荐”,正文不含任何公式,保证PM弄懂。一、概念什么是关联规则(AssociationRules)?答:关联规则是数据挖掘中的概念,通过分析数据,找到数据之间的关联。电商中经常用来分析购买物品之间的相关性,
1分钟了解基于内容的推荐,pm又懂了
前天的《1分钟了解“协同过滤”》,很多同学点了赞,今天接着用通俗的语言说说“基于内容的推荐”,也保证pm弄懂。什么是基于内容的推荐(Content-basedRecommendation)?答:通过用户历史感兴趣的信息,抽象信息内容共性,根据内容共性推荐其他信息。比如,如何通过基于内容的推荐,来对求